Hacker News Reader

Comment by anyfoo | Hacker News Reader

I'm in a similar boat as in the first quote: Have used emacs for decades, glad that I do, can't imagine switching... don't think I would recommend it to anyone new, unless they are really open about learning something entirely different.

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.

View on HN

> 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.

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.

I agree with what you say about IDEs, but Emacs' "advantage" over other text editors is that it is only superficially a text editor. It's really more of an operating system.

How does the old joke go -- "Now if Emacs only had a decent text editor, it would be a pretty decent OS."

Evil mode

I think you would still be surprised at how many things emacs can still do better like undo in region or even simple macros that find use even during simple text edits.

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).

I'm a long term emacs user and I know that my emacs use is not down simply to lock-in. I know this because a year ago I spent a month using Panic Nova to see what I might be missing with emacs.

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.

About point 2, this can be done with vscode using this extension

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...

Emacs has TRAMP as well out of the box, but for some reason they want o launch a lightweight cli instance of emacs on the serverside, which VSCode can't do.

If you have more than one ssh hop or a remote desktop in-between Tramp isn't an option.

Tramp works through multiple SSH hops just fine:

https://www.gnu.org/software/tramp/#Ad_002dhoc-multi_002dhop...

TIL! Thanks.

Any good videos as examples of the window partition practice?

> buffers and windows

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.

I haven't found any editor that makes handling of split panes as streamlined as Emacs, and that's because while having the tabs tied to a single document is a sensible metaphor, it's just way faster to have two or three panes whose contents you can switch from an autocompleted list of buffers. No clicking around, no squinting your eyes at the little tab titles, no dragging and dropping the tabs to switch them from pane with awkward snapping in and out.

(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.

Ah, excellent, just wanted to make sure there wasn't some magical insight i was missing out on by not being familiar with emacs.

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.

> No clicking around

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.

I find the overhead of selecting a pop up, having it appear, often then using the mouse to select something, then pressing do is just clumsy compared to the low overhead command structure of Emacs. Search is a primary cursor move operation, for example.

I don’t think I’ve ever used a mouse to operate a single function in VS Code. Literally everything (in the actually literal sense) is available through a keyboard shortcut.

The sticking point for me is that if I discover some functionality is missing, I can add it to Emacs on the fly with often just a few (1--25) lines of Lisp.

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.

The thing with Emacs is that sort-lines is a string you can copy and paste into a buffer, whereas in Visual Studio it's a command that you have to execute.

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

> 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.

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".

Top of my head, I am pretty sure that I can do that with a "keyboard macro" involving list-matching-lines, and delete-matching-lines (that is literally what the commands are called). "Keyboard macro" by the way is a good and a bad name at once: It does not fully describe the vastly more powerful feature, as it is much more semantic than just repetition of keystrokes, but at its surface it looks like that and helps you get started.

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.

Once you've hit C-x e once you can keep bouncing e to repeat the macro as well.

Thanks for the reminder. I knew that once, but completely forgot about it!

Using non-standard notation for describing keyboard shorcuts doesn't help.

This is the notation that emacs has been using forever, and also displays to the user, so every user should be well comfortable with it. It even says “Press C-x C-c to exit emacs” at startup.

It's still non-standard, and is yet another barrier to adoption.

I found it handy and I often use it outside of emacs as well when describing shortcuts to people. Mainly C-something for ctrl.

With modern autocomplete for commands, discovering commands in emacs has never been easier. "M-x sort" will show you all fuzzy completions of that commands basically instantly.

The flow you just mentioned I think looks nigh identical.

I'll second this. Take a look at Vertico [1] and Consult [2] which really improve discoverability. Other nice packages (links found on the Vertico page) include Marginalia and Orderless.

[1]: https://github.com/minad/vertico

[2]: https://github.com/minad/consult

Even the current version of Emacs doesn't do fuzzy completion for M-x commands, just start-of-token completion; out of the box the completion is a little basic. I know there are packages which make this a lot better, but you have to know about the packages. :)

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.

Right, I was assuming something like helm or ivy. I only have experience with helm.

I should also highlight that I think folks should lean on apropos way more than they typically do.

Apropos is definitely a great feature!

> Even the current version of Emacs doesn't do fuzzy completion for M-x commands, just start-of-token completion; out of the box the completion is a little basic. I know there are packages which make this a lot better, but you have to know about the packages. :)

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.

TIL. Planning to play with that in the near future. Thanks!

Interesting! It still doesn't quite shake my suspicion that the best documentation for Emacs is "find somebody else who knows more about Emacs than you do," but to be fair that's not unique to Emacs. :)

