From: Marcin Borkowski <mbork@mbork.pl>
To: John Mastro <john.b.mastro@gmail.com>
Cc: 20663@debbugs.gnu.org, ambrevar@gmail.com
Subject: bug#20663: page.el (forward-page): Avoid skipping pages
Date: Wed, 13 Apr 2016 22:54:25 +0200 [thread overview]
Message-ID: <8760vlcjr2.fsf@mbork.pl> (raw)
In-Reply-To: <CAOj2CQTXKvfuQ80D_rjd=BjLkkvpGqD70MuKMLYQqfdg9uZJiA@mail.gmail.com>
On 2016-04-13, at 20:14, John Mastro <john.b.mastro@gmail.com> wrote:
> Marcin Borkowski <mbork@mbork.pl> wrote:
>> My proposal is that a "page separator" would be a position in the buffer
>> where (looking-at-p page-delimiter) is true, and if point is at such
>> a place, then we consider it on the next page. I.e., in this situation
>>
>> abcabcabc
>> -!-^L
>> cbacbacba
>>
>> the point is already on the second page (unlike the default Emacs
>> behavior).
>
> That seems somewhat confusing to me. Intuitively, I would expect the new
> page to start after the delimiter, not immediately before it
>
> For comparison, when (looking-at-p "$") returns non-nil, that means
> point is at the end of the current line (i.e. before the "\n"), not the
> beginning of the next one. (Of course, they're not exactly the same,
> since page-delimiter can match multiple characters.)
Well, I'm fine with that version, too - but I'd insist that we should
settle on _something_ and make it clear in the docs.
BTW, the argument for my variant would be that a new page would always
start at beginning of (some) line (assuming that `page-delimiter' starts
with "^", as it does by default). (I don't claim that it's especially
strong argument, I just wanted to mention it.)
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
next prev parent reply other threads:[~2016-04-13 20:54 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 [this message]
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
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=8760vlcjr2.fsf@mbork.pl \
--to=mbork@mbork.pl \
--cc=20663@debbugs.gnu.org \
--cc=ambrevar@gmail.com \
--cc=john.b.mastro@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).