From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.orgmode,gmane.emacs.devel Subject: Sv: 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: Fri, 23 Aug 2024 07:15:12 +0000 Message-ID: References: <87v7zvay9a.fsf@localhost> <87r0agbvb3.fsf@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_AS8PR02MB101070F137FA3E05F0170B57596882AS8PR02MB10107eu_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21619"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" , "emacs-orgmode@gnu.org" To: Ihor Radchenko Original-X-From: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Fri Aug 23 09:16:45 2024 Return-path: Envelope-to: geo-emacs-orgmode@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 1shOXL-0005MN-5A for geo-emacs-orgmode@m.gmane-mx.org; Fri, 23 Aug 2024 09:16:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1shOWG-0000ls-8T; Fri, 23 Aug 2024 03:15:36 -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 1shOW4-0000gv-4B; Fri, 23 Aug 2024 03:15:28 -0400 Original-Received: from mail-vi1eur02olkn20819.outbound.protection.outlook.com ([2a01:111:f403:2e07::819] helo=EUR02-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1shOVx-00051L-1s; Fri, 23 Aug 2024 03:15:23 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=etdypzC7j/Z/p8DjEZ72tjhsb9nCwp6zrCdgr6GE4CTrWtxv62B7YRsfADVMKQqkc2veJp0gdDdMFc2ucartCRtXO25jfZ2eWaKPr9HZ2Sj1G8aikyAFzK0vmnLt2wvoklcHNxmPgM4uiEoRQAazf20WY2YPuXod9ZkYUkPDb5Rl5Q7gYLEe6rvyesS2AzSN71AoNN0uNcM+RmLjwsOhrxjgtWscgPoXcHM2ZxK1JsF9OjXTKna+BD/+BYD9NsVmQ8ixFO8M5ht7JxvHu/xSFXAXKENPgMz9i2fDtE8GJrY+RotKZ6UJNCvc0+0NUaWbmIWTgdd2UYH7N3PcHK2P4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Lvxnq7Hl5WM6FMzeaSXzZXDNEE7sXtlQqqDej0sgUok=; b=aueLVwNer8RsBY4H03kg9MaAxjFV55mVvDduurGYzI/I2KTFRjFl3Bk22QILeVjP+NZ+fPipQMTzG+yidhTKDegi4C2A347OhU0ywnIfL2CbcWRPVGpUZq0CAGMjL7/GWOS5CpM+u0DwO+3K+b+slxyM+qLldrWGyj7nsU/Ko2Ha1XUEh7dLAACiX9i/6pm4emlbG1RjY6m70/yq84Et1XMjDXf/ffHfmhhhS38o/tylr2mVxEK1npZY9KgEJ7ljOZOgOqr/gSYGQZVcbxqClOSCV17aKaqUae7g4zshiZK9R+Z+a7ZaA/XO4qWDgYn2/Gv9/fRbbs4BMIkC5AjRKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lvxnq7Hl5WM6FMzeaSXzZXDNEE7sXtlQqqDej0sgUok=; b=g0/wPrcaE19gVu43evDXzkSIiD0PTz1K15WoS1jqkhAABiaC6fg/m5yRtBqC5ByyfIcxRkuOjwSPvKz87rZVm0rZmxrmnWkzmRAn4ZkrZZ9xm27L4q3g3JMCdEX4spEJ2ym2WCBAUtyu4FZJqUAPg11bDJtR84iawu4I27QWnsZJqWFo1UaAJvckJPUeM1RHxBWn8O1fuonNfDllxoW9H6YXs4rln3peB10ywVFTYVy+oC2imz85C3o6vOajydBpNAGWZjFW+sSq3NU1RD0t1tmoS6OWgd89REBaHBQJ8aghuZ8Pt5j0KqreHabtTDtqcJtJC1uqvm/BnoqNUDjnJg== Original-Received: from AS8PR02MB10107.eurprd02.prod.outlook.com (2603:10a6:20b:633::7) by PAWPR02MB8957.eurprd02.prod.outlook.com (2603:10a6:102:331::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7875.21; Fri, 23 Aug 2024 07:15:13 +0000 Original-Received: from AS8PR02MB10107.eurprd02.prod.outlook.com ([fe80::80fe:77a2:35b:dfc]) by AS8PR02MB10107.eurprd02.prod.outlook.com ([fe80::80fe:77a2:35b:dfc%6]) with mapi id 15.20.7897.014; Fri, 23 Aug 2024 07:15:13 +0000 Thread-Topic: 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)) Thread-Index: AQHa8yfrq8RhRSG2qEaX6wx5X1PdNrIxAcTQgAI0GwCAATt+TQ== In-Reply-To: <87r0agbvb3.fsf@localhost> Accept-Language: sv-SE, en-US Content-Language: sv-SE x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [/bJfeMgyzIIBR1TObvnflaK5yV5mjpRB] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS8PR02MB10107:EE_|PAWPR02MB8957:EE_ x-ms-office365-filtering-correlation-id: a74fdb1d-f786-471e-49a7-08dcc3435488 x-microsoft-antispam: BCL:0; ARA:14566002|12050799009|8060799006|461199028|15080799003|19110799003|15030799003|9400799024|3412199025|440099028|4302099013|102099032|1602099012; x-microsoft-antispam-message-info: cg+3kz0/KjdI5qBSNUvcus2Kz4bmkuRQw77A8Y6cyOGPw5u1xonacIq+JroI6+YGUZw7S0zec1NWnHWPqiAqx81VYTK0Z7gh18Uf94GdFEA82B+oeL06SXb0rk5AH0iD2Ls8eOh+GHWnYVsRtSt2gaCPUeGlOY8qrSu60EQAHzrVaA34fAuVoBy+CBpOVvratS8sekunqWfs4SLlIUe0ieBK+WBXN/6TmRU1e/C1+wUzqPgwO2e4d6T8Brj9wjZDQ0GWLmDKtxfShJrc2aYAnTNu1yabaB3yAsBfOhL1PT4ZSefxLQDBeR5167qCGGz/qY5T+gV2FFA33h8tHfu+Gr4PZxSFIEEblT2gCE4N9OxI5rWpP9Q4BEMiIG8Zfy/U0qvTVeC+ne2DsPl7yVw45gnuI9JiCwA+KbkkumgtBYCPUqgfarM3DlaA625EOdajrDKhoRwoJysU00yR1BvgH8ASrScZgOx8nz30REb632J0aBoPGEeMNwj19PbcPB8GEhKZS3KGxRNaGzOAYFNHuACL/t6S92VU8aANKLVAqHBGMO8vPcNlLyikXIRPdxOTxcfb3eyRRfYpWjcOryCQK08OaDR6EioZWDIslM1SYsXFnvj5GqY4EwZB/LUwbIFwfiYqleBzXfw8IG8RwWJitrHiClGmBj4D+Fp1beSDWWP0QGniPKIwMWAMnN56gUkQB6tNOKQXRZ3oEgXQzcn9TkStJ3sCN9PbWjY7fJeOUc0hcFp6kxskCrTUnAlAT Jrck8aKUp1YHJB+ix+hgiwJ/goicBUDcZknL2HbXxJVNZ8fyLAyW5wO2mCEswgTwAiP4vCcdoFWe7txFX0SRAr3cE7DQkFKo56 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?mYJ/d6RkkBg9QM+MBxteJ+eSpUugiMXYCYxhglqr+x1iOtBAi+9hZgdnoX?= =?iso-8859-1?Q?KI7eYr0fo3g+u0l1C7KQHXkcp7UZp2iKsp+D7yhssoKxUKsJCEy68t+I2O?= =?iso-8859-1?Q?R4x6TsJTI7VXXNkNi4iUCdCPKQ+gIxDS5kYBJsjDXgRgy514/YGnPVXwU5?= =?iso-8859-1?Q?PuJAtZorGnYvYTY4lRYvX+eu5EP9VR/ygfWFs8HuXo9SPc/pBqczITV92I?= =?iso-8859-1?Q?ex8vKnys/sdxu4LE5/4MGSgGX/gEAyBphDnqyIV+k63WY/P7da3Kw9xyFM?= =?iso-8859-1?Q?wNTXitnhNcIvd6KonTUW7J61FQp7IRJJZjJh2eWsCvrmg+tKVYUe9D+tMa?= =?iso-8859-1?Q?bF6YxvqhUTGiWkJFLmT4dG7lqjJSUX+xItCxCjlzeEiw+PcMmHx7/4Fz9X?= =?iso-8859-1?Q?uvsjWtQDCF/Zrui+Oz7fBVFD8ib8Lx6ENoPqP2zFmVij/qKOwUUNE+2kih?= =?iso-8859-1?Q?QNpB7q5A++i683SPyHJZ+Fi302QtInMbvDW5wXQ8B/NZPZo6gtu4LskWE8?= =?iso-8859-1?Q?IM3SXbeqmJG/Hdg2ix49+y5vRDlhfdI4J6u7RqXuMtQT7UY+pyWvZP8LTx?= =?iso-8859-1?Q?DEpmPVWgXbaN5d2BFoW2CihUWQ3gtAsImw+PnuqNgmpDusaasv+TEtcg2C?= =?iso-8859-1?Q? X-OriginatorOrg: sct-15-20-7828-19-msonline-outlook-12d23.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR02MB10107.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: a74fdb1d-f786-471e-49a7-08dcc3435488 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2024 07:15:12.8043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR02MB8957 Received-SPF: pass client-ip=2a01:111:f403:2e07::819; envelope-from=arthur.miller@live.com; helo=EUR02-VI1-obe.outbound.protection.outlook.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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=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+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Original-Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.orgmode:163025 gmane.emacs.devel:323073 Archived-At: --_000_AS8PR02MB101070F137FA3E05F0170B57596882AS8PR02MB10107eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>> 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. I am not subscribed to mailing lists due to lots of trafic going on there, = so I am not overly introduced in directions in which org goes, so forgive me if = I am not so familiar with the latest features. >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) Well, yes something like that; make features available outside of org-mode,= and make org-mode use those features instead of having everything in a monolith= ical library. >> For example about links, there could be a mode "text-link-mode" or >> "pretty-links-mode" or something, that understands what a link descripti= on 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/shoul= d be >> enough customizable so that modes could be clients of this minor mode, a= s well >> as for user to be able to setup a regex or set a function that recognize= s some >> custom syntax for descriptions and links. Also a minor mode can come wit= h 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. The idea was that if such a minor mode has a list of regexes it recognizes, neither org-, md- or hyperbole would need to keep their code for this, but = could relly on users to just (desc-links-mode +1). If I had this as global minor = mode, I could also enable it while writing mail and use say md syntax and have pr= etty links, which admittedly would come out ugly on the other end, but that is a= n agreement between the reader and the writer. In other words org links or md links would be available in any format and up to users where they want to u= se them. >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@hypers= pace/ > >> 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 desi= rable >> it >> might be in other modes, perhaps in comments in programming languages, o= r >> 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? Not a novelty at all :). The same as for links. A user could (rich-text-mod= e +1), and have org-markup (or their own) available in any mode of their choi= ce. I had font-lock and thingatpt in my mind, but I didn't want to talk about the implementation. After all, org uses font-lock under the hood for this anywa= y (or am I too unfamiliar now? :)). It is just a convenience. In all of this case= s, I am thinking of those small minor modes be a tiny small "frameworks", where = a user can setup like very few regexes, or whatever is needed for a parser, a= nd have a "customized" syntax instead of going on through writing their own mi= nor mode. >> 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 w= ork to >> use C-left/right to change the date. It could be refactored into small t= iny >> 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 o= rg. >> 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. I see. Thanks. Something like that for other features. ________________________________ Fr=E5n: Ihor Radchenko Skickat: den 22 augusti 2024 14:23 Till: arthur miller Kopia: emacs-devel@gnu.org ; emacs-orgmode@gnu.org =C4mne: Re: Sv: Modularizing Org as GSoC project (was: New Emacs features v= ia Google Summer of Code (or other similar stipend schemes) (was: as for Ca= lc and the math library)) 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 descriptio= n 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@hypersp= ace/ > 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 desir= able 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 wo= rk to > use C-left/right to change the date. It could be refactored into small ti= ny > 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 or= g. They > are still usable outside of org mode. I can create table with org-table-c= reate > and I can align table with org-table-align, but by default I don't have t= his > 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 --_000_AS8PR02MB101070F137FA3E05F0170B57596882AS8PR02MB10107eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>>>         Do you want Org markup to be displ= ayed in non-Org buffers?
>>
>> Well, part of it. Or more to make some parts of org-markup configu= rable, and
>> usable as minor modes so they can be easier used outside of org-mo= de.
>
>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<= /div>
>third-party parsers and eventually registering Org syntax in IANA MIME = db.