Honestly, I wouldn't have been able to tell you this two weeks ago. I know all this now because completions in a language I don't normally use felt off somehow, and figuring out the solution involved going deep on how Emacs handles completions. That ended up not being relevant to the root cause, which was a change in Doom causing snippets to be overvalued in LSP completion, but at least I know a lot more about vanilla completion methods now!

This is a helpful tip, but I feel like it kinda reinforces the broader point about emacs's lack of discoverability. I've been using it for years and wasn't aware of this feature until today.

  M-x customize-apropos some-string

This is how I've discovered most things outside of just reading the documentation (and usually I go to the documentation once I find it). It's also helpful that the info pages in emacs are also searchable with:

  M-x info-apropos some-string

Both are kind of firehoses, but C-s inside the resulting buffer can usually narrow it down pretty quickly.

I'd like to know what other editors have a discovery system like this built-in.

As an emacs user, I would say that emacs really didn't have competition until VSCode and modern programming languages.

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.

I agree that lsp is a necessity nowadays, and I was almost willing and close to give up emacs. And then emacs got proper lsp support (even in at least two forms, lip-mode and eglot), and now I'm happy.

Is there a definitive Emacs key-binding plug-in for VSCode? I've tried several in the past and none seemed quite right.

IntelliJ, on the other hand, has great support for emacs key-bindings.

One other thing about VSCode being an Electron app -- it is by far the snappiest and most responsive and least bad memory-wise Electron app I've used. This isn't like Slack or Discord. It's like magic what they've built on Electron, one of these days I'll dig into the code to see how they did it.

> your LSP syntax highlighting could go to roughly 99% accuracy on VSCode.

? 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...

With respect to LaTeX, I only started to use it semi-recently in the cloud and I'd recommend it to anyone (but only in the cloud).

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.

I don't want to deeply learn an editor myself anymore, too, but that being said I am still extremely glad that the past decades have made me proficient in emacs. The editor is just one of the most important tools for me.

Just out of curiosity, which editor do you use? Overleaf?

Yes, Overleaf. I'd always had LaTeX envy but when faced with installation and configuration, I gave up again and again. Overleaf solved all that.

In college we were required to typeset assignments in LaTeX for all the math classes past multivariable calculus. I started out with Overleaf, but switched to local compilation about a year in. It's much nicer to be able to write in my usual text editor and compile documents instantly. On Arch, all I had to do was install texlive-most. It includes every package I have ever needed to use. To compile a document, I just run 'pdflatex *.tex'. Sometimes bibtex too. If you're having trouble with setup and configuration, I recommend texlive.

>installation and configuration

On Linux, literally run the texlive installer script and install an editor like TexStudio if you'd like. That's it.

Imagine a carpenter saying, "I don't want to master my tools, I just want to build things."

There’s mastering the use of your tools and there’s tinkering with the windings on the electric motor inside your tools. Emacs offers users both.

How common is it for carpenters to make their own tools? I actually don't know!

Did you write Emacs? Did I write Emacs?

For a lot of custom carpentry, it's pretty common for carpenters to make their own jigs to solve specific problems (e.g., if you need to use your router a bit like a thickness plane to mill down some object by a couple of millimetres along some axis so it fits somewhere, you probably want to build a jig first).

Pretty common, I think. I've made clamps and rove punches for instance, and I've been tempted to make drill bits. (But this is for wooden boatbuilding, which is its own uniquely crotchety corner of carpentry. Not unlike emacs...)

