Live data from Hacker News

Toward a “modern” Emacs

lwn.net

531–539 of 539 posts

Re: Toward a “modern” Emacs

#531

Earlier quoted context omitted.

Because it's not core emacs. Core emacs uses ELPA, which has fewer packages.

Don’t you see why that’s a problem? Multiple package managers, with none enabled out of the box, and poor usability?

It's not multiple packages managers, but different sources for packages.

And elpa is enabled out of the box ;-)

Re: Toward a “modern” Emacs

#532
post #504

Earlier quoted context omitted.

I don't think a starter pack that completely disables the "Customize" interface would be a good candidate for default. https://github.com/hlissner/doom-emacs/blob/a2a5038b970df20e... "Doom doesn't support `customize' and it never will. It's a clumsy interface" I find the Customize interface very useful.

It's easier this way for a beginner. Things are consistent; You put `(setq foo bar)` in your config. It's very intuitive. (I have also lost some settings to customize's bugs in Spacemacs.)

And how do you arrive at the correct values for 'foo' and 'bar'?. The key feature of customize is discoverability.

Re: Toward a “modern” Emacs

#533

Earlier quoted context omitted.

Here's what I do in emacs that makes me like it better than vim. If you want to do things like this, you should consider Emacs. If not, you are likely better served by Vim. - I write software with unit tests. I have a custom method bound to Shift-F5 that computes the test file associated with the current code file, and switches to the buffer. - I have a similar method bound to F5 that runs the tests for the current f…

Vim can do all of the above pretty easily. In fact, I have a mapping for json pretty-printing, filtering it with jq; mapping for autoformatting with black or other formatter depending on file type; a plug-in for undo history tree. I don't have configuration for running tests the way you do, but I know a guy who does something very similar in vim. I don't think the things you describe are the differentiators for the G…

> I don't have configuration for running tests the way you do, but I know a guy who does something very similar in vim.

I would love to see that: everyone I know who uses Vim ends up typing out test names in a separate terminal, or running some sort of a shell-out command that suspends editing of the current file until it is complete, and then hides its output.

Re: Toward a “modern” Emacs

#534

Earlier quoted context omitted.

In a generation, vim and emacs will still be around with their minuscule but loyal user bases of tinkerers and VS code will have long been replaced by something newer and flashier.

You're on the right track. There are really 3 editors in the world: Vim, Emacs, and Yes, VSCode will be replaced by something newer and flashier, but the learning curve to switch to it will be minimal.

> Yes, VSCode will be replaced by something newer and flashier, but the learning curve to switch to it will be minimal.

You're on the right track. Its shallow learning curve is itself a significant factor driving its replacement

Re: Toward a “modern” Emacs

#535

Earlier quoted context omitted.

> If only there were projects that repackaged Emacs together with packages which adapt the program for people who prefer other keybindings. And failing that, maybe Emacs should include some facility for remapping key bindings? The sarcasm here isn't warranted, the request wasn't for for distros of emacs to exist, but for them to be promoted to prospective users on the emacs website over a bare install.

My objection isn't to repackaging emacs with new defaults, but promoting forks and such on the emacs site. That's not what GNU does with other forks historically either. What'd be the point of it all? There are perhaps dozens to hundreds of personal takes on emacs on Github and around the web. emacs will remain as it is, it isn't for some people and that's OK.

As I understand it, these distros aren't forks at all. Promoting them would give an emacs beginner a better onboarding experience, and make it less likely that prospective new users give up in frustration.

Re: Toward a “modern” Emacs

#536
post #349

Earlier quoted context omitted.

This kind of ties back in to the point of the article. For people who have used $EDITOR for 20+ years there's little incentive to change to something else, but if you want to bring in fresh eyes to your project so that there'll be enough people around in another 20 years to maintain the whole thing it behoves you to think about attracting those people. Sane defaults and being more approachable is a good way to do tha…

>Does emacs even offer anything like `vimtutor`? https://i.stack.imgur.com/egD8V.jpg That is the splash page that hasn't changed much since 2000. Reading the helpfully highlighted first menu entry do you think that Emacs has a tutorial? Users who can't even be bothered to read the text in front of them are not an asset to a project that doesn't charge them, they are a liability since they force the project in stupid…

I don't follow this stuff closely, but I do have it in my RSS reader.

Here's someone recreating the Space Cadet keyboard key caps -- i.e. the plastic covers for the keys, not the actual keyboard. This is a more modern profile (key shape), rectangular/cylindrical similar to modern keyboards rather than the spherical top of the key like in the 1970s and 1980s.

It might give you an idea how expensive a custom keyboard would be.

https://www.reddit.com/r/MechGroupBuys/comments/j3pmmn/gb_gm...

Re: Toward a “modern” Emacs

#537

Earlier quoted context omitted.

A broke college student with nothing to lose but time and a professional programmer have entirely two different definitions of "painful". A broke college student will spend two weeks learning emacs to avoid paying for a $100 IDE. A professional developer will happily pay for a $100 IDE if it saves him two weeks of time.

It's an investment and the payback is considerable. I can start up emacs in any environment and it works the same. I could go back 20 years and use emacs without trouble. Also I can move around in emacs and do stuff with macros that has saved me a lot of time. And emacs rarely has problems, unlike visual studio, which crashes occasionally and is permanently sending my dual-core to 100% of both. Emacs refactoring, heh…

But you're not going to go back 20 years. No one's going to come along with a time machine and send you back to the year 2000. And, unlike vi, emacs isn't part of the POSIX standard, so your production servers aren't going to have emacs preinstalled. If you're a new programmer, with zero experience, why would you bother learning a program that is going to make you less productive than your peers and isn't going to give you any advantages when you're debugging in production? What exactly is the payoff to this "investment"?

Re: Toward a “modern” Emacs

#538

Earlier quoted context omitted.

A broke college student with nothing to lose but time and a professional programmer have entirely two different definitions of "painful". A broke college student will spend two weeks learning emacs to avoid paying for a $100 IDE. A professional developer will happily pay for a $100 IDE if it saves him two weeks of time.

In this case, it isn't about money, but proficiency.

Proficiency? Proficiency in what? Proficiency in learning a completely irrelevant language to spend two months getting up to the same level everyone else gets to in two weeks?

Re: Toward a “modern” Emacs

#539

Earlier quoted context omitted.

In this case, it isn't about money, but proficiency.

Proficiency? Proficiency in what? Proficiency in learning a completely irrelevant language to spend two months getting up to the same level everyone else gets to in two weeks?

Slower to learn, but with a higher cap, and more likely to endure for four more decades than a given learn-in-two-weeks gui program.
Post reply on HN