[O] RE: Alinea filling (hanlding of explicit line-breaks)‏

[Vincent Belaïche]

Salut Stéfan,

>>> Actually, no, because paragraph-separate would cause the whole line
>>> that ends with \\ to be treated as not being part of a paragraph, and
>>> paragraph-start wouldn't be appropriate either.  Hence the "good"
>>> above :-(
>[...]
>> I have implemented the thing locally on my machine.  It works well but
>> there is still something missing: the line containing the `\\' alinea
>> separtor is not filled.
> 
>As you can see above, I'm not surprised.
>Just don't use paragraph-separate.  What I'd do is to use
>a fill-forward-paragraph-function which calls forward-paragraph, then
>searches for a "\\\\\\\\$" between the start and end point, and if found
>adjust the end result accordingly.
> 
>If/when you come up with this function, please submit for inclusion in
>tex-mode.el where it will come in handy as well.
> 
>> So, after more thinking about it the problem is the following: the
>> fill-forward-paragraph has only one parameter which is the paragraph
>> number --- with n = 0 => current --- but for finding the paragraph
>> boundary we need *two* parameter
> 
>> => 1st argument: paragraph number
>> => 2nd argument: whether we want to point at the beginning the
>> paragraph or to the end of the paragraph. 
> 
>AFAIK the sign of the argument gives you this information.

Oh, I had missed that. The docstring of forward-paragraph is not very
clear about that.

So, I understand you as follows: basically when you are in the middle of
a paragraph, then -1 and +1 both mean current paragraph, with -1 meaning
beginning of paragraph and and +1 meaning end of paragraph.

But it seems that it does not exactly does the job this way: if the
argument sign is <0 and you are in the middle of a paragraph, then,
unless the paragraph is at beginning of buffer you are going to the
character before the 1st one, rather than to the 1st character of
paragraph.

So, it seems that you are indeed going to and end of paragraph with
arg > 0, but that with arg < 0, the what happens is more fuzzy.

> 
>> => maybe paragraph-separate could be a list of 3 items (REGEXP BEG END)
>>    where REGEXP is the usual regexp matching the separator, and BEG and
>>    END when non nil are function to go the the beginning of next or to
>>    the end of previous assuming that the match data corresponds to a
>>    match of REGEXP. This way would be really the most flexible.
> 
>Could be, but once you're in fill-forward-paragraph-function, you can do
>it by hand with Elisp code, so it's not that important.  If/when we have
>enough fill-forward-paragraph-functions we may revisit this opinion, but
>I don't think we have enough experience yet to make a good design.
> 

You are right, this can be done by implementing
fill-forward-paragraph-function accordingly. My idea was just to use the
same forward-paragraph engine for paragraph motion and for paragraph
filling, so the fill-forward-paragraph-function would just have been
some wrapper to call forward-paragraph with the correct parameters for
filling. 

Now, I am a bit confused about what should be the correct behaviour of
the fill-forward-paragraph-function: is that the following:

- arg < 0: goto beginning of paragraph arg+1, with paragraph 0 = current

- arg > 0 : goto beginning of paragraph arg-1, with paragraph 0 =
            current

Where:

- beginning = point to 1st character of paragraph,
- end = point to next character to last character of paragraph
      (typically the `\n' at the end of paragraph is part of this
      paragraph).

> 
>        Stefan

  Vincent.