Moving from org-mode 6.33/7.9.3 to 8.3.2

Moving from org-mode 6.33/7.9.3 to 8.3.2

[Steve Moreau]

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

Hi,

Moving from old org-mode versions (6.33 or 7.9.3f-17-g7524ef) to the latest
stable one currently (8.3.2), I noticed two changes which made me out of my
comfort zone.

   1. Demoting/promoting a header now changes the indentation of text below.
   I reverted to the previous mode with '(setf org-adapt-indentation nil)'
   in ~/.emacs, and that's fine but I mentioned it in case it has an impact on
   point#2.

   2. 'M-x fill-region' does not fill custom lists as before. In the
   previous version, I could select and fill several mixed paragraphs/lists
   directly. For example, filling the following block (without --- separator
   added as a delimiter in this message)
   ---------------
   # a very looooooooooooooooooooooooooooooooooooooooooooooooooooong comment

   a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence that
   should be filled over 2 lines

   - a looooooooooooooooooooooooooooooooooong item that should be filled
   over 2 lines

     - a looooooooooooooooooooooooooooooooooong item that should be filled
   over 2 lines

   a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence that
   should be filled over 2 lines
   ---------------
   resulted in (version 6.33 or 7.9.3):
   ---------------
   # a very looooooooooooooooooooooooooooooooooooooooooooooooooooong comment

   a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence
   that should be filled over 2 lines

   - a looooooooooooooooooooooooooooooooooong item that should be filled
     over 2 lines

     - a looooooooooooooooooooooooooooooooooong item that should be
       filled over 2 lines

   a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence
   that should be filled over 2 lines
   ---------------
   and now results in (version 8.3.2):
   ---------------
   # a very looooooooooooooooooooooooooooooooooooooooooooooooooooong comment

   a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence
   that should be filled over 2 lines

   - a looooooooooooooooooooooooooooooooooong item that should be filled
   over 2 lines

     - a looooooooooooooooooooooooooooooooooong item that should be filled
   over 2 lines

   a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence
   that should be filled over 2 lines
   ---------------

   Lists are not filled anymore and I have to select each list entry and
   fill it individually to get the same output.

So my questions are:

   - Is there any simple way to revert to the previous mode with a variable?
   - Else, could you explain briefly where I should look if I want to
   understand why the filling is skipped in this case, and eventually change
   it if I cannot change my mind and adapt to this different behavior? I had a
   look at function (org.el:23249 org-setup-filling) but I am not sure this is
   the right location.

Thanks, and have a nice day.

