GNU bug report logs -
#25030
elisp: highlighting of unexpected indentation should use separate face from highlight of error functions
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25030 in the body.
You can then email your comments to 25030 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Fri, 25 Nov 2016 23:13:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Klaus-Dieter Bauer <bauer.klaus.dieter <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 25 Nov 2016 23:13:02 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)]
Hello!
In `emacs-lisp-mode', the counting of the nesting level of forms seems
to be broken in some subtle way. Consider e.g.
(form
(
) WEIRD HIGHLIGHT
x) ;; Unexepected Indentation
It looks like "WEIRD HIGHLIGHT" is wrongly highlighted as junk after a
surplus closing parenthesis, and the subsequent form is also weirdly
indented.
So this particular example is artificial, it occurred for me when I was
writing testing-code with in some personal emacs-lisp project:
;; Example from actual code (abbreviated)
(ert-deftest expr--parser-rule-def-firsts ()
(myert-test-results #'expr--parser-rule-def-firsts
`("The `firsts' function doesn't yet enforce, that every rule
must have a resolvable first."
(((&def RuleA RuleB)
(&def RuleB RuleA))) => WEIRD-HIGHLIGHT-HERE
:WEIRD-INDENTATION-HERE)))
I confirmed the issue in Emacs 25.1.1 64bit (from Chocolatey), running
that same Emacs with "runemacs -q", and with Emacs 26.0.50.1
(self-compiled).
For reference I have attached an elisp file with examples and a
screenshot of how it looks on my system.
regards, Klaus
--------------------------------------------------
In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
of 2016-09-17 built on KAEL
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Configured using:
'configure --prefix=/tmp/emacs --without-imagemagick 'CFLAGS=-O2
-fomit-frame-pointer -g0''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS
Important settings:
value of $LANG: DEA
locale-coding-system: cp1252
Major mode: Emacs-Lisp
Minor modes in effect:
diff-auto-refine-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode cl-loaddefs pcase
cl-lib mail-prsvr mail-utils vc-git diff-mode easymenu easy-mmode
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
w32notify dbusbind w32 multi-tty make-network-process emacs)
Memory information:
((conses 16 94172 5940)
(symbols 56 20219 0)
(miscs 48 89 106)
(strings 32 17676 3993)
(string-bytes 1 489683)
(vectors 16 12293)
(vector-slots 8 433157 4526)
(floats 8 164 100)
(intervals 56 581 40)
(buffers 976 20))
--=-=-=--
[Message part 2 (text/html, inline)]
[emacs-indent-bug.el (application/octet-stream, attachment)]
[emacs-indent-bug.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Sun, 27 Nov 2016 20:39:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 25030 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Klaus-Dieter Bauer <bauer.klaus.dieter <at> gmail.com> schrieb am Sa., 26. Nov.
2016 um 00:13 Uhr:
> Hello!
>
> In `emacs-lisp-mode', the counting of the nesting level of forms seems
> to be broken in some subtle way. Consider e.g.
>
> (form
> (
> ) WEIRD HIGHLIGHT
> x) ;; Unexepected Indentation
>
> It looks like "WEIRD HIGHLIGHT" is wrongly highlighted as junk after a
> surplus closing parenthesis, and the subsequent form is also weirdly
> indented.
>
>
This is working as intended (i.e. not a bug). Lisp-mode explicitly tests
for this. When you hover over the highlighted part, you get a tooltip
"Hidden behind deeper element; move to another line?"
While not a syntax error, there's such a strong convention to avoid such
formatting that the Lisp modes warn unconditionally about it.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Wed, 14 Mar 2018 01:50:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 25030 <at> debbugs.gnu.org (full text, mbox):
tags 25030 + wontfix
quit
Philipp Stephani <p.stephani2 <at> gmail.com> writes:
> This is working as intended (i.e. not a bug). Lisp-mode explicitly
> tests for this. When you hover over the highlighted part, you get a
> tooltip "Hidden behind deeper element; move to another line?"
> While not a syntax error, there's such a strong convention to avoid
> such formatting that the Lisp modes warn unconditionally about it.
Since there's been no further movement on this, I'm closing as wontfix.
Added tag(s) wontfix.
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 14 Mar 2018 01:50:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
25030 <at> debbugs.gnu.org and Klaus-Dieter Bauer <bauer.klaus.dieter <at> gmail.com>
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 14 Mar 2018 01:53:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Sun, 18 Mar 2018 19:54:02 GMT)
Full text and
rfc822 format available.
Message #18 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sun 27 Nov 2016, Philipp Stephani wrote:
> Klaus-Dieter Bauer <bauer.klaus.dieter <at> gmail.com> schrieb am Sa., 26. Nov.
> 2016 um 00:13 Uhr:
>
>> Hello!
>>
>> In `emacs-lisp-mode', the counting of the nesting level of forms seems
>> to be broken in some subtle way. Consider e.g.
>>
>> (form
>> (
>> ) WEIRD HIGHLIGHT
>> x) ;; Unexepected Indentation
>>
>> It looks like "WEIRD HIGHLIGHT" is wrongly highlighted as junk after a
>> surplus closing parenthesis, and the subsequent form is also weirdly
>> indented.
>>
>>
> This is working as intended (i.e. not a bug). Lisp-mode explicitly tests
> for this. When you hover over the highlighted part, you get a tooltip
> "Hidden behind deeper element; move to another line?"
> While not a syntax error, there's such a strong convention to avoid such
> formatting that the Lisp modes warn unconditionally about it.
This may not be a bug, but it is certainly a mis-feature.
Warning should be reserved for syntax which may have unintended or
surprising semantics. Indentation that does not follow a convention is
not wrong either systacically or semantically.
Please remove this broken mis-feature.
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Sun, 18 Mar 2018 21:33:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 25030 <at> debbugs.gnu.org (full text, mbox):
> This may not be a bug, but it is certainly a mis-feature.
>
> Warning should be reserved for syntax which may have unintended or
> surprising semantics. Indentation that does not follow a convention is
> not wrong either systacically or semantically.
>
> Please remove this broken mis-feature.
I agree that warnings are not for such things. Emacs too
often uses "warnings" for things that are not warnings.
On the other hand, I do appreciate this highlighting, though
at first I didn't think I would. I think a different face
should be used for this - this is *warning* about anything.
That would let users control whether it is actually highlighted
(e.g., by resetting the face attributes to nil).
This is a duplicate of bug #18163, BTW. And the thread
repeats that one...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Mon, 19 Mar 2018 23:54:01 GMT)
Full text and
rfc822 format available.
Message #24 received at 25030 <at> debbugs.gnu.org (full text, mbox):
unarchive 18163
merge 25030 18163
quit
Andy Moreton <andrewjmoreton <at> gmail.com> writes:
> This may not be a bug, but it is certainly a mis-feature.
>
> Warning should be reserved for syntax which may have unintended or
> surprising semantics. Indentation that does not follow a convention is
> not wrong either systacically or semantically.
I'm not convinced by this. Code with unconventional indendation has
surprising syntax to a human reader (or from another perspective, when
I'm writing code which indents strangely, that clues me in that I've
written some unintended syntax), therefore, it seems a warning is
exactly appropriate.
Merged 18163 25030.
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 19 Mar 2018 23:54:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Tue, 20 Mar 2018 00:25:01 GMT)
Full text and
rfc822 format available.
Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):
On Mon 19 Mar 2018, Noam Postavsky wrote:
> unarchive 18163
> merge 25030 18163
> quit
>
> Andy Moreton <andrewjmoreton <at> gmail.com> writes:
>
>> This may not be a bug, but it is certainly a mis-feature.
>>
>> Warning should be reserved for syntax which may have unintended or
>> surprising semantics. Indentation that does not follow a convention is
>> not wrong either systacically or semantically.
>
> I'm not convinced by this. Code with unconventional indendation has
> surprising syntax to a human reader (or from another perspective, when
> I'm writing code which indents strangely, that clues me in that I've
> written some unintended syntax), therefore, it seems a warning is
> exactly appropriate.
I disagree. The interpreter and byte compiler do not care about the
indentation style that you choose for your code: the syntax and
semantics are unaffected.
Style choices should not produce warnings. An indication that code layout is
following an unusual style may be useful, but it should be optional, and
it should not use the warning face (it should have a separate face that can be
customised independently of the warning face).
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Tue, 20 Mar 2018 01:36:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 25030 <at> debbugs.gnu.org (full text, mbox):
> >> This may not be a bug, but it is certainly a mis-feature.
> >>
> >> Warning should be reserved for syntax which may have unintended or
> >> surprising semantics. Indentation that does not follow a convention is
> >> not wrong either systacically or semantically.
> >
> > I'm not convinced by this. Code with unconventional indendation has
> > surprising syntax to a human reader (or from another perspective, when
> > I'm writing code which indents strangely, that clues me in that I've
> > written some unintended syntax), therefore, it seems a warning is
> > exactly appropriate.
>
> I disagree. The interpreter and byte compiler do not care about the
> indentation style that you choose for your code: the syntax and
> semantics are unaffected.
>
> Style choices should not produce warnings. An indication that code layout
> is following an unusual style may be useful, but it should be optional, and
> it should not use the warning face (it should have a separate face that can
> be customised independently of the warning face).
What Andy said. This has nothing to do with byte-compiling
(or interpreting, for that matter).
There is nothing wrong with having optional (especially opt-in)
indications of flouting conventional style. And even then we
should not use, or inherit from, the warning face.
It should be easy for users to give the face(s) used for
stylistic highlighting different appearance(s) from standard
Emacs faces that have other meanings.
Error and warning faces are to be avoided for anything that is
not an error or warning. And any faces used by the byte-compiler
should be about something relevant to byte-compiling.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Tue, 20 Mar 2018 02:15:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 25030 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> I disagree. The interpreter and byte compiler do not care about the
>> indentation style that you choose for your code: the syntax and
>> semantics are unaffected.
>>
>> Style choices should not produce warnings. An indication that code layout
>> is following an unusual style may be useful, but it should be optional, and
>> it should not use the warning face (it should have a separate face that can
>> be customised independently of the warning face).
>
> What Andy said. This has nothing to do with byte-compiling
> (or interpreting, for that matter).
I don't understand why you guys are all of a sudden talking about
byte-compiling.
> It should be easy for users to give the face(s) used for
> stylistic highlighting different appearance(s) from standard
> Emacs faces that have other meanings.
Anyway, if this just about reorganizing the faces used, I have no
objections.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Tue, 20 Mar 2018 12:57:01 GMT)
Full text and
rfc822 format available.
Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):
On Mon 19 Mar 2018, Noam Postavsky wrote:
> Drew Adams <drew.adams <at> oracle.com> writes:
>
>>> I disagree. The interpreter and byte compiler do not care about the
>>> indentation style that you choose for your code: the syntax and
>>> semantics are unaffected.
>>>
>>> Style choices should not produce warnings. An indication that code layout
>>> is following an unusual style may be useful, but it should be optional, and
>>> it should not use the warning face (it should have a separate face that can
>>> be customised independently of the warning face).
>>
>> What Andy said. This has nothing to do with byte-compiling
>> (or interpreting, for that matter).
>
> I don't understand why you guys are all of a sudden talking about
> byte-compiling.
The point is that the unusual code layout does not cause any problems for
elisp code, and it does not matter if the code is interpreted or
byte-compiled: the result is the same, namely that indentation style has
no effect on the meaning of the code.
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Thu, 22 Mar 2018 02:39:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 25030 <at> debbugs.gnu.org (full text, mbox):
retitle 25030 elisp: highlighting of unexpected indentation should use separate face from highlight of error functions
severity 25030 wishlist
tags 25030 =
reopen 25030
quit
Andy Moreton <andrewjmoreton <at> gmail.com> writes:
> The point is that the unusual code layout does not cause any problems for
> elisp code, and it does not matter if the code is interpreted or
> byte-compiled: the result is the same, namely that indentation style has
> no effect on the meaning of the code.
This seems like an argument against the byte compiler emitting style
warnings, but since this bug is not about byte compiler warnings, I
don't understand why you are bringing it up.
Changed bug title to 'elisp: highlighting of unexpected indentation should use separate face from highlight of error functions' from '25.1; Unexpected indentation and syntax-highlighting in `emacs-lisp-mode''
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 22 Mar 2018 02:39:02 GMT)
Full text and
rfc822 format available.
Severity set to 'wishlist' from 'minor'
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 22 Mar 2018 02:39:02 GMT)
Full text and
rfc822 format available.
Removed tag(s) notabug and wontfix.
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 22 Mar 2018 02:39:03 GMT)
Full text and
rfc822 format available.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 22 Mar 2018 02:39:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25030
; Package
emacs
.
(Sat, 12 Feb 2022 08:55:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 25030 <at> debbugs.gnu.org (full text, mbox):
Philipp Stephani <p.stephani2 <at> gmail.com> writes:
> This is working as intended (i.e. not a bug). Lisp-mode explicitly tests for this. When
> you hover over the highlighted part, you get a tooltip "Hidden behind deeper
> element; move to another line?"
So I think this is working as designed, and I'm therefore closing this
bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
25030 <at> debbugs.gnu.org and Klaus-Dieter Bauer <bauer.klaus.dieter <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 12 Feb 2022 08:55:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 12 Mar 2022 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 18 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.