Regarding 3. Ability to scroll without bringing point along.
You can duplicate the buffer side by side with the original buffer and in each window point will be at a different location. This is fundamentally just better than such a peek mode as you can see two different segments of the same file side by side. If you do want to peek and return you can use goto-last-change to return to where you were last typing. In evil this is bound to g; no idea about a binding in plain emacs but nothing is stopping you from using and binding such a thing.
You can also use marks in evil m[a-z] to set a mark '[a-z] to go back to that mark. so for example ma 'a to go back.
Consider the alternative. Since you don't want scroll to always leave point behind you must have a special binding to enter peek mode and thereafter you scroll as normal. Then one of two things has to happen. Either you decide point really ought to be here now and you have to hit a key combo bound to end-peek-at-current-location or another key bound to end-peek-return-to-point. I would suggest escape/q for end-peek-return-to-point and return for end-peek-at-current-location. You can also do end-peek-return-to-point if you just start typing obviating the need for an additional binding but I think this would be a little weird because there would be a slight hitch while it pops back to prior location.
The biggest defect with this compared to goto-last-change is that it is ironically given the alternative being part of evil modal. You have to decide to use peek ahead of time and then you have to remember you are in that mode and do something to get out of it should you decide you actually want to do something different like exit with point at the new location. With goto-last-change you don't have to decide ahead of time you can simply decide to go back after the fact without needing to attend to any state in between.
Multiple windows on the same file and marks require attention ahead of time but are far more general and powerful than peeking.
Sometimes what people want and what is most useful are different things. Fortunately Emacs is simple enough and powerful enough for you to implement peek mode trivially if you like but I don't think it would be worth using compared to the alternatives. Logically you could implement it by remembering present point and making local bindings to go back to prior point example esc to go back enter to remove local binding to esc.
>You can duplicate the buffer side by side with the original buffer and in each window point will be at a different location.
I actually attempted that last night. It doesn't work unless you disable completion frameworks like company/LSP because as soon as a completion event triggers, both buffers snap to the completion location.
this is very odd. I both routinely have duplicate buffers visiting the same file and use LSP with company mode. I have never seen the snap effect you are describing. Why would completion trigger in both buffers? Maybe it is company vs ac-mode or some other completion system?
I was unable to reproduce this just now in emacs 26.3 using company/tide. I've been thinking about moving from tide to LSP, but that bug would drive me crazy so maybe I should wait for it to be fixed.
Just tested this with company in a clojure buffer and did not observe this. I would suggest that something else responsible for the effect. Do you have any idea what causes this?
To me this seems like the answer. We don’t need to change the way emacs works, we just need a standard way to do this that is familiar to people coming at emacs from other environments.
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.
https://ftp.gnu.org/old-gnu/Manuals/emacs-20.7/html_chapter/...
> 4. Improve threading so that things like TRAMP didn’t freeze when you were connecting
You really want this, as well as the low level functions to support TRAMP to be written in C.
https://code.visualstudio.com/docs/remote/remote-overview