From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 4HucEd0tx2a1UwAA62LTzQ:P1 (envelope-from ) for ; Thu, 22 Aug 2024 12:23:57 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id 4HucEd0tx2a1UwAA62LTzQ (envelope-from ) for ; Thu, 22 Aug 2024 14:23:57 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=M+E2erol; 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=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1724329437; 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=wb04kPG5RzWBL2W6K7J2YeSVU3LMr7dTip1E0pA0tzM=; b=d7RDiFVmJl7Q4QFnJ4UbUENuHYCnyS9z/jXFmUk9sNlfytI7xVfEyTnnLdH79w/E8By1EQ T6jI2WTGzUu9EX4NSYSYn99A6TUu0/XtSDKf30e4tT5wiIP2doCIntVy7OjFdT/xwaEly7 nWOtGHD3lEXWr9gKVXm77rX16z+86l9CWLYLMTNEM7VkszZQ6mq+5lvNwG8SnGr2Maph0+ xkUHhUMogg3f1D8PSDtz1wTnNm6BfmD01JkQMRUTRj2SJUbEwqwv+SZ1vLmlasqeygqlHB HLkTVmcNq6lT1ihMdtz761WvT0IBFHrkop2dr/1uq9Oc3MHeO1WkTMdfvaxEzA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=M+E2erol; 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=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1724329437; a=rsa-sha256; cv=none; b=J1jccBs213R89WiL4Ey0HIXA2AKnEHgXNIKmyx/Io4xTKnfTH/65Ae/joNZub4Awg2ioEi Vx9+cpiFoMiunIZjtVl+41XwRI1NRyu7irf4rjAZTy6JAyD4qJK53duvxyll5+1olsmDcT pzFO1/i024KZwQnRaC8hFlivfx/glRU4qA0r0jMWMWyOf7MEpoVai1sMxuv5awDqm86WDu BEj9jKN8qmval35j+hL8NHWt98aEdiSfGIas/dHoO9gwjHoq0HbdiKPqM6uJ4V6TJvGb2Q /cIm8xBNBgB6AB6aF7KHQWCoqkUn9FG8f8nQEQCvN1KFv6bXc9al9CqNMFiSEQ== 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 2A299602FD for ; Thu, 22 Aug 2024 14:23:57 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sh6pn-0007Qo-JP; Thu, 22 Aug 2024 08:22:35 -0400 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-0007QE-77 for emacs-orgmode@gnu.org; Thu, 22 Aug 2024 08:22:34 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sh6pj-0004Z0-1q for emacs-orgmode@gnu.org; Thu, 22 Aug 2024 08:22:33 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id C05F9240027 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== 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) From: Ihor Radchenko To: arthur miller Cc: "emacs-devel@gnu.org" , "emacs-orgmode@gnu.org" 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)) In-Reply-To: References: <87v7zvay9a.fsf@localhost> Date: Thu, 22 Aug 2024 12:23:28 +0000 Message-ID: <87r0agbvb3.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.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=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: , 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 X-Migadu-Queue-Id: 2A299602FD X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -9.69 X-Spam-Score: -9.69 X-TUID: x1LG0kD3lhUH 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