From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: bug#21818: 24.5; org-set-tags-to indentation problems when called programmatically Date: Fri, 20 Nov 2015 14:19:31 +0100 Message-ID: <87ziy8kduk.fsf@nicolasgoaziou.fr> References: <87r3k7prms.fsf@cersei.i-did-not-set--mail-host-address--so-tickle-me> <83h9l3w1di.fsf@gnu.org> <87bnbbvtkm.fsf@emanuel.industries> <83mvuuvm6j.fsf@gnu.org> <87mvutwa8o.fsf@emanuel.industries> <87d1vo277y.fsf@nicolasgoaziou.fr> <87r3k4ofa9.fsf@nicolasgoaziou.fr> <87egfq7fy9.fsf@gmail.com> <87h9kil72a.fsf@nicolasgoaziou.fr> <874mghrfz4.fsf@emanuel.industries> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzlZb-0006Bs-W7 for emacs-orgmode@gnu.org; Fri, 20 Nov 2015 08:17:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzlZX-0006LY-BS for emacs-orgmode@gnu.org; Fri, 20 Nov 2015 08:17:55 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:34241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzlZX-0006K1-5W for emacs-orgmode@gnu.org; Fri, 20 Nov 2015 08:17:51 -0500 In-Reply-To: <874mghrfz4.fsf@emanuel.industries> (Emanuel Evans's message of "Thu, 19 Nov 2015 10:39:27 -0800") 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Emanuel Evans Cc: emacs-orgmode@gnu.org Emanuel Evans writes: > Nicolas Goaziou writes: > >> I don't consider it to be a bug. >> >> `org-element-interpret-data' produces a string, which is expected to be >> syntactically correct, but doesn't guarantee aesthetics. In particular, >> `org-element-headline-interpreter' tries to align tags as accurately as >> possible, but, in this case, fails to succeed as it would require to >> introduce fontification in the process. This is out of the scope of the >> function. > > Hmmm, that doesn't really make sense to me. Shouldn't the flow of > > 1. Edit a document with org-mode > 2. (org-element-interpret-data (org-element-parse-buffer)) > > be as close to the original as possible? It is already as close to the original as reasonable. The guarantee is that it is syntactically equivalent to the original. Yet, some information is lost in the process. For example, global indentation is not meaningful syntax-wise and not retained in the parse tree. That information is lost. Case (for blocks, properties...) is another example. As you noticed, the same goes for tags' column, under some circumstances. > Seems like the fontification aspect is just an implementation detail. > In any case, I looked more into the code and would be happy to submit > a patch to change it if it makes sense to you. The problem is that the change has a cost. Basically, you need to create a new buffer, switch to Org mode, copy local variables from the original buffer, insert the headline and align the tags properly according to the current fontification rules. OTOH, all you need to from the caller is to re-align the tags after insertion. I suggest to do the latter. Regards,