unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Richard M. Stallman" <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Clean-up of forward-paragraph [Re: Beginingless paragraphs: second stab at a patch.]
Date: Thu, 20 Oct 2005 00:54:27 -0400	[thread overview]
Message-ID: <E1ESSRf-0006Iz-VG@fencepost.gnu.org> (raw)
In-Reply-To: <Pine.LNX.3.96.1051019154139.277B-100000@acm.acm> (message from Alan Mackenzie on Wed, 19 Oct 2005 16:56:30 +0000 (GMT))

    (i) When there is a left margin, sometimes forward paragraph moves to
    column zero, sometimes to after the margin.  I think it should always
    move to after the margin if it can.  (It can't when the line doesn't
    contain enough whitespace to constitute the margin.)

I am not sure of that.  We have to look at how this affects use of M-h
C-w to move a paragraph, followed by doing M-} M-} M-} C-y to yank it
back in between two other paragraphs.  That is the crucial criterion
for what these commands should do.  So please try that in all the
various cases you can think of, and try to design the behavior of
paragraph starts so that it leads to desirable results in that usage.

    (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.

    (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".  If the fill-prefix is followed by text
that would normally separate or start paragraphs, that does separate
or start paragraphs.  Also, a line that doesn't start with the
fill-prefix separates paragraphs.  So this is three paragraphs
if the fill prefix is "**********".

**********Here is one paragraph
**********in two lines.
**********
**********Here is another paragraph.

**********Here is a third paragraph
**********in two lines.

M-{ and M-} seem to work properly on that text; I see no bug.

    AAMOI (2):  Having told people precisely how to set up
    paragraph-s\(tart\|eparate\), why does forward-paragraph then go to such
    lengths to correct incorrect settings:  It removes spurious leading "^"s
    from these variables, and it combine the two into a regexp for searching,
    even though p-start should match anything that p-separate does.

I think that is for compatibility with old code that used
these variables when they had a different spec.

Please leave this alone.  It would make a bigger transient
and we don't want that now.

    As a first step to fixing the bugs in forward-paragraph, I've cleaned up
    the code somewhat and added some comments (though some of these are
    prolix enough to need removing later on).  The patch below is intended
    only to clean up the code without changing its function.  Should I commit
    this patch?

Not yet.  Please consider the issues above, first.

  reply	other threads:[~2005-10-20  4:54 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 [this message]
2005-10-20 13:53                   ` Alan Mackenzie
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

  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=E1ESSRf-0006Iz-VG@fencepost.gnu.org \
    --to=rms@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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).