From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [RFC] Moving "manual.org" into core Date: Mon, 29 Jan 2018 15:41:34 +0100 Message-ID: <87zi4wpw0x.fsf@nicolasgoaziou.fr> 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egAcx-0004LF-Db for emacs-orgmode@gnu.org; Mon, 29 Jan 2018 09:41:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1egAcs-00018f-Ha for emacs-orgmode@gnu.org; Mon, 29 Jan 2018 09:41:43 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:36519) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1egAcs-00017z-BB for emacs-orgmode@gnu.org; Mon, 29 Jan 2018 09:41:38 -0500 In-Reply-To: (Yasushi SHOJI's message of "Mon, 29 Jan 2018 11:40:24 +0900") 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: Yasushi SHOJI Cc: emacs-org list Hello, Yasushi SHOJI writes: > Do you see this on your env? Or, is it just me? I don't see anything like 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. 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. 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. We could however, un-fill everything. But the output would be very different. So, TRTD is not obvious. > 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. Regards, -- Nicolas Goaziou