For me it isn't about editor (anything text based is very usable), it is about not cluttering up the installer. Currently it doesn't ask for default shell, default pager or default editor. Those are per user choices.I think the best solution would be to be able to choose this in the installer at the user creation stage. I mean, both vi and ee are in base (we're not talking about adding stuff) and we're likewise asked for the default shell to use, so editor choice could easily be offered at this point and everyone would be satisfied.
I disagree. It's one of the features I miss most often when using some editor that's not vim (I don't use emacs). E.g. stripping a common base path from a list of files inside a larger text document, this comes very handy. Nothing you need every day, but definitely from time to time.Yes, very useful for ascii art and such.
But in general, not necessary for the default editor, and very rarely used otherwise.
To begin with, half the list is display related stuff: All the things that start with libX are for GUI use, and I think a few others too. I don't use the X-windows version, and my executable is only 8.5 MB large (ls -lL `which emacs` -> 8501132). Is using a GUI "bloat"? That's in the eye of the beholder.Yes. I use rectangular cut and paste from time to time. My problem with emacs:
... lots of files in the output of ldd
There are two questions mixed together here. First one is startup files (the .emacs file in one's home directory, and all the files in .emacs.d that are loaded). It is indeed a problem that some OS distributions like to dump a huge amount of stuff in there; that's typically worse on Linux, in particular on distributions that have been customized for corporate in-house use. All these are things that some people find helpful, but loading them at startup slows emacs down significantly (I even notice that on large, cloud-based machines where I do much of my editing). The fix is simple: Go into those places, and delete unnecessary files, and remove unnecessary lines.Every time a new version appears, I must struggle with the configuration files in order that
it continue behaving as I know it since decades.
I run current emacs versions on a Raspberry Pi 0 (with 1/2 GiB of RAM) no problem at all. My main home server has only 3GiB of RAM, and I can do development on it without any problems. For today's environment, those are low-memory machines. I've run emacs since the late 80s, on all manners of small machines. For example, in the early 90s my desktop machine was a NeXT, which had 8 MiB of RAM, and my home machine a 386-40 running Linux on 4 MiB. I used emacs all the time, with no problems. Obviously, these machines had all manner of other problems; for example running X on a 4MiB machine without FPU was painfully slow, and the NeXT's OS had more bugs that a dog has fleas, so I eventually replaced it with a VT220 connected via serial line to a RS/6000, but lack of memory for running emacs was not an issue.And I used it in machines with few ram. I suspect, this is bloat. Is it not?
After it is loaded. But if it fills the whole ram, it does matter.So the size of the executable and the number of shared libraries matters little to performance.
Only the pages that have instructions that are actually executed get loaded.After it is loaded. But if it fills the whole ram, it does matter.
I don't think any computer exists today that has RAM anywhere near 8.5 MiB. They tend to be measured in GiB; the smallest one I know of in current production that runs a full OS would be a Raspberry Pi, and that's 1/2 GiB.And 8.5 MB is also a lot. I think, I ran emacs in a computer with so much RAM. Very few of the new
features I would miss.
I don't have a FreeBSD GUI machine, so I just tried it on my CLI machine (1 GHz Atom, 3 GiB, FreeBSD 12.x): Starting "emacs foo.txt" on an existing file is sub-second, nearly instantaneous to the human feel. No noticeable delay due to bloat here.Do you see how fast sam and acme start? They are also a GUI editors.
I regularly edit large log files with emacs, and regularly get the warning "file ... is large, really open". Log files with a tens of thousands of lines, all the time. It is a bit slow to load them, but I don't find any problems. For fun, I just tried it: A log file that's 202 MB, 1.3M lines: starts in about two seconds, and editing feels smooth. I can search backwards and forwards across the whole file, without noticeable wait. (This is the Linux version though, not on FreeBSD.)BTW. I had to edit with ed some big files that emacs was unable to deal with.
Yes, slow loading, I think I had also other problems. It was many years ago and with a computer of 2000.I regularly edit large log files with emacs, and regularly get the warning "file ... is large, really open". Log files with a tens of thousands of lines, all the time. It is a bit slow to load them, but I don't find any problems. For fun, I just tried it: A log file that's 202 MB, 1.3M lines: starts in about two seconds, and editing feels smooth. I can search backwards and forwards across the whole file, without noticeable wait. (This is the Linux version though, not on FreeBSD.)
ssh& it starts up almost instantly (in contrast
xtermto a mac takes a few seconds). I use
nviI have to edit a lot of stuff ("power editing"). For everything else I keep
acmeopen on a screen/desktop.
block marking mode
plan9ports from ports
… Who wrote with a typewriter on paper, is happy punching cards.
Who punched cards, is happy with a line editor on a teletype.
Who used a line editor on a teletype, …
If you do an error punching a card, you throw it away and write the line in a new card. With the typewriterI vaguely recall doing so.
I have only a basic knowledge of (n)vi, but I suspect, sam, and acme that has the commands of sam,I use
nviI have to edit a lot of stuff ("power editing").
I'm happy. Here's a screenshot of a typical work session, using vim with 4 Mate terminal windows open at once, on 2 monitors. The top 1440x900 monitor shows 2 terminals with 50 lines of code each, and the bottom 1366x768 laptop monitor shows 2 terminals with 40 lines each. If I need to edit more than 4 files at a time, I can use the vi "e" command within any or all of these open terminals, or just start opening additional overlapping terminal windows to my heart's content-- whichever technique I prefer to use at any given time.... But we will be never happy.
catany size file into a terminal window, and copy and paste from one window into the next. If I prefer to use the keyboard exclusively, as I often do, I can "yank" and insert any number of lines at a time with vi's "y" command, into and out of up to 26 buffers labeled "a through "z. With vim's color syntax highlighting to boot, I can type code faster than I could dictate it into a speech recognition program. I've been typing since I was 15 years old and it's second nature. If I want to write a personal letter instead of code, I can use pluma or kate. If I want to write a newsletter or other formatted document, I can use LibreOffice. What could make me happier? I find it hard to imagine any software improvements that could make me s much happier typist than I already am. I've been happy and content with these tools for years.
vi is an editor for a terminal, but still line oriented as one for a teletype.If I prefer to use the keyboard exclusively, as I often do, I can "yank" and insert any number of lines at a time with vi's "y" command, into and out of up to 26 buffers labeled "a through "z.
"vi is a screen-oriented text editor. ex is a line-oriented text editor." ~ vi(1)vi is an editor for a terminal, but still line oriented as one for a teletype.
The apparently more primitive sam is superior.
Whilst I personally prefer vi (through years of habit), sam and in particular Acme really do have some cool ideas.The apparently more primitive sam is superior.
That may be but long beforeI have only a basic knowledge of (n)vi, but I suspect, sam, and acme that has the commands of sam,
is much more powerful, just see the link to the sam tutorial I sent, also the video of Russ Cox on acme
that appears in your link.
samwas available outside of Bell Labs, the
vicommand set was already hardwired in my fingertips! So I can do things faster in vi when a lot of editing has do be done. Even something as simple as a series of redo/undo is significantly faster when you don't have to worry that the pointer doesn't walk off the undo or redo button.
Whilst I personally prefer vi (through years of habit), sam and in particular Acme really do have some cool ideas.
Even something as simple as a series of redo/undo is significantly faster when you don't have to worry that the pointer doesn't walk off the undo or redo button.
"[Acme] was influenced by Oberon"
Perhaps you should learn vi thoroughly before commenting on it? BTW, I do use acme all the time as I find both useful in different contexts. I prefer keyboard shortcuts to using a mouse but not enough to extend acme (for my personal use). The preference may be due to having used keyboards for a couple decades longer than mice based editors but there it is!Part of the power of acme is that it collaborates good with the system, with tools outside acme. The copy
and paste of the window system using the mouse can be considered part of it. To see how powerful this
is: with commands vi can, in opposition to sam in console, only copy and paste lines. Of course, we want
to use the editor also in the console where there is not that possibility.