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

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

[Olivier Certner]

Hi,

I noticed that the current "bsd" CC mode style is not compliant with what all BSDs have been doing since their inception. This is the first patch.

Also, FreeBSD and OpenBSD have been having more stringent requirements (as documented in their style(9) manpage; for more than 20 years). So the second patch creates specific "freebsd" and "openbsd" styles deriving from "bsd" and adding just the two additional requirements.

Patches to be attached after the bug report is created and assigned an ID.

Regards.

-- 
Olivier Certner

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

[Eli Zaretskii]

> From: Olivier Certner <ocert.dev@free.fr>
> Date: Tue, 25 Apr 2023 19:49:09 +0200
> 
> I noticed that the current "bsd" CC mode style is not compliant with what all BSDs have been doing since their inception. This is the first patch.

ENOPATCH, but in any case, I don't think we can change a style that
was in use for such a long time.  So I suggest instead to create a new
style, say bsd2 or somesuch.

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

[Olivier Certner]

> ENOPATCH,

Yes. See end of initial message + was temporarily distracted.

> but in any case, I don't think we can change a style that
> was in use for such a long time.  So I suggest instead to create a new
> style, say bsd2 or somesuch.

That may be a problem, not so much for the ancient "bsd", but for the new 
ones.

After more reading, it seems that this "bsd" is in fact Allman's style, which 
indeed differs for the style used by BSD projects. So, I'm pondering with 
using "bsd-knf" instead (for Kernel Normal Form), which appears to be the 
dedicated term (and is even documented in Wikipedia).

What I intend to do with "freebsd" and "openbsd" is to have styles reflecting 
the current practice for these projects. Which means they can (in fact, most 
probably will) be changed in the future according to how they amend their 
style guidelines. If this policy of changes is documented, is that OK?

