unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Olivier Certner <ocert.dev@free.fr>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, 63072@debbugs.gnu.org
Subject: bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones
Date: Tue, 19 Sep 2023 18:15:44 +0200	[thread overview]
Message-ID: <4916306.ghxcXLinNW@ravel> (raw)
In-Reply-To: <CADwFkmkDV7khfZPBU8rat7GGZ7v-EUscoxwu=J_fOGDea1wadg@mail.gmail.com>

Hi Stefan,

> Ping.  Any progress with coming up with a patch?

I have been using a complete version since a short time after creation of this 
bug, but haven't had much time to work on upstreaming that, and probably won't 
in the coming weeks.

Refining the new styles to cope with some corner cases unfortunately required 
a couple of new fixup functions, and minor changes in CC mode that may be 
controversial, such as setting all variables as buffer-local when `c-style-
variables-are-local-p' is true, or working around the weird behavior of CC 
mode concerning `for' clauses (this one surely proved controversial, see 
#63286; it is possible to do away with a lineup function as a workaround, at 
the price of elegance and performance, but this is not the current setup I'm 
running so coming back to a vanilla one will require more work on my part).

Additionally, given the fallout of #63286, I think you can understand I'm not 
contemplating a new discussion with the CC mode maintainer with great joy.  In 
the context of this bug, being looked down on by someone who provided mostly 
wrong technical answers and that otherwise showed a pronounced tendency to 
spread FUD is not exactly my conception of an enriching collaboration.  
Certainly, my final answer there wasn't neat, but "as you sow, so shall you 
reap".

More generally, I've found that interacting with upstream often wastes way too 
much time than it should simply because people don't really read carefully 
what they have been sent and/or have trouble with the nuances, sometimes even 
insisting on focusing on mostly irrelevant details.  You don't have to search 
far for an example, look no further than this bug's initial discussion.  I 
unfortunately know of several other examples, half of which I've personally 
not been involved in at all.  At a higher level, to put it bluntly (and 
exaggerating in order to make sure the point gets through), a sample of 
discussions in the mailing list in the past months gives more the impression 
of a clique wanting to preserve their own way of working/thinking rather than 
genuinely addressing the concerns of other users and developers (yes, most of 
them are "outsiders", which is the reason why some "insiders" apparently think 
they know better even concerning their own requests).  Besides the atmosphere 
that all this creates, more practically I don't have much time to contribute 
here so when I do so it's a significant effort on my part.  In exchange, I 
*demand* that others be respectful for that by making the effort of carefully 
reading and understanding what I'm writing, and trying to stay to the point as 
much as possible.  Else, I'm simply likely to loose interest and keep all my 
Emacs developments and customizations for myself (in 20+ years, they are 
numerous).  I'm hoping your nomination as a co-maintainer will help improve 
this situation, so I'm sorry to have had to drop that on you.

I've not given up on the idea to finally be able to upstream all that, but it 
most likely won't happen in the short term (next weeks/a few months) for time 
constraints.  Also, I hope that, when the time comes, the next interactions 
will be treated with the goodwill and productivity I expect (and which some of 
the "core" members have already shown they are largely capable of to me).

So this bug is effectively on hold on my side.  I would simply leave it open 
for the time being, but then it's your call on how you want to manage that 
administratively.  If you prefer to have a clean backlog, you can close it and 
I'll re-open it later when I'm ready.

Thanks and regards.

-- 
Olivier Certner







  reply	other threads:[~2023-09-19 16:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25 17:49 bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones Olivier Certner
2023-04-25 18:03 ` Eli Zaretskii
2023-04-25 20:57   ` Olivier Certner
2023-04-26  5:50     ` Eli Zaretskii
2023-04-26  7:28       ` Olivier Certner
2023-04-26  9:13         ` Eli Zaretskii
2023-04-26  9:31           ` Olivier Certner
2023-04-26 10:31             ` Eli Zaretskii
2023-04-26 13:09               ` Olivier Certner
2023-04-26 13:32                 ` Eli Zaretskii
2023-04-26 13:53                   ` Olivier Certner
2023-04-26 16:07                     ` Eli Zaretskii
2023-09-05 16:01                       ` Stefan Kangas
2023-09-15 12:41                       ` Stefan Kangas
2023-09-19 16:15                         ` Olivier Certner [this message]
2023-09-21 15:22                           ` Stefan Kangas

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=4916306.ghxcXLinNW@ravel \
    --to=ocert.dev@free.fr \
    --cc=63072@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=stefankangas@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).