outline-minor-mode and org-mode capabilities for programming languages

[Christopher Dimech]

> Sent: Monday, May 10, 2021 at 6:22 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: outline-minor-mode and org-mode capabilities for programming 
> languages
>
> * Christopher Dimech <dimech@gmx.com> [2021-05-10 04:49]:
> > Whilst I agree that programming language modes do their thing well, and 
> > org-mode
> > does its things well, the idea of headings and folding could be made to 
> > work much
> > better for programming languages.  Additionally, there could be 
> > org-minor-mode
> > that is specific for programming languages.  The people at org-mode would 
> > know
> > best about the capabilities and functionalities that would entail.  We 
> > could also
> > take some information out on their implementation.
>
> You said org-minor-mode yet you maybe wish to say what features you
> think could Org mode provide to Emacs Lisp mode? It is unclear.

It could be called orgprog-minor-mode, org capability for programming
languages.

Mainly catering for highligting, headlines and folding to start with.

> Like should I mark functions with TODO/DONE?

No

> Should I be able to open up agenda to know which function is to be
> executed at which time?

No

> Should there be properties?

No

> Should I tag functions?

No

> Am I able to hyperlink one function to other?

No

> While this may sound apparently funny, I do think that type of editing
> would be useful.

Could be useful, I cannot deny it.  But let,s constrain things for now.

> One way to implement it could be to use the database backed chunked
> editing where every function receives its database node and has its
> attributes which are quickly cycled with TAB. It could show the same
> what is shown in outline mode. As I am developing system that augments
> thought processing I could simply define an Emacs Lisp programming
> node, and enter in such node any chunks I wish.

> Then each specific function, thus database node, could be verified on
> the fly if it is correct. A huge program could be written that way and
> one could see which function is node is written correctly which one
> not. It could create a file on the fly for final distribution. One
> could reach any functions by its semantics, tags, properties, describe
> them fully and thus augment human perception.

> All the thousands of Emacs packages could be imported in that way
> which would allow re-using of the code in a new fantastic manner,
> searchable by semantics and indexes. No more worries on which function
> was taken from which package, program could tell how it was modified
> and would create the Commentar or log, and thus solve licensing issues
> automatically.

Reuse of code is currently difficult.

> Creating new specialized packages would be a breeze, just choose those
> functions needed by its semantics and new narrowed package could be
> created with its headers, licensing issues, modifications, as nothing
> of that human need to think of.

> User is creating function for what? List related stuff? Just choose
> the function by its semantic, completion or other menu system, even
> review it, and it is inserted into buffer to create a new function.

The areas of action I outlined for programming languages would be valuable
during code review.

> When attributes and description of the code is well done, and it can
> be done fast, programmers would be able to tell in human language what
> they need to do, and algorithm could tell how to do it, and which
> available parts already exist.

That could help developers navigate the code without needing too much
input from the original author or maintainer.

> As we do not re-use enough. There are thousands of packages and we
> don't have quite a good database to find what we need.

Quite right.  Quite right

> Example of lack of code re-use are various markup modes that in the
> essence all do the same, like HTML has <strong></strong>, Markdown has
> its **bold** and Org has *bold*, then there is list of other similar
> markup that does essentially the same, code is re-written all over
> again instead of defining the tags or markup as some kind of data, and
> having it ready for user by some kind of universal mode that would
> find major mode and type of text and automatically assign the
> markup.
>
> And for each mode I have to use different key bindings, terrible. If I
> wish to markup something as "strong" or "bold" face, I want to use in
> every mode same key binding, not different.
>
> Importing functions into a database would not impair running program
> as a file or a distributing it, it could just help its structure
> better.
>
> It would allow the true collaboration: on the multiple functions on
> the same file several multiple users could work in parallel. On the
> same function people could work by using crdt.el package, each
> function and thus the node would have its automatic revision system,
> not file based revision, rather function or node based revision.
>
> It would be the Outline system, but Outline on a meta level.

I suggest that outline-minor-mode be also refactored and revamped, as I have
seen much additional code on top of it (outline-magic, orgstruct, outshine).

> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> Sign an open letter in support of Richard M. Stallman
> https://stallmansupport.org/
> https://rms-support-letter.github.io/
>
>
>