GNU bug report logs - #74156
29.4; Incorrect face with outline-minor-mode-highlight in lisp-mode

Previous Next

Package: emacs;

Reported by: Andreas Matthias <andreas.matthias <at> gmail.com>

Date: Fri, 1 Nov 2024 13:13:02 UTC

Severity: normal

Found in version 29.4

To reply to this bug, email your comments to 74156 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#74156; Package emacs. (Fri, 01 Nov 2024 13:13:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Matthias <andreas.matthias <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 01 Nov 2024 13:13:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Matthias <andreas.matthias <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.4; Incorrect face with outline-minor-mode-highlight in lisp-mode
Date: Fri, 1 Nov 2024 14:11:54 +0100
[Message part 1 (text/plain, inline)]
Take this example Elisp file:


;;; xxx -- OK: face is outline-1
;;;; xxx -- OK: face is outline-2
(defun test ()) ; WRONG: face is outline-8

;; Local Variables:
;; outline-minor-mode-highlight: override
;; eval: (outline-minor-mode 1)
;; End:


After loading this file into Emacs you will see that the function definition
is displayed incorrectly in face outline-8.

I guess this is due to the definition of outline-regexp in lisp-mode.el:

";;;;* [^
\t\n]\\|(\\|\\(^;;;###\\(\\([-[:alnum:]]+?\\)-\\)?\\(autoload\\)\\)"

Notice the opening parenthesis in the regular expression that causes
the function definition to be recognized as an outline heading.

I removed the opening parenthesis and now the face of the function
definition
is correct. This is fine for me. But note that you loose the ability to move
to top-level expressions, like this function definition, with
(outline-next-visible-heading) and (outline-previous-visible-heading).


Andreas
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#74156; Package emacs. (Sat, 02 Nov 2024 17:18:02 GMT) Full text and rfc822 format available.

Message #8 received at 74156 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Andreas Matthias <andreas.matthias <at> gmail.com>
Cc: 74156 <at> debbugs.gnu.org
Subject: Re: bug#74156: 29.4; Incorrect face with
 outline-minor-mode-highlight in lisp-mode
Date: Sat, 02 Nov 2024 19:14:02 +0200
> Take this example Elisp file:
>
> ;;; xxx -- OK: face is outline-1
> ;;;; xxx -- OK: face is outline-2
> (defun test ()) ; WRONG: face is outline-8
>
> ;; Local Variables:
> ;; outline-minor-mode-highlight: override
> ;; eval: (outline-minor-mode 1)
> ;; End:
>
> After loading this file into Emacs you will see that the function
> definition
> is displayed incorrectly in face outline-8.
>
> I guess this is due to the definition of outline-regexp in lisp-mode.el:
>
> ";;;;* [^ \t\n]\\|(\\|\\(^;;;###\\(\\([-[:alnum:]]+?\\)-\\)?\\
> (autoload\\)\\)"
>
> Notice the opening parenthesis in the regular expression that causes
> the function definition to be recognized as an outline heading.
>
> I removed the opening parenthesis and now the face of the function
> definition
> is correct. This is fine for me. But note that you loose the ability to
> move
> to top-level expressions, like this function definition, with
> (outline-next-visible-heading) and (outline-previous-visible-heading).

Isn't the face 'outline-8' because 'lisp-outline-level' returns
the level 1000 for the opening parenthesis in 'lisp-outline-level':

  (defun lisp-outline-level ()
    (let ((len (- (match-end 0) (match-beginning 0))))
      (cond ((or (looking-at-p "(")
                 (looking-at-p lisp-mode-autoload-regexp))
             1000)

The level 1000 corresponds to outline-8:

Level    1 - outline-1
Level    2 - outline-2
Level    3 - outline-3
Level    4 - outline-4
Level    5 - outline-5
Level    6 - outline-6
Level    7 - outline-7
Level    8 - outline-8
Level    9 - outline-1
Level   10 - outline-2
Level   11 - outline-3
...
Level  998 - outline-6
Level  999 - outline-7
Level 1000 - outline-8




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#74156; Package emacs. (Sat, 02 Nov 2024 23:43:02 GMT) Full text and rfc822 format available.

Message #11 received at 74156 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Matthias <andreas.matthias <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 74156 <at> debbugs.gnu.org
Subject: Re: bug#74156: 29.4; Incorrect face with outline-minor-mode-highlight
 in lisp-mode
Date: Sun, 3 Nov 2024 00:40:46 +0100
On Sat, Nov 2, 2024 at 6:16 PM Juri Linkov <juri <at> linkov.net> wrote:
>
> > I guess this is due to the definition of outline-regexp in lisp-mode.el:
> >
> > ";;;;* [^ \t\n]\\|(\\|\\(^;;;###\\(\\([-[:alnum:]]+?\\)-\\)?\\
> > (autoload\\)\\)"

[...]

> Isn't the face 'outline-8' because 'lisp-outline-level' returns
> the level 1000 for the opening parenthesis in 'lisp-outline-level':
>
>   (defun lisp-outline-level ()
>     (let ((len (- (match-end 0) (match-beginning 0))))
>       (cond ((or (looking-at-p "(")
>                  (looking-at-p lisp-mode-autoload-regexp))
>              1000)

AFAIU font-lock is using `outline-regexp` which triggers
`outline-font-lock-face()`
and eventually `lisp-outline-level()`.

My naive approach was to modify `outline-regexp`, i.e. remove the
opening parenthesis
in the regexp. Then `outline-font-lock-face()` cannot be triggered by
this regexp any more
and thus won't override the faces of normal lisp code.

The issue with this approach is: All commands that show, hide, or move to
outline headings use `outline-regexp` as well. Thus these commands won't
find headings starting with an opening parenthesis.

I don't know how important this opening-parenthesis-rule is. Actually I don't
need it. But I guess there were reasons to add it to the regexp.

Andreas




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#74156; Package emacs. (Sun, 03 Nov 2024 17:59:02 GMT) Full text and rfc822 format available.

Message #14 received at 74156 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Andreas Matthias <andreas.matthias <at> gmail.com>
Cc: 74156 <at> debbugs.gnu.org
Subject: Re: bug#74156: 29.4; Incorrect face with
 outline-minor-mode-highlight in lisp-mode
Date: Sun, 03 Nov 2024 19:54:18 +0200
> I don't know how important this opening-parenthesis-rule is. Actually I don't
> need it. But I guess there were reasons to add it to the regexp.

So there is no bug here and this report could be closed?

If you don't need opening-parenthesis-rule, it's fine
to customize 'outline-regexp' and 'outline-level'.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#74156; Package emacs. (Sun, 03 Nov 2024 18:27:02 GMT) Full text and rfc822 format available.

Message #17 received at 74156 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Matthias <andreas.matthias <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 74156 <at> debbugs.gnu.org
Subject: Re: bug#74156: 29.4; Incorrect face with outline-minor-mode-highlight
 in lisp-mode
Date: Sun, 3 Nov 2024 19:25:11 +0100
[Message part 1 (text/plain, inline)]
On Sun, Nov 3, 2024 at 6:58 PM Juri Linkov <juri <at> linkov.net> wrote:

> > I don't know how important this opening-parenthesis-rule is. Actually I
> don't
> > need it. But I guess there were reasons to add it to the regexp.
>
> So there is no bug here and this report could be closed?
>
> If you don't need opening-parenthesis-rule, it's fine
> to customize 'outline-regexp' and 'outline-level'.
>

Please take a look at the example I have given in my very first post.
There you see that font-lock is handling top-level lisp code incorrectly.
This is definitely a bug.

I don't agree with  you that customizing a variable is the recommended
way to fix a bug. But if there's really no other way to handle it, then it
should be documented at least.

Andreas
[Message part 2 (text/html, inline)]

This bug report was last modified 229 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.