Emacs is most definitely not a rocket science. The problem with people trying Emacs is that they approach it just like any other text editor, instead of understanding the grand, core principle of it - Emacs is first and foremost a Lisp interpreter with a built-in text editor and not the other way around. Therefore it makes much better sense if you approach it from a Lisp perspective. Alas, many, perhaps most, beginners try it after hearing how "powerful this Emacs thingy is", and try to learn "editor features", instead of focusing on the Lisp side of things. Some even admit that they don't like Lisp and don't understand it and plan to never deal with it. Most posts of "abandonment" and "I switch to VSCode after decades of Emacs use", after closer examination, reveal that the person perhaps never even written any elisp code - at most, they'd just [almost] blindly copy&paste existing snippets into their configs.
After learning the key bindings, I actually found a library book on a pre-CLisp dialect of lisp by some finnish authors and wrote a tool i later used to write my thesis in electrical engineering.
The tool was parsing my matlab files and generated latex, which i then made into the final pdf, complete with formulaes and calculations.
So instead of writing a decent thesis, i learned about makefiles, latex, emacs lisp and the fact that parsers are very interesting.
Also, Lisp felt sooooooo out of this world after pascal, C, Cpp.
Surely, i did not work a single day as an electric engineer.
I did - I first came to emacs during my lisp phase. I didn't stay with lisp, but I did stay with functional programming, and in those days emacs was the best environment for a number of functional programming languages (maybe still is).
And that's why it cost me two-three years of wasted experience. Looking back, I wish I had focused more on understanding Elisp, learning edebug and the built-in profiler. My bona fide Emacs journey began only after I started writing Elisp without fear.
Heh. In the early 1990s, I got initiated to the basic Emacs key bindings and editing UI via JOVE for a Scheme programming class. JOVE didn't have elisp behind it, instead being light enough that scores of students could all be running their own editor session and Scheme interpreter processes on the same memory-starved, multi-user server.
I'd already known Common Lisp from a prior class, which mostly used some Mac based REPL. Shortly after, I had real Emacs and various CL and Scheme runtimes on my Linux PC. Scheme was my obsession at the time. A lot of my pathway into CS was puzzling over what it would take to implement a Scheme runtime. But, I felt no desire to get into the bizarre-to-me elisp dialect. It just felt gross.
Probably because of early years using shared terminal server rooms and hosts, I also learned that over-customization just became a pain when I had to move between environments. I ran the Emacs that came bundled with my Linux distro, with the extensions that came packaged along with it. Mostly I just tried to have Xresources to get my preferred color scheme and text fonts.
From all of this, I'm nearly some kind of old school Unix fundamentalist. I've never wanted an IDE. Or rather, my IDE has always been the host OS, shell prompt, filesystem state, and other terminals. I use adjacent shells to run builds, tests, debuggers, version control, etc. Emacs is just my editor. I've never, ever wanted any editor to subsume my OS, window management, and these other tools.
My favorite interface feature is creating several "frames" (separate X windows) viewing into the same buffers. Sometimes several files side by side, and sometimes several editing viewports on the same file. I also use the X based menus to find many esoteric features or session settings for which I would never memorize the command names.
But, when I am forced to run Emacs in text terminal mode, I revert to thinking of it like JOVE. I'd rather open multiple terminals (and SSH connections, when remote) and have each one run its own ephemeral Emacs instance with one buffer for a brief foray into one file. Somehow, I've never had the urge to fire up an Emacs server to share state between these. I just find my way back to a proper graphical Emacs when I want that kind of complex editing session.
The only Emacs modes I use are for syntax highlighting and auto-indentation. I also never wanted Emacs "windowing", i.e. text terminal muxing. For me, learning to kill accidental window splits was roughly the same need as learning how to exit/abort out of accidentally launched vi. Repulsed, I head for the exit!
My favorite editing features are just search, find-replace, and find-replace-regexp. But search is mostly just a fast-scroll to me, jumping forward or back to text I know is there. If I'm really searching, I more likely mouse over to a terminal window and run find and/or grep from a shell. My favorite advanced editing feature is buffer-compare (Ediff), which I use for merging changes between two files in side-by-side frames.
Oh, and I despise the GNU infos-style help system too. I much prefer manpages, or secondarily reading docs in a web browser.
Emacs is most definitely not a rocket science. The problem with people trying Emacs is that they approach it just like any other text editor, instead of understanding the grand, core principle of it - Emacs is first and foremost a Lisp interpreter with a built-in text editor and not the other way around. Therefore it makes much better sense if you approach it from a Lisp perspective. Alas, many, perhaps most, beginners try it after hearing how "powerful this Emacs thingy is", and try to learn "editor features", instead of focusing on the Lisp side of things. Some even admit that they don't like Lisp and don't understand it and plan to never deal with it. Most posts of "abandonment" and "I switch to VSCode after decades of Emacs use", after closer examination, reveal that the person perhaps never even written any elisp code - at most, they'd just [almost] blindly copy&paste existing snippets into their configs.
No one, including yourself, approached emacs from a Lisp perspective.
I did.
After learning the key bindings, I actually found a library book on a pre-CLisp dialect of lisp by some finnish authors and wrote a tool i later used to write my thesis in electrical engineering.
The tool was parsing my matlab files and generated latex, which i then made into the final pdf, complete with formulaes and calculations.
So instead of writing a decent thesis, i learned about makefiles, latex, emacs lisp and the fact that parsers are very interesting.
Also, Lisp felt sooooooo out of this world after pascal, C, Cpp.
Surely, i did not work a single day as an electric engineer.
PS I keep looking for this book to this very day
I did - I first came to emacs during my lisp phase. I didn't stay with lisp, but I did stay with functional programming, and in those days emacs was the best environment for a number of functional programming languages (maybe still is).
And that's why it cost me two-three years of wasted experience. Looking back, I wish I had focused more on understanding Elisp, learning edebug and the built-in profiler. My bona fide Emacs journey began only after I started writing Elisp without fear.
Heh. In the early 1990s, I got initiated to the basic Emacs key bindings and editing UI via JOVE for a Scheme programming class. JOVE didn't have elisp behind it, instead being light enough that scores of students could all be running their own editor session and Scheme interpreter processes on the same memory-starved, multi-user server.
I'd already known Common Lisp from a prior class, which mostly used some Mac based REPL. Shortly after, I had real Emacs and various CL and Scheme runtimes on my Linux PC. Scheme was my obsession at the time. A lot of my pathway into CS was puzzling over what it would take to implement a Scheme runtime. But, I felt no desire to get into the bizarre-to-me elisp dialect. It just felt gross.
Probably because of early years using shared terminal server rooms and hosts, I also learned that over-customization just became a pain when I had to move between environments. I ran the Emacs that came bundled with my Linux distro, with the extensions that came packaged along with it. Mostly I just tried to have Xresources to get my preferred color scheme and text fonts.
From all of this, I'm nearly some kind of old school Unix fundamentalist. I've never wanted an IDE. Or rather, my IDE has always been the host OS, shell prompt, filesystem state, and other terminals. I use adjacent shells to run builds, tests, debuggers, version control, etc. Emacs is just my editor. I've never, ever wanted any editor to subsume my OS, window management, and these other tools.
My favorite interface feature is creating several "frames" (separate X windows) viewing into the same buffers. Sometimes several files side by side, and sometimes several editing viewports on the same file. I also use the X based menus to find many esoteric features or session settings for which I would never memorize the command names.
But, when I am forced to run Emacs in text terminal mode, I revert to thinking of it like JOVE. I'd rather open multiple terminals (and SSH connections, when remote) and have each one run its own ephemeral Emacs instance with one buffer for a brief foray into one file. Somehow, I've never had the urge to fire up an Emacs server to share state between these. I just find my way back to a proper graphical Emacs when I want that kind of complex editing session.
The only Emacs modes I use are for syntax highlighting and auto-indentation. I also never wanted Emacs "windowing", i.e. text terminal muxing. For me, learning to kill accidental window splits was roughly the same need as learning how to exit/abort out of accidentally launched vi. Repulsed, I head for the exit!
My favorite editing features are just search, find-replace, and find-replace-regexp. But search is mostly just a fast-scroll to me, jumping forward or back to text I know is there. If I'm really searching, I more likely mouse over to a terminal window and run find and/or grep from a shell. My favorite advanced editing feature is buffer-compare (Ediff), which I use for merging changes between two files in side-by-side frames.
Oh, and I despise the GNU infos-style help system too. I much prefer manpages, or secondarily reading docs in a web browser.
> Or rather, my IDE has always been the host OS, shell prompt, filesystem state, and other terminals.
As described by its creators: The Unix Programming Environment <https://en.wikipedia.org/w/index.php?title=The_Unix_Programm...>
How to get started with nvim?