Toward a "modern" Emacs [LWN.net]

Toward a "modern" Emacs

Posted Sep 26, 2020 11:27 UTC (Sat) by dottedmag (subscriber, #18590)
In reply to: Toward a "modern" Emacs by dskoll
Parent article: Toward a "modern" Emacs

etags means the definitions database is perpetually out of date (unless etags is run every time a file is changed in editor). This is not how computers ought to work in 2020.

to post comments

Toward a "modern" Emacs

Posted Sep 26, 2020 13:00 UTC (Sat) by dskoll (subscriber, #1630) [Link] (2 responses)

I've never found this to be a problem in practice. When you're first navigating a large new software project, you don't change it much and etags is indispensable for navigating it. After that, refreshing a couple of times a day is generally good enough.

Toward a "modern" Emacs

Posted Sep 26, 2020 15:36 UTC (Sat) by dottedmag (subscriber, #18590) [Link] (1 responses)

Have you tried doing any extensive refactoring work on large codebases? It is essential to have up-to-date lists of references, especially in dynamically typed languages, to be productive.

Toward a "modern" Emacs

Posted Sep 26, 2020 21:02 UTC (Sat) by dskoll (subscriber, #1630) [Link]

I have not done extensive refactoring work on large codebases. I have done Linux kernel driver development and development of several quite large systems in languages including C, C++, Perl and PHP. And Emacs has worked very well for me.

Toward a "modern" Emacs

Posted Sep 27, 2020 9:52 UTC (Sun) by pgdx (guest, #119243) [Link] (10 responses)

I have a post-commit-hook in git that runs etags. Keeping each commit relatively small has the added benefit of keeping TAGS up-to-date.

You of course rebase/reorder/reword/squash your history before publishing it if necessary.

Toward a "modern" Emacs

Posted Sep 27, 2020 10:48 UTC (Sun) by dottedmag (subscriber, #18590) [Link] (8 responses)

Post-commit is too coarse.

I don't understand how in 2020 the index is not *always* up-to-date. We've got so much computing power, and we still have to run tools manually over a dataset (source code) that is sized in megabytes, and is modified less than a kilobyte per second?

Toward a "modern" Emacs

Posted Sep 27, 2020 11:55 UTC (Sun) by cmonsanto (subscriber, #96651) [Link] (7 responses)

> I don't understand

There's nothing to understand, it's a technically inferior solution. It was a hassle decades ago, and unacceptable in the age of LSP.

Toward a "modern" Emacs

Posted Sep 27, 2020 11:59 UTC (Sun) by dottedmag (subscriber, #18590) [Link]

Thanks, I was beginning to question my own sanity.

Toward a "modern" Emacs

Posted Sep 27, 2020 14:27 UTC (Sun) by dskoll (subscriber, #1630) [Link] (5 responses)

It's a "technically inferior" solution whose inferiority matters roughly 0.00% of the time, to the nearest hundredth of a percent. This is really nitpicking.

Toward a "modern" Emacs

Posted Sep 27, 2020 15:49 UTC (Sun) by cmonsanto (subscriber, #96651) [Link] (4 responses)

It's not nitpicking. The tags solution requires more work to setup and you get less from it. If it works for you then great, but why would a new user want to learn this arcane workflow when LSP Just Works(tm) in VSCode, the editor everyone else in their office uses? This is what I'm getting at when I say tags are "unacceptable" in this day in age.

Toward a "modern" Emacs

Posted Sep 28, 2020 0:32 UTC (Mon) by dskoll (subscriber, #1630) [Link] (3 responses)

Never having used VSCode before, I gave it a whirl. Fired it up on a directory containing some C sources, installed the C/C++ addon, and...

The cross-referencing didn't work. Every time I tried to jump to the definition of a function, it took me to the declaration instead. So much for "Just Works (tm)".

Toward a "modern" Emacs

Posted Sep 28, 2020 5:14 UTC (Mon) by jem (subscriber, #24231) [Link] (1 responses)

The C/C++/C# extensions for VSCode come from Microsoft. Call me paranoid, but I suspect Microsoft does not really want VSCode to be easy to use on projects using those languages. This because they don't want it to compete with their commercial offering, the original Visual Studio.

Toward a "modern" Emacs

Posted Sep 28, 2020 5:24 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

The original MSVS is 0xDEAD. It's stuck on 32 bits and apparently moving it to 64 bits would be tantamount to rewriting it fully. It's still being developed with incremental features because VSCode is not yet up to feature parity, but that's just a matter of time.

There's no incentive for MS to sabotage VSCode, they want to make sure developers are using Microsoft's tools that conveniently have all these nice out-of-the-box integrations with Microsoft services.

I have no idea what went wrong for you, but my VSCode works just fine with navigation and refactoring support.

Toward a "modern" Emacs

Posted Sep 28, 2020 12:04 UTC (Mon) by dskoll (subscriber, #1630) [Link]

I also investigated using VSCode for Perl development. The Perl extension I found asks you to install (surprise) ctags. So again, meh.

Toward a "modern" Emacs

Posted Sep 28, 2020 13:08 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

So you have to rerun manually when you switch branches? There is also a post-checkout hook too you might want to attach that to.

Toward a "modern" Emacs

Posted Oct 1, 2020 11:54 UTC (Thu) by neilbrown (subscriber, #359) [Link] (1 responses)

I used to use etags extensively when working with code. I recently changed to a different editor which doesn't (yet) support etags, and having missed it at all.
This editor has easy access to "git grep", so I click on a name, "Alt-dot", and up pops a list of matches, which I can select from or walk through. Sometimes finding the declaration among all the uses is tricky, but usually it is no trouble.
The result of "git grep" is always completely up-to-date!

Toward a "modern" Emacs

Posted Oct 1, 2020 14:48 UTC (Thu) by geert (subscriber, #98403) [Link]

Tried that in the days your git (or bk) tree didn't fit in the page cache?
Indexing matters, if your full data set doesn't fit in RAM.
These days we have Google search, which is faster than finding something on your local machine.