Hi,
On Mon, Jan 29, 2018 at 11:41 PM, Nicolas Goaziou
<m...@nicolasgoaziou.fr> wrote:
> Yasushi SHOJI <yasushi.sh...@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
