It's great that the Emacs team sees the need for more modern defaults. Emacs's great power, of course, is its ability to change to fit the user. But many new-comers are, I think, turned off by its rather basic default state. Thrusting every user into Emacs Lisp, while educational, does not hold the new user's hand very well.
I agree. Although the flexibility of configuration is nice, it's sometimes I big turn-off. Personally, I've had a time where loved to configure Vim and Emacs (I've used both extensively). These days I'm using Sublime because I'm overwhelmed and couldn't find the right Emacs plugin equivalent.
By the way, I was using Emacs with vim-mode, obviously ;-)
There was a couple things. In no particular order:
- I never got to have The syntax / Auto-complete / Smart-indent working flawlessly. Sometimes pressing enter would just screw all the indent.. at one point I was so tired that I just deactivated everything and had a "notepad" feeling where I preferred to do everything manually then some plugin just magically alter things I didn't want.
- Quick jump between files never really work as I wanted it. Yes there are some ultra-amazing plugins that do ultra-amazing fuzzy-matching and auto-complete things but all I wanted was a very fast fuzzy-matching goto file/symbol like in Vim/Sublime. I just never got that working. By using a couple of very good Emacs plugin, I almost got it.. but it was very funky with dozen of hacks.
- Copy/Pasting was kinda funky between emacs/terminal/chrome (On Archlinux/Stumpwm). I almost got it to work but for some reasons sometimes it just didn't work. Copy/Pasting is such a basic feature.. when this is not working it's really frustrating. Sometimes I had to copy from emacs, paste in chrome url-bar, re-select it, and then paste it in the terminal.. else it wouldn't work and would just erase my buffer.
- The vim plugin was great but it wasn't well integrated with the overall Emacs workflow (Obviously). In sublime, since the Vim-mode is provided by default (mostly), plugin creators pay particular attention.
- Mixing Html / Javascript / Templating never really worked flawlessly.
So, as you probably noticed, I'm saying flawlessly a lot.. I got much things to work good-enough, but I was tired of them not just working as I wanted it and to fight an eternal battle with spaghetti emacs-lisp code. Whereas with Sublime, yes you have less freedom, but things are overall better integrated and "just work" as I expected them to.
Hopefully people don't take this as a rant. I'd recommend every hackers to give a fair try to both Emacs and Vim. I guess also what happened is that I have less and less time to code with the startups I'm involved with.. so the few hours I have really need to be productive, I can't spend 1-2 hours tweaking the configuration because some buggy indenting plugin is screwing with me.
- I think indentation is one of the things emacs does best tbh.
- For jumping between files, did you try ido-mode?
- Evil in emacs is very well integrated if you're into vim emulation. You can just do package-install evil.
- I don't use html/javascript so I can imagine issues with conflicting major modes or less than ideal minor modes.
I'll be honest, your struggles to me seem somewhat strange but glad you seem to have found something that works for you. Everybody has different requirements. For me, the ability to write lisp to add whatever I want is a huge win (it's really the only reason why I settled on Emacs + Evil over vanilla vim). It's when you code in languages like Haskell or Macaulay that you really start to see Emacs shine.
I really like where Emacs is going recently. The speed with which new features move upstream has increased. There is a push by some developers for git to make contributions easier and even some progress towards modernizing or replacing good ol' info. That makes me confident that GNU Emacs is going to be around and that the eco-system is going to stay healthy for some time.
This is what I was alluding to but just because someone is working on something in an open source project doesn't mean it is ever going to happen. Particularly something as controversial as switching to another VCS. If you don't think this is controversial I encourage you to try it yourself with some project that is dear to you.
It's also evident if you go through any big project's mailing list in the past few years and search for git/mercurial/svn/cvs/dvcs or the like. I followed Pidgin's devel mailing list for a while. For some reason, when they switched away from SVN several years ago they switched to a very niche DVCS called monotone which, among other oddities, had such a large data format/slow clone process that they had a tarball of the database for download that you had to then use to initialize your local checkout, because actually cloning the database the normal way would take too long. I assume they chose it due to some core developers' familiarity with it or something. Later, they eventually realized this was a huge barrier to entry for new developers and there was a protracted discussion/flame war about the replacement. One guy in particular, felipec, seemed to spend days writing up long detailed posts about how hg was inferior to git, which were more or less factual, but written in a snarky/condescending tone, and the core developers never took him seriously and made it clear that his input was not welcome. It's kind of funny, that guy ended up writing a bunch of hg to git interoperability scripts ostensibly for the sake of proving git's superiority, and those are now included in git-contrib.
So, yeah, (D)VCS choice is probably a bigger holy war than editor, and getting a project to switch is quite nontrivial. Especially a lot of the projects you'd want to switch away from some poor DVCS, because they often stick to it for some non-technical reason (eg. bzr seems to be largely a GNU thing).
Reading info is fantastic, I agree. But writing it is a traumatic experience. There are also no converters to info from many of the common markdown derivatives. You cannot even reliably generate it from in-source Emacs Lisp comments which doubles the maintenance effort for most elisp code.
This is also less about the tools themselves but the mind-share they have. FOSS projects need a steady flow of new contributors to replace old ones and to get new steam. Switching to tools that are more likely to be known by a younger generation of programmers makes this easier. This applies to the git migration as well.
texinfo is pretty nice. Many GNU projects use this for their manuals. That way you can create a printed manual, an HTML manual, and an info manual from the same source.
>You cannot even reliably generate it from in-source Emacs Lisp comments which doubles the maintenance effort for most elisp code.
Good code comments do not make a good manual. A manual needs to do much more. I don't really believe in generating docs from docstrings in source code. I am surprised that you can't bootstrap a manual with the docstrings, though. That's unfortunate. I was able to do so rather easily with Guile.
I think that this new generation of programmers (which I am included in) should learn that Markdown is inadequate for large documents.
Oh, and I am in full support of the git migration.
Emacs' indentation system is notoriously difficult to configure, so it's good to see some work being done in that area. However, the particular point described in the article is less exciting. I think every serious Emacs user who wants this behavior (binding RET to newline-and-indent) has it set up this way already anyway.
Some may consider it a good default behavior (though a matter of taste) for some modes (such as, e.g., programming language modes) but not for others (e.g. text-mode). The default behavior so far has been "no automatic indent" while now it will be "automatic indent". But since it will still be necessary for the user to maintain a list of modes s/he wants it enabled it for, therefore this change is really not such a big deal.
IMHO, the most pressing issue with indentation in Emacs is to make it easy for the user to adapt it, and especially to adjust certain edge cases. Given the mode-centered architecture of Emacs, this is a big challenge. But questions about very specific indentation preferences pop up on sites like stackoverflow all the time: people want to be able to say "I want a continuation of a line be indented by four spaces, except when the line break is in the middle of the argument list of a function definition -- then the arguments should all indent to the same column."
Coming up with a configurable indentation system that works for every mode would be very cool and thought-after feature.
used by tuareg-mode and sml-mode (AFAIK) with good results. I never used it personally but I felt it should be mentioned if someone else wants to dig into it.
The bounce indenter in Steve Yegge's js2-mode is an interesting approach:
For any given line, there are some obvious possible indentation points:
- whatever position Karl's guesser wants to use
- the beginning of the line
- after the '=' if the previous line is an assignment
- same indentation as the previous line
- first preceding line with less indentation than the preceding line
[...]the TAB key cycles among them.
It takes a lot of the frustration out of the indenter getting it wrong; in practice this doesn't cycle around tab points as much as you'd think.
And then there's cc-guess.el, which guesses your preferred indentation style by examining the current file. It would be soooooo nice if these ideas were available across all modes.
Most of the time you should use C-j to insert a new line, not RET. If you press ctrl with your left hand and j with your right it is much more efficient than RET because you dont have to move your hands from the home row.
Maybe it depends on how big your hands are, but reaching RET doesn't require a move off home for me?
Although it does use a pinkie, it's a nice hand-opening gesture, like when playing piano. As opposed to the left-pinkie hand-scrunching gestures that give some folks trouble.
Perhaps it does. I can't press RET while my three other fingertips rests on j, k, l. But I can press Ctrl (or Caps-Lock which I've remapped) comfortably with resting fingers on s, d, f.
I've completely moved on to C-m instead of RET and C-h instead of Backspace. I did this after feeling some stress on my right pinky (it would twitch involuntary when I laid in bed after a long coding day,) on which occasion I also switched from Dvorak to Programmer Dvorak (sharing the load from typing square brackets and curly braces among other fingers.) My left pinky, on the other hand, didn't suffer much because Caps Lock was already remapped to Ctrl.
same here, I eventually realised that I needed better clojure integration (read: better plugins) and that what I enjoyed most about vim was its navigation and editing keys. evil-mode is the best of both worlds
Why do people like auto-indentation? It's just extra work undoing it when it decides I need indents when I don't, plus the mental overhead of "will it autoindent here?" all the time. Pasting is the worst, especially when it decides that as some config starts with a comment, it should turn it all into comments.
:set formatoptions-=ro and :set noautoindent are the first lines in my vimrc.
