[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clean-up of forward-paragraph [Re: Beginingless paragraphs: second s
From: |
Richard M. Stallman |
Subject: |
Re: Clean-up of forward-paragraph [Re: Beginingless paragraphs: second stab at a patch.] |
Date: |
Sat, 22 Oct 2005 11:51:18 -0400 |
The problem which started me off on all this was that of a blank line
belonging to two paragraphs, as in the following file:
The bug there is that the blank line is treated as part of the
_preceding_ paragraph. It should be part of the following paragraph,
and _not_ part of the preceding paragraph.
Can you fix that bug in forward-paragraph?
This has been implemented as (forward-paragraph -1) moving to the blank
line. This is a misfeature, IMAO, no matter how long it may have been
so.
I don't think so. I normally want M-{ and M-} to stop in the blank line
between paragraphs. Normally that blank line is a separator, so it
will happen anyway. But as long as that special feature for blank lines
remains, it should apply to M-} and M-{, just as to M-h.
[Suggestions for Emacs 23: "blank line" in the above should be
generalised here to "separator line".
I don't understand what that would mean.
We should make the definition of
paragraph-separate explicitly state that it matches AT MOST a single
line, so that separators can be found reliably whilst searching
backwards.
It can't hurt to add this to the documentation, since that assumption
is already made. We could do it now.
forward/backward-paragraph should be supplemented by (or even
superseded by) beginning/end-of-paragraph, which would work like
b/e-of-defun.
I have nothing against it, but I don't see much use for it,
and there are no keys to put them on.
OK. There are several bugs in forward-paragraph. I will fix them. The
easiest way to fix them is with a thoroughgoing refactoring of the
function (which I have already done). I suspect, though, you will
prefer the basic structure of the code to be left unchanged. Please
confirm or deny this!
For now, I'd rather stick with the basic structure of the code.
After the release, we could refactor it.