* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones @ 2023-04-25 17:49 Olivier Certner 2023-04-25 18:03 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Olivier Certner @ 2023-04-25 17:49 UTC (permalink / raw) To: 63072 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 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 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2023-04-25 18:03 UTC (permalink / raw) To: Olivier Certner; +Cc: 63072 > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-04-25 18:03 ` Eli Zaretskii @ 2023-04-25 20:57 ` Olivier Certner 2023-04-26 5:50 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Olivier Certner @ 2023-04-25 20:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 63072 > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-04-25 20:57 ` Olivier Certner @ 2023-04-26 5:50 ` Eli Zaretskii 2023-04-26 7:28 ` Olivier Certner 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2023-04-26 5:50 UTC (permalink / raw) To: Olivier Certner; +Cc: 63072 > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-04-26 5:50 ` Eli Zaretskii @ 2023-04-26 7:28 ` Olivier Certner 2023-04-26 9:13 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Olivier Certner @ 2023-04-26 7:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 63072 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-04-26 7:28 ` Olivier Certner @ 2023-04-26 9:13 ` Eli Zaretskii 2023-04-26 9:31 ` Olivier Certner 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2023-04-26 9:13 UTC (permalink / raw) To: Olivier Certner; +Cc: 63072 > 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-04-26 9:13 ` Eli Zaretskii @ 2023-04-26 9:31 ` Olivier Certner 2023-04-26 10:31 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Olivier Certner @ 2023-04-26 9:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 63072 > > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-04-26 9:31 ` Olivier Certner @ 2023-04-26 10:31 ` Eli Zaretskii 2023-04-26 13:09 ` Olivier Certner 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2023-04-26 10:31 UTC (permalink / raw) To: Olivier Certner; +Cc: 63072 > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-04-26 10:31 ` Eli Zaretskii @ 2023-04-26 13:09 ` Olivier Certner 2023-04-26 13:32 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Olivier Certner @ 2023-04-26 13:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 63072 > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-04-26 13:09 ` Olivier Certner @ 2023-04-26 13:32 ` Eli Zaretskii 2023-04-26 13:53 ` Olivier Certner 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2023-04-26 13:32 UTC (permalink / raw) To: Olivier Certner; +Cc: 63072 > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-04-26 13:32 ` Eli Zaretskii @ 2023-04-26 13:53 ` Olivier Certner 2023-04-26 16:07 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Olivier Certner @ 2023-04-26 13:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 63072 > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 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 0 siblings, 2 replies; 16+ messages in thread From: Eli Zaretskii @ 2023-04-26 16:07 UTC (permalink / raw) To: Olivier Certner; +Cc: 63072 > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-04-26 16:07 ` Eli Zaretskii @ 2023-09-05 16:01 ` Stefan Kangas 2023-09-15 12:41 ` Stefan Kangas 1 sibling, 0 replies; 16+ messages in thread From: Stefan Kangas @ 2023-09-05 16:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 63072, Olivier Certner 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 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 1 sibling, 1 reply; 16+ messages in thread From: Stefan Kangas @ 2023-09-15 12:41 UTC (permalink / raw) To: Eli Zaretskii, Olivier Certner; +Cc: 63072 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-09-15 12:41 ` Stefan Kangas @ 2023-09-19 16:15 ` Olivier Certner 2023-09-21 15:22 ` Stefan Kangas 0 siblings, 1 reply; 16+ messages in thread From: Olivier Certner @ 2023-09-19 16:15 UTC (permalink / raw) To: Stefan Kangas; +Cc: Eli Zaretskii, 63072 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#63072: 28.2; CC Mode: Fix "bsd" style and add "freebsd" and "openbsd" ones 2023-09-19 16:15 ` Olivier Certner @ 2023-09-21 15:22 ` Stefan Kangas 0 siblings, 0 replies; 16+ messages in thread From: Stefan Kangas @ 2023-09-21 15:22 UTC (permalink / raw) To: Olivier Certner; +Cc: Eli Zaretskii, 63072 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2023-09-21 15:22 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2023-09-21 15:22 ` Stefan Kangas
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.