Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bad NEWS, Emacs

eshelyaron.com

Post reply on HN
Print view View original

241–250 of 250 posts

Re: Bad NEWS, Emacs

#241

Post by kazinator »

mtraven wrote: post #111

Seriously, WTF? The whole point of Emacs is that it is a radically customizable platform, and if you don't like the behavior of some feature you can modify it yourself with a few lines of Lisp. Forking the whole project over a change to one obscure feature makes zero sense. Status: Emacs user since it was implemented as TECO macros (1981 or so), but I don't use registers.

What's the difference between "modify it yourself" and "fork"?

If this patch sticks, and someone wants it exactly the old way, they basically have to have a local repo of Emacs with the reverse patch applied, and then theirs.

Every time upstream Emacs changes, and they want to pick up the new changes, they have to rebase.

That's a private fork! Forever forked, forever rebasing.

Now you could play it fast and loose and try to monkey patch that; just load your file instead or after the shipped file to redefine the functions. That's still a kind of fork. You have to keep your materials somewhere as a project, and be prepared to adjust them if things change so that the monkey patching breaks in some way.

Re: Bad NEWS, Emacs

#242

Post by kazinator »

3836293648 wrote: post #196
cratermoon wrote: post #133

Earlier quoted context omitted.

You must have missed the part where this change does not include the ability to revert to the old behavior via any settings.

No, they didn't. It's Emacs. Every thing is dynamically scoped lisp. It's like if you could include arbitrary javascript in your vscode config and if you shadow any core function any code calling it will now use your function instead.

How is that not a fork? You have to maintain your function. Upstream can change in ways that your monkey patched function won't work; you have to maintain that going forward.

If you want to share your change with others, you have to ask them: which version of VSCode are you on, and give them the correct monkey patch which worked with that version.

You're doing everything fork-like except calling it a fork.

Re: Bad NEWS, Emacs

#243

Post by kazinator »

domq wrote: post #226
CoastalCoder wrote: post #77

Earlier quoted context omitted.

From the blog post, I couldn't really tell what the author's long term intentions were for his fork. Maybe just to persuade the mainline maintainers?

Forking Emacs on such grounds is a symptom of ego malfunction. The proper step (after diplomacy has failed, which it hasn't yet in this instance) is to author an alternate implementation of the feature in Emacs Lisp and publish it.

Your alternate implementation would have to monkey patch the shipped code. That is a fork in disguise.

Not to repeat myself: https://news.ycombinator.com/item?id=38604600

The easiest way to produce a monkey patch for Emacs which reverts some behavior would be to maintain your own private fork of the repo, where you do a proper job of rebasing, resolving conflicts and validating. Then from that you take the necessary files (all the files that are different from upstream) and produce the hot-load that can be distributed to people. But, totally not a fork, man!

Re: Bad NEWS, Emacs

#244

Post by gnulinux »

kazinator wrote: post #242
3836293648 wrote: post #196

Earlier quoted context omitted.

No, they didn't. It's Emacs. Every thing is dynamically scoped lisp. It's like if you could include arbitrary javascript in your vscode config and if you shadow any core function any code calling it will now use your function instead.

How is that not a fork? You have to maintain your function. Upstream can change in ways that your monkey patched function won't work; you have to maintain that going forward. If you want to share your change with others, you have to ask them: which version of VSCode are you on, and give them the correct monkey patch which worked with that version. You're doing everything fork-like except calling it a fork.

It doesn't need to be a fork, you can have your own emacs config, everybody does. Are you familiar with emacs internals?

Re: Bad NEWS, Emacs

#245

Post by Ferret7446 »

mtraven wrote: post #111

Seriously, WTF? The whole point of Emacs is that it is a radically customizable platform, and if you don't like the behavior of some feature you can modify it yourself with a few lines of Lisp. Forking the whole project over a change to one obscure feature makes zero sense. Status: Emacs user since it was implemented as TECO macros (1981 or so), but I don't use registers.

One of the requirements for a radically customizable platform is that the platform itself must be extremely stable, otherwise everyone has to rewrite/fix every customization every time the platform changes.

Re: Bad NEWS, Emacs

#246

Post by kazinator »

gnulinux wrote: post #244
kazinator wrote: post #242

Earlier quoted context omitted.

How is that not a fork? You have to maintain your function. Upstream can change in ways that your monkey patched function won't work; you have to maintain that going forward. If you want to share your change with others, you have to ask them: which version of VSCode are you on, and give them the correct monkey patch which worked with that version. You're doing everything fork-like except calling it a fork.

It doesn't need to be a fork, you can have your own emacs config, everybody does. Are you familiar with emacs internals?

What morelisp said: https://news.ycombinator.com/item?id=38592976

Re: Bad NEWS, Emacs

#248

Post by wibblewobble125 »

dig1 wrote: post #70

It may be an unpopular approach, but I'm a fan of Linus's "you must never break user-space/UX." Some changes might be trivial for you or even an "improvement" (which is mostly a personal opinion, especially regarding UX, unless you prove it with many research papers or have many complaints). Still, if I hit some key combos 100 times a day in the last 20 years, that became second nature for me. Adding Enter or any oth…

I agree. I’ve been using Emacs for approaching 20 years. In the past few years when I upgrade I’m noticing the same thing. Some font faces have the wrong colors, in one case an actual function was removed and Emacs wouldn’t start, some commands prompt slightly differently. I like to point at Emacs as being like Linux, that it’s a stable platform I can rely on, but do have to admit that more recently I don’t want to upgrade for fear of breakage.

Hell, I’m still on a version of magit from 2014 because they wouldn’t stop moving things around despite it being, in my opinion, done. In all other software in my life I have to put up with things constantly changing for silly reasons, Emacs is the one piece of software where I’m in control.

I fully empathize with the poster being infuriated with changing behavior. I might not agree with the way it’s being expressed. It’s sort of “et tu, Emacs?”

Re: Bad NEWS, Emacs

#249

Post by cratermoon »

3836293648 wrote: post #196
cratermoon wrote: post #133

Earlier quoted context omitted.

You must have missed the part where this change does not include the ability to revert to the old behavior via any settings.

No, they didn't. It's Emacs. Every thing is dynamically scoped lisp. It's like if you could include arbitrary javascript in your vscode config and if you shadow any core function any code calling it will now use your function instead.

You know what? I was wrong, you're right. I thought this was a change to the core engine, but I looked again and see it's in the lisp. The user's ~/.emacs file can override this setting, so no hard fork is needed.

Re: Bad NEWS, Emacs

#250

Post by broscillator »

monsieurbanana wrote: post #42
broscillator wrote: post #34

Earlier quoted context omitted.

with all due respect c-x r s sounds far from smooth and frictionless to me

If you're so used to type C-x that you don't even register it, like most emacs users, then it's just pressing "r s" for "register save". It's not terrible, and the mnemonic is sound. If you don't like it, perfectly valid opinion, you're just not made for emacs' default behavior.

I can think of no instances where I need to press a key and a modifier, a key, and then another key, in any program. If I had any bindings like that in vim I remapped them.

I'm definitely not made for emacs, specially not its pinky :)

Post reply on HN