What is your favorite text editor?

No, ee not. Either ed or vi. ee is a mostly unknown editor, better to delete it from base.
Do people really use Ed? I think people can argue all day about what should and should not be in base but most of the time it is pretty insignificant. Doesn't really matter if the base has three tiny but functional editors. Removing things seems pointless most of the time, it makes sense if the program has vulnerabilities that are constantly needing attention otherwise might as well leave it alone.
 
Perhaps if we were all forced to write our code on paper first, software would be a lot more succinctly written and more terse.
I've done coding on paper. For example coding in COBOL and RPG-II, then entering the code using a card punch, and commenting the code with a felt-tip pen by writing on the cards. The code itself tends to be very terse (short variable names, no blank lines, and definitely no comments), because card punching is painful and slow. On the other hand, the real work product is not code punched on the cards, it is either the paper version, or the cards with comments. So the net effect is probably not that the writing is more terse.

Biggest problem with this technique: If you duplicate the source code deck, the comments go away.

Perhaps more optimal. How cares today on performance instead of relying in fast and faster processors?

Lots of people care very deeply about performance. Big software engineering departments and big companies have highly specialized experts who improve performance, often putting lots of effort into gains of a few percent here and there. People who spend billions (with a b) on computers tend to be very cost conscious and efficient.

Now, you might say "I don't see any of this when using bloated software on my cell phone / laptop / favorite OS, and everything is slow". Sorry, you're wrong. The software itself is probably quite efficient and well written, it was done by professionals. But: Those professionals are being driven by their user base (those evil customers) to include zillions of features, which users want. And trying to run software that can do zillions of things on undersized hardware is frustratingly slow. Try running that software on the type of hardware it was intended for, and you'll find that modern computers are amazingly fast. How many people remember compiles of 1000-line programs taking 15 minutes on a completely overloaded mainframe (500 users on a 10MIPS machine) or minicomputer (20 users on a VAX 11/780)?
 
If you know how to use ed(1), then you know how to use sed(1), and ex(1), and vi(1) in "line" mode. It's also the fundamental underlying sam.

If you don't know these things, then there is much to discover about the power and elegance of Unix, and it all starts with learning ed(1).

Even today if I have to write a script that does some sort of file modification I use ed due to portability.
Yes, ed(1) is the one universal scripting tool for in-situ editing that works with complete portability. For this reason, it should never be removed from base.
 
If you know how to use ed(1), then you know how to use sed(1), and ex(1), and vi(1) in "line" mode. It's also the fundamental underlying sam.

If you don't know these things, then there is much to discover about the power and elegance of Unix, and it all starts with learning ed(1).


Yes, ed(1) is the one universal scripting tool for in-situ editing that works with complete portability. For this reason, it should never be removed from base.
UNIX is not a religion, buddy.😩🤷‍♂️
 
Lots of people care very deeply about performance. Big software engineering departments and big companies have highly specialized experts who improve performance, often putting lots of effort into gains of a few percent here and there. People who spend billions (with a b) on computers tend to be very cost conscious and efficient.
Well, my posting was more or less irony and you knew it. "who cares today", insinuating no one, means
perhaps few, perhaps in absolute numbers lots as you say.

Who writes for example a program for resolving partial differential equations must care a lot on performance.
But programs for "normal people", like the browser I am using to write this, are mostly a bloat and I
cannot imagine that someone took much care on performance when programming it. Free Software is
a very good thing, but it is filled with bloat.
 
Let's stick to the browser example. I don't know whether there is any browser left that is written by amateurs, since I don't know who develops Opera, Firefox, and the myriad of other open source browsers. Three of the big browsers (Edge, Safari and Chrome) are developed by paid professionals, working for companies that are for profit. I'm quite sure that the three teams that develop those browsers try to make them reasonably efficient. Where "reasonably" mean: A tradeoff between functionality and size / speed. And in the few cases where I know people working on them (or at least know about them), I can assure you that faster performance and smaller size is an important design goal, and that things like performance regressions are treated like bugs and fixed. And I do occasionally eat lunch with people who do develop browsers (Silicon Valley is a small town).

