From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Gergely Risko Newsgroups: gmane.emacs.devel Subject: Re: find-file-hook, recenter, scroll-conservatively and save-place Date: Thu, 31 Jan 2019 16:31:58 +0100 Message-ID: <87va24u9ld.fsf@errge.nilcons.com> References: <877eelupkc.fsf@errge.nilcons.com> <87zhrhszwf.fsf@errge.nilcons.com> <83womkzy40.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="43534"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: GNU Emacs with Gnus To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 31 16:32:50 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gpEKg-000BBj-5o for ged-emacs-devel@m.gmane.org; Thu, 31 Jan 2019 16:32:50 +0100 Original-Received: from localhost ([127.0.0.1]:56475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gpEKf-0003bL-82 for ged-emacs-devel@m.gmane.org; Thu, 31 Jan 2019 10:32:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gpEJz-0003b4-BS for emacs-devel@gnu.org; Thu, 31 Jan 2019 10:32:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gpEJy-0004xD-3k for emacs-devel@gnu.org; Thu, 31 Jan 2019 10:32:07 -0500 Original-Received: from [195.159.176.226] (port=50624 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gpEJx-0004wq-TT for emacs-devel@gnu.org; Thu, 31 Jan 2019 10:32:06 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1gpEJw-000AFP-HS for emacs-devel@gnu.org; Thu, 31 Jan 2019 16:32:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:p3e/bBkMOXJ1ghotYlsNXl91uWc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232862 Archived-At: Hey Eli, Thanks for your answer, I was aware of the scroll-conservatively = 30 workaround and I think by now I understand the tradeoffs. Let me tell you why I don't like it: if I scroll up by sexps and a big one (>30) is coming, that will cause a recenter, while setting it to 101 will put the sexp to the top of the screen how I expect. Basically I'm after getting rid of these small inconsistencies, that scrolling through a 29 line sexp behaves differently than a 30. I'm not saying this is the end of the world, just saying that it breaks my flow a little and would be interested in a fix. Any opportunity to learn more about Emacs and do some work I take as a positive, not as a cost that I should avoid ;-) > Once upon a time scroll-conservatively only affected scroll commands, > such as scroll-up etc. But then users came up and demanded that this > setting should affect any motion command, including goto-char etc. > What you see is the consequence of that: Emacs does this by popular > demand. Any command that moves point outside of the window will, > under scroll-conservatively > 100, behave like you see, i.e. always > put point on the last or the first window line. Very interesting history, thanks for it! I was not aware. I can understand why users complained, and I think it was the correct reaction of the Emacs maintainers to give in to the popular demand. This is exactly why I love Emacs compared to some other communities, which are tech first, user second... I would imagine that if you interview 100 users about the save-place situation, they will say recenter at least 90 times. On the other hand, they pushed for "scroll-conservatively always" in the past, because they were simply not aware the meaning of that in the case of save-place. Also scroll-conservatively is set to 101 in a lot of starter kits, so making it more compatible with save-place is a worthwhile goal in my book, even if setting to 30 is acceptable. Here is a user complaining and walking away without a solution or any idea what's wrong: https://github.com/syl20bnr/spacemacs/issues/10484 Can you maybe give me some directions and oversight to fix this in a way that is acceptable? I would be willing to work on this for the fun of it. Of course, we would leave the defaults as it is now for other use cases, so the users with pitchforks don't return. ;) What would be an acceptable way? I think by now we have mentioned three completely different approaches at least. Very low level (C): an alternative goto-char that somehow signals the redisplay about how to position the window? (So selectable behavior between the historical and the current one in the API.) Mid-level (Elisp, maybe some C): make recenter callable before we have buffer and window correctly setup and then somehow remember this recenter request for later? (So basically make recenter callable in a find-file-hook) High-level (Elisp only, sounds small and easy): providing the missing find-file-with-window-hook, using some approach from my previous email? > You could perhaps do what you want by some clever one-time setting in > pre-redisplay-functions. But it might not be easy, I'm afraid, > because you'd need to do that in a way that works only the first time > a buffer is displayed whose place was saved by save-place. Yes, I already came up with a workaround: (defvar-local nce/flagged-for-recenter nil) (defun nce/flag-for-recenter () (setq-local nce/flagged-for-recenter t)) (defun nce/recenter-if-flagged () (when nce/flagged-for-recenter (recenter) (setq nce/flagged-for-recenter nil))) (save-place-mode t) (add-hook 'find-file-hook 'nce/flag-for-recenter) (defadvice find-file (after nce/find-file-save-place-ff-fix activate) (nce/recenter-if-flagged)) (defadvice find-file-other-window (after nce/find-file-save-place-ow-fix activate) (nce/recenter-if-flagged)) (defadvice find-file-other-frame (after nce/find-file-save-place-of-fix activate) (nce/recenter-if-flagged)) (defadvice find-file-literally (after nce/find-file-save-place-fl-fix activate) (nce/recenter-if-flagged)) ;; these 2 are required during startup (startup.el uses find-file-noselect directly) (defadvice switch-to-buffer (after nce/find-file-save-place-sb-fix activate) (nce/recenter-if-flagged)) (defadvice switch-to-buffer-other-window (after nce/find-file-save-place-so-fix activate) (nce/recenter-if-flagged)) So basically, this is solution number 3, high level, I provide myself the find-file-with-window-hook with advices. I think this is ugly and I would prefer to get rid of these once I have my shiny Emacs 27. :) I know this sounds like a small problem, but it works for xref, I'm sure we can fix save-place in an acceptable way. Cheers, Gergely