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

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2021-05-10 11:32]:
> > There are already other packages, I have been testing it, and they
> > worked similar to outline-minor-mode and could fold things.
> 
> Folding of functions is good, folding by headings not so good.   

I still think you have to verify outline-heading-alist as that is
where you define headings. I just did it on my side  and it works
well. 

;;;; ↝ THIS IS MY STYLE OF A HEADING in Emacs Lisp

I like it that way, and I have only defined one level, as I don't need
more in that mode.

In that mode it is:

outline-heading-alist ⇒ '((";;;; ↝" . 2))

As simple as that.

See my video demonstration here below.

The Power of Outline Minor Mode for Emacs
https://hyperscope.link/3/7/2/7/9/The-Power-of-Outline-Minor-Mode-for-Emacs-37279.html

> How about extending it to subheadings like org-mode.  It is a good idea
> to use the comment declaration for defining headings, and also use * for
> heading levels as in org-mode.  For languages with multiline comments
> I simply used *, then changed to org-mode.  In elisp I made a multiline
> comment function.
> 
> For texinfo, which has multi-line comment capability I have been doing
> 
> @ignore
> * Heading
> @end ignore
> 
> @ignore
> ** Subheading
> @end ignore

No need for that, please just see description of variable:
outline-heading-alist

outline-heading-alist is a variable defined in ‘outline.el’.

Its value is nil

  Automatically becomes buffer-local when set.

Alist associating a heading for every possible level.
Each entry is of the form (HEADING . LEVEL).
This alist is used two ways: to find the heading corresponding to
a given level and to find the level of a given heading.
If a mode or document needs several sets of outline headings (for example
numbered and unnumbered sections), list them set by set and sorted by level
within each set.  For example in texinfo mode:

     (setq outline-heading-alist
      '(("@chapter" . 2) ("@section" . 3) ("@subsection" . 4)
           ("@subsubsection" . 5)
        ("@unnumbered" . 2) ("@unnumberedsec" . 3)
           ("@unnumberedsubsec" . 4)  ("@unnumberedsubsubsec" . 5)
        ("@appendix" . 2) ("@appendixsec" . 3)...
           ("@appendixsubsec" . 4) ("@appendixsubsubsec" . 5) ..))

Instead of sorting the entries in each set, you can also separate the
sets with nil.

Also, when I need re-numbering of lists like in Org mode, invoke
orgalist-mode when I need that. In general, many Org functions could
be useful in other modes, would they be split into separate packages.

> They should always go with the comment declaration for the language.
> Most likely good, but then one cannot easily switch to org-mode.
> Then again, if the topics of discussion are resolved, there wauld
> not me much need to change to org-mode for certain org-mode
> operations.

I don't believe Org mode is solution for everything. In my Hyperscope
system and also Website Revision System specific system, I have no
limitation on what mode or text processor to use. 

Org mode IS bloated. It has everything what one needs and much more
what I don't need. It is based on Outline mode and thus I like often
invoking Outline mode as that satisfies basic needs without fiddling
with Org mode keybindings and whatever other additional not necessary
functions. Surely I do use Org mode, but when it is needed.

When you mention "Org" I think of bloated number of Org packages and
functions. That is why I asked, what do you think you need? You said
highlighting, headings, folding, so that is about all available in
outline-minor-mode

> I agree with you up to a point.  For starters let's just clean
> things up with the capabilities that are already implemented.
> Literate schemes are good for organisational purposes, but for
> programming, literate schemes make everything much more cumbersome,
> and ultimately yield to total disaster in terms of efficiency in
> going through the code base.  One thing that does help is self
> documuntation if kept brief within the code file.

Disaster comes with inefficient or non-integrated implementation. How
I see Emacs in general, it is a pile of useful stuff, on which pile,
more piles are added on top, with more stuff on top of the top, of the
top of the piles of piles. 

We have all function well described, indexed, findable, locatable,
usable in programming, we have it all, but IMHO integration is not
adequate for my standard. I have expected more of computing in 21st
century.

I would expect something like, to tell by speech to computer:

"...THEN GIVE ME ALL BUFFER AS A STRING..." which would interpolate
into necessary functions.

"...THEN REPLACE ALL OCCURENCES OF THE FOLLOWING..." (type the string)
and computer asks "With what do you want to replace it?" then type the
replacement. And then computer would ask for various possible
mischievous effects, and would correct programmer, and in the same
time find similar functions in other 10000 Emacs packages or for any
kind of programming language that could be related to it. It would
conduct database queries locally and remotely.

How about tag based programming? Just think what you want to do, and
other tags appear. Like STRING --- CUT, FIRST PART, LAST PART, FIND
ANYWHERE IN THE STRING, SPLIT, CONVERT TO LIST, CHARS, or LIST --
REMOVE DUPLICATES, REVERSE etc. Tags could be shown on screen, user
just clicks on it and decides relations, something similar to 
https://scratch.mit.edu -- where children program animations. More
literate, more meanings, just ideas and intentions that result in a
program. 

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