From: Alan Mackenzie <acm@muc.de>
Subject: Re: Clean-up of forward-paragraph [Re: Beginingless paragraphs: second stab at a patch.]
Date: Thu, 20 Oct 2005 13:53:18 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.3.96.1051020073728.419B-100000@acm.acm> (raw)
In-Reply-To: <E1ESSRf-0006Iz-VG@fencepost.gnu.org>
On Thu, 20 Oct 2005, Richard M. Stallman wrote:
[ .... ]
> (ii) When `use-hard-newlines' is non-nil (i.e. Longlines Mode is
> enabled), forward-paragraph can spuriously recognise a line "in the
> middle of a paragraph" as a separator line when it "looks like" one.
> (This only shows itself with a non-blank separator line.)
>Sorry, I do not understand.
With the following text line:
First line of paragraph ;sep; second line of par third line
, turn on Longlines Mode. The line acquires two "soft" newlines, and
now looks like this:
First line of paragraph
;sep; second line of par
third line.
The middle line, beginning with ";sep;", is spuriously recognised as a
separator line by paragraph-separate. There is buggy code in
forward-paragraph which tries to detect this situation. I will fix it.
[ .... ]
> (iii) When there is a non-nil fill-prefix, f-p uses it in place of
> paragraph-start when searching backwards, but not when searching
> forwards. Half of these cases is a bug.
>I am not sure either one of them is right. What is right is to
>implement the proper criterion--see the next issue.
> Incidentally: The Elisp manual is a bit unclear on the page
> "Paragraphs", where it says:
> When there is a fill prefix, then paragraphs are delimited by all
> lines which don't start with the fill prefix.
> This doesn't make clear (? clear enough) whether this scheme of
> terminating paragraphs is in addition to or in place of
> paragraph-s\(tart\|eparate\). I think one of the words "also" and
> "instead" should be inserted before "delimited". Which one?
>It should be "in addition".
OK.
>If the fill-prefix is followed by text that would normally separate or start
>paragraphs, that does separate or start paragraphs.
Not quite: in the current implementation, paragraph-start is ignored when
there's a fill-prefix. Non-separator lines without the fill-prefix
always start paragraphs. What I've called "divider" lines below, are
normal separator lines or lines with the prefix which are otherwise
whitespace.
The current implementation doesn't test for paragraph-s\(tart\|eparate\)
on the same line as the fill-prefix. Should it? I'm trying to think of
situations where somebody might want this. Perhaps they'd want an
indentation to start a paragraph. Something like this:
**********last line of paragraph.
********** First line of new paragraph.
I've put together a tentative formulation of paragraph boundaries, (which
doesn't as yet deal with this last situation). Please give me some feedback
on it.
#########################################################################
Definitions:
(i) A @dfn{hard BOL} is the beginning of a line following a hard newline.
(ii) A @dfn{separator (line)} is a line which paragraph-separate matches after
any margin.
(iii) A @dfn{starter (line)} is a line which paragraph-start matches after any
margin, but which isn't a separator;
(iv) A @dfn{divider (line)} is a line which is either a separator or has the
fill-prefix (after any left margin) and is otherwise only whitespace. [This
definition only applies when the fill-prefix is non-null.]
(iv) The beginning and end of (the accessible portion of) the buffer always
count as paragraph boundaries. [From this point on, "ALL paragraph
boundaries" disregards BOB and EOB.]
(v) All other paragraph boundaries are always at BOL, even when there is a
left margin. (This is so that M-h C-w will always grab complete
paragraphs.)
(vi) When `use-hard-newlines' is non-nil, all paragraph boundaries are at hard
BOLs. A paragraph starts at a non-separator line, and ends at the next hard
BOL. Here, fill-prefix and paragraph-start are ignored.
(vii) Otherwise, if fill-prefix is non-null: A paragraph starts at any
non-divider line which either lacks the fill-prefix or follows a divider
line. A paragraph ends at the start of the next paragraph or a divider
line. Here, paragraph-start is ignored.
(viii) Otherwise (fill-prefix is null), a paragraph starts at a non-separator
line which is either a starter line or follows a separator line. It ends
just before the next separator or starter line.
(ix) If there happens to be a blank line before a paragraph start, this line
is NOT regarded as being part of the paragraph. [This is the problem which
was at the heart of this thread.]
#########################################################################
--
Alan Mackenzie (Munich, Germany)
next prev parent reply other threads:[~2005-10-20 13:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-30 10:50 Beginingless paragraphs Alan Mackenzie
2005-08-30 11:48 ` Benjamin Riefenstahl
2005-08-31 14:36 ` Richard M. Stallman
2005-08-31 17:00 ` Eli Zaretskii
2005-08-31 18:11 ` Alan Mackenzie
2005-09-01 15:53 ` Richard M. Stallman
2005-09-01 17:56 ` Alan Mackenzie
2005-09-01 23:17 ` Thien-Thi Nguyen
2005-09-03 1:42 ` Richard M. Stallman
2005-09-03 1:41 ` Richard M. Stallman
2005-09-03 12:26 ` Alan Mackenzie
2005-09-04 16:49 ` Richard M. Stallman
2005-09-07 19:17 ` Beginingless paragraphs: second stab at a patch Alan Mackenzie
2005-09-08 9:04 ` Richard M. Stallman
2005-10-19 16:56 ` Clean-up of forward-paragraph [Re: Beginingless paragraphs: second stab at a patch.] Alan Mackenzie
2005-10-20 4:54 ` Richard M. Stallman
2005-10-20 13:53 ` Alan Mackenzie [this message]
2005-10-21 4:50 ` Richard M. Stallman
2005-10-21 20:09 ` Alan Mackenzie
2005-10-22 15:51 ` Richard M. Stallman
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.3.96.1051020073728.419B-100000@acm.acm \
--to=acm@muc.de \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.