For those who want to use the current style for whatever project they have and 
don't want it to change afterwards, we could, e.g., make "freebsd" an alias of 
some "freebsd1" style (let's say, for version 1), and they would "freebsd1", 
i.e., a specific version that will not change. I'm not sure if this will be 
useful for some people, but at least it is cheap to do so we should probably 
do it even if in the end nobody would use it.

I think I need a little bit more reading and pondering (and your answers) 
before I can actually submit meaningful patches. (So the interruption might 
have been a blessing.)

Thanks.

-- 
Olivier Certner

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

[Eli Zaretskii]

> From: Olivier Certner <ocert.dev@free.fr>
> Cc: 63072@debbugs.gnu.org
> Date: Tue, 25 Apr 2023 22:57:29 +0200
> 
> After more reading, it seems that this "bsd" is in fact Allman's style, which 
> indeed differs for the style used by BSD projects. So, I'm pondering with 
> using "bsd-knf" instead (for Kernel Normal Form), which appears to be the 
> dedicated term (and is even documented in Wikipedia).

Renaming old styles is also a problem, but new styles can be named as
we see fit, of course.

> What I intend to do with "freebsd" and "openbsd" is to have styles reflecting 
> the current practice for these projects. Which means they can (in fact, most 
> probably will) be changed in the future according to how they amend their 
> style guidelines. If this policy of changes is documented, is that OK?

If documented that these styles change to follow the corresponding
projects, it might be okay, but do we really want to commit ourselves
to follow them from now to eternity?  That's a non-trivial maintenance
burden, unless the projects themselves take that up upon themselves,
and will be submitting changes whenever their conventions change.

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

[Olivier Certner]

Hi,

> If documented that these styles change to follow the corresponding
> projects, it might be okay, but do we really want to commit ourselves
> to follow them from now to eternity?  That's a non-trivial maintenance
> burden, unless the projects themselves take that up upon themselves,
> and will be submitting changes whenever their conventions change.

But I never said we would commit to that. On the contrary, what I would like 
is that the documentation says clearly that "freebsd" and "openbsd" may 
change, so that people are aware they cannot rely on these styles to always 
remain the same (contrary to the old styles). So that's rather a non-
commitment.

Additionally, these changes will be exceedingly rare, and styles will just be 
updated on a best-effort basis.

Is that OK?

-- 
Olivier Certner

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

[Eli Zaretskii]

> From: Olivier Certner <ocert.dev@free.fr>
> Cc: 63072@debbugs.gnu.org
> Date: Wed, 26 Apr 2023 09:28:17 +0200
> 
> > If documented that these styles change to follow the corresponding
> > projects, it might be okay, but do we really want to commit ourselves
> > to follow them from now to eternity?  That's a non-trivial maintenance
> > burden, unless the projects themselves take that up upon themselves,
> > and will be submitting changes whenever their conventions change.
> 
> But I never said we would commit to that. On the contrary, what I would like 
> is that the documentation says clearly that "freebsd" and "openbsd" may 
> change, so that people are aware they cannot rely on these styles to always 
> remain the same (contrary to the old styles). So that's rather a non-
> commitment.
> 
> Additionally, these changes will be exceedingly rare, and styles will just be 
> updated on a best-effort basis.

The "best-effort" part is what bothers me.  We introduce these new
styles because the relevant projects change the styles, and then we
basically tell users: don't expect these styles to actually follow
those projects, except by luck?  Does that make sense?

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

[Olivier Certner]

> > Additionally, these changes will be exceedingly rare, and styles will just
> > be updated on a best-effort basis.
> 
> The "best-effort" part is what bothers me.  We introduce these new
> styles because the relevant projects change the styles, and then we
> basically tell users: don't expect these styles to actually follow
> those projects, except by luck?  Does that make sense?

By luck? The last changes in these styles with a practical consequence for CC 
mode were done more than 20 years ago. Had the changes proposed here been done 
at that time, users would have been able to use the right style since then.

Truth is, users not having the right style would be extremely unlucky, given 
the rate of changes (practically zero). These styles are *intended* to follow 
these projects' practice. And they will so more than 99% of the time. Of 
course, if a style changes and requires a CC style modification, then someone 
will have to submit it and in the meantime users will have to live with the 
discrepancy. Is that what really bothers you? That's what best effort means. 
Again, this will be useful to the relevant users more than 99% of the time.

-- 
Olivier Certner

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

[Eli Zaretskii]

> From: Olivier Certner <ocert.dev@free.fr>
> Cc: 63072@debbugs.gnu.org
> Date: Wed, 26 Apr 2023 11:31:28 +0200
> 
> > > Additionally, these changes will be exceedingly rare, and styles will just
> > > be updated on a best-effort basis.
> > 
> > The "best-effort" part is what bothers me.  We introduce these new
> > styles because the relevant projects change the styles, and then we
> > basically tell users: don't expect these styles to actually follow
> > those projects, except by luck?  Does that make sense?
> 
> By luck? The last changes in these styles with a practical consequence for CC 
> mode were done more than 20 years ago. Had the changes proposed here been done 
> at that time, users would have been able to use the right style since then.
> 
> Truth is, users not having the right style would be extremely unlucky, given 
> the rate of changes (practically zero). These styles are *intended* to follow 
> these projects' practice. And they will so more than 99% of the time. Of 
> course, if a style changes and requires a CC style modification, then someone 
> will have to submit it and in the meantime users will have to live with the 
> discrepancy. Is that what really bothers you? That's what best effort means. 
> Again, this will be useful to the relevant users more than 99% of the time.

If the styles don't change in practice, then I'm okay with adding
them.  But then I wonder why you bothered to mention the fact that
they do change.

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

[Olivier Certner]

> If the styles don't change in practice, then I'm okay with adding
> them.  But then I wonder why you bothered to mention the fact that
> they do change.

I thought this was clear, but apparently not. I mentioned the possibility of a 
change, yes, because you and I care about backwards compatibility. To quote 
you: "I don't think we can change a style that was in use for such a long 
time".

There may be changes in the project styles, maybe next month, maybe in ten 
years, maybe in twenty. I do not think the probability is 0 over such a long 
period of time. What I would not want is you or someone else telling me in 10 
or 20 years, after such a change: "I don't think we can change a style that 
was in use for such a long time". What I want instead is that, e.g., "freebsd" 
can be changed as necessary. I specifically do not want to then be told to 
create another style named "freebsd2" or whatever. For that to be possible, 
users must be warned that these styles, although almost always stable, are 
not, and will not, be set in stone for eternity, contrary to, perhaps, "bsd" 
or "whitesmith". And I even offered a scheme with additional styles that will 
never change, if you think that is useful (I think it might be and is so cheap 
to implement that I think we should do it anyway, even if in the end nobody 
uses it).

Is that clear now?

-- 
Olivier Certner

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

[Eli Zaretskii]

> From: Olivier Certner <ocert.dev@free.fr>
> Cc: 63072@debbugs.gnu.org
> Date: Wed, 26 Apr 2023 15:09:21 +0200
> 
> > If the styles don't change in practice, then I'm okay with adding
> > them.  But then I wonder why you bothered to mention the fact that
> > they do change.
> 
> I thought this was clear, but apparently not. I mentioned the possibility of a 
> change, yes, because you and I care about backwards compatibility. To quote 
> you: "I don't think we can change a style that was in use for such a long 
> time".
> 
> There may be changes in the project styles, maybe next month, maybe in ten 
> years, maybe in twenty. I do not think the probability is 0 over such a long 
> period of time. What I would not want is you or someone else telling me in 10 
> or 20 years, after such a change: "I don't think we can change a style that 
> was in use for such a long time". What I want instead is that, e.g., "freebsd" 
> can be changed as necessary. I specifically do not want to then be told to 
> create another style named "freebsd2" or whatever. For that to be possible, 
> users must be warned that these styles, although almost always stable, are 
> not, and will not, be set in stone for eternity, contrary to, perhaps, "bsd" 
> or "whitesmith". And I even offered a scheme with additional styles that will 
> never change, if you think that is useful (I think it might be and is so cheap 
> to implement that I think we should do it anyway, even if in the end nobody 
> uses it).
> 
> Is that clear now?

Given all that, I'm not sure we should single out these new styles at
all.  Once in 10 years any constant is eligible for a change.

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

[Olivier Certner]

> Given all that, I'm not sure we should single out these new styles at
> all.  Once in 10 years any constant is eligible for a change.

Then maybe it's my turn not to understand. To me, allowing them to be changed 
in 10 years from now is singling them out with respect to, e.g., "bsd" which, 
as you said yourself in preamble, should not be changed after all these years.

Apart from this caveat, I'm fine with your conclusion. 

-- 
Olivier Certner

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

[Eli Zaretskii]

> From: Olivier Certner <ocert.dev@free.fr>
> Cc: 63072@debbugs.gnu.org
> Date: Wed, 26 Apr 2023 15:53:21 +0200
> 
> > Given all that, I'm not sure we should single out these new styles at
> > all.  Once in 10 years any constant is eligible for a change.
> 
> Then maybe it's my turn not to understand. To me, allowing them to be changed 
> in 10 years from now is singling them out with respect to, e.g., "bsd" which, 
> as you said yourself in preamble, should not be changed after all these years.
> 
> Apart from this caveat, I'm fine with your conclusion. 

Let's see that patch of yours, then.

Thanks.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Olivier Certner <ocert.dev@free.fr>
>> Cc: 63072@debbugs.gnu.org
>> Date: Wed, 26 Apr 2023 15:53:21 +0200
>>
>> > Given all that, I'm not sure we should single out these new styles at
>> > all.  Once in 10 years any constant is eligible for a change.
>>
>> Then maybe it's my turn not to understand. To me, allowing them to be changed
>> in 10 years from now is singling them out with respect to, e.g., "bsd" which,
>> as you said yourself in preamble, should not be changed after all these years.
>>
>> Apart from this caveat, I'm fine with your conclusion.
>
> Let's see that patch of yours, then.

Oliver, did you have a chance to look into this?

Thanks.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Given all that, I'm not sure we should single out these new styles at
>> > all.  Once in 10 years any constant is eligible for a change.
>>
>> Then maybe it's my turn not to understand. To me, allowing them to be changed
>> in 10 years from now is singling them out with respect to, e.g., "bsd" which,
>> as you said yourself in preamble, should not be changed after all these years.
>>
>> Apart from this caveat, I'm fine with your conclusion.
>
> Let's see that patch of yours, then.

Ping.  Any progress with coming up with a patch?

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

[Olivier Certner]

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

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.