From: Richard Stallman <rms@gnu.org>
To: "João Távora" <joaotavora@gmail.com>
Cc: larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Indentation of def*
Date: Sat, 23 Oct 2021 19:26:34 -0400 [thread overview]
Message-ID: <E1meQPK-0003ae-6X@fencepost.gnu.org> (raw)
In-Reply-To: <CALDnm52_75muw0yoK4HE-bRUCL7xRNP2wSp8GefgYr8zYspBXA@mail.gmail.com> (message from João Távora on Wed, 20 Oct 2021 10:32:51 +0100)
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> But, regardless, is it not so that there are various grades of
> change here?
> a - do nothing
> b - keep heuristic but only for macros, delete for everything else.
> c - delete heuristic entirely
The heuristic defines the default way of indenting calls to entities
when they have no specific indentation rule to override that default.
The question is which default is better.
Following the heuristic by default will lead to better indentation in
some cases, and worse in some cases. An ugly indentation due to
following the heuristic (when it is wrong) is no worse than an ugly
indentation due to not following it (when it is right). In either
case, we know what to do to make that problem go away.
So unless we find that the heuristic causes more bad than good, we
should keep it.
I expect it gives us a lot of good and only a little bad. Though I
have no way of actually measuring this.
> If you want the data, it's there in the Emacs tree. Look at all
> functions/macros named def* with/without indent specs, examine what they
> are, and count.
This would count the number of constructs which have the potential to
be indented well due to the heuristic, or the potential to be indented
badly due to the heuristic. But that's the wrong way to evaluate the
amount of good and bad done by the heuristic.
Consider for example this function:
> Or wrongly -- functions like `default-boundp' are indented wrongly using
> that heuristic.
Indeed, if you break the line right after `(default-boundp', it
indents one extra space. That indentation is not bad or confusing,
only slightly different.
But I conjecture it will almost never happen anyway -- that people
break the line there so rarely that it hardly qualifies as a problem.
To evaluate how well the heuristic works, we should look for the cases
which are more likely to occur and would indent in a truly annoying or
misleading way, either due to the heuristic or due to its absence.
> I don't see what makes these macros special. You have the same problem
> with macros like `with-*' and `when-let' -- these also indent wrongly if
> you haven't loaded their definitions.
That's true. The convention of macros called `with-...' macros
started in the 1990s, I think.
I suggest we look at adding a few more indentation heuristics.
We could start with `with-...'
Normally the first sexp is the one that should be indented specially.
Are there any `with-...' macros that don't follow that general pattern?
Are there any other function/macros named `with-...'?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
next prev parent reply other threads:[~2021-10-23 23:26 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 23:13 Indentation of def* Lars Ingebrigtsen
2021-10-14 4:22 ` Stefan Monnier
2021-10-14 11:07 ` Po Lu
2021-10-14 11:14 ` Lars Ingebrigtsen
2021-10-14 11:23 ` Lars Ingebrigtsen
2021-10-14 12:05 ` Po Lu
2021-10-14 12:09 ` Lars Ingebrigtsen
2021-10-14 12:22 ` Po Lu
2021-10-14 12:49 ` João Távora
2021-10-14 13:40 ` Lars Ingebrigtsen
2021-10-14 21:41 ` João Távora
2021-10-15 9:57 ` Lars Ingebrigtsen
2021-10-15 10:14 ` João Távora
2021-10-14 13:25 ` Stefan Kangas
2021-10-14 13:30 ` Po Lu
2021-10-14 19:06 ` Stefan Kangas
2021-10-14 23:42 ` Po Lu
2021-10-15 0:50 ` Stefan Kangas
2021-10-15 5:21 ` Po Lu
2021-10-15 6:50 ` Eli Zaretskii
2021-10-15 8:35 ` Stefan Kangas
2021-10-15 10:42 ` Eli Zaretskii
2021-10-15 13:07 ` Stefan Kangas
2021-10-15 13:30 ` Eli Zaretskii
2021-10-15 13:48 ` Stefan Kangas
2021-10-15 13:17 ` Stefan Monnier
2021-10-15 12:42 ` Lars Ingebrigtsen
2021-10-15 12:43 ` Lars Ingebrigtsen
2021-10-14 18:35 ` Stefan Monnier
2021-10-18 8:02 ` Lars Ingebrigtsen
2021-10-20 6:47 ` Richard Stallman
2021-10-20 7:52 ` Lars Ingebrigtsen
2021-10-20 8:19 ` João Távora
2021-10-20 8:38 ` Lars Ingebrigtsen
2021-10-20 9:32 ` João Távora
2021-10-20 9:36 ` Lars Ingebrigtsen
2021-10-20 16:10 ` João Távora
2021-10-23 23:26 ` Richard Stallman [this message]
2021-10-24 13:22 ` Lars Ingebrigtsen
2021-10-24 14:27 ` Stefan Kangas
2021-10-24 15:19 ` João Távora
2021-10-24 16:23 ` Stefan Monnier
2021-10-24 16:55 ` Lars Ingebrigtsen
2021-10-24 18:36 ` João Távora
2021-10-27 14:37 ` Richard Stallman
2021-10-27 14:36 ` Richard Stallman
2021-10-27 14:40 ` Lars Ingebrigtsen
2021-10-30 6:49 ` Richard Stallman
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=E1meQPK-0003ae-6X@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@gmail.com \
--cc=larsi@gnus.org \
/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).