There is a strange editing mode that I stumbled on by myself, which I can do in Emacs.
Suppose I am editing a huge file, and need to make change in some other part without necessarily forgetting where I am. I just open a new buffer for the same file, edit the desired area, and close the new buffer. I have the old position restored automatically in the old buffer. Of course, this can be done to arbitrary number of levels.
This is because Emacs separates the concept of buffer and the file it visits. This is a basic concept, but its use in the above manner is not something I have explicitly seen mentioned.
Do other editors (vi, eclipse, sublime) have similar features?
Every programmer's editor and IDE I've used in the past 22 years has had this feature, all the way back to Delphi in 1996. I don't think Turbo Pascal's text UI had the feature but wouldn't be surprised if it did.
Support varies in whether e.g. lines introduced above the view cause scrolling, or if the views are sticky to relative position, but the basics of multiple editing cursors in multiple views for a single buffer have been pretty pervasive.
Emacs can do far more nice things, for instance meaningful text navigation so you can move not only between lines and columns but also between functions/method/class definitions, scope/context/namespaces, paragraphs, ...
You can edit multiple files at once (for instance if you change a string, like a variable name, in multiple files), you can edit with multiple cursors, record&execute text macro on the fly and with a prefix to transform code/data in a snap...
You can edit file/dirs like text in dired, receive a patch via mail and have it highlighted, applied and committed in a snap... List is long to a point that anything you think if useful probably already exists in Emacs, otherwise you can create it in very few lines of elisp at runtime.
How much time do you need to spend setting up all those possibilities? And figuring out all the little incompatibilities be tween all the plugins and modes, and lisp extensions?
Most of what you mentioned already exists in most IDEs.
In term of "spending" my answer is ZERO, simply because I do not spent time, I discover things casually or when I feel the need of something and it's nearly always there, ready to go in my config (org-mode based) with a quick cut&paste.
Sometime yes, I found a thing that require more investigation or something happen and need action but with modern Emacs is far simpler than undebuggable monsters like Eclipse or Netbeans dotdirs.
BTW there is no difference in terms: plugins, extensions etc; core Emacs is an elisp virtual machine and anything are simply sexps, from my own config to the most famous major mode like org.
About modern IDE: in Emacs I do anything from mail (notmuch-emacs) to personal finance (ledger) to slides (org-mode with skeletor/yasnippet and reveal.js/beamer) to other documents, to deploy documents, live in org via babel, to window manager (EXWM) etc. No IDE or other app exists that can do anything with the level of simplicity, effectiveness and integration of Emacs. Even in terms of mere editing modern IDE are not integrate with anything but barely themselves so you need tons of different apps to do a single thing, in Emacs everything is there.
In terms of time: I was a hardcore vimmer for decades, at a certain point in time I feel the need of something different and I decide to try Emacs. Initially as an editor, after as MUA, after as agenda, after as a file manager, after as a ... discovering new things regularly and ease my life like never before.
The long-time Emacs user has heard this same argument repeatedly for decades, with regard to historic IDEs that no longer exist. How much time do you spend switching to new IDEs every couple of years.
Well, in the past I have used Eclipse, Netbeans, SunStudio (essentially netbeans), IntelliJIdea, Oracle JDeveloper and others: all of them are enormously bugged, perhaps Netbans/Sunstudio was the least bugged. All of them suffer from an ever grown dotdirs that sooner or later brake and you need to restart from scratch...
In Emacs I have had brackeage, and an emacs bankruptcy. But in all case I have recovered anything when I have time simply investigating, when happen if I'm in hurry a quick revert and anything works again.
Exactly. If all those IDEs in the IDE graveyard were so good, why are they dead, while your Emacs is still here?
Too tied to a platform or language, perhaps, and very specific processes related to these? No vision for extensibility or future maintenance?
Sometimes IDEs are very tied to specific target platforms: like IDEs from microcontroller and DSP vendors and such. E.g. if you're programming PICs, you use Microchip's IDE. It provides the image downloading to the target and breakpoint debugging.
Modern GUIs have no extensibility, they are designed from the widget library to the entire software as commercial product, FOSS included because the idea of "modern" GUIs is commercial at design stage.
Emacs, like LispM, Xerox ancient worsktation etc instead was born in a world where software is free, only hardware is commercial. So they are designed from start to be flexible, user-centric, non product-centric.
It's worth remembering an ancient joke of MIT AI lab: An engineer ask few secretaries if they know how to program; they respond no. It ask if they were sure; they respond "of course". As a matter fact they use Emacs and program the mode they need, only no one tell them that's programming, they simply learn how to bend a flexible environment to their needs. Another thing worth mentioned is the classic "In the beginning was the command line" paper, short and nice.
Unfortunately people born in commercial world that do not know IT history can't really imaging that world and it's power. They are incapable of think outside actual business model so they do not understand that other models and software exists...
Hem... We are people, so we are sometimes lovers, sometimes cookers, sometimes fighters, businessman, ... but we are still the very same body. So why our tools need to be divided and confined to a purpose if we are able to craft a single efficient and integrated one?
That's the trouble. It's more flexible than most ides, but you have to configure it, which isn't easy if you lack the imagination or the technical know-how (elisp).
It's not just the technical know-how of knowing elisp. It's also the often arcane ways of configuring emacs and the arcane and often undocumented ways of configuring the packages and plugins and modes that you bring into the system.
The amount of hacks one needs to maintain a reasonably working emacs is mind-boggling, and has nothing to do with imagination. I know, I used to maintain one: https://gist.github.com/dmitriid/4078311
With req-package and org-mode init you do not need any specific hack and anything that does not work remain "isolated".
Many try el-get, borg, ... but personally I found simple setup effective enough and in years my config is now ~4000 lines of org+elisp + few personal packages...
> I found simple setup effective
> my config is now ~4000 lines
We have critical production services which are a magnitude of lines fewer than your "simple config".
There's a reason I linked my own init.el: I'm not talking about something I have no idea about. It's quite short and quite extensively documented. And even there you see: somethign is set as global vars, something is buffer local args, something is inited through hooks, something is inited through hooks and then thorough a global var (doesn't work the other way around), something requires a lambda for a config, something requires a list of values, something is inited through a macro, some are just elisp macros you have to write yourself. And so on and so on.
Once you start extending emacs to be your personal programming environment (especially a multi-language environment), you'll run into exactly what I'm talking about: it's not a simple system. There are the often arcane ways of configuring emacs itself, and then there are often arcane ways to configure the modes and packages. And often these are undocumented, or specific ways to configure them are passed down in oral tradition from one init.el to another.
Even in this post you see multiple people recommending not just differenet packages, but different combinations of packages (each has to be configured separately).
And when something goes wrong? Good luck figuring it out.
That's why I use org-mode for my config so I can set :tangle no anytime, with {use,req}-pacakge I can handle the complexity without feeling it.
Actually I live (in IT terms) in Emacs, from the WM (EXWM(-x)) to MUA (notmuch-emacs) to personal finance (ledger-mode) to document system (skeletor+org+LaTeX+yasnippet) to programming environment (personal use of guile (geiser), hy, python (jedi etc), nim and various shells/DSL language), I administer systems inside Emacs with NixOS and tramp+eshell, I forget the concept of filemanger with dired (and tons of related addons), I super reduce CLI usage thanks to various Emacs packages, I have chat, rss, news all inside all well integrated... Yep, the start give me some frustration, I have a config bankrupt but after that things goes far smother than any other environment I have ever tried.
And yes, the config is big, but I do not made it before starting using Emacs, it evolve regularly in the time as I need so it's length and complexity have essentially no weigh. When something goes wrong (essentially after an update) I simply rollback and keep working until I have time to investigate. No real interruption, nothing like Windows update during presentation we all have seen.
Sometimes I have encountered "strange" bugs, the last few days ago that doom-modeline break notmuch-mua-new-mail: I quickly rollback and do my stuff; in a moment of free time I try to figure out what happen and yes I encounter some difficulties (my knowledge of elisp it's not well enough) so I simply ignore the problem. Yesterday I update again and the problem was gone. Long-story short in many case a problem is not only mine and tons of people working on Emacs find and debug it :-)
My complaint: emacs requires a lot of configuration that is often arcane or poorly documented.
You: but it's so simple! I only use notmuch-emacs, and ledger-mode, and skeletor+org+LaTeX+yasnippet, and geiser, and jedi, and tramp+eshell, and dired with tons of related addons, and..., and..., and..., and...
Something tells me you just reinforce the point I'm making. I personally have a life outside of looking for and configuring dozens of emacs packages in a hundred different ways.
I never quite got that. What is the advantage of doing everything on your PC with Emacs plugins, instead of using dedicated programs for specific tasks? I get that the text editor for all these tasks is behaving the same way when going the Emacs way - is that the only advantage though?
This is exactly what keeps happening to my emacs. I have tried emacs in 3 or 4 periods for work and home use. Every time, I add useful things to my config until something breaks, I try fix it and maybe fail or partially fix it.
I eventually give up. Latesty try was with spacemacs, which I quite liked. It gots so broken it refused to start up and I never even really bothered fixing it. I tried VS Code and that is where I am at.
Now my VS Code is getting slow, and Iv'e already had some problems extensions!
I have experienced far in the past a similar situation, I've tried both Emacs and XEmacs at that time and give up sticking to vim. After, time ago pushed by curiosity and few demos I casually see I tried Emacs again but with a far slower start, only as a side curiosity and a step at a time I grow my config keep using (n)vim until I decide it's time to jump. After that I still experience some problems but I keep evolution speed slow to avoid frustration, in few months Emacs became my environment.
Maybe you have tried Emacs as an editor expecting to been able to use it quickly as other "editors" you already encounter and that cause the fail. Emacs is an OS, not an editor, an ancient one that have some idiosyncrasy because of that vestige. And we know that learning an OS is not as simple as learning a single-purpose application.
In vim, I use vsplit to open the same file, make my edit, and close it. tbh, it's faster to mark my spot with m[az], make my edit, and return to my spot `[az] ([az] means any lower case letter).
What you describe can also be done with one buffer and multiple windows that show the same buffer, and I do this all the time. The position of the cursor is associated with a window when multiple windows present the same buffer.
The fact that Ctrl-O and Ctrl-I exist is just a tiny example of why the modern editors just can't compete with vim and the plethora tiny productivity features it has.
Hardcore vimmer here, but I don't think you're right. I know at least VSCode has this functionality and probably other editors as well. I don't use vim because of it's features but more because modal editing and the keybindings are cemented into my muscle memory. There's also the extremely lightweight nature that let's me have several projects open in vim at once with little resource impact. Were I to start over today, I might pick VSCode and be just as happy.
I respectfully disagree. I think VSCode's ergonomics pale in comparison to Vim. I just mentioned Ctrl-O, but there's a hundred little other features that I use constantly that VSCode doesn't have, and even if it does, it executes them much slower than Vim does. If Vim's plugin system was improved, it would blow VSCode out of the water.
Then you may find the "narrow-to-region" command useful too. It allows you to select a region of text, and make everything else in the buffer invisible and unmodifiable.
I find it useful when trying to grok a specific function without getting distracted, or more usefully, doing a search-and-replace without fear of doing a replace in an unintended part of the buffer.
You can do the same thing in vim by opening the same buffer in another split. Very useful for editing in multiple places without having to keep jumping around.
I think buffers/splits are considered a better option than tabs for this use case? I believe tabs are more for layouts of open buffers in splits rather than like browser tabs.
Suppose I am editing a huge file, and need to make change in some other part without necessarily forgetting where I am. I just open a new buffer for the same file, edit the desired area, and close the new buffer. I have the old position restored automatically in the old buffer. Of course, this can be done to arbitrary number of levels.
This is because Emacs separates the concept of buffer and the file it visits. This is a basic concept, but its use in the above manner is not something I have explicitly seen mentioned.
Do other editors (vi, eclipse, sublime) have similar features?