For most woodworkers, I'd say the analogy is closest to making "plugins" for existing tools. They require a little knowledge (which easily obtained on YouTube), and can greatly increase your ability to use the base tool.

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.).

It's more like a carpenter saying "I don't want to master my car, I just need to be able to get from place to place". A mathematician isn't payed to typeset papers, they're payed to do mathematics and typesetting in LaTeX is just a means to an end.

I once worked with a pretty amazing older Common Lisp programmer who used some IDE (Xanalys?) He selected forms by dragging with the mouse. Watching that felt uncomfortable, almost like physical pain.

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.

I can definitely sympathize with this. Typing in things has never been the bottleneck. Rather, deciding what needs to be typed in takes up the majority of the time. It probably helps that neither of my main two languages (Ruby for work/Haskell for fun) is all that verbose.

The problem with LaTeX is that it isn't well-designed enough that you can just use it without thinking about the magic.

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.

The thing with LaTeX is that it's a full text-oriented programing language. What is great if you want to extend it, but a problem if you want to use it on any context not supported by the interpreter. So, if you don't want to create a PDF, it just sucks.

> With respect to LaTeX, I only started to use it semi-recently in the cloud and I'd recommend it to anyone (but only in the cloud).

$ 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.

How do you do package (version) management for LaTeX? There's more than a few documents I've come across that won't build on my system, giving often-indecipherable compilation errors. Overleaf at least ensures everyone involved is using the same environment without needing to ship a Docker container or the like, or try to pin down versions.

I suppose it should be fairly portable, except for missing packages maybe. In my case I have literally every common package installed so that's not an issue. But LaTeX errors are a real pain, I'll admit that.

Nix has a decent solution here, i.e. turn the document into a nix derivation.

  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/
  ''

These days I'd probably use flakes to pin down the latex version.

Lol, that's not the command for making a LaTeX document. The command for making a LaTeX document fills a sheet for all the shit you have to install--half of which isn't correct on whatever documentation you're reading--and THEN you can `latexmk`.

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.

$ sudo apt install texlive latexmk $ latexmk -pdf main.tex

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 :(

Excuse me for being one of the 80% of working Americans

So download whatever latex distro you prefer for windows, open your document, click the button. It will automatically download missing packages in the background. Done.

Highly relevant username.

> Yes, I said PowerPoint. Set you're slides to 8.5x11 and it became a typesetting program.

That won't print sensibly on the paper in your printer, in most of the civilised world.

> I'll just make whatever I want in PowerPoint

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 :-)

> The only thing Overleaf adds here is a button and a 10x compilation time overhead.

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.

4GB today is not that much. Current OpenBSD and NetBSD install recommend 2-3GB at minimum for a base OS and 10-16GB for a confortable usage (installing a bunch of pkgs/ports, swap partitions, and so on).

Maybe it's just me, but 4.4 GB does feel like a not insignificant amount of space for something I don't have to install locally. Or for people that use it rarely.

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...

I've used LaTeX for about as long as I've used Emacs, and really, the thought of editing LaTeX from my browser is rather painful. You can still use Overleaf via git, though admittedly the experience isn't as smooth.

Overleaf allows you to work with several authors at the same time on the document. I was skeptical (after all, git allows that too). But after using that feature, well, it is just the killer thing. Now Overleaf doesn't add much on top on my own Latex installation. But the collaborative thing is just spot on (much like Google docs which I have discovered not a long time ago; same analysis : not that good presentation tool, but working together is just incredibly useful).

In my experience, Overleaf is actually awful for collaboration. Maybe my workflow is weird, but I tend to look at the diffs after my colleagues make changes. Also, we mainly use pull requests to add to our papers. This way, everyone can see and comment on changes.

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.

my workflow is different : we use voice chat to share and we edit collaboratively. Both these allow to actually work together and, more importantly, think together.

