Earlier quoted context omitted.
And with Vim in it.
...and with emacs listed twice.
OK, new rule: Nobody makes a poll about text editors anymore.
131–140 of 163 posts
Earlier quoted context omitted.
And in the same way that a car includes many control interfaces but is not itself a control interface, a program that contains text editors is not itself a text editor.
Well, Emacs isn't a text editor then.
Earlier quoted context omitted.
...and to "other cli" just as well ;-)
I wouldn't have said so. Even ignoring the fact that it's a GUI app, it's also mouse driven. And the "CLI" aspect of Acme is really just a novel way of implementing shortcuts and macros, but since those functions are non-interactive, it's not really behaving like a command line. At risk of nitpcking, I think the "other CLI" option should have read "other console based" (that is, unless they were expecting people to a…
But re:"other cli" I agree: even ed counts as console-based, not CLI (which would be sed, cat, maybe awk and echo... not fun, but of course real programmers use butterflies)
Out of interesting (OS X Users) - Emacs or Aquamacs?
I consider Aquamacs's stated goal to be a worthy goal, but Aquamacs does not actually change Emacs's behavior to be more like an ordinary GUI app in situations I care about.
For example, in Emacs, if you use the pointing device to select an extent of text then hit the right (left) arrow key, the selection is increased in size by one character to the right (left). In contrast, the vast majority of GUI apps on Windows, OS X and Linux inactivate the selection leaving the insertion point at the right (left) edge of where the selection was (and you can get the behavior that Emacs uses by modifying the right-arrow key press with the shift key). Aquamacs chose the Emacs way of behaving here.
In summary, most of the choices Aquamacs made for when to do things the Emacs way and when to do them the standard GUI way differ from the choice I would have made.
P.S. In the situation examined above, the behavior of Acme (tested on plan9port on OS X) also differs from standard GUI behavior, but in a way different from how Emacs differs: Acme inactivates the selection, but then moves the insertion point one character to the right of the right edge of where the insertion point was, which makes some sort of internal logical sense (if the selection is considered to be a sort of insertion point that has temporarily stretched to be n characters wide) but is a poor design decision for Acme users that have to switch back and forth between Acme and other GUI apps.
jEdit. I'm surprised nobody seems to be using it considering how powerful it is. I have tried many editors over the years and SublimeText is the first one that comes close to it; but jEdit still has much better search functionality, especially in 'hypersearch' mode.
If you can still change the options, please change Vi to Vim, as I'm sure most of the people voting for it actually mean Vim.
Well, vi is the editor I use 2nd most (after Emacs), but I use nvi nearly as often as I use vim, and I avoid the vim extensions (except the useful :help). I imagine changing vi to vim would be a bit like changing Emacs to GNU Emacs.
For the pure editing of text, Vim is the clear winner. Whether that's all you want, is another question.
If only working with multiple files was easier... what are you guys using these days ? [edit] Also, one thing that shows how Vim is oriented towards opening and closing it all time is that preventing acidental quitting is quite hard to achieve (only with hacks..)