From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Org mode and Emacs (was: Convert README.org to plain text README while installing package) Date: Wed, 08 Jun 2022 08:10:28 +1000 Message-ID: <87r140yuof.fsf@gmail.com> References: <87h74ztshe.fsf@gmx.de> <871qw31ois.fsf@yahoo.com> <8735gj4ceo.fsf@gnu.org> <87ee038ipt.fsf@gmx.de> <87o7z61v59.fsf@gmail.com> <87bkv527p5.fsf@gmail.com> <835yld93w7.fsf@gnu.org> <877d5t0yrn.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27005"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.26; emacs 28.1.50 Cc: Alan Mackenzie , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 08 01:34:53 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nyiiq-0006pt-Ej for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Jun 2022 01:34:52 +0200 Original-Received: from localhost ([::1]:57530 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nyiip-0000LQ-Es for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Jun 2022 19:34:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58834) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyhhJ-0000xA-Ud for emacs-devel@gnu.org; Tue, 07 Jun 2022 18:29:14 -0400 Original-Received: from mail-io1-xd31.google.com ([2607:f8b0:4864:20::d31]:34674) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nyhhI-000898-81 for emacs-devel@gnu.org; Tue, 07 Jun 2022 18:29:13 -0400 Original-Received: by mail-io1-xd31.google.com with SMTP id z197so12875875iof.1 for ; Tue, 07 Jun 2022 15:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=BvNgNiCl+Fpy9sqj/B3Z7GqRMQx4+4x/Jqb4mRyUroM=; b=ZyksUUY0B3oieWK5Mc3Gtm98FW5yk+v6jqCyRouUCXSKOM6XftLMozC9901477CZXz gfK9IKPTJDA/Gwtv08Jo85ejxBFjABDlbypqkHh6v7XSYG1rU5tPMT31dZUDdx0Qfosu gIzOk77ZMaNok6TlrPqbXOtVBDoL4VMQTZGfs2ZNIp6oYRgoDIW25FOcFr1nPI8fZHJN rRJFFMvP37DIR2qHhMb4lc++2kzUIQvxtJyDNY0qfpvgE32y+naEveftlnBFZOD3wZOF 1XVWfXOvsUAzdFWZ4Pd2i4y/LXdHEt/lnhXhjhSmQeo4FsYSNu9Ssu2OKaCzPvEGc21L 6eJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=BvNgNiCl+Fpy9sqj/B3Z7GqRMQx4+4x/Jqb4mRyUroM=; b=F35JzYq/MBXv4dT66MyADmUHxgS1P/9ZveAktTdTBX+55RAtjSWcy/e/Ak/zD/LVc/ 5I8Ym69QdkRXai9IezdP50oQa3dxSjAJE3lW7mioLRKLklPjTiDizOyp39deDcPz8ye6 aJfY5gIib+br8jNjdGjMZ4ZxQawXIj6xkooJujpX1riq99p6mz0+7YUippP9iBjEgE7h eyg7bWB+X3Gs1krXTdow0o1hMx/dsqyi+t1/ATjdBJmonk01X5BrF/38I73pX+atAh7T DX5G7PdNZ2S+s6t1wraY3ihmqdVTMVJB6hCxk1LSBJNSGX5hrY/mVa9Sb9yRfw32Hnxg wnjg== X-Gm-Message-State: AOAM533bQ+05vHetqCqwiGqoXRX4L7doLboz4xGIbV64GH0LOqREmmYw cDpn3gFXSGo3hZNKzIavj+JwVJ5Onhs= X-Google-Smtp-Source: ABdhPJwFfnM6PMHJOg8MrAQe9IguojH0p+39zjZpaWp0HcbQB7xq793+Us+iG/v6sV/CrgTwuzrvuQ== X-Received: by 2002:a05:6a02:11c:b0:3f9:e159:5fa5 with SMTP id bg28-20020a056a02011c00b003f9e1595fa5mr27341707pgb.245.1654640940384; Tue, 07 Jun 2022 15:29:00 -0700 (PDT) Original-Received: from dingbat (2001-44b8-31f2-bb00-ff77-5ac0-4a8a-87f3.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:ff77:5ac0:4a8a:87f3]) by smtp.gmail.com with ESMTPSA id 19-20020a621713000000b0051b8e5d7260sm13612037pfx.49.2022.06.07.15.28.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 15:29:00 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2607:f8b0:4864:20::d31; envelope-from=theophilusx@gmail.com; helo=mail-io1-xd31.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:290889 Archived-At: Stefan Monnier writes: > Rather than try and figure out who's right or wrong, I hope we can take > advantage of this discussion to get some code out that try to solve > the problem. > > AFAICT the problem seen from Emacs, is that Org is large (even for > a basic uses, which occasionally leads to high load times) and that it > doesn't follow all the usual Emacs conventions, such as > overriding/remapping standard key-bindings (the resulting behaviors may > sometimes be similar to the standard one, but even when that's the case > the redefinition can easily bite the user). > > The problem seen from Org is that Emacs doesn't use Org enough :-) > [ This paragraph's shorter length probably reflects the fact that I'm > less familiar with Org than with Emacs. ] > > I think the way forward is to define a "basic org-mode". This one could > be used at many more places where there's currently an occasional desire > to use Org that's resisted because of the above problems. > Ideally, org-mode would then be defined as an extension of this "basic > org-mode". Also ideally some of those extensions would be reworked so > they can be used "Emacs-wide" rather than only in Org (obviously, that > can only make sense for some of them). > > We could start this "basic org-mode" as a trivial copycat of > `outline-mode` and then start adding Org features to it. The driving > constraint is to keep it lightweight and rules-abiding enough that there > won't be any resistance to using it, while at the same time making sure > that the features added to it can be removed from the "org-mode > extension", so that org-mode and "basic org-mode" don't diverge. > > Thanks Stefan and I agree. I also think this is in general exactly the direction current org maintainers/developers are taking. At this point, considerable work is being done (by Ihor and others) to - Implement a concise and efficient parser. This has also involved refining and clarifying org syntax, which has had some holes and ambiguities. - Replace org's largely regexp based font locking mechanism with one based on the parsing and tagging made possible by the org parser. This should improve both performance and accuracy in parsing. - Improving efficiency of folding etc - Improving efficiency with respect to larger org files through the use of caching etc. - Increasing org's use of built-in Emacs capabilities rather than using org specific implementations. For example, adopting transient instead of an org implemented module which replicates similar functionality. - Increase modularity an enable loading of the functionality that you want. In particular, the important work being done by Ihor wrt folding, parsing and caching will provide a core of functionality which can be used to define something like an org minor mode which could be used in those situations where we want some basic org functionality, like folding, navigation and formatting/presentation, but we don't need all the additional advanced features, such as babel, todo and time management, spreadsheets, tables and table formulas etc. Of course, to what extent Emacs will/should leverage off org mode is a completely different debate.