I am not subscribed to mailing lists due to lots of trafic going on there, = so I
am not overly introduced in directions in which org goes, so forgive me if = I am
not so familiar with the latest features.

>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 basi= c
>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)

Well, yes something like that; make features available outside of org-mode,= and
make org-mode use those features instead of having everything in a monolith= ical
library.

>> For example about links, there could be a mode "text-link-mod= e" 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, w= hereas
>> markdown uses angle brackets and parenthesis. Thus link-mode could= /should be
>> enough customizable so that modes could be clients of this minor m= ode, as well
>> as for user to be able to setup a regex or set a function that rec= ognizes some
>> custom syntax for descriptions and links. Also a minor mode can co= me 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-mo= de
>> itself. Org-mode could use those under the hood.
>
>I am not sure if many places (except Markdown) have a notion of link +<= /div>
>description. And the rest is supported by, say, Hyperbole.

The idea was that if such a minor mode has a list of regexes it recognizes,=
neither org-, md- or hyperbole would need to keep their code for this, but = could
relly on users to just (desc-links-mode +1). If I had this as global minor = mode,
I could also enable it while writing mail and use say md syntax and have pr= etty
links, which admittedly would come out ugly on the other end, but that is a= n
agreement between the reader and the writer. In other words org links or md=
links would be available in any format and up to users where they want to u= se them.