Now, it is very likely that many of the features and capabilities that those engineering teams implement are things you are not personally interested in. You might call them "bloat", from your viewpoint. That is interesting, but not relevant: A big company and a big engineering team that creates a tool that has to solve billions of users has to make a compromise on what features need to be supported. That compromise is usually towards saying "yes" rather than "no", in particular in a competitive landscape. As an example, I use two browsers (Safari and Chrome) all the time on a reasonably modern computer (a 2017 MacBook Pro), and I have no performance problems, with dozens of tabs open, and typically one tab playing video (I use youtube as a classical music player). One of my colleagues typically has many hundreds to low thousands of tabs open (he uses some browser extension to manage and find tabs), and he doesn't complain about performance either. I would not call that "bloat".
 
on a reasonably modern computer
30 years ago people would have dream to have a computer as powerful as a smartphone,
they would have written wonderful programs on it.

Were the programs for computer algebra like reduce and maxima not wonderful at the time they
appeared? Based on LISP, one of the oldest high level computer programming languages? Sure there
are today similar wonders, but their number do not increase with the power of computers, a web
browser is very far away of being one.
 

Thanks. Weird, I use Code - OSS every day but could not recognise the icon of Visual Studio Code.

The icons are subtly different:

1632558385420.png


(I probably do have Visual Studio Code on Windows somewhere, can't recall when I last used it.)

Side note: Icons missing for GTK-Mixer, Firefox, Thunderbird and more • KDE Community Forums
 
And I do occasionally eat lunch with people who do develop browsers (Silicon Valley is a small town).
When I worked for SGI, I'd occasionally sit at the same table as Jim Clark, the founder, and listen in. I recall him talking about having a meeting with someone about a new internet browser. That must have been Marc Andreessen and the new browser was eventually Firefox.

Another aside. Was taking the shuttle at the airport when this guy was trying to get his box on the bus and dropped it. The guy was Ed Catmull and his box was Pixar hardware. How many here knew Pixar once made hardware?
 
Editors. Just like desktop environments, everyone has an opinion, everyone believes "their choice is best".
A big aspect of text editors to me, is "muscle keystroke memory".
I'm a vi and emacs user for a long time, sometimes I find myself doing ctrl-x ctrl-s in vi and go "why is my terminal frozen? Oh stupid me". Of course doing vi sequences in emacs also leads to fun stuff :)

vi (or variants) is pretty standard in the default install of every Unix and *nix system I've ever worked on, so even just learning the basics to modify and save changes is worth while.

switching to ee or others? Not in the default install, users can install it if they need it.
 
The installer already offers choices in a variety of areas.
No offense, but "so what?" What areas? Areas affecting the default programs installed in base?

There's enough contention/frustration around vi and ee to justify offering the choice.
Where is the contention and frustration exhibited? I have never seen anything that would justify a need to offer a choice on this, again, in my opinion. In my career I can count the number of times I've used ee to edit a file on less than a single finger. Never used it, never missed it.

I also believe it would be a slope, that would be slippery, with an increasing gradient we'd start on.
Choice of default editor in base system, then what next?

A lot of people seem to forget every shell has an environment variable called EDITOR that you set to define your default editor for a lot of things. You want it to be ee instead of vi? setenv EDITOR /usr/bin/ee in your csh/tcsh init files, set EDITOR=/usr/bin/ee; export EDITOR in your sh/bash init files.

You want to use ee from a command line? Well, simply type ee instead of vi. In at least 13.0-RELEASE ee is installed by default in /usr/bin/ee. I have never installed the port or the pkg (pkg info | grep ee does not show it on my system), so it largely boils down to your shell environment settings.
 
Where is the contention and frustration exhibited?

Here, with me. I have never got on with vi.

Additionally, there are new users to Freebsd, that do not know (or need to care) about its history, but want to use it. Vi is anything but intuitive.

If you expect Freebsd to continue to mature, be developed and the userbase to expand, it must not be exclusive.
 
The installer already offers choices in a variety of areas.
Strangely my experience is the opposite, that the installer asks barely anything. Filesystem and default services mainly.

The installer is actually so basic (which is a good thing) that I really don't believe it even needs to have a TUI interface. The OpenBSD style stdin/out questions is possibly more than enough. bsdinstall currently gives an illusion of it being more complex than it really is.

If you expect Freebsd to continue to mature, be developed and the userbase to expand, it must not be exclusive.
Now I am not saying everyone needs to learn (n)vi but there is a delicate balance. For example, if we want the userbase to expand overnight, FreeBSD could just become a Linux distro or a Windows reseller. However none of us would want to see that. Exclusivity is sometimes what keeps a higher quality of software.

Looking at the top players, I would even suggest that userbase and quality are mutually exclusive properties.

What I do think is ideal (and something FreeBSD currently does well) is prefer small, light UNIX-like software. That way we can justify having 5 small text editors in base. We could even probably fit 20 in there before the size adds up to something heavier like Vim or Emacs.
 
Well, no tragedy if it remains in base as an editor for beginners. But I think it is good to learn a little of vi
and ed, because they are in every Unix like system.

Also OpenBSD has an alternative editor in base, but perhaps not as simple as ee:


Code:
# ll /bin/ed /usr/bin/ee /usr/bin/vi
-r-xr-xr-x  2 root  wheel   57752 Jul 23  2020 /bin/ed*
-r-xr-xr-x  3 root  wheel  100840 Jul 23  2020 /usr/bin/ee*
-r-xr-xr-x  6 root  wheel  451392 Jul 23  2020 /usr/bin/vi*
# ldd /bin/ed /usr/bin/ee /usr/bin/vi
/bin/ed:
        libcrypto.so.8 => /lib/libcrypto.so.8 (0x800a00000)
        libc.so.7 => /lib/libc.so.7 (0x800e75000)
/usr/bin/ee:
        libncursesw.so.8 => /lib/libncursesw.so.8 (0x80083a000)
        libc.so.7 => /lib/libc.so.7 (0x800a99000)
/usr/bin/vi:
        libutil.so.9 => /lib/libutil.so.9 (0x80088f000)
        libncursesw.so.8 => /lib/libncursesw.so.8 (0x800aa3000)
        libc.so.7 => /lib/libc.so.7 (0x800d02000)

See also:

Code:
# ll /usr/local/plan9/bin/sam
-rwxr-xr-x  1 root  wheel  150776 Oct  4  2020 /usr/local/plan9/bin/sam*
# ldd /usr/local/plan9/bin/sam
/usr/local/plan9/bin/sam:
        libm.so.5 => /lib/libm.so.5 (0x800846000)
        libutil.so.9 => /lib/libutil.so.9 (0x800a76000)
        libthr.so.3 => /lib/libthr.so.3 (0x800c8a000)
        libc.so.7 => /lib/libc.so.7 (0x800eb2000)
 
If you expect Freebsd to continue to mature, be developed and the userbase to expand, it must not be exclusive.
Both are already installed by default.
The choice of "which is default" is up to the user, by setting EDITOR in their shell init scripts.

Why is ee any easier than vi? Simply because one of the e's stands for "easy"? If I already have vi command memory muscled, ee is not easy to me.

Is it that difficult for a user to set up their shell init scripts to have their preference?
Or if one is using a desktop environment to set the preferences to their editor of choice?
Or if you want to use ee from a command line, you need to type in ee instead of vi?
Or should vi be a symlink to ee?

grahamperrin yes, but the questions I remember relate to system setup; you are advocating for a choice in the default editor for all users, which frankly is suprising to me.

This thread is a prime example that on anything, people have preferences and alot of this thread sounds like "the system default XYZ should be MY preferred XYZ, so that I don't have to do anything special to set the default to my preference."
Which basically says "the other 50% that preferred the current default XYZ should be forced to do extra work now instead of me".

Again, I really don't care what text editor you prefer to you, both vi and ee are installed in the default installation, if you want to set your personal choice, set it in your shell environment variables just like everyone else does.
 
Back
Top