emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Vincent Belaïche" <vincent.b.1@hotmail.fr>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Org mode <emacs-orgmode@gnu.org>, emacs-devel@gnu.org
Subject: RE: Alinea filling (hanlding of explicit line-breaks)‏
Date: Sun, 13 Mar 2011 16:48:21 +0100	[thread overview]
Message-ID: <8039mrt41m.fsf@gmail.com> (raw)

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.

             reply	other threads:[~2011-03-13 15:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-13 15:48 Vincent Belaïche [this message]
2011-03-13 21:34 ` Alinea filling (hanlding of explicit line-breaks)‏ Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2011-03-13 13:49 Alinea filling (hanlding of explicit line-breaks) Vincent Belaïche
2011-03-12 21:09 Vincent Belaïche
2011-03-13  3:59 ` Stefan Monnier
2011-02-16  6:42 Vincent Belaïche
2011-02-16 15:02 ` Stefan Monnier
2011-02-14 21:30 Vincent Belaïche
2011-02-15 17:22 ` Stefan Monnier
2011-02-13  8:47 Vincent Belaïche
2011-02-14 18:16 ` Stefan Monnier

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.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8039mrt41m.fsf@gmail.com \
    --to=vincent.b.1@hotmail.fr \
    --cc=emacs-devel@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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/org-mode.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).