>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@hyp= erspace/
>
>> Similarly for italics, bolds, underlines, etc. Those could be slig= htly
>> generalized and taken out into minor mode. Clients could setup the= ir own
>> start/end markers and use them to enrich the text on the display i= nstead of
>> perhaps defining own faces and regexes. I don't know how useful an= d desirable
>> it
>> might be in other modes, perhaps in comments in programming langua= ges, 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?

Not a novelty at all :). The same as for links. A user could (rich-text-mod= e
+1), and have org-markup (or their own) available in any mode of their choi= ce. I
had font-lock and thingatpt in my mind, but I didn't want to talk about the=
implementation. After all, org uses font-lock under the hood for this anywa= y (or
am I too unfamiliar now? :)). It is just a convenience. In all of this case= s, I
am thinking of those small minor modes be a tiny small "frameworks&quo= t;, where a
user can setup like very few regexes, or whatever is needed for a parser, a= nd
have a "customized" syntax instead of going on through writing th= eir own minor
mode.

>> org-timestamp interactiveity could be usable elsewhere than just i= n org
>> mode. For example I can insert  org-timestamp in any mode, bu= t it does work to
>> use C-left/right to change the date. It could be refactored into s= mall tiny
>> minor mode timestamp-mode or something, that comes with tis mode m= ap and
>> enable
>> this interactive stuff.
>
>This idea does sound useful.
>
>> ascii tables or org tables started as its own mode but got consume= d 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. Perhap= s I am just
>> not familiar with it. But this could be a minor mode also.
>
>See orgtbl-mode.

