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.
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.
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.
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’).
I think, no I know, more about
than much of what you guys talk about sometimes. Haha