From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 rNYENqDyumPhNgEAbAwnHQ (envelope-from ) for ; Sun, 08 Jan 2023 17:43:13 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id aJqoJ6DyumN/YwAAG6o9tA (envelope-from ) for ; Sun, 08 Jan 2023 17:43:12 +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 6DCF8AA80 for ; Sun, 8 Jan 2023 17:43:12 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pEYka-0004WH-TQ; Sun, 08 Jan 2023 11:42:26 -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 1pEYkS-0004Ua-Qd for emacs-orgmode@gnu.org; Sun, 08 Jan 2023 11:42:16 -0500 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pEYkR-0005aQ-B8 for emacs-orgmode@gnu.org; Sun, 08 Jan 2023 11:42:16 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pEYkL-0008eG-7b for emacs-orgmode@gnu.org; Sun, 08 Jan 2023 17:42:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org, Date: Sun, 8 Jan 2023 23:42:02 +0700 Message-ID: References: <877cy673ot.fsf@localhost> <87edsckkym.fsf@localhost> <87v8lldyco.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.107, FREEMAIL_FROM=0.001, GAPPY_SUBJECT=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=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-Seal: i=1; s=key1; d=yhetil.org; t=1673196192; a=rsa-sha256; cv=none; b=Fp+eVhKsrpEY7HQdhdCd/mNrfoy/jRWHxcYPYoB0sbDR53dpQ230AuCREeZiwyYQxVMwYP vfTvZiDKFtnQc4cz2wuTcz5iD2Oa3s6FmmwdSev3Gk/fs4WtLQg/l6d4MDg7RsrGuLsMQU 7mUZ2rnAmRvlJM2EeoMGVv2+us8UEcQB1J4jbaw3ZCNLYBPkNuJk0T4tEsjElyqRvp/7/c Dgd+4rvr8ENfjrxYs6kwb45SAjfIyDijfYa8ur7xU84Aszni12mL0QojtnornoZUwFGUEb c93qfHnvmwppoV1sBux9VGyZhSCWKmR4BDjQSJ2Kjfbz0e4cAM7Q8xXqEFjmbA== 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=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673196192; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=W1x+ilSkuoKpjeLj33cfLmkhtDvAMJO9AuKtoP7Fam0=; b=KYk9vYKJptDadVcMSI9IKkqldzuYZ9tH0xMqQU4sXZg6WQXtBvBc7LW++/xlQyYLyXneG1 di91HVibRhawD+aXLtwfPXIqhTjYlIVlhr67JOYY/HRNnwwi5/Mq4QISq1CklZLe5KppXZ 3Knybkj0hCtggNpgsyKgK06pbp+gtP2uq5+0LUzT1E3UKJguQz23hFXLnpkW9cMJSmP6iF 4QtVNyfYnlnWRbsHe9ss1YRR0Jn7tWZEFeZBehj1rtSK+rIPhKCuege84oQyBq3+emt4Pz dg5gmBaxLXOJo2B9Ee+nSME0L5crSZ0LumgnQlaDi5rn7WuFdTNm+Hv6ufv40A== X-Spam-Score: -1.57 X-Migadu-Queue-Id: 6DCF8AA80 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=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -1.57 X-TUID: x54ij7C44fko On 08/01/2023 03:07, Jean Louis wrote: > * 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. Org has user manual, but not developer manual. Doesn't `org-export-define-backend' provide enough details concerning `org-export-registered-backends'? Your vision of `org-export-registered-backends' design might shed some light why you consider its design as poor. I do not see any real problem to use it as is with a better menu implementation. > 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. I am aware of it. In the context of export menu, third party package may register their export function. > 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. I do not see any problem. The structure associates export functions, titles and hints for key bindings. It is normal for UI to have accelerator keys. If you do not like suggested key, you are free to override it in your menu framework. What code is tangled from your point of view? In the posted snippet I see a declaration of a function that should be exposed to UI. > 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. Allowing users to customize key bindings is not the same as imposing obligations to choose key bindings. You are free to not provide default key bindings or to shuffle menu entries by popularity for "convenience" in *your* packages. Default keys means consistency for novices and users who do not want to customize such aspects. > And principle is not consistent to (info "(elisp) Key Binding Conventions") I see just a minor issue that ESC ESC does not dismiss menu. C-g still works. Local variables dialog ("do you want to apply...") behaves similar to Org menus. There is enough room for improvements, but I would not call it a great trouble. > I am repeating it thousands of times on website pages. If it disturbs > you, is personal problem, which I can't help with. I do not care what you are posting on some websites. I do not like that in messages sent to my email you are repeating the same obvious ideas even when asked to clarify your particular statements.