all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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)

  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.