GNU bug report logs -
#74156
29.4; Incorrect face with outline-minor-mode-highlight in lisp-mode
Previous Next
To reply to this bug, email your comments to 74156 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
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):
[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):
> 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):
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):
> 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):
[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.