If you're not into Emacs, I suggest you give it a whirl. For most development, nothing else will get you close to the joy and productivity that a well configured Emacs can.
Well, that's the real issue for me. I spent a month an a half working on "configuring" NeoVim. I got it to a somewhat ready to use state for my usual workflows. But I still had a big pile of tasks in my backlog to actually get it finally 100% mine.
Then I discovered Helix, which doesn't need any configuration, no plugins to play around with. Builtin LSP, Builtin Fuzzy Finding of files, TreeSitter and the list goes on.
Even though it's still not fully checking all the boxes I need to have a 1 to 1 mapping of my previous workflows to what Helix offers. I find not having to build my own editor out of the Lego pieces and always needing to improve what it can offer me, makes the editor actually enjoyable.
IMO, VIM, NeoVIM and Emacs should start looking into implementing a bit more than just the barebones, some of these new features that people are accustomed to in 2023, and more and more will flock to these good editors.
Personally I much prefer that the editor NOT ship with something like that by default, especially when it's so easy to set up. I have several different vim config I use, including a pretty bare-bones one for headless systems, and I much prefer the ability to customize something very specifically.
Build tools that can compose together, rather than a single do-it-all tool. That is the power of the low level editors vs IDE's.
Helix is different from Lunar in the sense that the features it comes with are part of the core editor and the editor still feeling like an editor
Maybe 2 lines, if you otherwise would not use company-mode.
1 line requiring lsp-mode.
1 line setting lsp diagnostics provider.
1 line adding lsp mode to python-mode-hook.
2 lines enabling the linter (if you want that) (I use flake8).
2 lines for setting an additional shortcut.
23 completely optional lines for marking some variables from .dir-locals as accepted/safe.
1 optional line for changing the color of the breadcrumbs header line.
Approximately 2/3 of a page, including all optional config I have.
But I hadn't touched my config for three years before that! I've been using Emacs for 15 years and you definitely get to a point where you don't need to tweak it every day. 3 years is the kind of time some people would switch to a completely new editor. I have, in a way, except it still supports all the workflows that have become familiar over the years.
And those 5 tools would likely beat Emacs in their individual area.
At the end it's all a tradeoff between low fringe with somewhat good enough performance, or high fringe for stellar performance. Sometimes you need it, sometimes not.
"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.
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
Seems potentially workable. Youd just jump back to the last buffer a lot of time, but that's quick and intuitivr.
Ex: In Magit when committing it now first shows a "changes" buffer that you have to kill and then you can get to the buffer where you write the commit message. Not a biggie but prolly breaks the original UI design
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.
(setq magit-display-buffer-function 'magit-display-buffer-fullframe-status-topleft-v1)
(setq magit-bury-buffer-function 'magit-restore-window-configuration)
(add-to-list 'display-buffer-alist
'("\\*Magit*\\*"
(display-buffer-reuse-window display-buffer-in-direction
(direction . bottom)
(window . root)
(inhibit-same-window . t)))*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.
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
- 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.
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).
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.