unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: npostavs@users.sourceforge.net
Cc: ahyatt@gmail.com, 5718@debbugs.gnu.org, gavenkoa@gmail.com
Subject: bug#5718: scroll-margin in buffer with small line count.
Date: Wed, 14 Sep 2016 20:26:57 +0300	[thread overview]
Message-ID: <83zina75pa.fsf@gnu.org> (raw)
In-Reply-To: <874m5j19wi.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net)

> From: npostavs@users.sourceforge.net
> Cc: 5718@debbugs.gnu.org,  ahyatt@gmail.com,  gavenkoa@gmail.com
> Date: Tue, 13 Sep 2016 22:40:29 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> I have a patch set for fixing this and allowing the user to change the
> >> maximum margin from 0.25.  The latter doesn't quite work perfectly, for
> >> some reason when setting the maximum margin to 0.5 and scroll-margin to
> >> 100, `scroll-down-command' doesn't keep point centered in the window,
> >> even though other commands (e.g. `scroll-up-command') do.
> >
> > However, I think we need to solve those glitches as part of
> > introducing the feature.  Setting a margin to half the window size
> > makes centering point difficult, but since some commands do succeed,
> > I'm guessing that those commands which succeed have a bug, i.e. they
> > leave point inside the margin.  Is that indeed so?
> 
> I'm not sure what you mean by "succeed" here.  `next-line',
> `previous-line', and `scroll-up-command' are able to keep point ouside
> of the margin (thus keeping it centered); `scroll-down-command' leaves
> it one line down from where it should be.

I assumed that when maximum margin is set to 0.5, there's no way Emacs
can center point in the window, because wherever it puts point will be
inside the margin.  So therefore, if it sometimes does succeed to
position point, there must be a bug.

However, ...

> Actually, the above applies to windows with an odd number of lines, I
> realized I didn't account for the case of an even number of lines, which
> currently has 0 lines that are outside the margin.  I need to change the
> cap on `max-scroll-margin' to account for this.

... given the above, I now understand that your interpretation of 0.5
is "half the window minus one line", which leaves the center line for
point.  Is that so?

> I hadn't; trying it out now, it seems to cause `next-line' to also have
> the bad behaviour of `scroll-down-command' where point is one line too
> far down.

Some code involved in this probably assumes the margin cannot be that
large.

> > Same here (in another function).
> 
> These are 2 different functions: try_window and try_window_id.

Oops.

Thanks.





  reply	other threads:[~2016-09-14 17:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-14 17:26 bug#5718: scroll-margin in buffer with small line count Oleksandr Gavenko
2016-08-11  4:11 ` Andrew Hyatt
2016-08-11 12:03   ` npostavs
2016-08-11 13:05     ` Oleksandr Gavenko
2016-08-11 13:24       ` Noam Postavsky
2016-08-12  7:54         ` Oleksandr Gavenko
2016-08-11 15:28     ` Eli Zaretskii
2016-08-13 22:01       ` npostavs
2016-08-14  2:36         ` Eli Zaretskii
2016-09-11 20:58           ` npostavs
2016-09-12  6:19             ` martin rudalics
2016-09-14  2:23               ` npostavs
2016-09-14  5:30                 ` martin rudalics
2016-09-12 17:36             ` Eli Zaretskii
2016-09-14  2:40               ` npostavs
2016-09-14 17:26                 ` Eli Zaretskii [this message]
2017-01-03  0:48                   ` npostavs
2017-01-07  8:17                     ` Eli Zaretskii
2017-01-14  4:18                       ` npostavs
2017-01-14  7:58                         ` Eli Zaretskii
2017-01-15 21:43                           ` npostavs
2017-01-16 17:08                             ` Eli Zaretskii
2017-01-21 18:46                               ` npostavs
2017-01-21 19:17                                 ` Eli Zaretskii
2017-01-22 17:21                                   ` npostavs
2017-01-22 17:58                                     ` Eli Zaretskii
2017-01-29  0:57                                       ` npostavs
2017-01-30 15:29                                         ` Eli Zaretskii
2017-01-31  4:52                                           ` npostavs
2017-01-31 15:33                                             ` Eli Zaretskii
2017-02-03  2:40                                               ` npostavs

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=83zina75pa.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=5718@debbugs.gnu.org \
    --cc=ahyatt@gmail.com \
    --cc=gavenkoa@gmail.com \
    --cc=npostavs@users.sourceforge.net \
    /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).