Live data from Hacker News

Emacs is the 2D Command-line Interface

hongchao.me

151–160 of 180 posts

Re: Emacs is the 2D Command-line Interface

#151

Sometimes I think people trick themselves into thinking that all their fiddling with Emacs counts as part of their productivity. Don't hate on me. I use Emacs just about every day. I used to use Emacs as my go to editor for writing code ... and it almost worked. But it was never hassle free, and things often worked more poorly than I would have liked, or ended up requiring too much fiddling to get it to work right, o…

I'm in the same position. I've used Emacs intensively for 20 years and I'm the author of Emacs packages that other people use. Nowadays I work on Python, Rust, and Typescript/$JSFramework projects. Here are some of the requirememts: - Completions need to take the type system into account (even in Python), etc. - Emacs has to provide intelligent completions, linting, type-checking, compiler error annotations, type inf…

Is Eglot the go-to for LSP in Emacs these days?

Re: Emacs is the 2D Command-line Interface

#152
post #143

Earlier quoted context omitted.

I was fully down the path you're talking about, and would have agreed with you... until COVID happened and I've been stuck working from home on a fairly low bandwidth (rural) Internet connection with source code that can't (because of BigCorp policy) be on my local machine. So it's SSH for most things, and suddenly my 25+ year old emacs skills (such as they are) have come back to be a big help. That and even when I w…

TRAMP used to be my reasons to use emacs too, but VS code's ssh remote plug in is amazing.

Remote SSH plus indexing a code base of my size over a 10mbpsa connection is just... oh nope, no way. Can't even reliably index it locally.

Re: Emacs is the 2D Command-line Interface

#153

This is pretty tangential, but I don't understand why there isn't a roguelike framework available for Emacs. It seems like the perfect roguelike platform for playtesting and hacking on and would on-board a lot of new people into the Emacsen ecology without any real difficulty. The standard roguelike library libtocd has bindings for every other language--why not elisp?

Well, it's not Elisp, but:

https://github.com/Ruin0x11/OpenNefia

It's an engine rewrite of an old roguelike I used to play in Lua. I'm trying to experiment with making a game where the engine is similar in flexibility to Emacs.

It has an Emacs frontend, and I designed it with the zealotry of an Emacs user, meaning it has advice, hooks, interactive evaluation and runtime module hotloading. You can run anything the engine can run from a REPL (and cause all the state to become broken easily).

To be clear, it's not a general-purpose roguelike engine, but it proves that with enough effort such an iterative developer experience of modding a game can be achieved.

Re: Emacs is the 2D Command-line Interface

#154
post #78

Earlier quoted context omitted.

> That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program. My comment had nothing to do with usability. I merely find the incessant comparisons with VSCode to be (mostly) noise. I'm not even here to advocate for Emacs (although I love it). People want better usability? Fine.…

> There is no hard data out there. MELPA has download-numbers. This is hard enouhg to give a rough impression on general package-usage. Looking at them, most people are doing software-work, markdown or enhance emacs itself. Even org-packages have only a rather low usage-number. Which could mean the alternative usages of emacs are all with pre-installed packages or from other sources. Quite possible that there are mil…

> This is hard enouhg to give a rough impression on general package-usage.

Not really, because it doesn't have all the numbers for built-in features. As you noted: A huge number of users use Emacs for org-mode, which is built in, and many don't feel the need to upgrade org mode often (I myself upgrade it once every year or two).

Also, the sets overlap. Those who use, say, lsp-mode may also use mu4e. That lsp-mode may have more downloads doesn't mean a given user used it more.

I myself use Emacs for SW development. Yet the bulk of my Emacs usage is not SW development. It's mail, tracking TODOs, writing notes, keeping track of things, etc.

Re: Emacs is the 2D Command-line Interface

#155
post #139

Earlier quoted context omitted.

> Do we have any hard data here? Or is this just an anecdote? 55% according to the Emacs survey 2020 (obviously, take it with a pinch of self-selection bias due to the survey being self selecting). [1] https://emacssurvey.org/2020/

And yet that same survey says 91% use it for software development, too.

Yet there is no hard data for my claim:

> The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.

I didn't claim most users don't use it for SW development. I didn't even claim most users don't use it primarily for SW development. I said the number of people who primarily use it for other stuff is larger than most people think.

If HN thinks the number is 5%, and in reality it is 20%: The survey does not have data either way.

