From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id YBnYCMtjmWGFXgEAgWs5BA (envelope-from ) for ; Sat, 20 Nov 2021 22:08:27 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 4BWEA8tjmWHoWQAAB5/wlQ (envelope-from ) for ; Sat, 20 Nov 2021 21:08:27 +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 8586210389 for ; Sat, 20 Nov 2021 22:08:26 +0100 (CET) Received: from localhost ([::1]:42590 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1moXaw-0005Z1-Al for larch@yhetil.org; Sat, 20 Nov 2021 16:08:22 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moXYz-0005Yq-49 for emacs-orgmode@gnu.org; Sat, 20 Nov 2021 16:06:21 -0500 Received: from mail.hostpark.net ([212.243.197.30]:48994) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moXYw-0000kV-Ta for emacs-orgmode@gnu.org; Sat, 20 Nov 2021 16:06:20 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 5159F163FC; Sat, 20 Nov 2021 22:06:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from:received :received; s=sel2011a; t=1637442372; bh=elYYHvPbPv6WU4dTbBcYykMy WUeH+bu6pft+R9hy+8o=; b=H6QqaDwx5uArVtI1AHVKWaur6EQdUIAVZA4P2WHM KuT9zLavtkSTPM0WsTsUn6lT9vfWEhEVsOmNJoiNjxZKLqqM0HGA4o1Hbj5BpVxU 0WL1/05B85cRkN9xlHn5C+1Vk1r6sECCxoq0VwWzAujk8jClP8xn8VyeRNYCkCyY QzA= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id po97-d1rSMSc; Sat, 20 Nov 2021 22:06:12 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 21E021647F; Sat, 20 Nov 2021 22:06:12 +0100 (CET) From: Jonas Bernoulli To: Nicolas Goaziou Subject: Re: Merging ox-texinfo+ into ox-texinfo In-Reply-To: <87v90o2tz8.fsf@nicolasgoaziou.fr> References: <87ilx19pjh.fsf@bernoul.li> <87v90o2tz8.fsf@nicolasgoaziou.fr> Date: Sat, 20 Nov 2021 22:06:10 +0100 Message-ID: <8735nq4jwd.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: none client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1637442506; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=eQrezB3Ba661Kk/cqLu+qcXX/GN8Y/v+OZsOb3fp86w=; b=pcWbumRfb1XFhdjGgmLteqot34F0hayBy3e3jeLXrOFuxt7lrCwwk41lPnH/ooOIfuG+AU McNo5suly3iZuISWVHjqpgkygwzKUrFnzWz2S+PPRksCCoz3yPDWqtGoIulTiw0rPm9Eo5 c0KZVi2QPTsQ20mggZMnUPfkGaienIhxaRDiPCcfDC45sv0sLg0OVvzOweastQ/WNR6e14 M2VRY3qYcLXQRe5kkOUItFQ991jE00DVMKMYuM2RegaRZ1vl9IpFhHok4sOQsmA8HaCXu1 Y0NyYfvQxq6dzp312BxhyG4iEGFZI1/Bi16S8LbYfip1pCdv4t8MQt5hFErdZw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1637442506; a=rsa-sha256; cv=none; b=lMCfq57LRAqTIqYIdFape7yxwVB61aLV1WP2BSQflhGEJ5UBNvKvYzmp8U61VC02kKdswn EUWhkgXBum9pyG3ZWQicPM0loFRqs4Jnd2FEjCbxtCyUxKkpwdWfOFavZXDvP4xT2OFgQ0 t5UpMyO4kSIHFQi384NI6pOy5rXsJChkiF97ZEKyvkDhB55+eQWIAYEpco/JwqU/i7eIBq Ug4ZPhDmFLpXNjdbTWXRLn7zRHK+VlR6GuH790S013NTxqE6dKwjFSYKhrOYUjcEmqAvbC S6q+SvN3XrDICopHKmOA38St2+ZXNkeeqMXw4fQpdpBfxnnVrUm5Hy1Di3OsEg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=bernoul.li header.s=sel2011a header.b=H6QqaDwx; 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-Spam-Score: -3.67 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=bernoul.li header.s=sel2011a header.b=H6QqaDwx; dmarc=none; 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: 8586210389 X-Spam-Score: -3.67 X-Migadu-Scanner: scn1.migadu.com X-TUID: ZEzzACW4sXww Nicolas Goaziou writes: > I like the idea, thank you for suggesting it. Great :D >> #+TEXINFO_DEFFN: t > > The chosen UI is rather odd however. I cannot think of another use of > controlling export thhough "#+keyword: boolean" syntax. Usually, we > extend the "options" keyword. It could become, for example: > > #+options: texinfo+:t > > Could it be possible to use that syntax instead? Of course. I probably used the separate keyword because all the entries for ox-texinfo's :options-alist did that too, but if that's not how this is usually done for booleans, then I see no reason not to change it. >> It is possible to mix the two styles; you can use the ox-texinfo+.el >> style for most or all definitions but use the additional flexibility of >> ox-texinfo.el, when that is needed. > > How is it possible? Keywords are global. How do you change value > locally? Well... it turned out not to be true, but I should be able to get it to work. The idea is that the new shorthand handling is only used if such a shorthand is actually used by the item that is being processed. All other list items should effectively be treated as before, but that isn't the case yet. For now all non-shorthand list items are simply treated as @item, but `org-texinfo+-item' could be changed to instead fall back to the `org-texinfo-item's default behavior in those cases. (It would still have to check whether it needs to begin and/or end the "item container" (itemize/table/...), so it is not completely trivial, but should be doable.) For testing purposes I have moved the relevant `ox-texinfo+.el' code into `ox-texinfo.el', changing only how the feature has to be enabled, and everything that worked before continues to work. If the feature is enabled, then my manuals are exported the same as before and with the feature disabled org-manual.org also results in the same texi file as before. So I have to address the above issue and then we also have to think about naming. I was thinking about using the term "shorthands"; instead of "texinfo-deffn:t" we could use "texinfo-shorthands:t". The functions need to be renamed too of course, but IMO simply replacing "ox-texinfo+" with "ox-texinfo-shorthand" is quite ugly. Do you have a suggestion for that? All the new functions could be placed in the "Item" section. Jonas