From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id aHB7BkLSuWMpdgAAbAwnHQ (envelope-from ) for ; Sat, 07 Jan 2023 21:12:50 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YM8fBkLSuWO7ZQAAauVa8A (envelope-from ) for ; Sat, 07 Jan 2023 21:12:50 +0100 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 E3D701FD0C for ; Sat, 7 Jan 2023 21:12:49 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pEFXt-0003dn-Qs; Sat, 07 Jan 2023 15:12:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pEFXs-0003de-Jw for emacs-orgmode@gnu.org; Sat, 07 Jan 2023 15:12:00 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pEFXq-0006gf-Ri for emacs-orgmode@gnu.org; Sat, 07 Jan 2023 15:12:00 -0500 Received: from localhost ([::ffff:197.239.14.179]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000055DA4.0000000063B9D20F.00003B8A; Sat, 07 Jan 2023 13:11:59 -0700 Date: Sat, 7 Jan 2023 23:07:13 +0300 From: Jean Louis To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org, Message-ID: Mail-Followup-To: Max Nikulin , emacs-orgmode@gnu.org References: <877cy673ot.fsf@localhost> <87edsckkym.fsf@localhost> <87v8lldyco.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, GAPPY_SUBJECT=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no 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: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673122369; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=nHJATVpfqu2T0Fb1UYoJya0ZKtGwHkcqlkiCgxvdTis=; b=gFusditNKUmdtm8cs8xXdP4+serGIJI+gUKq08N1PK9SCXXh8XsKtKgF4NuziXCDEUfC4+ 7RA5lpbuqlz72MWO1iheUjm2hNIb5jgc3FOE1sTWKD/Ozt3kHZ+sYBvXG1RLSTllgLWmgO yLRLo5rZTk1+PWiMnLo1YXwPcMLJiIfqjqVfnjNQXvdvVpUv60buLXMkZaPP7ci+I+VzPE bgX9SL27BO+swsXV417/BmaghCjdTFwCPmN/mL5K8KlEsgZSojxZBjZQU6qgA4kYblO+Yi ih1UkzZ26J6TP+oiucq+I4mqH9GS2DmB6Bwp5p50PgEVfuCmD2mWA31VF1pLHA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673122369; a=rsa-sha256; cv=none; b=C4mqIJQt+kv25Xzpb8wQLkWyXDOSXGuwG7AB66yQCcVRKaJzohK6mUXnz/2CB/3J0Mrtuv MWHjIlkoRMlro0WcnSI03QEaF/0v0b4H9N7jnsD5TF1N45+7u1MQxsTZDVYtto6HF/4Psw TvrQuIOa6kuk4o48iuh7Ad5eOPODs7BJMx1RuZ9z6c6kGTWj3vJ5Nxhp/ZGSEL3/KkABpS be6kg/XZhR9EQX47amXMFfra5fSc6A6E0l8twlr1AXQqv+fYVhQkeWk1sfgmNrd1z2fwOu 5eknu2vCjWLwZCDwj0plYq1BAyazTo2EnRH54VCGlbnn4zgj/+wQZdOFsI73Mg== X-Spam-Score: -2.86 X-Migadu-Queue-Id: E3D701FD0C Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -2.86 X-TUID: RaUqiIHOlj5F * Max Nikulin [2023-01-06 06:30]: > Could you, please, concentrate on your vision of proper > `org-export-registered-backends' design? I leave that to Org developers. That variable is not described well, neither mentioned in Org manual. I can only reiterate my point which you did not understand. In Emacs there are thousands of extensions. There is mainstream Emacs and there are ELPA, and other repositories and all kinds of Emacs packages. Functions found in those packages may be commands (interactive), and it is up to user how to bind those keys. Read (info "(elisp) Key Binding Conventions") Based on that I don't find it consistent that in variable `org-export-registered-backends' Org has something like this: (85 "As UTF-8 buffer" (lambda (a s v b) (org-ascii-export-as-ascii a s v b '(:ascii-charset utf-8)))) as that asks for key probably 85 to be defined for that specific function. And the design of that variable leads to Gordian knot of the tangled code because it demands from all other exporters and extensions to follow that principle. And principle is not consistent to (info "(elisp) Key Binding Conventions") So why do that? I recommend not binding authors of Org export packages to provide keys and let users be free to decide which keys to use for which export. I can think that by clicking first time on a menu item in RCD Org Export, that I can ask user if to assign which key for that export, and remember that option. Provide something like that, a helpful assistance function that when some option is invoked multiple times, that computer may offer to user to assign it permanently to some key. Or when some prefix is invoked that user may decide which key to use, and that key is remembered for next sessions. In general, leave to users how to bind keys. > Do not repeat that blocking menu is not convenient enough sometimes. I am repeating it thousands of times on website pages. If it disturbs you, is personal problem, which I can't help with. Some things don't get done unless points are repeated.. > Say what should be used instead of `org-export-registered-backends'. Before to tell that, you should describe that variable better. "List of backends currently available in the exporter. This variable is set with `org-export-define-backend' and `org-export-define-derived-backend' functions." What I see from RCD Org Export view point is that: - there is variable `org-export-backends' which says which exports are customized by user to be "there". In my case: org-export-backends ➜ (org odt md latex html ascii) - I would like menu in RCD Org Export to appear for those backends which are customized by user. So I have 3 solutions, one is totally independent of Org mainstream, which would simply recognize those to me known exporting functions and show the menu of whatever packages are available for export, and other would be convenient, to recognize what user wants and offer only that. Or combination of those. Sorry, I do not understand why `org-export-backends' do not recognize all the pandoc based exports. I do understand why those exports appear in the org-export-dispatch menu. Is then Org consistent to user that user can turn on, turn off, any export that user wish or want? Or is not consistent? It appears not consistent for ox-pandoc package. If Org is not consistent, then I better build on the external foundation without asking Org variables, but just recognizing which functions already exist. I can as well simply parse variable `org-pandoc-menu-entry' for construction of the menu. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/