minad
commented
1 year ago Thank you for notifying me about this issue.
Removing the function at this stage won't be ideal, since packages may rely on it and Compat has seen growing adoption in recent months. file-name-split seems like a potentially popular function.
The reason I did not add this function, was that the semantics were not clear and edge-cases (which are currently not tested in compat-test) were very inconsistent.
Note that the common cases we test are guaranteed to be consistent. It is okay if packages rely on these cases. There is no uncertainty regarding these cases.
The manual explicitly mentions that Emacs 29 functionality may change. If we change the behavior of the function in edge cases, it can be considered a bug fix, but such potential changes don't justify removing the function again. Obviously the situation would be different if the function causes serious issues in popular downstream packages, which does not seem to be the case.
Changes in Emacs at this point have the same character for downstream users. Emacs 29 is already widely rolled out in its current form, this is at least the feeling I got from reports in my packages. Iirc the data of the Emacs community survey gave a similar result, but it was probably biased towards enthusiasts which regularly build Emacs from source.
BTW. this is one of the reasons I don't like releasing Compat X.1.0.0 before Emacs X.1 is released, I would suggest we refrain from doing so in the future.
I see your point, however we only released Compat 29 when Emacs 29 was already frozen. I am fully with you that a release should not happen significantly earlier. For package authors it is good if we have a somewhat early access to features, also since we can provide feedback regarding APIs. From my personal experience I can tell you that this is valuable. I am sure that other package authors agree with me on that, given that new Compat functionality has seen early adoption, e.g., in Transient or Magit. Releasing Compat early enough enabled Jonas to follow upstream changes in Transient and merge them back to Emacs before the release of Emacs 29.1. This would be harder otherwise.
I suggest we keep the function and follow changes which make it into Emacs 29. For the future, ideally bugs in new APIs are sorted out earlier. To give you some more perspective, sometimes bugs in Emacs are fixed in a backward incompatible and messy way, e.g., the function string-lines, which just changed its behavior between releases. This is not great and we should do our best to avoid such situations in the future. Changes of edge cases in file-name-split do not seem as serious.
I hope we can converge to a workflow where new Emacs APIs are added soon to Compat in a separate branch. Then we provide critical feedback and testing early on. This will help preventing changes in APIs at a late stage. The new emacs-30 branch is a good start in that direction. Maybe we can even encourage other Emacs contributors to also contribute to Compat as Joseph did.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57102. The reason I did not add this function, was that the semantics were not clear and edge-cases (which are currently not tested in
compat-test) were very inconsistent. I don't think it is a good idea to distribute Compat with this kind of uncertainty, especially because upstream has no better solution either.(BTW. this is one of the reasons I don't like releasing Compat X.1.0.0 before Emacs X.1 is released, I would suggest we refrain from doing so in the future)
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57102.