What is your favorite text editor?

Although I can not confirm this
Perhaps you do not pay attention to the new "features" and get used to them fast, so that you do not need to turn them off.

The turning off begins with the building:

configure --prefix=XXX --without-all --with-x-toolkit=no
 
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.
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.

If you do opt to select "Create user" towards the end of the installer (rather than doing it post install), then pager and editor could be specified along with shell. However these aren't global defaults. This is what the skel files are for.
 
Yes, very useful for ascii art and such.

But in general, not necessary for the default editor, and very rarely used otherwise.
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. I use rectangular cut and paste from time to time. My problem with emacs:
... lots of files in the output of ldd
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.

And: One man's bloat is another man's functionality. For every library that emacs uses, there is a good reason, namely some functionality of emacs that needs that library. For example, on my machine emacs is linked against libz ... that's because it can edit (read and write) compressed files directly. Some person found this to be convenient functionality.

And the size of the executable and the shared library make little difference. Programs being executed are demand paged, and shared libraries are loaded only on demand and shared among all processes (thence the name). So the size of the executable and the number of shared libraries matters little to performance.

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.
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.

The second question is that emacs seems to be seeing active development, so changes and new functionality will show up. If you don't like that, you'll have to compile your own version from frozen source code.

And I used it in machines with few ram. I suspect, this is bloat. Is it not?
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.
 
So the size of the executable and the number of shared libraries matters little to performance.
After it is loaded. But if it fills the whole ram, it does matter. :)

Do you see how fast sam and acme start? They are also a GUI editors.

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.

BTW. I had to edit with ed some big files that emacs was unable to deal with.
 
After it is loaded. But if it fills the whole ram, it does matter. :)
Only the pages that have instructions that are actually executed get loaded.

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 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.

Do you see how fast sam and acme start? They are also a GUI editors.
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.

BTW. I had to edit with ed some big files that emacs was unable to deal with.
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.)
 
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.)
Yes, slow loading, I think I had also other problems. It was many years ago and with a computer of 2000.

BTW, sam is a good alternative to the standard editor (ed):


But the "best editor" is a question of custom. Sometimes I am unable to name key combinations that
I continuously type in emacs, it is like a reflex action.

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, is happy using it on a VT100, and
much more happy with vi or emacs. But even that seems too difficult for people that never tasted
the teletype or the punching card machines. It must be easy editor.
 
block marking mode

Whilst seeking the manual page for something in mfsBSD I stumbled across:

LEeditors/le

cc5fa2f87bb45412e50b321028150e3d_medium.jpg


Interesting, but I couldn't get it to work (and I'm not seeking help).

To anyone who previously mentioned LE: sorry, XenForo disallows seeking things such as this.

plan9ports from ports

devel/plan9port
 
… Who wrote with a typewriter on paper, is happy punching cards.

I taught myself first on an Underwood – manual, not electric, probably a No. 5.

An Oliver No. 15 helped me to improve the rhythm and coordination of keystrokes:

1632891182561.png

Who punched cards, is happy with a line editor on a teletype.

I vaguely recall doing so.

Who used a line editor on a teletype, …


I used one much like that in my first full-time job.

For terminal-based edition, I prefer nano.
 
I vaguely recall doing so.
If you do an error punching a card, you throw it away and write the line in a new card. With the typewriter
you must write the whole page again, not only a line. The teletype is an improvement, because the storage
is not a sheet of paper or a card, you can modify its state with commands, but still you waste paper, and
the way of interacting with it is not very comfortable. Using the same line editor on a terminal you do
not waste paper. Then came more comfortable editors for terminals and graphical displays. But we
will be never happy.
 
I use nvi I have to edit a lot of stuff ("power editing").
I 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.

If they are more comfortable is more a subjective issue. As said before, it depends also on custom. These
Plan9 programs are mouse-oriented, acme works only on a graphical terminal, sam can be used as a more
powerful ed in a normal terminal, but the taste of ed remains. And I do not like the background colours,
I want a white background.

Analogous is the preference of ee over vi. Probably is vi more powerful than ee, but people find ee more
comfortable.
 
... But we will be never happy.
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.

I can change the terminal background color to any color I wish. Each terminal has unlimited scrollback, so if I want to use the mouse, I can just cat any 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.

Screenshot at 2021-09-29 04-31-10.png
 
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 an editor for a terminal, but still line oriented as one for a teletype.
The apparently more primitive sam is superior.
 
vi is an editor for a terminal, but still line oriented as one for a teletype.
The apparently more primitive sam is superior.
"vi is a screen-oriented text editor. ex is a line-oriented text editor." ~ vi(1)

If you feel sam is superior that's fine. I'm happy enough with vi, not trying to pass judgment on what's "superior."
 
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.

Once tablets seriously evolve from being stupid toys, I really do hope we see Acme get revived. I think it will work very well on a touch environment (possibly the only editor I have seen that can actually leverage touch?). The idea of putting repeat commands, pipes and filters within the window frame itself is actually perfect for tablets (where typing is not a strong point).

Acme could also be a really good candidate for VR. Again, where the keyboard is not a first class citizen but instead some sort of pointing device is.
 
I 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.
That may be but long before sam was available outside of Bell Labs, the vi command 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.

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.

The discussion of how powerful an editor is, is in part nonsense. They are limited programs, the only
purpose is to write or modify comfortably a text. Emacs is an exception, contains a whole scripting
language, a from the beginning bad implemented LISP.

I think today everyone can very fast implement his own scriptable editor in the way he means is
comfortable. A scripting language give the building blocks. The text widget in Tk is for example
a ready primitive editor that can be completed with some tcl procedures.
 
For those of us who are unfamiliar:

"[Acme] was influenced by Oberon"

Ah, Oberon, fond memories. A beautifully simple language. Blindingly fast compilation speed.

And the System with a tiled GUI, interclicks, multiple entry point applications. I don't remember any shell or command interpreter.


And it was possible to run the whole thing from a 1.44Mbyte floppy.
 
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.
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!

Been through too many editor "discussions" to care much about which editor is more powerful. Use whatever works for you as per your preferences.
 
In the terminal I use Neovim for most things and Micro for quick/simple editing. With X11 I use Geany and unrelated to FreeBSD on windows I use NotePad++. All of them are powerful editors worth checking out!
 
Back
Top