unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Marcin Borkowski <mbork@mbork.pl>
To: Pierre Neidhardt <ambrevar@gmail.com>
Cc: 20663@debbugs.gnu.org
Subject: bug#20663: page.el (forward-page): Avoid skipping pages
Date: Mon, 02 May 2016 22:42:26 +0200	[thread overview]
Message-ID: <87k2jcyyx9.fsf@mbork.pl> (raw)
In-Reply-To: <20160427075738.GA2587@gmail.com>


On 2016-04-27, at 09:57, Pierre Neidhardt <ambrevar@gmail.com> wrote:

> On 16-04-20 09:32:37, Marcin Borkowski wrote:
>> And by the way, the patch the OP gave is also wrong, though in
>> a different way.  (I should have noticed that earlier.)  The OP proposed
>> this instead of (if (bolp) (forward-char 1)):
>> 
>> (if (string= page-delimiter "") (forward-char 1))
>> 
>> Of course, this condition should never be true: if `page-delimiter' is
>> "", functions from page.el will most probably never work correctly
>> anyway.  What (maybe) should have been tested would be
>> 
>> (eq (match-beginning 0) (match-end 0))
>> 
>> but anyway, since Emacs regex engine does not have a lot of zero-width
>> assertions, this is not going to happen very often anyway (certainly
>> never with the default value of `page-delimiter', which explains why the
>> OP hasn't noticed any problems with his patch).  One possible value of
>> `page-delimiter' that comes to my mind which could lead to the above
>> condition holding would be "^$" -- though I can hardly see any practical
>> use for it.
>> 
>> So my proposal would be to just delete the offending line altogether.
>> I'd be very surprised if we heard any complaints afterwards.
>
> Why disallowing "^$" as a page delimiter? I would not use it either, but I can
> fathom that somebody else would. At the end of the day, the page display is like
> colors: a matter of taste. So instead of removing the line, I'd use the
> replacement you suggested.

I'm not saying it should be disallowed.  I'm saying that most probably
it's not very useful, and I'd be surprised if anyone used it.  But
I agree with your suggestion anyway, if only for aesthetical reasons.

>> BTW, the analogous code for moving back one page seems also suspicious
>> to me.  I'll look into it tomorrow.
>
> The code for moving back first skips the page delimiter we are currently on, if
> any. This is not problematic if the page was narrowed down since it is not
> possible to be on the page delimiter at (point-min).
>
> The code looks good to me if we consider that the delimiters belong to the end
> of a page.

I'll try to look at them again.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University





  reply	other threads:[~2016-05-02 20:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-26 17:14 bug#20663: page.el (forward-page): Avoid skipping pages Pierre Neidhardt
2016-04-09 10:13 ` Marcin Borkowski
2016-04-09 12:00   ` Eli Zaretskii
2016-04-09 18:16     ` Marcin Borkowski
2016-04-09 19:34       ` Eli Zaretskii
2016-04-10  1:29         ` Pierre Neidhardt
2016-04-11 10:20           ` Marcin Borkowski
2016-04-11 15:35             ` Eli Zaretskii
2016-04-13 17:53               ` Marcin Borkowski
2016-04-13 20:14                 ` John Mastro
2016-04-13 20:54                   ` Marcin Borkowski
2016-04-16 11:03                 ` Marcin Borkowski
2016-04-16 11:26                 ` Eli Zaretskii
2016-04-20  7:32                   ` Marcin Borkowski
2016-04-27  7:57                     ` Pierre Neidhardt
2016-05-02 20:42                       ` Marcin Borkowski [this message]
2016-06-04  9:55                         ` Pierre Neidhardt
2016-06-04 20:36                           ` Marcin Borkowski
2020-09-15 13:53                             ` Lars Ingebrigtsen
2022-04-22 12:05 ` Lars Ingebrigtsen
     [not found]   ` <87pmjje5mt.fsf@kraus.my>
2022-06-09 10:21     ` Lars Ingebrigtsen

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=87k2jcyyx9.fsf@mbork.pl \
    --to=mbork@mbork.pl \
    --cc=20663@debbugs.gnu.org \
    --cc=ambrevar@gmail.com \
    /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).