Well, yes, it's Emacs, we can probably do anything we can imagine, but that's beside the point. This particular behavior is stupidly annoying for both newbies and old-timers.
Even if Emacs works internally with the concept of a "point" that is always set to a position in the visible part of a window, text editors evolved over time to adopt the concept of a "cursor" that always stays in place unless the user moves it. It's about time Emacs adopts the concept too, and sets a well-thought default behavior for it.
> Even if Emacs works internally with the concept of a "point" that is always set to a position in the visible part of a window, text editors evolved over time to adopt the concept of a "cursor" that always stays in place unless the user moves it. It's about time Emacs adopts the concept too, and sets a well-thought default behavior for it.
I'm a Vim user, not an Emacs user, which likely means my opinion isn't worth much; but I think the point I'm about to make is the same.
I use Vim because I like its user interaction paradigm. It is badly out of sync with modern text-editing paradigms, and that's fine. I would be _very_ upset if it started updating to stay relevant. If someone wants an editor that behaves more like modern editors, then they can use a modern editor; and, if they want the best of both worlds, then they can fork Vim and modify it (and there are successful projects doing exactly that). There's no need to modify core Vim to attract new users while alienating old ones.
Establishing better defaults in an application is never a bad move. Power users can still customize things to make them behave in whatever way they want, and newbies benefit from a better default setup. This doesn't mean dumbing down the UX. The goal is to provide a better ramp from newbie to power user, so that newcomers can quickly benefit from some of the cool features without having to study for a week before being able to do the most basic things.
This is how Vim does it, actually. If you keep it in insert mode, it's like a basic text editor, usually with the terminal itself taking care of basic copy-paste. Eventually, people begin dropping out to normal mode to use more and more commands.
I find this kind of thinking interesting. Like Emacs is a bold child that needs to shape up … rather than a conintiually evolving codebase developed by enthusiasts. If it doesn’t do “this thing” it’s probably because it doesn’t need to. There’s probably better ways to do this that experienced users are comfortable with. For the newbies then you only need workarounds to make them comfortable, such as that which I described.
I’m fairly positive 90% of any feature in emacs being unchanged in decades is directly attributable to backwards-compatibility than anything else. With how invasive emac scripts can be, it’s difficult to imagine anything to be changed without forcing the question: is it worth breaking userspace for this?
I don’t think the defaults are good — I suspect they’re stuck.
Why would Emacs turn down the possibility of adopting new user interaction concepts? It's not like we have to choose between "point" and "cursor", both concepts can coexist.
I find it funny to characterize Emacs as "evolving". There's been a lot of internal work, and some new features over the years, but almost all of the evolution happens on the Emacs ecosystem, not in Emacs itself. Core Emacs isn't evolving. Default Emacs is nothing more than a blank slate. And there's no clear, easy way to go from "blank slate" to "useful tool". It's either opting for one of the big config packages such as Spacemacs or Doom Emacs, or keeping Emacs as an Elisp playground (and I'd argue that an Elisp playground isn't a tool anymore, it becomes a goal in itself before it can be useful as a tool).
If you are thinking of a mouse oriented text editing gui where one scrolls with the scroll wheel and then clicks somewhere and starts typing from there this might make perfect sense. In fact you can of course use Emacs like that if you prefer but for keyboard oriented operation it would be absolutely odd if operations that moved the view didn't also move point and in fact other functionality depends on this. Presumably making visual point from internal point different would complexity and work and I have no idea to what end this work would be.
It would be equally weird if scrolling with a mouse wheel worked differently than scrolling with page down for example. In fact in many applications I now realize it does work differently. It's likely that I and many others are not likely to notice because when we do scroll with the scroll wheel in an editable field or document we immediately follow a series of scroll operations with a click in the appropriate location where we intend to insert text. That is to say people are unlikely to exploit the fact that visual point and point are different as a deliberate feature because its awkward. It's spacebar heating.
I would also venture to guess people are vastly more likely to scroll documents in emacs via keys compared to the scroll wheel in part because mouse scrolling emacs isn't awesome. That is a better thing to improve.
Even if Emacs works internally with the concept of a "point" that is always set to a position in the visible part of a window, text editors evolved over time to adopt the concept of a "cursor" that always stays in place unless the user moves it. It's about time Emacs adopts the concept too, and sets a well-thought default behavior for it.