tags 22847 + patch thanks Glenn Morris writes: > Eli Zaretskii wrote: > >>> TLDR: >>> Let's remove the test for nil fill-column in current-fill-column. >> >> I don't understand what you propose to do instead. >> current-fill-column does arithmetics on fill-column when it's non-nil, >> so we cannot just remove the test, because the function will then >> signal an error. > > Yes, I'm fine with the error. > >> I see 3 possible ways to fix these bugs: >> >> . Fix the code which is not prepared for fill-column being nil to be >> prepared. This leaves everyone happy, except, perhaps, the person >> who would need to fix all those places in Emacs. > > I think this would be a waste of time for the Emacs, and third party, > maintainers. Agreed. >> . Change current-fill-column to return most-positive-fixnum when >> fill-column is nil. > > I suppose this would be ok, so long as it comes with something like a > once-per session display-warning about this being an obsolete usage that > will be removed soon. I've attached a proposed patch which does that here. >> . Disallow fill-column being nil and remove the test from >> current-fill-column without changing anything else, i.e. let it >> signal an error, perhaps with some text that tells this value is >> no longer supported. This will break setups of those who use that >> value to disable auto-fill, something that was available since >> forever, so I don't think we can do that. > > That's what I would do. I don't have a problem breaking an undocumented > feature that already fails in several places, and has a trivial > workaround (don't want auto-fill - don't turn it on). Other times I can > recall similar breakage happening: byte-compile of nil, setq with odd > number of arguments. People gripe for a bit, then get on with life. I'm perfectly fine with this solution as well, if we prefer that. Thoughts? Best regards, Stefan Kangas