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
Date: Mon, 10 May 2021 09:22:51 +0300 [thread overview]
Message-ID: <YJjRO/5x+v6rK0Re@protected.localdomain> (raw)
In-Reply-To: <trinity-3bba264f-2c93-43de-ba29-29a942d3f7ea-1620611360594@3c-app-mailcom-bs04>
* 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.
Like should I mark functions with TODO/DONE?
Should I be able to open up agenda to know which function is to be
executed at which time?
Should there be properties?
Should I tag functions?
Am I able to hyperlink one function to other?
While this may sound apparently funny, I do think that type of editing
would be useful.
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.
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.
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.
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.
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.
--
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/
next prev parent reply other threads:[~2021-05-10 6:22 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-09 8:53 outline-minor-mode and org-mode capabilities for programming languages Christopher Dimech
2021-05-09 9:11 ` Jean Louis
2021-05-09 12:35 ` Christopher Dimech
2021-05-09 12:45 ` Jean Louis
2021-05-09 13:00 ` Christopher Dimech
2021-05-09 16:27 ` Jean Louis
2021-05-09 17:35 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-05-09 17:50 ` Jean Louis
2021-05-09 18:02 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-05-09 19:09 ` Jean Louis
2021-05-10 1:49 ` Christopher Dimech
2021-05-10 6:22 ` Jean Louis [this message]
2021-05-10 6:53 ` Christopher Dimech
2021-05-10 7:32 ` Jean Louis
2021-05-10 8:32 ` Christopher Dimech
2021-05-10 9:29 ` Christopher Dimech
2021-05-10 9:31 ` Jean Louis
2021-05-10 10:01 ` Christopher Dimech
2021-05-10 11:43 ` Jean Louis
2021-05-10 12:52 ` Christopher Dimech
2021-05-10 17:05 ` Jean Louis
2021-05-11 2:00 ` Christopher Dimech
2021-05-10 10:27 ` Christopher Dimech
2021-05-10 11:53 ` Jean Louis
2021-05-10 12:32 ` Christopher Dimech
2021-05-10 16:07 ` Jean Louis
2021-05-11 2:26 ` Christopher Dimech
2021-05-10 8:46 ` Christopher Dimech
2021-05-10 9:15 ` Christopher Dimech
2021-05-10 9:33 ` Jean Louis
2021-05-10 6:08 ` Christopher Dimech
2021-05-10 1:25 ` Christopher Dimech
2021-05-09 13:02 ` Christopher Dimech
2021-05-09 16:34 ` Jean Louis
2021-05-09 14:02 ` Stefan Monnier via Users list for the GNU Emacs text editor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YJjRO/5x+v6rK0Re@protected.localdomain \
--to=bugs@gnu.support \
--cc=dimech@gmx.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).