From: Drew Adams <drew.adams@oracle.com>
To: Andy Moreton <andrewjmoreton@gmail.com>, 25030@debbugs.gnu.org
Subject: bug#25030: 25.1; Unexpected indentation and syntax-highlighting in `emacs-lisp-mode'
Date: Mon, 19 Mar 2018 18:35:43 -0700 (PDT) [thread overview]
Message-ID: <b3f4a4f9-9e43-4916-be53-91247b33138e@default> (raw)
In-Reply-To: <86in9rmw6h.fsf@gmail.com>
> >> 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.
next prev parent reply other threads:[~2018-03-20 1:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-25 23:12 bug#25030: 25.1; Unexpected indentation and syntax-highlighting in `emacs-lisp-mode' Klaus-Dieter Bauer
2016-11-27 20:38 ` Philipp Stephani
2018-03-14 1:49 ` Noam Postavsky
2018-03-18 19:53 ` Andy Moreton
2018-03-18 21:32 ` Drew Adams
2018-03-19 23:53 ` Noam Postavsky
2018-03-20 0:23 ` Andy Moreton
2018-03-20 1:35 ` Drew Adams [this message]
2018-03-20 2:14 ` Noam Postavsky
2018-03-20 12:55 ` Andy Moreton
2018-03-22 2:38 ` Noam Postavsky
2022-02-12 8:54 ` bug#25030: elisp: highlighting of unexpected indentation should use separate face from highlight of error functions Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b3f4a4f9-9e43-4916-be53-91247b33138e@default \
--to=drew.adams@oracle.com \
--cc=25030@debbugs.gnu.org \
--cc=andrewjmoreton@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).