bug#46878: 27.1; lisp-outline-level returns imprecise level number

[Juri Linkov]

> So I checked this "apparent strange behavior" on master branch and it
> seems to be working as expected. The commit
> 5a823a2a0c3eca60dd3939fba67df1bbe5a1b715 (Lars on 24 Nov 2020) added a
> new condition ('has-top-level') to 'outline-cycle-buffer' to check,
> well, if there is a top level heading, which is used to decide to hide
> or not sublevels, in case they exist. For emacs-lisp-mode, it fails to
> identify a top-level because 'outline-level' for a line starting with
> ";;; " returns a number greater than 1, which the code thinks its a
> child level:
>
> (when (= (funcall outline-level) 1)
>   (setq has-top-level t))
>
> Even though the outline level is used to compare relatively the headings
> to decide which ones are parents and which ones are children (level 5 is
> parent of level 6 and subsequent levels), there are cases (like the one
> above) where it's expected to have an ordered levelling starting from
> 1. It's more intuitive, and otherwise it's impossible to know what is a
> top-level or to set faces according to is level (level 1 with face
> outline-1 and so on).

Thanks for the analysis.  After replacing the hard-coded 1 with 5
it works as expected in emacs-lisp-mode.

> A simpler approach to avoid rewriting the existing functions and regexps
> would be to create a new variable called 'outline-level-offset', which
> could be used inside 'outline-level' to subtract from the original
> value. For example, if today the outline level for ";;; " in emacs-lisp
> returns 3, the elisp-mode.el (or lisp.mode.el) could set
> 'outline-level-offset' to 2, so 3 - 2 = 1, the expected value.

Maybe a better name for a new buffer-local variable would be 
'outline-top-level',
to make it similar to the internal variable 'has-top-level'.

Or maybe better just to apply the patch that Howard sent in the top message
of this bug report to change 'outline-level' in emacs-lisp-mode to count
from 1.