And as I noted in another post: The survey is flawed in that it didn't contain a representative sample. In particular, people on the Emacs mailing list were quite opposed to filling out the survey, and one of their concerns was what is happening right here: People drawing conclusions from a very poorly executed survey.

Re: Emacs is the 2D Command-line Interface

#156
post #147

Earlier quoted context omitted.

Emacs is your system. You can't integrate all that well in the other direction, because host OS platforms don't let software interop as well. Even the Unix family. The deep interop of course comes at the expense of security. There's no sandboxing or restrictions in Emacs world. One day somebody will release a piece of elisp malware, and a lot of people - myself included - will lose their crown jewels. But until then,…

Actually you can interop in the Unix family, that's what ACME is doing: write specific text to specific files and the content of your editor windows change. That allows the editor to implement any command you could find elsewhere, such as indent, put the contents of a directory, display compile errors...

I didn't realize that. I'll need to dig into ACME (and the history behind its ideas - I suspect there are many gems lost to time, like it is the case with Lisp machines).

> write specific text to specific files

Is that all plaintext, UNIX-style? Part of me wishes we could leave the era of unstructured text, and every tool carrying its own ad-hoc, bug-ridden, poorly specified parser and serialization logic - and send richly typed data structures (or objects) instead.

Re: Emacs is the 2D Command-line Interface

#157
post #116

Earlier quoted context omitted.

Its also a daemon that does a lot of work for me from the shell! I meta-click to capture xterm output, call dired, make it give me popup-windows to edit short scripts and long command lines, i query the feed-reader, get my backup-schedule, have it popup for debrief when new voice notes are downloaded, serve as an emergency window manager, capture into multiple bins while browsing, turn into a presentation tool, creat…

Can you do all of those without emacs ? My point is that yes Emacs can do so many things, but 1) it's all accessible from Emacs only and 2) it uses Emacs-only components. This is fine if you live inside Emacs, but it doesn't really integrate with the rest of your system

That's kind of like asking "Can you do all the cool things Linux provides without installing UNIX?"

Re: Emacs is the 2D Command-line Interface

#158
post #6

I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code, which is vastly more popular. I think what made VSCode popular was the availability of many high-quality extensions for major languages. Unfortunately, my experience with Elisp packages is that they tend to be much less stable. This is changing some with LSP mode, of course, but I think the Emacs community would do well…

From what I can tell, the relative instability of Emacs comes from two things: the lack of well-supported concurrency primitives and defadvice. The former is the source of UI lockups, and if you're really out of luck, you'd have no other choice but to kill the Emacs process. The latter is a footgun in Elisp that allows you to replace or hook into any function defined in Emacs. I think the concurrency problem is solva…

I have to disagree -- in part -- about the advice system: used sparingly, I think it's one of the killer features that lets me tweak emacs exactly how I want it.

That said, yes, I think packages should be (at least) discouraged from using it. A highly dynamic and patch-able software system is a huge asset IF you're the only person working on it, which is true for my own emacs config. But having third parties simultaneously monkeying with the same component without knowing about each other is certainly a recipe for instability, even indeterminism.

Re: Emacs is the 2D Command-line Interface

#159
post #28

Earlier quoted context omitted.

Emacs was 21-ish when vim came along

vi and emacs were released in the same year. The fact that vi iMproved became the dominant implementation isn't particularly relevant here.

> The fact that vi iMproved became the dominant implementation isn't particularly relevant here.

I think it is. Most vim users I know have never used vi and would hate it.

As a reminder: In vi, when you go into "insert" mode, you cannot edit anything prior to where the cursor was when you entered insert mode. vim got rid of such annoyances.

Re: Emacs is the 2D Command-line Interface

#160
post #69
post #59

Earlier quoted context omitted.

Thank you for this thoughtful comment. I assume you are talking about use-package? I've been using it for several years. There is a long standing effort to have it merged into emacs/elpa, so we hope the situation will improve. https://github.com/jwiegley/use-package/issues/282

Yes, I think it should be merged. Although the fact that this has been open since 2015 also highlights how the copyright assignment requirement slows down the pace of development.

Honestly, it's kept me from contributing to packages, too. I have no problem with the outcome, my patch being "owned" by the project -- that would be my intention by contributing.

I just have a strong dislike of bureaucracy, form-filling, and being "on file" somewhere.

Post reply on HN