From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yasushi SHOJI Subject: Re: [RFC] Moving "manual.org" into core Date: Thu, 1 Feb 2018 20:43:06 +0900 Message-ID: References: <87bmhooaj9.fsf@nicolasgoaziou.fr> <87tvveqi7u.fsf@bzg.fr> <87y3kqyp6m.fsf@gmx.us> <87y3kncx6x.fsf@nicolasgoaziou.fr> <87efmcucyw.fsf@nicolasgoaziou.fr> <87bmherp0r.fsf@nicolasgoaziou.fr> <87zi4wpw0x.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehDGo-0005vk-4S for emacs-orgmode@gnu.org; Thu, 01 Feb 2018 06:43:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehDGn-0006sd-1m for emacs-orgmode@gnu.org; Thu, 01 Feb 2018 06:43:10 -0500 Received: from mail-lf0-x236.google.com ([2a00:1450:4010:c07::236]:40710) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ehDGm-0006s4-PC for emacs-orgmode@gnu.org; Thu, 01 Feb 2018 06:43:08 -0500 Received: by mail-lf0-x236.google.com with SMTP id h92so25737253lfi.7 for ; Thu, 01 Feb 2018 03:43:08 -0800 (PST) In-Reply-To: <87zi4wpw0x.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou Cc: emacs-org list Hi, On Mon, Jan 29, 2018 at 11:41 PM, Nicolas Goaziou wrote: > Yasushi SHOJI 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