From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id +7MnCHMS11/gEgAA0tVLHw (envelope-from ) for ; Mon, 14 Dec 2020 07:21:23 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id PlFsA3MS119XOQAAB5/wlQ (envelope-from ) for ; Mon, 14 Dec 2020 07:21:23 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id ABB1F94042E for ; Mon, 14 Dec 2020 07:21:22 +0000 (UTC) Received: from localhost ([::1]:36330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koiAb-0007D8-9M for larch@yhetil.org; Mon, 14 Dec 2020 02:21:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koi9x-0007Cp-Ca for emacs-orgmode@gnu.org; Mon, 14 Dec 2020 02:20:41 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48073) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koi9w-0003yI-Ps; Mon, 14 Dec 2020 02:20:40 -0500 Received: from lns-bzn-32-82-254-31-120.adsl.proxad.net ([82.254.31.120]:58950 helo=guerry) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1koi9w-0002WX-9T; Mon, 14 Dec 2020 02:20:40 -0500 Received: by guerry (Postfix, from userid 1000) id 555881A60435; Mon, 14 Dec 2020 08:20:38 +0100 (CET) From: Bastien To: TEC Subject: Re: [PATCH] Enhance org-html--build-meta-info References: <87pn6kfr19.fsf@gmail.com> <87v9gcz9ge.fsf@wi.uni-muenster.de> <87lfh8fkj1.fsf@gmail.com> <87zh5n1p3s.fsf@wi.uni-muenster.de> <87tuvl3fyc.fsf@gmail.com> <878scvs0z7.fsf@wi.uni-muenster.de> <87wo0fktjs.fsf@gmail.com> <874knjrtg9.fsf@wi.uni-muenster.de> <87tuvjkqzl.fsf@gmail.com> <87sgb28gd8.fsf@wi.uni-muenster.de> <87blexel9f.fsf@gmail.com> <87im94ordh.fsf@gnu.org> <871rfs6fl0.fsf@gmail.com> Date: Mon, 14 Dec 2020 08:20:38 +0100 In-Reply-To: <871rfs6fl0.fsf@gmail.com> (TEC's message of "Mon, 14 Dec 2020 14:34:28 +0800") Message-ID: <87k0tkam61.fsf@bzg.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jens Lechtenboerger , org-mode-email Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.80 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: ABB1F94042E X-Spam-Score: -2.80 X-Migadu-Scanner: scn1.migadu.com X-TUID: H1hGdUSNU2lb Hi Timothy, TEC writes: >> In a nutshell, can you restate what problem is this patch fixing? > > There are two things I intend to achieve with this patch: > 1. DRY* out the existing code. The existing code is quite repetitive in > structure, and easily lends itself to being extracted to a function. > This is easier to read, and work with IMO. > 2. Make use of the DRYer code in (1) to provide a make the meta building > function more versatile, and then add in the ability for user > customisation at low-cost (again, thanks to (1)). Can we approach this with two patches, one with the refactoring and one with the added functionality? > Necessary? Not really, I mean the export /works/ without it. I'd argue > that it's desirable though, as it provides an easy way for a user (such > as myself) to add useful meta tags not included by default. This sounds useful. >> Are there backward compatibility considerations we should take care of? > > None AFAIK. Barring this errors that Jens raised, and now have hopefully > been addressed, this should function /exactly/ as the current > implementation does, with a minor (beneficial) caveat, mentioned below. > Just with nicer-to-work-with code and a bit more versatility (IMO, of > course). > > These are the two changes to be mentioned: > 1. The (or {title} "Org Export") bit I added. > I believe the current behaviour when no #+title is given is to have a > blank one (""). I think "Org Export" is preferable, as it's more > informative than ... nothing. I think "Org Export" as the default is counter-intuitive, let's stick to the empty string. (Also, this kind of "small" changes should be made with consideration of all exporters.) > 2. Using org-html-encode-plain-text for formatting the content of the > meta tags. From Jens, I take it that the current org-export-data can > cause nested HTML tags, which are invalid in this context. Plain text > should be safer. Yes, this is better. >>> +(defun org-html--build-meta-entry (label identity &optional content-format &rest content-formatters) >>> + "Construct tag with LABEL=\"IDENTITY\" and content from CONTENT-FORMAT and CONTENT-FORMATTER." >> >> The first line of this defun is too long. You can try M-x checkdoc >> RET on your elisp files to catch those issues. >> >> Thanks, > > I see, I'm guessing I'll just need to add a line break. Nope, the first line of a docstring should be a sentence. You'll have to reformulate the beginning of the docstring... Thanks! -- Bastien