[-- Attachment #2: Type: text/html, Size: 3241 bytes --]

Re: Moving from org-mode 6.33/7.9.3 to 8.3.2

[John Hendy]

On Fri, Nov 27, 2015 at 10:56 AM, Steve Moreau <moreau.steve@free.fr> wrote:
> Hi,
>
> Moving from old org-mode versions (6.33 or 7.9.3f-17-g7524ef) to the latest
> stable one currently (8.3.2), I noticed two changes which made me out of my
> comfort zone.
>
> Demoting/promoting a header now changes the indentation of text below.
> I reverted to the previous mode with '(setf org-adapt-indentation nil)' in
> ~/.emacs, and that's fine but I mentioned it in case it has an impact on
> point#2.
>
> 'M-x fill-region' does not fill custom lists as before. In the previous
> version, I could select and fill several mixed paragraphs/lists directly.
> For example, filling the following block (without --- separator added as a
> delimiter in this message)
> ---------------
> # a very looooooooooooooooooooooooooooooooooooooooooooooooooooong comment
>
> a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence that
> should be filled over 2 lines
>
> - a looooooooooooooooooooooooooooooooooong item that should be filled over 2
> lines
>
>   - a looooooooooooooooooooooooooooooooooong item that should be filled over
> 2 lines
>
> a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence that
> should be filled over 2 lines

[snip]

> Lists are not filled anymore and I have to select each list entry and fill
> it individually to get the same output.
>
> So my questions are:
>
> Is there any simple way to revert to the previous mode with a variable?
> Else, could you explain briefly where I should look if I want to understand
> why the filling is skipped in this case, and eventually change it if I
> cannot change my mind and adapt to this different behavior? I had a look at
> function (org.el:23249 org-setup-filling) but I am not sure this is the
> right location.

I don't really have an answer regarding *why*, but I have this in my
.emacs that seems to work with either spaces at the end of your
example above (fills the current line) or with M-x fill-region. Want
to try that? Maybe the new org requires manually setting fill options?

#+begin_src .emacs

;; change 80 to whatever you prefer
(setq-default fill-column 80)
(add-hook 'text-mode-hook 'turn-on-auto-fill)

#+end_src


Hope that helps!
John

>
> Thanks, and have a nice day.

Re: Moving from org-mode 6.33/7.9.3 to 8.3.2

[John Hendy]

On Fri, Nov 27, 2015 at 11:32 AM, John Hendy <jw.hendy@gmail.com> wrote:
> On Fri, Nov 27, 2015 at 10:56 AM, Steve Moreau <moreau.steve@free.fr> wrote:
>> Hi,
>>
>> Moving from old org-mode versions (6.33 or 7.9.3f-17-g7524ef) to the latest
>> stable one currently (8.3.2), I noticed two changes which made me out of my
>> comfort zone.
>>
>> Demoting/promoting a header now changes the indentation of text below.
>> I reverted to the previous mode with '(setf org-adapt-indentation nil)' in
>> ~/.emacs, and that's fine but I mentioned it in case it has an impact on
>> point#2.
>>
>> 'M-x fill-region' does not fill custom lists as before. In the previous
>> version, I could select and fill several mixed paragraphs/lists directly.
>> For example, filling the following block (without --- separator added as a
>> delimiter in this message)
>> ---------------
>> # a very looooooooooooooooooooooooooooooooooooooooooooooooooooong comment
>>
>> a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence that
>> should be filled over 2 lines
>>
>> - a looooooooooooooooooooooooooooooooooong item that should be filled over 2
>> lines
>>
>>   - a looooooooooooooooooooooooooooooooooong item that should be filled over
>> 2 lines
>>
>> a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence that
>> should be filled over 2 lines
>
> [snip]
>
>> Lists are not filled anymore and I have to select each list entry and fill
>> it individually to get the same output.
>>
>> So my questions are:
>>
>> Is there any simple way to revert to the previous mode with a variable?
>> Else, could you explain briefly where I should look if I want to understand
>> why the filling is skipped in this case, and eventually change it if I
>> cannot change my mind and adapt to this different behavior? I had a look at
>> function (org.el:23249 org-setup-filling) but I am not sure this is the
>> right location.
>
> I don't really have an answer regarding *why*, but I have this in my
> .emacs that seems to work with either spaces at the end of your
> example above (fills the current line) or with M-x fill-region. Want
> to try that? Maybe the new org requires manually setting fill options?
>
> #+begin_src .emacs
>
> ;; change 80 to whatever you prefer
> (setq-default fill-column 80)
> (add-hook 'text-mode-hook 'turn-on-auto-fill)
>
> #+end_src

I take that back. It didn't work on the unordered list after all.
Googling around, turns out someone asked about this sort of thing
before (me!):
- http://comments.gmane.org/gmane.emacs.orgmode/76593

In following the thread, it does't seem like there was a
fill-paragraph equivalent that worked on lists. Perhaps someone else
can chime in here on why Org doesn't fill on lists. I get no filling
when running =M-x fill-paragraph= on your example, and it turns it
into a paragraph (ignoring the current "-" bullet structure) using
=M-x fill-region-as-paragraph=.


John

>
>
> Hope that helps!
> John
>
>>
>> Thanks, and have a nice day.

Re: Moving from org-mode 6.33/7.9.3 to 8.3.2

[Steve Moreau]

[-- Attachment #1: Type: text/plain, Size: 4062 bytes --]

To anyone interested in tracking this behavior, here's what I can say for
now.

Filling list in the given example changes* from tag 'release_8.0.7' to tag
'release_8.1'*.

I keep you updated. Have a nice day,

2015-11-27 19:15 GMT+01:00 John Hendy <jw.hendy@gmail.com>:

> Whoops! I swore when I tested that it filled the lists, but you're
> right! Hmm. Just sent a follow-up to the list clarifying that this did
> *not* work, as well as including a link where it turns out I actually
> asked the same thing some 2 years ago! Hope someone chimes in to help
> you out. I definitely would like to use something like this, as when I
> edit lists in my work reports/presentations, I mess up the nicely
> filled original wrapping behavior and I'd like to tidy it back up.
>
>
> John
>
> On Fri, Nov 27, 2015 at 11:54 AM, Steve Moreau <moreau.steve@free.fr>
> wrote:
> > Hi John,
> >
> > Thanks for your answer.
> > You made me discover the auto-fill hook and it works fine both in
> paragraphs
> > and list whatever the number of nested level (list entries).
> > But, if I select all the block and run fill-region (let say after a
> > copy/paste), only the paragraphs are properly filled in my case.
> > I guess it's worth getting a deeper look at the source code. Keep you
> > updated.
> >
> >
> >
> > 2015-11-27 18:32 GMT+01:00 John Hendy <jw.hendy@gmail.com>:
> >>
> >> On Fri, Nov 27, 2015 at 10:56 AM, Steve Moreau <moreau.steve@free.fr>
> >> wrote:
> >> > Hi,
> >> >
> >> > Moving from old org-mode versions (6.33 or 7.9.3f-17-g7524ef) to the
> >> > latest
> >> > stable one currently (8.3.2), I noticed two changes which made me out
> of
> >> > my
> >> > comfort zone.
> >> >
> >> > Demoting/promoting a header now changes the indentation of text below.
> >> > I reverted to the previous mode with '(setf org-adapt-indentation
> nil)'
> >> > in
> >> > ~/.emacs, and that's fine but I mentioned it in case it has an impact
> on
> >> > point#2.
> >> >
> >> > 'M-x fill-region' does not fill custom lists as before. In the
> previous
> >> > version, I could select and fill several mixed paragraphs/lists
> >> > directly.
> >> > For example, filling the following block (without --- separator added
> as
> >> > a
> >> > delimiter in this message)
> >> > ---------------
> >> > # a very looooooooooooooooooooooooooooooooooooooooooooooooooooong
> >> > comment
> >> >
> >> > a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence
> that
> >> > should be filled over 2 lines
> >> >
> >> > - a looooooooooooooooooooooooooooooooooong item that should be filled
> >> > over 2
> >> > lines
> >> >
> >> >   - a looooooooooooooooooooooooooooooooooong item that should be
> filled
> >> > over
> >> > 2 lines
> >> >
> >> > a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence
> that
> >> > should be filled over 2 lines
> >>
> >> [snip]
> >>
> >> > Lists are not filled anymore and I have to select each list entry and
> >> > fill
> >> > it individually to get the same output.
> >> >
> >> > So my questions are:
> >> >
> >> > Is there any simple way to revert to the previous mode with a
> variable?
> >> > Else, could you explain briefly where I should look if I want to
> >> > understand
> >> > why the filling is skipped in this case, and eventually change it if I
> >> > cannot change my mind and adapt to this different behavior? I had a
> look
> >> > at
> >> > function (org.el:23249 org-setup-filling) but I am not sure this is
> the
> >> > right location.
> >>
> >> I don't really have an answer regarding *why*, but I have this in my
> >> .emacs that seems to work with either spaces at the end of your
> >> example above (fills the current line) or with M-x fill-region. Want
> >> to try that? Maybe the new org requires manually setting fill options?
> >>
> >> #+begin_src .emacs
> >>
> >> ;; change 80 to whatever you prefer
> >> (setq-default fill-column 80)
> >> (add-hook 'text-mode-hook 'turn-on-auto-fill)
> >>
> >> #+end_src
> >>
> >>
> >> Hope that helps!
> >> John
> >>
> >> >
> >> > Thanks, and have a nice day.
> >>
> >
>
>

[-- Attachment #2: Type: text/html, Size: 5700 bytes --]

Re: Moving from org-mode 6.33/7.9.3 to 8.3.2

[Steve Moreau]

[-- Attachment #1: Type: text/plain, Size: 5766 bytes --]

Hi,

First, I have been struggling with git since I have no methodology, and I
got lost several times.
But I converged anyway and, as far as I understand, the issue here should
have been introduced in the following commit:

Revision: f3955d5367bd44e98824e3a5bd4b36e06483f4c2
Author: Nicolas Goaziou <n.goaziou@gmail.com>
Date: 2013-06-02 11:12:02 AM
Message:
org.el: Slight change to filling mechanism

* lisp/org.el (org-setup-filling): Set `paragraph-start' and
  `paragraph-separate'.
(org-fill-paragraph-separate-nobreak-p): Remove function.
(org-mode): Do not set `paragraph-start'.
----
Modified: lisp/org.el


Indeed, the org-setup-filling was concerned.

*Before:*

      (append fill-nobreak-predicate
          '(org-fill-paragraph-separate-nobreak-p
            ...

(defvar org-element-paragraph-separate) ; org-element.el
(defun org-fill-paragraph-separate-nobreak-p ()
  "Non-nil when a new line at point would end current paragraph."
  (looking-at (substring org-element-paragraph-separate 1)))

*After:*

'org-fill-paragraph-separate-nobreak-p' predicate removed and the previous
function has been deleted

The following code has been added:

  (let ((paragraph-ending (substring org-element-paragraph-separate 1)))
    (org-set-local 'paragraph-start paragraph-ending)
    (org-set-local 'paragraph-separate paragraph-ending))


Could someone explain to me why the function has been removed?
Thanks a lot for the great job on this wonderful org-mode.
Have a nice day,

Steve




2015-11-28 18:15 GMT+01:00 Steve Moreau <moreau.steve@free.fr>:

> To anyone interested in tracking this behavior, here's what I can say for
> now.
>
> Filling list in the given example changes* from tag 'release_8.0.7' to
> tag 'release_8.1'*.
>
> I keep you updated. Have a nice day,
>
> 2015-11-27 19:15 GMT+01:00 John Hendy <jw.hendy@gmail.com>:
>
>> Whoops! I swore when I tested that it filled the lists, but you're
>> right! Hmm. Just sent a follow-up to the list clarifying that this did
>> *not* work, as well as including a link where it turns out I actually
>> asked the same thing some 2 years ago! Hope someone chimes in to help
>> you out. I definitely would like to use something like this, as when I
>> edit lists in my work reports/presentations, I mess up the nicely
>> filled original wrapping behavior and I'd like to tidy it back up.
>>
>>
>> John
>>
>> On Fri, Nov 27, 2015 at 11:54 AM, Steve Moreau <moreau.steve@free.fr>
>> wrote:
>> > Hi John,
>> >
>> > Thanks for your answer.
>> > You made me discover the auto-fill hook and it works fine both in
>> paragraphs
>> > and list whatever the number of nested level (list entries).
>> > But, if I select all the block and run fill-region (let say after a
>> > copy/paste), only the paragraphs are properly filled in my case.
>> > I guess it's worth getting a deeper look at the source code. Keep you
>> > updated.
>> >
>> >
>> >
>> > 2015-11-27 18:32 GMT+01:00 John Hendy <jw.hendy@gmail.com>:
>> >>
>> >> On Fri, Nov 27, 2015 at 10:56 AM, Steve Moreau <moreau.steve@free.fr>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > Moving from old org-mode versions (6.33 or 7.9.3f-17-g7524ef) to the
>> >> > latest
>> >> > stable one currently (8.3.2), I noticed two changes which made me
>> out of
>> >> > my
>> >> > comfort zone.
>> >> >
>> >> > Demoting/promoting a header now changes the indentation of text
>> below.
>> >> > I reverted to the previous mode with '(setf org-adapt-indentation
>> nil)'
>> >> > in
>> >> > ~/.emacs, and that's fine but I mentioned it in case it has an
>> impact on
>> >> > point#2.
>> >> >
>> >> > 'M-x fill-region' does not fill custom lists as before. In the
>> previous
>> >> > version, I could select and fill several mixed paragraphs/lists
>> >> > directly.
>> >> > For example, filling the following block (without --- separator
>> added as
>> >> > a
>> >> > delimiter in this message)
>> >> > ---------------
>> >> > # a very looooooooooooooooooooooooooooooooooooooooooooooooooooong
>> >> > comment
>> >> >
>> >> > a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence
>> that
>> >> > should be filled over 2 lines
>> >> >
>> >> > - a looooooooooooooooooooooooooooooooooong item that should be filled
>> >> > over 2
>> >> > lines
>> >> >
>> >> >   - a looooooooooooooooooooooooooooooooooong item that should be
>> filled
>> >> > over
>> >> > 2 lines
>> >> >
>> >> > a looooooooooooooooooooooooooooooooooooooooooooooooooooong sentence
>> that
>> >> > should be filled over 2 lines
>> >>
>> >> [snip]
>> >>
>> >> > Lists are not filled anymore and I have to select each list entry and
>> >> > fill
>> >> > it individually to get the same output.
>> >> >
>> >> > So my questions are:
>> >> >
>> >> > Is there any simple way to revert to the previous mode with a
>> variable?
>> >> > Else, could you explain briefly where I should look if I want to
>> >> > understand
>> >> > why the filling is skipped in this case, and eventually change it if
>> I
>> >> > cannot change my mind and adapt to this different behavior? I had a
>> look
>> >> > at
>> >> > function (org.el:23249 org-setup-filling) but I am not sure this is
>> the
>> >> > right location.
>> >>
>> >> I don't really have an answer regarding *why*, but I have this in my
>> >> .emacs that seems to work with either spaces at the end of your
>> >> example above (fills the current line) or with M-x fill-region. Want
>> >> to try that? Maybe the new org requires manually setting fill options?
>> >>
>> >> #+begin_src .emacs
>> >>
>> >> ;; change 80 to whatever you prefer
>> >> (setq-default fill-column 80)
>> >> (add-hook 'text-mode-hook 'turn-on-auto-fill)
>> >>
>> >> #+end_src
>> >>
>> >>
>> >> Hope that helps!
>> >> John
>> >>
>> >> >
>> >> > Thanks, and have a nice day.
>> >>
>> >
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 8163 bytes --]

Re: Moving from org-mode 6.33/7.9.3 to 8.3.2

[Nicolas Goaziou]

Hello,

Steve Moreau <moreau.steve@free.fr> writes:

> Indeed, the org-setup-filling was concerned.
>
> *Before:*
>
>       (append fill-nobreak-predicate
>           '(org-fill-paragraph-separate-nobreak-p
>             ...
>
> (defvar org-element-paragraph-separate) ; org-element.el
> (defun org-fill-paragraph-separate-nobreak-p ()
>   "Non-nil when a new line at point would end current paragraph."
>   (looking-at (substring org-element-paragraph-separate 1)))
>
> *After:*
>
> 'org-fill-paragraph-separate-nobreak-p' predicate removed and the previous
> function has been deleted
>
> The following code has been added:
>
>   (let ((paragraph-ending (substring org-element-paragraph-separate 1)))
>     (org-set-local 'paragraph-start paragraph-ending)
>     (org-set-local 'paragraph-separate paragraph-ending))
>
>
> Could someone explain to me why the function has been removed?

It was removed because `org-element-paragraph-separate' is not enough to
find the boundaries of a paragraph, e.g.,

  - item1
  - item2
  This is a new paragraph

It is usually not a problem except for `fill-region', as you noticed.
However, I do not know how to plug our own functions into `fill-region'.

We could replace `fill-region' with `org-fill-region', tho.


Regards,

-- 
Nicolas Goaziou

Re: Moving from org-mode 6.33/7.9.3 to 8.3.2

[Steve Moreau]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

Hi Nicolas,

Thanks for you answer.
OK, I understand. That explains why I needed to add blank lines between
list items before to fill region, such as:

  - item1

  - item2

  This is a new paragraph

I have 2 more questions for you please.
Let say I would like to give a hand and try to improve the org-fill-region
to deal with this case.
- Would it be local to fill-region only, as I would suspect, or would it
put a mess around because it is used in some other contexts I am not aware
of, and would it be something interesting for the org-mode according to you?
- If you wanted to develop it, would you surround it with a when condition
so that user can disable it?

Thanks,

Steve

2015-11-29 22:43 GMT+01:00 Nicolas Goaziou <mail@nicolasgoaziou.fr>:

> Hello,
>
> Steve Moreau <moreau.steve@free.fr> writes:
>
> > Indeed, the org-setup-filling was concerned.
> >
> > *Before:*
> >
> >       (append fill-nobreak-predicate
> >           '(org-fill-paragraph-separate-nobreak-p
> >             ...
> >
> > (defvar org-element-paragraph-separate) ; org-element.el
> > (defun org-fill-paragraph-separate-nobreak-p ()
> >   "Non-nil when a new line at point would end current paragraph."
> >   (looking-at (substring org-element-paragraph-separate 1)))
> >
> > *After:*
> >
> > 'org-fill-paragraph-separate-nobreak-p' predicate removed and the
> previous
> > function has been deleted
> >
> > The following code has been added:
> >
> >   (let ((paragraph-ending (substring org-element-paragraph-separate 1)))
> >     (org-set-local 'paragraph-start paragraph-ending)
> >     (org-set-local 'paragraph-separate paragraph-ending))
> >
> >
> > Could someone explain to me why the function has been removed?
>
> It was removed because `org-element-paragraph-separate' is not enough to
> find the boundaries of a paragraph, e.g.,
>
>   - item1
>   - item2
>   This is a new paragraph
>
> It is usually not a problem except for `fill-region', as you noticed.
> However, I do not know how to plug our own functions into `fill-region'.
>
> We could replace `fill-region' with `org-fill-region', tho.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
>

[-- Attachment #2: Type: text/html, Size: 3059 bytes --]

Re: Moving from org-mode 6.33/7.9.3 to 8.3.2

[Nicolas Goaziou]

Hello,

Steve Moreau <moreau.steve@free.fr> writes:

> Thanks for you answer.
> OK, I understand. That explains why I needed to add blank lines between
> list items before to fill region, such as:
>
>   - item1
>
>   - item2
>
>   This is a new paragraph
>
> I have 2 more questions for you please.
> Let say I would like to give a hand and try to improve the org-fill-region
> to deal with this case.

Actually, there is nothing to improve. It needs to be built from
scratch. There is no function in Org to fill a region ATM.

> - Would it be local to fill-region only, as I would suspect, or would it
> put a mess around because it is used in some other contexts I am not aware
> of, and would it be something interesting for the org-mode according
> to you?

I think we should bind M-q to org-fill-paragraph. This function could
delegate the work to `org-fill-region' when a region is active.

> - If you wanted to develop it, would you surround it with a when condition
> so that user can disable it?

Why would someone want to disable it?

Regards,

-- 
Nicolas Goaziou

Re: Moving from org-mode 6.33/7.9.3 to 8.3.2

[Steve Moreau]

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

Hello,

Well, actually, it seems that I did not understand anything at all :-)
Sorry about that, but I am new to the source code, and it is not very clear
to me.

So if I try to summarize what I have got:
- In the past, what I could see with the standard 'M-x fill-region' over
paragraphs or lists with empty lines between each inner items, was probably
performed thanks to several calls to org-fill-paragraph. Removing the
org-fill-paragraph-separate-nobreak-p function simply highlights that I was
fortunate to use it this way before, and there is just no org-fill-region.
- There are no unit tests, nor past discussions about how different text
block contents should be filled with this new function

Please tell if I am still wrong, and otherwise I gonna try to implement
some unit tests over different cases I may think about.
Have a nice day,


2015-11-30 15:53 GMT+01:00 Nicolas Goaziou <mail@nicolasgoaziou.fr>:

> Hello,
>
> Steve Moreau <moreau.steve@free.fr> writes:
>
> > Thanks for you answer.
> > OK, I understand. That explains why I needed to add blank lines between
> > list items before to fill region, such as:
> >
> >   - item1
> >
> >   - item2
> >
> >   This is a new paragraph
> >
> > I have 2 more questions for you please.
> > Let say I would like to give a hand and try to improve the
> org-fill-region
> > to deal with this case.
>
> Actually, there is nothing to improve. It needs to be built from
> scratch. There is no function in Org to fill a region ATM.
>
> > - Would it be local to fill-region only, as I would suspect, or would it
> > put a mess around because it is used in some other contexts I am not
> aware
> > of, and would it be something interesting for the org-mode according
> > to you?
>
> I think we should bind M-q to org-fill-paragraph. This function could
> delegate the work to `org-fill-region' when a region is active.
>
> > - If you wanted to develop it, would you surround it with a when
> condition
> > so that user can disable it?
>
> Why would someone want to disable it?
>
> Regards,
>
> --
> Nicolas Goaziou
>
>

[-- Attachment #2: Type: text/html, Size: 2892 bytes --]

Re: Moving from org-mode 6.33/7.9.3 to 8.3.2

[Samuel Wales]

whenever something doesn't fill, i enable filladapt.el.

Re: Moving from org-mode 6.33/7.9.3 to 8.3.2

[Nicolas Goaziou]

Hello,

Steve Moreau <moreau.steve@free.fr> writes:

> - In the past, what I could see with the standard 'M-x fill-region' over
> paragraphs or lists with empty lines between each inner items, was probably
> performed thanks to several calls to org-fill-paragraph.

I don't think so. `fill-region' uses `fill-region-as-paragraph', which
does its own thing. AFACT, it never calls `fill-paragraph-function',
i.e., `org-fill-paragraph'.

> - There are no unit tests, nor past discussions about how different text
>   block contents should be filled with this new function

`org-fill-paragraph' is heavily tested in `test-org/fill-paragraph'.
`org-fill-region' is expected to behave as if `org-fill-paragraph' is
called on every element in the region.

Regards,

-- 
Nicolas Goaziou