Re: [RFC] Moving "manual.org" into core

[Yasushi SHOJI <yasushi.shoji@gmail.com>]

Hi,

On Mon, Jan 29, 2018 at 11:41 PM, Nicolas Goaziou
<mail@nicolasgoaziou.fr> wrote:
> Yasushi SHOJI <yasushi.shoji@gmail.com> writes:
>
>> Do you see this on your env?  Or, is it just me?
>
> I don't see anything like this.

Hmm... I don't know how to fix this.

>> I'd like to have the formatter and `fill-paragraph` work in a coherent way.
>> But, if you, who know org much better than me, don't know, I don't think
>> I can help.  Though, just in case, can you elaborate a bit?
>
> The formatter doesn't call `fill-paragraph' at all. No wonder both do
> not work in a way you would expect.

ah, ok.

> The newline characters introduced in the output of the formatter were
> present already in the original text. However, some objects ignore white
> spaces on purpose. For example, [[foo bar]] and [[foo bar]] and [[foo\n
> bar]] are equivalent, so the parser does not retain the distinction
> between them. Hence links are always formatted on a single line.

I see.

> Now, I'm not sure the formatter should call `fill-paragraph', for some
> reasons:
>
> - the original document could be using `visual-line-mode' so there's
>   could be nothing to fill without Org knowing about it;
>
> - Calling `fill-paragraph' requires full fontification, so `org-mode'
>   would be initialised at every paragraph to fill;
>
> - `fill-paragraph' depends heavily on user's configuration (custom link
>   types, `org-fontify-emphasized-text', `org-hide-emphasis-markers',
>   `org-pretty-entities'...) whereas the formatter is expected to be more
>   neutral.

Being neutral is good.

What if _I_, for my own project, want to customize the formatter and like to
call fill-paragraph, can I still do this?

I don't know how `fill-paragraph` works and the second point you listed
above worries me.

With my ignorance, I thought just call org-fill-paragraph. Or, do you
mean that "`org-mode' will be initialized" in `org-fill-paragraph`?

BTW, while reading `org-fill-paragraph`, I found a bug.

#+begin_src emacs-lisp
  (add-to-list 'load-path "~/path/to/orgdir/lisp")
#+end_src

activate the region for the src block above, and do `M-x org-fill-paragraph`.
It will inf-loop because `M-q` moves the cursor back to the beginning of
the middle line.

> We could however, un-fill everything. But the output would be very
> different. So, TRTD is not obvious.

For the default behavior, I don't think that a good idea.

>> Since you fixed the big ones, I can see another issue.  This is also indentation
>> issue, but with a macro replacement .  Somehow, macro replacement
>> gets extra indentation.  Like this:
>
>>       a numeric prefix, check that many days.  For example, {{{kbd(C-1
>> -     C-c / d)}}} shows all deadlines due tomorrow.
>> +          C-c / d)}}} shows all deadlines due tomorrow.
>
> This is related to the explanation above. Macros did the opposite of
> links. The parser didn't remove meaningless spaces upon parsing macros.
> So those would be inserted twice. I fixed this. Now macros show the same
> behaviour as links: even multi-lines macros are inserted as a single
> line.

Thank you for fixing this, too.
-- 
            yashi