From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel,gmane.emacs.orgmode Subject: Re: Sv: Modularizing Org as GSoC project (was: New Emacs features via Google Summer of Code (or other similar stipend schemes) (was: as for Calc and the math library)) Date: Thu, 22 Aug 2024 12:23:28 +0000 Message-ID: <87r0agbvb3.fsf@localhost> References: <87v7zvay9a.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="550"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" , "emacs-orgmode@gnu.org" To: arthur miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 22 14:23:45 2024 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 1sh6qu-000AUb-Pw for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Aug 2024 14:23:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sh6pp-0007R5-E7; Thu, 22 Aug 2024 08:22:37 -0400 Original-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 1sh6pm-0007QG-7l for emacs-devel@gnu.org; Thu, 22 Aug 2024 08:22:34 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sh6pi-0004Yz-Vn for emacs-devel@gnu.org; Thu, 22 Aug 2024 08:22:33 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C57DC240107 for ; Thu, 22 Aug 2024 14:22:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1724329347; bh=9UEC0uiJRruNtRXOJxAa8rfx3/bvw1o0+NaCcNhLB0M=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=M+E2erolXO0C2U22n6Q1y1z3E2OqkdTUSWgLzx4ljfOoD5bLUyYeRyih7D/NLfXL+ db1gON+m09kiJyruNSKoEbV5l+rlu4XlG4G7uPSSa68a4VgFtJ/mYSLKvoSsSG5kqg Ozb8EBP+/TfpMcy0I5jetgKQxvc+MiySi7N5/cHh9hA6I5YYbjZb7lxtIN0IrXnTaG BRX8O2pknUJpNB3dFLp4tLQhYCuoaPIrKjaidwFpkHm2p+WLe1WnbN+D9Armdh011c p32o8CPYibTTdVxF4Drm/KHKhENnUMr931g1siE0UcLlb2vgRYZ7RqNgd54AkxqZss qvNeIYS2TlsEw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WqMlk4phdz9rxR; Thu, 22 Aug 2024 14:22:26 +0200 (CEST) In-Reply-To: Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:323043 gmane.emacs.orgmode:163009 Archived-At: arthur miller writes: >> Do you want Org markup to be displayed in non-Org buffers? > > Well, part of it. Or more to make some parts of org-markup configurable, and > usable as minor modes so they can be easier used outside of org-mode. This is not the direction Org mode project is going. We do the reverse - Org markup is getting more stable, with the aim to simplify developing third-party parsers and eventually registering Org syntax in IANA MIME db. However, stable Org markup does not mean that we cannot implement Org mode features outside Org mode. Another general direction we are going to is using parser APIs across Org mode. The idea is to encapsulate the fine details of Org markup into the parser, only leaving some very basic structures like recursiveness of markup objects exposed. In theory, one may eventually just replace the parser with, say, Markdown parser (with appropriate API), and get Org mode features in Markdown (well... except that Markdown has fewer kinds of syntax and certain things do not exist there) > For example about links, there could be a mode "text-link-mode" or > "pretty-links-mode" or something, that understands what a link description is, > and what a link itself is. The minor mode would have some mean to parse > description and link parts, and when on it would do what org-toggle-link-display > does. For example org uses angle brackets for link desc and url, whereas > markdown uses angle brackets and parenthesis. Thus link-mode could/should be > enough customizable so that modes could be clients of this minor mode, as well > as for user to be able to setup a regex or set a function that recognizes some > custom syntax for descriptions and links. Also a minor mode can come with a key > map and some actions, for example to follow link, to insert a link etc. I think > of org-links, but a bit more generalized and usable without org-mode > itself. Org-mode could use those under the hood. I am not sure if many places (except Markdown) have a notion of link + description. And the rest is supported by, say, Hyperbole. What might be more interesting is generalizing Org previews: Org can preview LaTeX and images, but we can think of it more generally - any kind of text object might have alternative (possibly image) representation. See https://list.orgmode.org/orgmode/87edbhljr7.fsf@hyperspace/ > Similarly for italics, bolds, underlines, etc. Those could be slightly > generalized and taken out into minor mode. Clients could setup their own > start/end markers and use them to enrich the text on the display instead of > perhaps defining own faces and regexes. I don't know how useful and desirable it > might be in other modes, perhaps in comments in programming languages, or > similar. Just a thought. You are describing font-lock here. Users can already add custom fontification in buffers by supplying regexps + face to be used for specific text fragments. What is the novelty? > org-timestamp interactiveity could be usable elsewhere than just in org > mode. For example I can insert org-timestamp in any mode, but it does work to > use C-left/right to change the date. It could be refactored into small tiny > minor mode timestamp-mode or something, that comes with tis mode map and enable > this interactive stuff. This idea does sound useful. > ascii tables or org tables started as its own mode but got consumed by org. They > are still usable outside of org mode. I can create table with org-table-create > and I can align table with org-table-align, but by default I don't have this > functionality bound in some keymap if I am not in org-mode. Perhaps I am just > not familiar with it. But this could be a minor mode also. See orgtbl-mode. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at