unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stephen Berman <stephen.berman@gmx.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 13690@debbugs.gnu.org
Subject: bug#13690: 24.3.50; scroll-conservatively and Info-up
Date: Thu, 14 Feb 2013 12:32:23 +0100	[thread overview]
Message-ID: <87sj4zm8qg.fsf@rosalinde.fritz.box> (raw)
In-Reply-To: <83621v4gxl.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Feb 2013 07:12:38 +0200")

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

On Thu, 14 Feb 2013 07:12:38 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 13690@debbugs.gnu.org
>> Date: Thu, 14 Feb 2013 00:18:30 +0100
>> 
>> >   . scroll-conservatively being non-nil
>> 
>> I think you mean non-zero, since only integer values are admissible.
>> But when scroll-conservatively is zero, recentering happens anyway, so I
>> don't see the point of adding this condition.  Or is there a problem is
>> if recentering happens twice (once directly from the display engine and
>> once by explicitly calling recenter)?  I don't notice any problem.
>
> Why recenter twice?  It's a waste of cycles.

Ok.

>> >   . perhaps also scroll-margin being zero, because otherwise you get
>> >     several lines of context before point
>> 
>> I tested scroll-margin and found no difference in the behavior of Info-up
>> whether it is zero or non-zero; do you see something different?
>
> Do you have the latest trunk?  If so, you should see a difference:
> when scroll-margin is N, typing 'u' puts the line with cursor N+1
> lines from the top.

Ah, I just updated and now see it (my previous build was a couple of
days too old).  However, I would prefer for Info-up to recenter even if
scroll-margin is non-zero.  When using C-p or C-n, I can well imagine
wanting the display to start scrolling before point reaches the top or
bottom of the window, i.e., I might want to set scroll-margin to a
non-zero value.  But when I type `u' in Info, I really want to see as
much of the superior node as possible, not just one or two lines above
the target line.  If scroll-margin obeyed SCROLL_LIMIT like
scroll-conservatively does (or perhaps a different limit just for
scroll-margin), this would allow more flexibility.  But in default of
that, and not wanting to complicate things with another user option (at
least until someone screams bloody murder), I would rather omit the
scroll-margin check for now.

2014-02-13  Stephen Berman  <stephen.berman@gmx.net>

	* info.el (Info-up): If scroll-conservatively is non-zero and
	less than 101, display as much of the superior node above the
	target line as possible.  (Bug#13690)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Info-up patch --]
[-- Type: text/x-patch, Size: 896 bytes --]

=== modified file 'lisp/info.el'
*** lisp/info.el	2013-02-14 09:15:55 +0000
--- lisp/info.el	2013-02-14 11:27:50 +0000
***************
*** 2246,2252 ****
  		nil t))
  	  (progn (beginning-of-line) (if (looking-at "^\\* ") (forward-char 2)))
  	(goto-char p)
! 	(Info-restore-point Info-history)))))
  
  (defun Info-history-back ()
    "Go back in the history to the last node visited."
--- 2246,2257 ----
  		nil t))
  	  (progn (beginning-of-line) (if (looking-at "^\\* ") (forward-char 2)))
  	(goto-char p)
! 	(Info-restore-point Info-history))))
!   ;; If scroll-conservatively is non-zerop and less than 101, display
!   ;; as much of the superior node above the target line as possible
!   ;; (bug#13690).
!   (when (and (> scroll-conservatively 0) (< scroll-conservatively 101))
!     (recenter)))
  
  (defun Info-history-back ()
    "Go back in the history to the last node visited."


  reply	other threads:[~2013-02-14 11:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-11 23:24 bug#13690: 24.3.50; scroll-conservatively and Info-up Stephen Berman
2013-02-12 16:14 ` Eli Zaretskii
2013-02-12 22:00   ` Stephen Berman
2013-02-13  4:02     ` Eli Zaretskii
2013-02-13 13:36       ` Stephen Berman
2013-02-13 17:41         ` Eli Zaretskii
2013-02-13 19:02           ` Dmitry Gutov
2013-02-13 21:48             ` Eli Zaretskii
2013-02-14  1:51               ` Dmitry Gutov
2013-02-14  5:16                 ` Eli Zaretskii
2013-02-13 23:18           ` Stephen Berman
2013-02-14  5:12             ` Eli Zaretskii
2013-02-14 11:32               ` Stephen Berman [this message]
2020-08-25 11:31                 ` Lars Ingebrigtsen
2020-08-25 18:02                   ` Stephen Berman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sj4zm8qg.fsf@rosalinde.fritz.box \
    --to=stephen.berman@gmx.net \
    --cc=13690@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).