From TECO to Neovim: 50 Years of Text Editing on Unix and Linux

Read the full article: From TECO to Neovim: 50 Years of Text Editing on Unix and Linux

Every so often, something surfaces in the LinuxCommunity.io forums that deserves a wider audience. Generally it is a question, a solved problem, or a quick tip. But occasionally a member shares something that stops you mid-scroll. A post so rich in lived experience that it feels less like a forum reply and more like a… continue reading.
7 Likes

Thanks for editing my writing and turning into an attractive article. For those of you who just aren’t quite ready for a deep excursion into GNU Emacs, Doom Emacs or even a fancy version of Neovim, I’m around and I’ve found some simple improvements (or changes that I personally considered improvements to efficient, light, simple text editors like Nano and Micro). If that’s your speed, a few of us around here can help you out and assuming I “show up” on any given day, I’d be more than happy to endorse whatever you’re using or discuss trying out a few other options.

GNU Emacs, Doom Emacs and Neovim aren’t the right choices for everyone, though all of them are excellent tools. Recently I was chatting in the forum and PyCharm was mentioned. That’s a very handy tool to use if you are deeply involved in Python coding. If that’s you, it might be perfect in those scenarios, but as big as Emacs is, running PyCharm, unless you really need it to help you with intricate details in Python code, is like asking an 18 or 19 year old Great Dane (that’s if they actually LIVE that long) to go out on a track and run a five mile race around a track! It probably won’t go very well.

That brings us to editors: the right thing to do is to find an editor that helps you get your stuff done. A Text Pad like we’re using here may be good enough to write here. Nano is good enough to write short scripts or make small changes in configuration files, and maybe even to write a small article. Anything else and it may not be the right tool, except for one thing: it is efficient, doesn’t use a lot of resources, so it can work on a system that is gasping for breath, but still works.

Micro is like that too; it’s pretty small and reasonably fast; it can be extended if you have knowledge; otherwise the name tells you enough: like Nano it can handle micro, that is, small editing tasks. Yes, it can be used all the time, but if you are editing 2,000-3,000 lines of code, it’s probably NOT the right tool for you.

That’s why we have SO MANY text editors and a lot of integrated development environments out there; they all do the job, but certain ones are ideal for a particular set of tasks and a few are really good general purpose tools worth learning, using and becoming really proficient; when you find the right one, sometimes there is no need to look any further - unless user interfaces and usability studies are of interest - which they have been for me throughout my professional career and into retirement.

One other quicky I remember about Vi and Emacs: one day I was working with some really big files, can’t remember if it was “Content Management” or something else, but it was at one of my financial organization assignments.

I think it was an implementation of Vi I was using, but I finally found a file TOO BIG to work with whatever editor I was running, so i thought to myself: great! What am I going to do now? I thought that I’d read something about GNU Emacs being smart enough to use a stack, swap, or some type of data structure capable of releasing some parts of a file, yet recovering if you needed to go back to it, so if I remembered correctly, I tried it with Emacs - yup, it took a while when I deliberately tried to jump from the front to the back of the file, but it definitely DID work, so there is at least one use case where Emacs is one of the best, if not the only, appropriate choice if you have to edit something really massive.

I know another way: you can use them: split, join, or — the famous “cat”, which is capable of concatenating multiple files together!

So just as their is more than one way to “skin a cat”, there is more than one way to solve a large file issue and there is more than one way to edit a file. Learn more than one set of tools and you’ll ultimately be more effective; find the right balance between spending too much or too little time doing this and you’ll get to the right place for whatever jobs you must do, and do them well.

Tip: https://unix.stackexchange.com/questions/24630/whats-the-best-way-to-join-files-again-after-splitting-them

5 Likes

From TECO to Neovim: 50 Years of Text Editing on Unix and Linux

That’s a memory I don’t expect to read today…

The first text editor I learned was actually TECO, back in the time-sharing days where you got to select if you booked a terminal (screen) or teleprinter (computer responses were printed on paper; meaning you got to go home with a record of everything you did; or had something to hand if the session was part of a test in an education environment, or needed something to be attached to a submission/report as ‘proof’).

4 Likes

I think, no I know, more about :sauropod: :t_rex: than much of what you guys talk about sometimes. Haha

3 Likes

I concur. I’ve tried a few other editors but for the quick/small jobs I’ve settled on micro. (FYI: I just don’t like nano; it’s mappings just seem weird. I’d rather use vi than nano cause my fingers still remember how. :wink:)

3 Likes

@guiverc so you enjoy "working with line noise too eh? :grin:

2 Likes

@IronRod while I don’t expect everyone to know how to do it, both Nano and Micro have ways to customize their configuration. In the case of Nano, editing a file called .nanorc will take care of it. Most distributions have default configurations, typically in a place such as /usr/share/config or something similar. A search can usually locate it; once you find it, you can copy basic configurations to your own private directory. Some configurations can go into ~./config in a subdirectory, others can go in a hidden file right in your home directory. On my system, Nano uses ~/.nanorc, Micro uses ~/.config/micro.

1 Like

I was reviewing some of the references from the text editor research, and specifically I retrieved a Web browser I was using especially to look at it and I found not one, but two very interesting articles.

The first one was the information about the original TECO, but the second one was about the person who attended MIT from 1961-1965, Dan Murphy.

The article he wrote was Origins and Development of TOPS-20 but it was a lot more about history and background than just TECO, TENEX and TOPS-10, they were a biography of Dan Murphy, what was going on in the computer industry, the development of paging systems and so much more.

and
TECO (text editor) - Wikipedia are all very interesting articles, but if you are truly interested you may wish to visit some of the references; that’s how I found a few more things that turned out to be even more interesting than the editor itself!

I just found something really fascinating in the history of Emacs. James Gosling (who is also famous for creating Java), and Richard M. Stallman had been collaborating on an Emacs release. They rewrote a lot of the earlier code in C. However, Gosling was interested in a commercial Emacs product; Stallman was not, so instead of the early version being known as GNU Emacs, Stallman disowned this collaboration, referring to it as “Gosling Emacs”.

Because of this, GNU Emacs as we know it only came out in 1985; the previous 1984 version, which is what I’ve long considered the beginning of the GNU project and GNU Emacs, is what Stallman called Gosling Emacs.
Reference: XEmacs Internals Manual: 3. A History of Emacs

MORE:

What about “Doom Emacs”? Have any of you tried it - or heard of it? Distro Tube has quite a few articles about it on his YouTube channel:
https://www.youtube.com/results?search_query=Doom+Emacs+Tutorials+by+DistroTube

3 Likes