Hacker News new | past | comments | ask | show | jobs | submit login

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.

https://github.com/emacs-evil/goto-chg/blob/master/goto-chg....

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 use company with lsp. Perhaps it's dependant on language (server)? I was hacking some Go at the time.


I just tried it, can't reproduce. I'm programming in C++, so different server, but lsp shouldn't really care about the actual upstream server.

How do you open the second buffer visiting the file?


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.


We haven't established that the bug isn't specific to users configuration.


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?


You are probably visiting the same buffer in a different window. What you want is clone-indirect-buffer-other-window.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: