FWIW this is something most editors let you do trivially.
With VS Code, select the lines you want to sort, press Cmd-Shift-P to bring up fuzzy command search, type "sort", press enter. Your selected lines are sorted.
I think you might be surprised to find that all the major editors these days have most all of the little things you might want day-to-day covered. Of course the set of little things one cares about will differ from person to person and from the capabilities we've personally found the most use out of. It's hard to argue when that one thing you use every day isn't supported in some other editor, but the list of those is shrinking quicker than I suspect most people realize.
There are a lot of people contributing to these tools and that plus not having to reinvent every wheel from scratch (and maintain that code on top) means that modern editors can cut into the lead time advantage of something like Emacs quicker than you might otherwise think.
Though ultimately feature per feature, I don't think emacs looks all that great, but the difference is that you can actually use a lot of what it has to offer whereas it's difficult to do so in more modern editors (with fuzzy matching and all).
Nova looked super pretty and it's easy to figure out how to do a lot of things out-of-the-box that's harder to figure out on emacs at first.
But there are a couple of core things about emacs that I just don't see replicated in the popular IDEs.
1. The way you manage buffers and "windows" (just partitions of the screen in your GUI window). Buffers and windows are decoupled, which will make no sense to most people if they aren't fluent in it. And these little window partitions are quickly built, re-sized, split, and destroyed at a moment's notice from the keyboard. I can and do regularly go from 1 to 12 partitions at a moment's notice. I switch buffers in partitions constantly.
I tried so hard to figure out how to not make buffer and window management suck in Nova, but to no avail. I've also done some professional development in VS Code, and it doesn't appear to be any more flexible.
Maybe someone has an extension, but I doubt it. And this is too core to my development experience to trust to something as ephemeral as an extension. And emacs has already been doing it for 30 years.
2. I use emacs in the terminal, whether on my desktop or ssh'd into AWS.
The development experience is 100% seamless. Being able to work remotely on any server with my exact same developer experience is huge for me. I don't have to have a mirror copy of the files and do any syncing between edits. I can use all the project management, file browsing, and directory searching features built into emacs with no problem. I'm always at home.
The last thing I'll mention is that, contrary to the person having doubts in the linked article, I'm not an emacs power user. Currently I use an almost-stock spacemacs install, not even in evil-mode, and I've barely explored it. The basic emacs features I learned in the first couple months of using emacs give me more than anything I've found.
I will say that if I made a whole career out of Java or .Net development, and if versatility wasn't that important, an IDE tailored to those environments would have some polish that's hard to ignore. But if I knew I was missing the foregoing, it would hurt a lot every day.
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
This explains it https://code.visualstudio.com/docs/remote/ssh-tutorial
There's a similar extension to work within containers https://marketplace.visualstudio.com/items?itemName=ms-vscod...
https://www.gnu.org/software/tramp/#Ad_002dhoc-multi_002dhop...
How is this different from tabs? You have global search to open files in new tabs, you can opt to leave a trail of new tabs as you follow links through your code, you create arbitrary new tabs and plop snippets in, and have an option to persist to a file whenever you wish. You can reorganize your tabs layout, create an arbitrary number of rows and columns, move tabs back and forth between different groups, splitting and merging groups as you need.
(buffers can be files, configurations panels, terminals, applications, whatever really)
But editor ergonomics are always trumped by tool support, and Emacs' can be good, but it's never reliable in supporting environments that aren't Lisp and academic stuff like R and LaTeX.
re: clicking/squinting/dragging/animations those i would usually handle by things like keyboard shortcuts, configuring your global search to list tabs first, configuring animation.
I think what is more interesting is the idea to use the same buffers/windows for non-text-files. So, the first half is the idea of having all your tooling be text-based. There's some slider along, text driven by keyboard => gui driven by keyboard => gui driven by mouse. And then the second half of the idea seems to be how you separate text-editing/config/applications. So maybe along that slider, emacs mixes all sources / IDE groups sources within an application / separate applications for each source.
Maybe pushing everything to one edge of the slider is able to put one in a zen-like state. I guess for now I just try to find a sweet spot with my tools, where stuff i want to do fast i can do fast, and everything else is ok as is.
Every modern graphical editor I'm aware of lets you jump around in tabs/windows/panes etc. exclusively with hotkeys.
I don't know why people keeping talking about clicking around. They are all completely operable without resorting to clicking. Maybe not with IDEs, but with VS Code / Sublime / Atom, you don't need a mouse for anything I'm aware of.
So there's several tiers to this convenience:
1. Does it do the obviously important things out of the box, or with easily installed add-ons? For most editors, this is yes.
2. Does it do the little things out of the box, or with easily installed add-ons? For some editors, this is yes.
3. If none of the above, can you create the thing you need as an add-on without breaking your step, almost as part of what you were already doing? To get to this point it takes a very dynamic system like Emacs.
Disclaimer: I don't know Visual Studio that well. Still, I suspect what I'm writing is true.
I wrote about this in a separate comment: https://news.ycombinator.com/item?id=28104243
Speaking from the experience of someone who has repeatedly bounced off Emacs for going on two decades now, you absolutely will. :)
> When I want to sort a few lines in a region and immediately discover that I can just call "sort-lines", because of course I can, I know that I'm not going to bother waiting for some other editor to catch up in all those little things.
This sort of "little thing" is, perhaps ironically, why I keep going back to BBEdit, at least for my technical writing work: it has a whole lot of these little "multipurpose tool" commands for text manipulation -- and, because they're in old-school Mac menus, they're discoverable. Thinking about it, that's one of the main reasons I bounce off both Emacs and Vim: it's not that I can't figure out the basics or even the, er, intermediates; it's that so much of the advanced stuff is relatively opaque. I am sure that there is probably a command in both Emacs and Vim that equates to, for instance, "find all lines matching this regex that occur more than once in this document, delete them, and copy them to a new document" (a task which sounds like I am making it up, but I swear I have had to do on multiple occasions in my current role). But I am also sure that it is not as easy as selecting "Text > Process Duplicate Lines..." and checking "Delete duplicate lines", "Leaving one" and "Match using pattern".
If anyone reading this hasn't used keyboard macros in emacs, try it out the next time you do something repetitive. It's amazing how it can simplify those tasks. "C-x (" to start defining one, "C-x )" to end it, "C-x e" to run it, which conveniently also ends definition if you want to use it right away. Of course you can do things like "M-5 C-x e" to run it 5 times.
But I do get your point: Things are probably much less discoverable in emacs, unless you are relatively proficient in it already maybe. You need to switching into a "programmer" mind fairly quickly, while BBedit probably just lets you do powerful stuff through simple UI.
The flow you just mentioned I think looks nigh identical.
Even so, the "sort lines" example works well with even the out-of-the-box completion. But, Emacs sometimes has its own language for things. If I didn't know the keyboard commands for "make region uppercase" and "make region lowercase" (which in fact I'd forgotten, although they're pretty trivial), then as far as I could tell the best way I could find them would be: Google. Inside Emacs, I could type "M-x up" and get the correct "upcase-region", but if I'd typed "M-x upp", I'd be out of luck. And Emacs-ese for "lowercase" is "downcase"; I wouldn't have guessed that at all!
So I'm not sure the flow looks nigh identical for that many cases like this. The way I remember learning Emacs basics many years ago was actually through menus. Looking at Emacs's menus now, in v27.2, they're...kind of eclectic? The basics are there, but a lot, well, isn't. BBEdit is admittedly somewhat at the other extreme, with possibly just too damn much in its menus, but that does make a lot of its functionality very easily discoverable.
At any rate, I should be clear that I think this is a mild knock against Emacs; I bounce off it in part because of this relative lack of discoverability, and also because it just seems like it takes a lot of effort relative to most other editors to set up comfortably. The flip side of that is that, as the "Lock-In Effect" article notes, once you do have it set up the way you like it, you are probably never going to have any motivation to switch. That is absolutely not a knock -- it's configurable and extensible in a way nothing else is.
This is not quite true.
The minibuffer, which is what vanilla Emacs uses for M-x command completion, has a set of completion styles, ordered by preference. You can find the full set of completion categories supported by Emacs in the variable completion-styles-alist. Among those is one called flex, which allows for full fuzzy matching between provided tokens.
This is not a default minibuffer completion style, but it provided without additional packages. One would add it by adding it to the list of completion styles used by the minibuffer as specified by the variable completion-styles. I recommend trying it out.
M-x customize-apropos some-string
M-x info-apropos some-string
I'd like to know what other editors have a discovery system like this built-in.
I should also highlight that I think folks should lean on apropos way more than they typically do.
For example, everybody was kind of 80-90% on syntax highlighting. Some editors and IDEs were a little better at one language than others, but most weren't that great and had all manner of weird edge cases. And, if you wrote a new language, good luck because you had to write a syntax highlighter for it in both emacs and vim to get traction.
And then VSCode came along with the Language Server Protocol. Suddenly, you only needed to write a well-constrained plugin to get your syntax highlighting to about 80%. That was okay.
But the modern languages learned from the failures of C and C++ and designed themselves to be parsed quickly and accurately. So, now your LSP syntax highlighting could go to roughly 99% accuracy on VSCode. And the highlighters were incremental. Suddenly there was a genuine advantage to using something other than emacs.
And this is before we get to things like a debugger that works, etc. I've used all the IDE's, but VSCode is the first one to pry emacs from under my fingers.
And for people who like to complain about VSCode and Electron bloat (a valid complaint), I'd like to point you to some of the old nicknames from the emacs vs vi religious wars (Eight Megabytes And Constantly Swapping springs to mind ...) Bloat simply isn't an argument for most people.
? LSP, the protocol, doesn't (yet) have a syntax highlighting aspect.
And doesn't VSCode still use TextMate grammars? https://code.visualstudio.com/api/language-extensions/syntax...
IntelliJ, on the other hand, has great support for emacs key-bindings.
I don't want to master an editor anymore. I want to get work done. Pretty much the same with LaTeX. When I want to improve something in a doc, I look it up and do that. When I go back to the doc later, I don't always remember what that magic meant. But that's ok, I'm writing a doc. I'm not trying to master the writing of a doc.
$ latexmk -pdf main.tex
How hard is that? The only thing Overleaf adds here is a button and a 10x compilation time overhead.
> I don't always remember what that magic meant.
Overleaf mostly won't help you here, unless I'm mistaken.
I don't mean to be aggressive here, I just don't get the Overleaf hype. What's wrong with good old text editor + version control? I think I'll pass on the slow web app for now. At least they have Git integration so nobody is going to force me to use it.
This kind of workflow is not really usable with Overleaf. Overleaf uses Git in the background, but every commit is named "changes on Overleaf" and the individual commits do not really make much sense. In addition, everything is immediately put into the master branch and there's no way to summarize or group changes (like with commits and/or pull requests).
My next problem is, that Overleaf just uses latexmk so if you have some code to generate graphics or tables, you have to compile and add them manually all the time.
Overleaf removes the need for local install. A full MacTex.pkg install is 4.4GB. I've lived in LaTeX for more than 30 years, and I love the ability to edit docs from any browser.
I'm not a huge fan of Overleaf, mind you, but I agree with those that say it does have its uses. The easy collaboration for people that don't like -- or don't get how -- to use git. I wish everyone I collaborate with liked git...
with import <nixpkgs> {};
pkgs.runCommand "cv.pdf" rec {
src = ./cv.tex;
bin = with pkgs.texlive; combine {
inherit scheme-medium collection-latexrecommended collection-fontsextra
moderncv etoolbox;
};
buildInputs = [ bin ];
allowSubstitutes = false;
} ''
ln -s $src cv.tex
latexmk -pdf cv.tex
mkdir $out
mv *pdf $out/
''
And I do mean you. I gave up after a solid week. I'll just make whatever I want in PowerPoint, save it to a PDF, and be done in 15 minutes.
Yes, I said PowerPoint. Set you're slides to 8.5x11 and it became a typesetting program. I've started getting my coworkers to use it for such and they are absolutely delighted by the bump in design quality they are getting because they aren't fighting Word anymore.
I didn't try it, but it wasn't much harder than that if I recall... If you're on Windows, well, it's your loss :(
If you use PowerPoint, you might try TeXmacs (WYSIWYG, structured and programmable).
> they are absolutely delighted by the bump in design quality
I expect them to be even more delighted :-)
That won't print sensibly on the paper in your printer, in most of the civilised world.
When stuff is not up to scratch (image is placed incorrectly, spacing in your table is wrong, your diagram has an incorrect alignment, etc), the error messages suck, and you often need to figure out what the magic does to be able to fix the issue.
I tried to get him into paredit, but he smiled a little and said his brain isn't so fast that it could keep up with frantic fingers like mine.
Indeed, he worked out things in his head before splashing into the buffers and mostly got things right by doing just a few things, slowly. Of course CL is one of the better languages for that.
I think programmers overestimate the importance of editors or typing. Comfort is more important than speed or efficiency, but of course you feel discomfort if you lose the speed you are accustomed to! If you feel comfortable in whatever editor you use, congrats, your quest is complete.
One example is a table saw sled, which helps you make clean, repeatable, 90º cuts. It's one of the most useful "plugins" you can have for your table saw, and relatively easy to make. Making the actual table saw, on the other hand, would be expensive and very difficult, and would require knowledge of many fields (metal working, electrical systems, etc.).
On Linux, literally run the texlive installer script and install an editor like TexStudio if you'd like. That's it.
I am a research mathematician, and I and essentially all my colleagues are LaTeX users. To me it feels like the correct tool for the job; the only widespread criticism I've heard is that it doesn't produce documents accessible to the blind. (And I've heard that work on this is in process.)
I tend to be unsympathetic to criticism that a tool is "outdated"; if a tool is right for the job, why change it? But I want to keep an open mind -- what would you like to see in LaTeX's place?
Let's get started with some negatives (the positive are well known):
- Recompilations needed. Can be mitigated by latexmk, but still.
- Choice of latex, pdflatex, xelatex, lualatex ... and documents compiled with one may or may not compile with another
- packages that are incompatible with each other in odd ways
- when you encounter an error you have to enter "X". if you're using latexmk, you have to enter "X" multiple times
- math commands are not structure-based but presentation based, despite LaTeX's (otherwise well executed) posturing of separating content from styling. If you want to change the alignment of your equations or the size of the integrals sign or just slightly tweak the appearance of the | sign in {x^2 | x € R }, be prepared for a lot of rewriting (some of this can be alleviated by defining new commands, but I don't know how many people actually do that)
- Math LaTeX input is basically unparseable in the sense that it is not really possible to take some latex math code and convert it into some actual meaningful structure (this is a corollary of the above point). Given the ubiquity of LaTeX-style math even in a range of other contexts (e.g. KaTeX), this is a bit of an issue. It's possible to do a best effort implementation that sort-of works, but it's always gonna come up short
- Error messages: "Missing $", thanks
- Outdated defaults. Unicode should just work by default.
I think I could go on, but you get the point.
Seems like you haven't heard of the "-interaction=nonstopmode" flag...
If you're pressing X for each error, this will be life-changing.
While markdown is not advanced enough, I feel the making it easier for the user to use is the right modern approach, from which maybe a full system could be designed.
Also figure placement should allow more fine-tuning (not sure how, and yes this is against the original spirit)
Honestly I think I am missing all the points about brackets in Latex, if somebody knows the Syntax (and the 'why' pls tell me).
a document preparation system in which
- it is easy to read what you wrote (without having to switch between the editor and the typeset text)
- customization is done with a sensible programming language
I could even argue that since Emacs hasn't been phased out (and still has a decent user base) that it does something that other text editors don't (or can't) do.
In particular, the biggest change I'm aware of with Emacs Lisp (the language) is that we now have lexically scoped variables. The biggest change to its implementation has been a push towards native compilation (much improved performance, I like it). The language has, otherwise, largely remained the same.
In some regard, this can be seen as a consequence of having a decent base language. Where Fortran's original version became increasingly indecent as time went on, Emacs Lisp seems to have held up better thanks to a stronger foundation. That doesn't mean there isn't room for improvement.
In particular, the things that (my opinion) are still missing from the language are:
1. A good concurrency model. CSP, actors, I don't care but it needs to exist. Paired with the native execution we're getting now, this would greatly improve the real and perceived performance of the system.
2. A real module system. I'm not talking about a package manager, but moving things into module scopes a la Common Lisp packages. The prefixed names for functions and variables is a hazard. Even if you leave every symbol exported by default so that you don't lose visibility to module internals it would be better than now. It would also open up a lot of opportunities like the potential to run multiple versions of the same package side-by-side.
And yet most Fortran programmers reject/ignore those changes and stick to Fortran 77. When I was in academia, I couldn't find a single person writing Fortran code in anything newer than 77.
Even then, FORTRAN 77 is a major change over FORTRAN (1957 and even the later FORTRAN 66). Specifically, that's the version that got structured programming elements added to the language. Having once inherited some pre-F77 code (well, it was F77 by the time I got it, but was started before then and that was obvious by its almost complete lack of structured programming), I can say that F77 is a substantially improved language over the prior versions.
That's because FORTRAN is one of the oldest languages, and you'd expect lots of changes as the whole field develops. If you use that as a metric, most languages will appear stagnant. Python hasn't changed much in the last 20 years, for example.
One might think Eclipse IDE is old. But Fortran predates the three-point seatbelts. The Vietnam War. Berlin Crisis. The Space Race.
(1) Except that one old beard who was convinced F77 was the ultimate, and everything newer was crap.
This is definitely the biggest pain point, especially as people go to expand their use of Emacs (e.g. with Doom, adding more modules and integrations, one has to be careful to lazily evaluate config blocks to avoid loading everything at startup).
Even without such extensive configs, working on a large repo with a slow I/O (e.g. some network mount) with magit will cause large pauses once a command finishes if it has to refresh the magit buffer, or trying to search myriad org agenda files for an ID or text search (e.g. org rifle) will basically lock up emacs.
I do at least look forward to Emacs 28, which iirc is going to get native-comp (although that is already available as an experimental branch perhaps?).
Please try `org-ql` and `helm-org-ql`; these newer search tools perform better than `org-rifle` and generally supersede it.
No matter what, emacs still feels "alien" in my OS's desktop interface with its UI concept, and never fully integrates. That's fine if you don't want it to integrate, but I actually like some concepts of my OS's UI a lot, and miss them in emacs.
And elisp is not a very good language, born of a time where programming languages still had a long way to go (at least in the mainstream, academically it always seems a bit different to me). They are actively trying to fix things, e.g. the adoption of lexical binding, but the scope of this effort also shows how emacs is a very big ship that is hard to change course.
Someone else mentioned lack of proper multi-threading in another comment now, and this is also very noticeable.
>Emacs seems to be in the same position as LaTeX: Outdated paradigms that would probably need an entire redesign from the ground up to start "making sense" in the modern world.
I was really responding to this. You're right though: there are aspects of Emacs that are dated, the UI isn't very spiffy, and I've never dealt with elisp before so I'll take your--and everyone else's--word for that. I was just suggesting that it gets the job done for a lot of people and maybe, as a result, shouldn't be classified as outdated.
I wonder if there will be a way to sidestep these limitations or if something in the language semantics would forbid it (e.g. the way Python is basically limited with the GIL because current updates are basically not tolerated by the semantics).
- You could reimplement the Emacs LISP VM and change what some of the native editor types refer to (buffer, point, window, etc.) so that they are interpreted in a “modern” UI setting. Maybe add some new opcodes while you’re at it to handle things like threading.
- You could fork emacs, strip out the display engine, and completely rewrite it (it’s notoriously complicated and probably not worth dealing with 50 years of legacy hacks).
Either of these options would give you a reasonable chance of skipping over the inherent complexity of the system without having to ditch all of the ecosystem packages), though they’re both still pretty involved.
A big part of the reason for this is you’d inherently end up losing some OS compatibility in the process, and maintaining compatibility is probably the biggest problem with making changes or updates to emacs. If you’re willing to ditch that burden, your options expand dramatically.
For LaTeX a large part of the appeal is to get a template and be able to respect whatever arbitrary formatting requirements.
Someone could build a layer on top of existing LaTeX to add a more modern language on top of it and have it expand to LaTeX.
Well not entirely - it's modeless, and some usual keybindings work as well (Home/End, etc.). The built-in tutorial is brief and to the point, it will get one started pretty quickly.
Emacs seems to be in the same position as LaTeX: Outdated paradigms that would probably need an entire redesign from the ground up to start "making sense" in the modern world. This starts with (nowadays) non-conformant shortcuts, includes window/buffer management (the terminology alone is archaic: panes are windows and windows are frames), and ends with elisp, which even Lisp programmers themselves rebuke.
But such a do-over is impossible in both LaTeX and emacs, since that would also mean throwing all the thousands (ten thousands?) packages--and lots of core functionality--away. Stuff that has accumulated for many decades and that is the reason why we're sticking with it: Everything else feels very limited in comparison.
And it's not just the "big" things. When I want to sort a few lines in a region and immediately discover that I can just call "sort-lines", because of course I can, I know that I'm not going to bother waiting for some other editor to catch up in all those little things.
Admittedly, I haven't tried modern distributions like spacemacs and DOOM Emacs, but it's a bit hard for me to imagine that you won't need to come face to face with "emacsism" at some time.