From: Julia Lawall <julia.lawall@inria.fr>
To: Jan Tojnar <jtojnar@gmail.com>
Cc: cocci@inria.fr
Subject: Re: [cocci] [PATCH v2] Exit with non-zero status when spatch on a directory fails
Date: Sat, 22 Oct 2022 14:26:15 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2210221418000.2783@hadrien> (raw)
In-Reply-To: <eb2be587f68870a1394fef6cedb15d142a26a29a.camel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]
On Sat, 22 Oct 2022, Jan Tojnar wrote:
> On Mon, 2022-09-05 at 22:35 +0200, Julia Lawall wrote:
> > Not so clear what the impact of this is. I prefer tabs to be used
> > when possible.
>
> I very much prefer tabs myself but the choice of tabs vs spaces is not
> important. As long as they are used consistently. Unfortunately, that
> is not currently the case, which leads to various issues:
>
> Most importantly, when a developer edits a code with mixed indentation,
> they will almost certainly adjust the indentation in one direction or
> another. This means that the patches will include extra changes
> unrelaated to the main contribution, making them more difficult to
> review and retrospectively analyze.
>
> Additionally, different contributors may have different visual tab
> widths, which can cause indentation to “jump” making it harder to grasp
> the code nesting. Editors often allow to adjust this but users
> would need to do it in their text editor, Git client, e-mail client
> and maybe even GitLab. For example, the following image is what I saw
> when I reviewed the patch earlier from this thread in my Git client:
>
> https://imgur.com/VeM6jbN
> (I highlighted the actual nesting of the syntax tree with red arrows.)
>
> And that assumes all contributors use the same visual tab width.
> If that is not the case, the nesting will be mangled no matter
> how the developer viewing the code sets the width in their editor.
>
> ----
>
> It looks like the original codebase used two spaces for indentation (as
> seems to be the convention for OCaml [1]) but later, tabs started to
> creep in.
>
> [1]: https://ocaml.org/docs/guidelines#using-tab-stops
> Though, their argument against tabs is as fallacious as always.
> Their only valid point actually argues against mixed indentation,
> which could just as well be used to deny using spaces for indentation.
Thanks for your thoughts, but I'm sorry nothing is likely to happen on
this. We don't have the development resources for this to be a priority.
julia
next prev parent reply other threads:[~2022-10-22 12:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-04 22:50 [cocci] [PATCH] Exit with non-zero status when spatch on a directory fails Jan Tojnar
2022-09-05 7:57 ` Julia Lawall
2022-09-05 9:09 ` [cocci] [PATCH v2] " Jan Tojnar
2022-09-05 10:48 ` Julia Lawall
2022-09-05 12:04 ` Jan Tojnar
2022-09-05 12:29 ` Julia Lawall
[not found] ` <CAFGSp1umoczUe4npSesAUOLgSq=9VkvLUOV3x1hSvSajqQkGfw@mail.gmail.com>
2022-09-05 12:51 ` Julia Lawall
2022-09-05 14:18 ` Jan Tojnar
2022-09-05 16:03 ` Julia Lawall
2022-09-05 19:51 ` Julia Lawall
2022-09-05 20:21 ` Jan Tojnar
2022-09-05 20:35 ` Julia Lawall
2022-10-22 12:09 ` Jan Tojnar
2022-10-22 12:26 ` Julia Lawall [this message]
2022-09-05 21:28 ` Julia Lawall
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.22.394.2210221418000.2783@hadrien \
--to=julia.lawall@inria.fr \
--cc=cocci@inria.fr \
--cc=jtojnar@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.
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).