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.goaz...@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.st...@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.he...@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.st...@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.he...@gmail.com>:
>> >>
>> >> On Fri, Nov 27, 2015 at 10:56 AM, Steve Moreau <moreau.st...@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.
>> >>
>> >
>>
>>
>

Reply via email to