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

121–130 of 250 posts

Re: Bad NEWS, Emacs

#121

Post by NeutralForest »

tarsius wrote: post #110

When a breaking change is made on Emacs' development branch, whether intentionally or not, and some users voice concerns about that change, then the change isn't reverted the minute those concerns are raised. The pros and cons are discussed, different solutions are implemented and improved, and finally a compromise is found. Users raising their concern started three days ago. That's not enough for this process to hav…

I'm fully with you here; let the process happen and the discussion between contributors and maintainers happen before talking about "BAD NEWS".

Re: Bad NEWS, Emacs

#122

Post by [deleted] »

smarx007 wrote: post #119

I am sorry but this whole post seems like gaslighting. Looks like maintainers welcomed a patch bringing the old behaviour behind a flag [1]. Eshel Yaron then writes "Sure. I'm attaching two patches", while doing the exact opposite of what was asked, namely undoing the commit that has already landed on the main branch and introducing merely parts [2] of the new behaviour behind the flag. It's totally fine to disagree…

[deleted]

Re: Bad NEWS, Emacs

#123

Post by samus »

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…

Pleasing the newer/younger crowd is important! The default experience of Emacs should make it possible for new users to get up to speed as quickly as possible. Else, Emacs will slowly fade to irrelevance until it is a museum piece. There are of course different views about how to approach this.

Of course, for any change there should be switches or other possibilities to restore the old user experience. Power users (especially of Emacs) can be expected to be able to maintain their init.el file. Even the case of Spacebar Heating[0] could be handled that way. The legacy of a genuine technical bug should not impact the rest of the community forever.

Some might point out that there are Emacs distributions out there that offer a modern experience. But these are hardly known to newcomers. Distribution shopping is a useless distraction before starting to use an editor which already has a higher-than-average learning curve.

[0]: https://xkcd.com/1172/

Re: Bad NEWS, Emacs

#124

Post by samus »

rjzzleep wrote: post #81
lvncelot wrote: post #69

Earlier quoted context omitted.

This is what I've been wondering here, as well. So far, the downsides (Change to an almost subconscious muscle-memory-task, added friction) of this are pretty apparent - what even are the upsides of this?

Attracting new users for with the old behaviour is too complex maybe?

The new behavior doesn't make me want to invest effort in learning registers. A notification in the status bar which register just got filled would be all I want.

Re: Bad NEWS, Emacs

#125

Post by [deleted] »

deng wrote: post #100

Maybe let's keep the drama down a bit? There was a change committed which made using registers more friendly to use for newbies. IMHO, working on making Emacs' features more accessible is a good thing. And yes, this of course annoys old-school Emacs users (including me). AFAICS the discussion is still very much in progress. There will be an option added to be able to revert to the old behavior. There's still discussi…

[deleted]

Re: Bad NEWS, Emacs

#126

Post by deng »

philipwhiuk wrote: post #118
deng wrote: post #100

Maybe let's keep the drama down a bit? There was a change committed which made using registers more friendly to use for newbies. IMHO, working on making Emacs' features more accessible is a good thing. And yes, this of course annoys old-school Emacs users (including me). AFAICS the discussion is still very much in progress. There will be an option added to be able to revert to the old behavior. There's still discussi…

> fail to see why one would need to write a long blog post and maintain a fork because of something like this... Probably because, and it certainly appears the case, that the process is being ruled by fiat not by good technical/policy decisions (and the approach of broadcast is intended to replace the fiat by overwhelming numbers)

And again with the drama...

The maintainer already said: he thought it was a clear improvement, so it landed on master. Now that it has landed and people use it, people react to it, and it turns out the old behavior was well beloved and it's already decided it will stay through an option. Now further details are discussed. This has happened many times before. Just give it a bit of time, voice your opinion, and hopefully a consensus will be achieved (and if not, yes, the maintainer has the last word, that's how it supposed to be).

This is the master branch. It often takes months to flesh out these kind of things. You might say this should be done on a feature branch, but these get used much less and hence you'll get much less feedback.

Re: Bad NEWS, Emacs

#128

Post by samus »

binary132 wrote: post #63

Obviously the only possible solution is to attempt another fork/reimplementation of emacs. This one will definitely win and not be totally irrelevant like all the others.

The impact of these forks is that the community around the main project is slowly eroded. But it doesn't really matter whether the fork brings the main project to the negotiation table. The author of TA is able and is committed to carry and maintain that patch in his local repository until the end of time. What is missing to complete such a fork is publishing that local repository.

Re: Bad NEWS, Emacs

#129

Post by Jochim »

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 get it; this is maybe to please the newer/younger crowd

This seems to miss the point of these changes. If you're only concerned with your own workflow then almost any changes that you didn't specifically request are annoying. However, if you're concerned with the continued development/relevance of the program then it becomes clear that change must occur. Taking into account both existing user's concerns and barriers to entry for new users.

Many of emacs defaults are pretty awful at introducing users to the "emacs" way of doing things while also failing at easing unfamiliar users in.

Re: Bad NEWS, Emacs

#130

Post by PurpleRamen »

jhoechtl wrote: post #10

I someone is to fork Emacs its because of getting proper UI integration or multithreading. This is just a neglectable, whimsical step. Sorry. What Emacs needs is the nvim/vim Schisma.

There are enough unsuccessful forks of GNU Emacs. None of them get enough attention and support for whatever reason, but I guess mainly because there have no real reason to exist. Emacs devs are working diligently and improving it regularly, and there is no good and simple solution for the problems it has.

There won't be any nvim/vim-like Schisma happen, unless some super-dev appears who can outsmart the whole community and it's devs. Maybe, in a decade when AI become good enough and someone feeds Emacs to electron or something like that.

Post reply on HN