Magit is probably the easiest one for casual devs to appreciate.

"M-x magit" get a nice list of the status of the files in the current branch.

After you mark which ones you want to keep by moving up and down pressing s(tage) u(nstage) you just press "c c" and write your commit message. Then you press P and your git repo is up to date.

At a previous job the head engineer flagged the number of commits I was making as an issue since I must be wasting a lot of time pushing incremental changes. When I showed him that it took me about as long to push changes to my branch as it did to save the file he was flabbergasted that one could use git without pain.

> "M-x magit" get a nice list of the status of the files in the current branch.

Except it will randomly split your frame and show up in a seemingly arbitrary location - often obscuring what you're working on. I find the whole layout system in Emacs completely chaotic. I guess it comes with the flexibility (VS a fixed system like most Ides) nor do I have any particular solution in mind

I'm curious if anyone has tamed the weird inconsistencies of how new frames (or is it windows? Can never keep the terms straight) pop up. For instance a CIDER error buffer shows up using some completely different black magic than magit

For magit, I like having it display full screen (deleting other windows), and then on quitting restore to the windows/splits I had before:

     (setq magit-display-buffer-function 'magit-display-buffer-fullframe-status-topleft-v1)
     (setq magit-bury-buffer-function 'magit-restore-window-configuration)

For more general display-buffer tweaks, OP has a whole article on it https://www.masteringemacs.org/article/demystifying-emacs-wi... (though for display-buffer I just stick to the defaults myself, never tried CIDER)

This thread is on the "Mastering Emacs" book and from its author, on the topic of mastering Emacs window managements you can read this:

https://www.masteringemacs.org/article/demystifying-emacs-wi...

To be honest I've never played with this part of Emacs. The way I use it I'm fine with the default. But if not it's possible to take control of Emacs internal windows management.

I have my Emacs setup to never split anything and just use the whole frame (window). That also goes for things like helm. Instead of splitting I prefer to open multiple frames and let my window manager, manage them. This really improved my workflow.

Same here, but I let most things replace the current buffer. Magit always fills the frame though.

How do I go about doing this ?

Seems potentially workable. Youd just jump back to the last buffer a lot of time, but that's quick and intuitivr.

(setq display-buffer-base-action '(display-buffer-same-window))

thank you !

There is definitely a system to it. Something like "split at the longest side of the current window" or so. I have developed a feeling for where my magit buffer will show up. 95% of the time I am right and my eyeballs already move where it will appear. Anyway, if you want to get rid of some window/undo a split: C-x 0.

Add something like this?

    (add-to-list 'display-buffer-alist
          '("\\*Magit*\\*"
            (display-buffer-reuse-window display-buffer-in-direction
            (direction . bottom)
            (window . root)
            (inhibit-same-window . t)))*

I would say magit as an example. Single key presses for most actions. I often have that situation, when I share my screen and perform some commits and then people ask me whether I already commited X. I then think something like: "Uh, but I just did that, in front of your eyes." but then I remember the other workflow involving the normal command line or some clicky-gui kind of tool, that is just slower and is what others are used to.

Then maybe keyboard macros. Define anything you can input in a "tiling" way on your keyboard as a macro to let the editor perform it repeatedly. Approximate quote from coworker: "Sometimes you do things inconveniently, but what you do in Emacs was highly efficient."

Then running vterm inside emacs and searching and copying from the vterm buffers to use text elsewhere.

Of course org-mode as an extremely neat way of managing information and to do. I use it every day, a lot. I use it for notes, for to-do, for time tracking, for literate programming, for devops, for creative writing, and probably more.

Then the pain I get, when I see people closing their vscode, just to reopen it in another directory ...

Then the pain I see others have, when juggling a high number of editor tabs in intellij or vscode, instead of buffers that exist and can be switched to using keyboard shortcuts. I lost faith in tabs for code editors.

> Then the pain I get, when I see people closing their vscode, just to reopen it in another directory > Then the pain I see others have, when juggling a high number of editor tabs in intellij or vscode, instead of buffers that exist and can be switched to using keyboard shortcuts. I lost faith in tabs for code editors.

That my biggest beef with VScode and IntelliJ. Why on earth I can’t have multiple projects open and switch between them as fast as in Emacs / Vim with Tmux Other than that I could somewhat live with modern editor, but I’m switching constantly between 5 different projects and VSCode solution to have single workspace makes navigation an awful experience

- Open a jira request backport in https://github.com/ahungry/org-jira

- Check to see that there isnt an MR outstanding bysomeone else ( using https://github.com/isamert/lab.el )

- (Optional) Cherry pick the commit from another stream where it may be fixed (magit-cherry-pick)

- Often massage the code (emacs cedet)

- Commit the code (magit)

- Submit a build (local built in code, elisp calling a local binary)

- Tag the build as the correct type (magit)

- Update the jira status (org-jira again)

- Wait for testing to complete, watch (eww)

- Email the requester on test results (wanderlust)

I also use:

- Some slack client for emacs (i dont remember the name)

- slime connected to nyxt brower so that I can automate some of the garbage that requires javascript.

Can you share details of your experience with org-jira? My question would be: Is it feature complete? Does it allow one to do everything one can do in browser Jira? Set custom fields, handle multiple boards and so on?

> Is it feature complete?

Its enough for me to complete my day to day work.

>Does it allow one to do everything one can do in browser Jira?

I dont think it can do the dashboards and reporting metrics, but for the 'issue' work yes.

> Set custom fields

Yes. Although i had to maintain a map of custom field names to what they actually were, or you'd see cf_023042432 as the name.

> handle multiple boards

I don't use jira this way to know what it means, is that the same as multiple project prefixes (if so yes, i dont know what boards are).

In addition things other people have mentioned, like magit, I would add org-capture as a good example. Let's say I'm busy at work in a buffer and a thought comes to mind: "I could refactor that other module using this code". Instead of doing it immediately and breaking my flow, I press C-c c, select "todo", type "refactor that other module", perhaps add a tag, a category etc. then C-c C-c and it's filed away.

What's really important about all of this is, it's all Emacs. Every magit buffer, every org-capture buffer, it's all just Emacs buffers and they're all configured the way you like. If you need to do a regexp find and replace while you're capturing a note, you can. If you make a typo in a note, in a commit message, in an email or anything else, it's spell checked and you can correct it with the same key you always do. This integration is the real magic.

In this particular example, I was documenting my investigation into a defect. I was jotting down notes in Org-mode (1. note-taker). Those notes included SQL scripts which evaluate directly in the note-file (2. ejc-sql / replacing dbbeaver), letting the next user see which result I got from the queries and the ability to re-run the queries (C-c C-c). Some of the results returned large jsonb blobs, which were made readable with M-x json-prettify (3. replacing some online json prettifier). The git stuff (branching, making a pull request, updating it) was handled using Magit/forge (replacing git/lazygit). And ofc the code-editing replaces (5) whatever IDE you could otherwise use.