I see. Thanks. Something like that for other features.

Fr=E5n: Ihor Radchenko <= yantar92@posteo.net>
Skickat: den 22 augusti 2024 14:23
Till: arthur miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>; emacs-orgmod= e@gnu.org <emacs-orgmode@gnu.org>
=C4mne: Re: Sv: Modularizing Org as GSoC project (was: New Emacs fea= tures via Google Summer of Code (or other similar stipend schemes) (was: as= for Calc and the math library))
 
arthur miller <arthur.miller@live.com> write= s:

>>         Do you want Org ma= rkup to be displayed in non-Org buffers?
>
> Well, part of it. Or more to make some parts of org-markup configurabl= e, and
> usable as minor modes so they can be easier used outside of org-mode.<= br>
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.<= br>
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&qu= ot; or
> "pretty-links-mode" or something, that understands what a li= nk description is,
> and what a link itself is. The minor mode would have some mean to pars= e
> description and link parts, and when on it would do what org-toggle-li= nk-display
> does. For example org uses angle brackets for link desc and url, where= as
> markdown uses angle brackets and parenthesis. Thus link-mode could/sho= uld 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 recogni= zes some
> custom syntax for descriptions and links. Also a minor mode can come w= ith 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 o= wn
> start/end markers and use them to enrich the text on the display inste= ad of
> perhaps defining own faces and regexes. I don't know how useful and de= sirable 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 or= g
> 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 a= nd 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-tabl= e-create
> and I can align table with org-table-align, but by default I don't hav= e 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 <https://o= rgmode.org/>.
Support Org development at <h= ttps://liberapay.com/org-mode>,
or support my work at <https:= //liberapay.com/yantar92>
--_000_AS8PR02MB101070F137FA3E05F0170B57596882AS8PR02MB10107eu_--