That's very interesting. I honestly didn't think of that, since we often worked asynchronously or at the same machine (which doesn't work at the moment, of course). I can see how Overleaf can be nice for that purpose.

Use pandoc

What is your criticism of LaTeX?

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?

My pick with Latex is: Error messages look to me as complicated as C++ template errors, packages sometimes don't work well together, a lot of boilerplate is usually needed, and I feel somehow the Syntax needs too many keystrokes, like why not make {} for sub and superscript optional and everything until the next space character is sub or superscripted (and not only one character). Also writing {\rm text} feels wrong. Shdnd it be \rm {text} and maybe instead one shd be able to use $ in an equation block to get to a non italic font.

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)

Might the {\rm text} notation be LISP-inspired syntax? Replace the braces with parentheses and remove the slash and you get `(rm text)`

Somehow \mbox is the opposite though (see the examples) : https://www.tutorialspoint.com/tex_commands/mbox.htm

Honestly I think I am missing all the points about brackets in Latex, if somebody knows the Syntax (and the 'why' pls tell me).

> what would you like to see in LaTeX's place?

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'm a heavy LaTeX user, but LaTeX manages to be simultaneously amazing and completely insane.

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.

> - when you encounter an error you have to enter "X". if you're using latexmk, you have to enter "X" multiple times

Seems like you haven't heard of the "-interaction=nonstopmode" flag...

If you're pressing X for each error, this will be life-changing.

Thanks, I have actually never heard of that.

Why redo something if it works? People are still using Fortran because it works well for certain applications. Just because its old doesn't mean its outdated.

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.

Fortran has seen major changes over the 64 years it's been in use. I feel that Emacs Lisp has had a much slower evolution (though admittedly I've only used it for about 20 years, I can't comment on how much it changed prior to that).

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.

> Fortran has seen major changes over the 64 years it's been in use.

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.

My experience with that convinced me that many academic Fortran users are cargo cult programmers to the extreme. They're "taught" by examining the code written by their advisor's advisor's advisor who may have properly learned F77 back in 1980, but no one else did.

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.

> Even then, FORTRAN 77 is a major change over FORTRAN (1957 and even the later FORTRAN 66).

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.

Yep, folks often fail to distinguish between old and OLD.

One might think Eclipse IDE is old. But Fortran predates the three-point seatbelts. The Vietnam War. Berlin Crisis. The Space Race.

Interesting, my experience was the opposite, everyone (1) was writing Fortran 95'ish. Might not have been the most beautiful code, but they took extensive advantage of the major F95 features like modules and array syntax.

(1) Except that one old beard who was convinced F77 was the ultimate, and everything newer was crap.

> 1. A good concurrency model.

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?).

Native comp was merged to the mainline a few months ago. It's behind a config flag `--with-native-compilation`. There is not yet an official release that includes it, but it's fairly common for people to run Emacs built from the mainline source.

> trying to search myriad org agenda files for an ID or text search (e.g. org rifle) will basically lock up emacs.

Please try `org-ql` and `helm-org-ql`; these newer search tools perform better than `org-rifle` and generally supersede it.

Well, Emacs has some major limitations as an editor, places where it really shows its age. Particularly, it is single threaded and this affects many normal uses - for example, while opening a connection to a remote machine with TRAMP, the whole GUI is completely frozen. Similarly with many development tools, such as magit or the excellent lsp-mode (Language Server Protocol support).

Exactly, if it wasn't for the community building and maintaining great packages like org/magit/lsp-mode etc, I would've dumped Emacs long ago. Building that as someone who has other responsibilities than editor hacking is just a non-starter, so I stick with Emacs despite it's event-loop-blocking quirks because of it.

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).

Part of my point was that it's difficult to get into (still worth it overall), but another part is definitely that technology has moved on, and emacs often reminds me of its age there.

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.

I should have clarified...

>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.

It's true that I maybe made it seem a bit too much like emacs itself was outdated. But really I think that it is built on outdated paradigms, which hinders its development and presentation a bit. I was fully serious when I said I cannot imagine switching to anything else (and I'm not afraid of switching otherwise), it's still the best we have in my mind.

There’s at least two ways you could keep the Emacs ecosystem while refreshing some of the other pieces (to build a new editor):

- 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.

> 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.

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.

> entirely different

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.

Reply on news.ycombinator.com