>>>         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 monolithical
library.

>> 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.

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 pretty
links, which admittedly would come out ugly on the other end, but that is an
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 use 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@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?

Not a novelty at all :). The same as for links. A user could (rich-text-mode
+1), and have org-markup (or their own) available in any mode of their choice. 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 anyway (or
am I too unfamiliar now? :)). It is just a convenience. In all of this cases, 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, and
have a "customized" syntax instead of going on through writing their own minor
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 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.

I see. Thanks. Something like that for other features.
Från: 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-orgmode@gnu.org <emacs-orgmode@gnu.org>
Ämne: 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))
 
arthur miller <arthur.miller@live.com> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>