[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22847: #17062: 24.3 current-fill-column breaks fill-match-adaptive-p
bug#22847: #17062: 24.3 current-fill-column breaks fill-match-adaptive-prefix
Sat, 10 Dec 2016 21:18:57 -0500
Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
Eli Zaretskii wrote:
>> 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,
> . 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.
> . 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.