bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones

[Stefan Kangas]

Hi Olivier,

Olivier Certner <ocert.dev@free.fr> writes:

> 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 understand your position, and let me be the first to acknowledge that
email can be a challenging medium to work in.  From my point of view, I
can only urge everyone to try work together even when there are or have
been misunderstandings.

I also urge people to give each other the benefit of the doubt.  If
someone asks a question, more likely than not it is a genuine question.
Emacs contributors come from all types of backgrounds, and there's
always a chance that someone is lacking the necessary context to
understand what is being said.  Or they didn't yet have their morning
coffee... you know, shit happens.  Let's be patient with each other when
we make mistakes or oversee some important aspect.

The GNU Kind Communication Guidelines is recommended reading as a broad
outline of the kind of environment we try to foster (even though we
don't always succeed, admittedly):

    https://www.gnu.org/philosophy/kind-communication.html

My goal is that we can find a way to work constructively and move
forward towards our common goal of improving Emacs.  That would be the
best outcome.  If we fail, let's try again, and let's try to do better.
In my experience, we usually get the best result if we focus on the
specifics of the issue at hand.

> 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.

I suggest keeping the bug open for now, as a reminder about this work.
There is no rush, but I'm looking forward to seeing your patch once you
can find the time to work on it.

Thanks again for your contributions.