* Creating a git branch for cond* @ 2024-01-25 15:48 Alan Mackenzie 2024-01-25 15:53 ` Eli Zaretskii 2024-01-25 16:16 ` Alfred M. Szmidt 0 siblings, 2 replies; 16+ messages in thread From: Alan Mackenzie @ 2024-01-25 15:48 UTC (permalink / raw) To: Richard Stallman, Eli Zaretskii, emacs-devel Hello, Richard, Eli, and Emacs. Richard posted some embryonic code for cond* a little over a week ago. To move things forward, I propose creating the git branch feature/condstar, and incorporating the new code into it in lisp/emacs-lisp/condstar.el. This will enable its development to happen more systematically and rapidly. Does anybody have any objections? -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 15:48 Creating a git branch for cond* Alan Mackenzie @ 2024-01-25 15:53 ` Eli Zaretskii 2024-01-25 16:08 ` Alan Mackenzie 2024-01-29 3:19 ` Richard Stallman 2024-01-25 16:16 ` Alfred M. Szmidt 1 sibling, 2 replies; 16+ messages in thread From: Eli Zaretskii @ 2024-01-25 15:53 UTC (permalink / raw) To: Alan Mackenzie; +Cc: rms, emacs-devel > Date: Thu, 25 Jan 2024 15:48:18 +0000 > From: Alan Mackenzie <acm@muc.de> > > Hello, Richard, Eli, and Emacs. > > Richard posted some embryonic code for cond* a little over a week ago. > > To move things forward, I propose creating the git branch > feature/condstar, and incorporating the new code into it in > lisp/emacs-lisp/condstar.el. This will enable its development to happen > more systematically and rapidly. > > Does anybody have any objections? You intend to maintain that branch personally? If you intend for Richard to do that, it's up to him, I think. Having more than one branch in a repository complicates Git-related workflows, and could cause problems if the user pushes to the wrong branch. So it is not an easy decision. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 15:53 ` Eli Zaretskii @ 2024-01-25 16:08 ` Alan Mackenzie 2024-01-25 16:14 ` Eli Zaretskii 2024-01-29 3:19 ` Richard Stallman 1 sibling, 1 reply; 16+ messages in thread From: Alan Mackenzie @ 2024-01-25 16:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rms, emacs-devel Hello, Eli. On Thu, Jan 25, 2024 at 17:53:51 +0200, Eli Zaretskii wrote: > > Date: Thu, 25 Jan 2024 15:48:18 +0000 > > From: Alan Mackenzie <acm@muc.de> > > Hello, Richard, Eli, and Emacs. > > Richard posted some embryonic code for cond* a little over a week ago. > > To move things forward, I propose creating the git branch > > feature/condstar, and incorporating the new code into it in > > lisp/emacs-lisp/condstar.el. This will enable its development to happen > > more systematically and rapidly. > > Does anybody have any objections? > You intend to maintain that branch personally? I'm prepared to do that, yes. > If you intend for Richard to do that, it's up to him, I think. Richard will surely respond to my last post. Let's see what he says. > Having more than one branch in a repository complicates Git-related > workflows, and could cause problems if the user pushes to the wrong > branch. So it is not an easy decision. It's clear from my code reviewing so far that cond* is not yet ready for prime time. Creating a branch for it would be, I think, the normal thing in Emacs development. My main motivation is not to let the current impetus peter out. But let's see what Richard says. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 16:08 ` Alan Mackenzie @ 2024-01-25 16:14 ` Eli Zaretskii 0 siblings, 0 replies; 16+ messages in thread From: Eli Zaretskii @ 2024-01-25 16:14 UTC (permalink / raw) To: Alan Mackenzie; +Cc: rms, emacs-devel > Date: Thu, 25 Jan 2024 16:08:37 +0000 > Cc: rms@gnu.org, emacs-devel@gnu.org > From: Alan Mackenzie <acm@muc.de> > > My main motivation is not to let the current impetus peter out. You should have no reasons to worry about that. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 15:53 ` Eli Zaretskii 2024-01-25 16:08 ` Alan Mackenzie @ 2024-01-29 3:19 ` Richard Stallman 2024-01-29 3:36 ` Eli Zaretskii 1 sibling, 1 reply; 16+ messages in thread From: Richard Stallman @ 2024-01-29 3:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] cond* is just one file, and no change in anyplace else is needed to get it working and make it usable. So there should be no need for a branch for it. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-29 3:19 ` Richard Stallman @ 2024-01-29 3:36 ` Eli Zaretskii 2024-01-29 3:51 ` Jim Porter 2024-02-02 3:40 ` Richard Stallman 0 siblings, 2 replies; 16+ messages in thread From: Eli Zaretskii @ 2024-01-29 3:36 UTC (permalink / raw) To: rms; +Cc: acm, emacs-devel > From: Richard Stallman <rms@gnu.org> > Cc: acm@muc.de, emacs-devel@gnu.org > Date: Sun, 28 Jan 2024 22:19:24 -0500 > > cond* is just one file, and no change in anyplace else is needed to > get it working and make it usable. So there should be no need for a > branch for it. The idea was to keep it on a branch until we decide it is ready to land on master. Having it on a branch will allow to work on finilizing it more conveniently. This includes solving any significant issues and adding documentation. I would prefer to keep it on a branch during this (hopefully, short) period, since that would allow us to keep its history afterwards, and will also avoid the need to send whole files each time something changes. Alan offered his technical help in managing this vis-a-vis Git, so you personally don't need to worry about these aspects. But for us, having cond* on a branch during this period is a significant advantage. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-29 3:36 ` Eli Zaretskii @ 2024-01-29 3:51 ` Jim Porter 2024-02-02 3:40 ` Richard Stallman 1 sibling, 0 replies; 16+ messages in thread From: Jim Porter @ 2024-01-29 3:51 UTC (permalink / raw) To: Eli Zaretskii, rms; +Cc: acm, emacs-devel On 1/28/2024 7:36 PM, Eli Zaretskii wrote: > The idea was to keep it on a branch until we decide it is ready to > land on master. Having it on a branch will allow to work on > finilizing it more conveniently. This includes solving any > significant issues and adding documentation. I would prefer to keep > it on a branch during this (hopefully, short) period, since that would > allow us to keep its history afterwards, and will also avoid the > need to send whole files each time something changes. One thing I especially hope for with a branch for cond* is that it would allow for making backwards-incompatible changes without (much) risk of causing problems for users of cond*. I'm open to the possibility that cond* is nicer than pcase (for my purposes, anyway), but I'm not sure yet. A branch would make it easier for me to track any changes to cond* and try my hand at rewriting some pcase-based code to use cond*. Such an attempt might reveal some area of improvement for cond*, and it would be a shame if it were too late to do anything about it. (Of course, we could probably change cond* in backwards-incompatible ways up until Emacs 30.1 or so, but I think it'd be nicer for everyone if it were mostly-stable by the time it hits master so that people who prefer it can start using it without worrying much about breaking changes.) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-29 3:36 ` Eli Zaretskii 2024-01-29 3:51 ` Jim Porter @ 2024-02-02 3:40 ` Richard Stallman 2024-02-02 7:17 ` Eli Zaretskii 1 sibling, 1 reply; 16+ messages in thread From: Richard Stallman @ 2024-02-02 3:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The idea was to keep it on a branch until we decide it is ready to > land on master. Having it on a branch will allow to work on > finilizing it more conveniently. This includes solving any > significant issues and adding documentation. I would prefer to keep > it on a branch during this (hopefully, short) period, since that would > allow us to keep its history afterwards, and will also avoid the > need to send whole files each time something changes. I really don't want it to be in a branch, but I can commit some of the past versions before committing te current versions. I figure to start with the earliet version that's not drastically different. WDYT? -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-02-02 3:40 ` Richard Stallman @ 2024-02-02 7:17 ` Eli Zaretskii 0 siblings, 0 replies; 16+ messages in thread From: Eli Zaretskii @ 2024-02-02 7:17 UTC (permalink / raw) To: rms; +Cc: acm, emacs-devel > From: Richard Stallman <rms@gnu.org> > Cc: acm@muc.de, emacs-devel@gnu.org > Date: Thu, 01 Feb 2024 22:40:24 -0500 > > > The idea was to keep it on a branch until we decide it is ready to > > land on master. Having it on a branch will allow to work on > > finilizing it more conveniently. This includes solving any > > significant issues and adding documentation. I would prefer to keep > > it on a branch during this (hopefully, short) period, since that would > > allow us to keep its history afterwards, and will also avoid the > > need to send whole files each time something changes. > > I really don't want it to be in a branch, but I can commit some of the > past versions before committing te current versions. I figure to start > with the earliet version that's not drastically different. WDYT? We can start with whatever version you like. What's important is that all the changes since the first commit are tracked by Git, rather than maintaining the code aside, locally on someone's machine. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 15:48 Creating a git branch for cond* Alan Mackenzie 2024-01-25 15:53 ` Eli Zaretskii @ 2024-01-25 16:16 ` Alfred M. Szmidt 2024-01-25 16:37 ` Alan Mackenzie 1 sibling, 1 reply; 16+ messages in thread From: Alfred M. Szmidt @ 2024-01-25 16:16 UTC (permalink / raw) To: Alan Mackenzie; +Cc: rms, eliz, emacs-devel Hello, Richard, Eli, and Emacs. Richard posted some embryonic code for cond* a little over a week ago. To move things forward, I propose creating the git branch feature/condstar, and incorporating the new code into it in lisp/emacs-lisp/condstar.el. This will enable its development to happen more systematically and rapidly. Does anybody have any objections? I hope it goes to master directly, it is a single file that doesn't affect anything else. And _if_ existing code is updated to use cond* that will get much more milage. Nothing should really stop development if this lives on master, or a branch. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 16:16 ` Alfred M. Szmidt @ 2024-01-25 16:37 ` Alan Mackenzie 2024-01-25 16:49 ` Alfred M. Szmidt ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Alan Mackenzie @ 2024-01-25 16:37 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: rms, eliz, emacs-devel Hello, Alfred. On Thu, Jan 25, 2024 at 11:16:43 -0500, Alfred M. Szmidt wrote: > Hello, Richard, Eli, and Emacs. > Richard posted some embryonic code for cond* a little over a week ago. > To move things forward, I propose creating the git branch > feature/condstar, and incorporating the new code into it in > lisp/emacs-lisp/condstar.el. This will enable its development to happen > more systematically and rapidly. > Does anybody have any objections? > I hope it goes to master directly, it is a single file that doesn't > affect anything else. And _if_ existing code is updated to use cond* > that will get much more milage. It does affect other things, in particular, other .el files which are adapted to use cond*. If that happens on master, then both cond* and the conversion need to be perfect before the file can be committed. On a branch, things can be a lot less constrained. What I want to do early on in cond* development is convert lisp/emacs-lisp/macroexp.el from pcase to cond*. Currently, pcase.el is dependent upon macroexp.el and macroexp.el is dependent upon pcase.el. This leads to an unlovely artifice in the bootstrapping file, loadup.el, and this has caused me grief in another branch I'm working on. cond* has no dependency on macroexp.el, so could simply be loaded as the fourth file, after debug-early.el, byte-run.el, backquote.el. Having macroexp.el loaded as the fifth file (rather than the 17th, as it currently is) would simplify the initial loadup appreciably. No doubt Eli will have something to say about this idea. ;-) > Nothing should really stop development if this lives on master, or a > branch. There are advantages to the branch, as well as advantages to having it on master. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 16:37 ` Alan Mackenzie @ 2024-01-25 16:49 ` Alfred M. Szmidt 2024-01-25 16:56 ` Eli Zaretskii 2024-01-25 19:47 ` Stefan Kangas 2 siblings, 0 replies; 16+ messages in thread From: Alfred M. Szmidt @ 2024-01-25 16:49 UTC (permalink / raw) To: Alan Mackenzie; +Cc: rms, eliz, emacs-devel What I want to do early on in cond* development is convert lisp/emacs-lisp/macroexp.el from pcase to cond*. Currently, pcase.el is dependent upon macroexp.el and macroexp.el is dependent upon pcase.el. This leads to an unlovely artifice in the bootstrapping file, loadup.el, and this has caused me grief in another branch I'm working on. Wouldn't it make more sense to put _those_ changes on a branch when cond* is on master? macroexp.el changes would have much more significant impact on things than just adding cond*. And when cond* is modified in a significant matter, it would be easy to rebase the branch accordingly. The additional beneift would be that one would have good examples of where cond* is much clearer than pcase. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 16:37 ` Alan Mackenzie 2024-01-25 16:49 ` Alfred M. Szmidt @ 2024-01-25 16:56 ` Eli Zaretskii 2024-01-25 17:57 ` Alan Mackenzie 2024-01-25 19:47 ` Stefan Kangas 2 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2024-01-25 16:56 UTC (permalink / raw) To: Alan Mackenzie; +Cc: ams, rms, emacs-devel > Date: Thu, 25 Jan 2024 16:37:44 +0000 > Cc: rms@gnu.org, eliz@gnu.org, emacs-devel@gnu.org > From: Alan Mackenzie <acm@muc.de> > > > I hope it goes to master directly, it is a single file that doesn't > > affect anything else. And _if_ existing code is updated to use cond* > > that will get much more milage. > > It does affect other things, in particular, other .el files which are > adapted to use cond*. Please don't make any changes except installing cond* and fixing it. There's no decision yet to start converting any code to use it, nor do I envision such a decision any time soon. > If that happens on master, then both cond* and > the conversion need to be perfect before the file can be committed. Once again: we are not converting anything, at least not yet. We are only discussing how best to handle installation of cond*. > What I want to do early on in cond* development is convert > lisp/emacs-lisp/macroexp.el from pcase to cond*. I don't agree with such a change, so please don't do anything like that. > Currently, pcase.el is dependent upon macroexp.el and macroexp.el is > dependent upon pcase.el. This leads to an unlovely artifice in the > bootstrapping file, loadup.el, and this has caused me grief in > another branch I'm working on. We are not going to make any such changes just because we can, or just because you have problems on some branch you'd like to avoid fixing. cond* is a new construct, and once it is in Emacs, and documented as it should be, we should collect experience with using it before we even think about converting existing code. Please don't forget that Emacs is a stable program: we don't make changes just because we can. Changes to code that was with us for years are only justified if we have a very good reason. > No doubt Eli will have something to say about this idea. ;-) He does, see above. You don't have my okay for making any changes except installing cond* and fixing it and its documentation. Btw, we should also have tests for it. > There are advantages to the branch, as well as advantages to having it > on master. Yes. But, as you say, let's hear what Richard thinks about this. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 16:56 ` Eli Zaretskii @ 2024-01-25 17:57 ` Alan Mackenzie 0 siblings, 0 replies; 16+ messages in thread From: Alan Mackenzie @ 2024-01-25 17:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ams, rms, emacs-devel Hello, Eli. On Thu, Jan 25, 2024 at 18:56:05 +0200, Eli Zaretskii wrote: > > Date: Thu, 25 Jan 2024 16:37:44 +0000 > > Cc: rms@gnu.org, eliz@gnu.org, emacs-devel@gnu.org > > From: Alan Mackenzie <acm@muc.de> > > > I hope it goes to master directly, it is a single file that doesn't > > > affect anything else. And _if_ existing code is updated to use cond* > > > that will get much more milage. > > It does affect other things, in particular, other .el files which are > > adapted to use cond*. > Please don't make any changes except installing cond* and fixing it. > There's no decision yet to start converting any code to use it, nor do > I envision such a decision any time soon. > > If that happens on master, then both cond* and > > the conversion need to be perfect before the file can be committed. > Once again: we are not converting anything, at least not yet. We are > only discussing how best to handle installation of cond*. > > What I want to do early on in cond* development is convert > > lisp/emacs-lisp/macroexp.el from pcase to cond*. > I don't agree with such a change, so please don't do anything like > that. You know me. I wouldn't make any such changes without asking first, anyway. But for people asking _why_ we're introducing cond*, that it opens up such possibilities is a good answer. > > Currently, pcase.el is dependent upon macroexp.el and macroexp.el is > > dependent upon pcase.el. This leads to an unlovely artifice in the > > bootstrapping file, loadup.el, and this has caused me grief in > > another branch I'm working on. > We are not going to make any such changes just because we can, or just > because you have problems on some branch you'd like to avoid fixing. The point I was making is that our bootstrap procedure in loadup.el verges on unmaintainability. What should be a simple linear list of ..el(c) files being loaded one after the other has turned into a difficult tree where some files are loaded from loadup, some are loaded with (require 'foo) inside eval-when-compile, and some may be straight requires, I can't remember exactly. Some loaded files get unloaded again. (pcase.el is an example.) macroexp.el is loaded twice (or four times, if you count the second loadup separately). All this has hindered me on that other branch (for bug #67455, about getting position information into doc strings that we discussed extensively back in November). It is likely to hinder others, too. My point was that cond*, once it's established, will give us the mechanism to sort at least some of this out. > cond* is a new construct, and once it is in Emacs, and documented as > it should be, we should collect experience with using it before we > even think about converting existing code. > Please don't forget that Emacs is a stable program: we don't make > changes just because we can. Changes to code that was with us for > years are only justified if we have a very good reason. Understood. > > No doubt Eli will have something to say about this idea. ;-) > He does, see above. You don't have my okay for making any changes > except installing cond* and fixing it and its documentation. > Btw, we should also have tests for it. Indeed. They will be needed to get the code working properly anyway. > > There are advantages to the branch, as well as advantages to having it > > on master. > Yes. But, as you say, let's hear what Richard thinks about this. Yes. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 16:37 ` Alan Mackenzie 2024-01-25 16:49 ` Alfred M. Szmidt 2024-01-25 16:56 ` Eli Zaretskii @ 2024-01-25 19:47 ` Stefan Kangas 2024-01-25 20:08 ` Alan Mackenzie 2 siblings, 1 reply; 16+ messages in thread From: Stefan Kangas @ 2024-01-25 19:47 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel Alan Mackenzie <acm@muc.de> writes: > What I want to do early on in cond* development is convert > lisp/emacs-lisp/macroexp.el from pcase to cond*. I think such a decision should strongly involve the people mainly responsible for maintaining that file. Here are the top 5 contributors to that file, going by number of lines: 501 Stefan Monnier 136 Mattias Engdegård 88 Miles Bader 39 Paul Eggert 18 Alan Mackenzie Going by number of commits, it looks something much like that (though Eggert has more commits than Bader). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Creating a git branch for cond* 2024-01-25 19:47 ` Stefan Kangas @ 2024-01-25 20:08 ` Alan Mackenzie 0 siblings, 0 replies; 16+ messages in thread From: Alan Mackenzie @ 2024-01-25 20:08 UTC (permalink / raw) To: Stefan Kangas; +Cc: emacs-devel Hello, Stefan. On Thu, Jan 25, 2024 at 11:47:36 -0800, Stefan Kangas wrote: > Alan Mackenzie <acm@muc.de> writes: > > What I want to do early on in cond* development is convert > > lisp/emacs-lisp/macroexp.el from pcase to cond*. > I think such a decision should strongly involve the people mainly > responsible for maintaining that file. Of course. It should be a decision reached factually after open discussion on this mailing list. I believe the benefits of this change would be substantial, as outlined in another post. But that is to be demonstrated after cond* is up and running. > Here are the top 5 contributors to that file, going by number of > lines: > 501 Stefan Monnier > 136 Mattias Engdegård > 88 Miles Bader > 39 Paul Eggert > 18 Alan Mackenzie > Going by number of commits, it looks something much like that (though > Eggert has more commits than Bader). Miles is no longer actively contributing to Emacs (unfortunately). If I remember correctly, he was the prime mover in implementing lexical binding, which probably explains his high activity with this file. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-02-02 7:17 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-01-25 15:48 Creating a git branch for cond* Alan Mackenzie 2024-01-25 15:53 ` Eli Zaretskii 2024-01-25 16:08 ` Alan Mackenzie 2024-01-25 16:14 ` Eli Zaretskii 2024-01-29 3:19 ` Richard Stallman 2024-01-29 3:36 ` Eli Zaretskii 2024-01-29 3:51 ` Jim Porter 2024-02-02 3:40 ` Richard Stallman 2024-02-02 7:17 ` Eli Zaretskii 2024-01-25 16:16 ` Alfred M. Szmidt 2024-01-25 16:37 ` Alan Mackenzie 2024-01-25 16:49 ` Alfred M. Szmidt 2024-01-25 16:56 ` Eli Zaretskii 2024-01-25 17:57 ` Alan Mackenzie 2024-01-25 19:47 ` Stefan Kangas 2024-01-25 20:08 ` Alan Mackenzie
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.