FontManager SWIs mistake

[Justin F]

> On 8 Dec, Justin F wrote in message
>     <alpine.DEB.2.21.1912080951040.23300 at work.gerph.org>:
> 
> > This one is curious in that it's clearly been there a long time.
> > 
> >    Font_UseLinefeed         = Font_ListContext:     %1000000000000000000,
> > 
> > That bit uses a Carriage Return if it's set, not a line feed.
> 
> I've just started looking back through the unfixed reports, and wondered
> what the preferred approach was to things like this? The options seem to be:
> 
> 1) Ignore it, or
> 
> 2) Change the entry to Font_UseCarriageReturn, which will break any code
> that's using Font_UseLinefeed, or

I'd go with this one.

Reasoning:

In C, it would be very unlikely to have anyone actually using this 
constant - because they'd more than likely be using a NUL not a CR, and 
if they were, their code would already handle the interpretation of the 
terminator as being a '\r'. So almost certainly they'll now have code 
which says 'use linefeed' and then in the parser looks for CRs - and thus
when writing it, and when reading it, they will have gone 'tut, OSLib's 
got it wrong', and may even have comments beside the constant saying 'this 
isn't really a linefeed, it's a carriage return, OSLib's labelled it 
wrongly'.

So, by removing the erroneous label you reduce confusion for people in the
future, and you break current user's code compiling - which in this 
instance is a good thing, because they'll look at their code and realise 
it was wrong, and fix it, thus removing a burden for them of having to 
question the behaviour of that code every time they review it and 
notes about its use. It also removes any sort of confusion in the future
over whether it really is a linefeed or return.

BUT - the number of people affected by this will be near 0 because you'd 
have to be a C author writing code that works to the BASIC convention of 
line endings, which has to be a pretty small minority. If you were 
providing a module which exposed the FontManager interfaces in a way that 
was more paletteable to BASIC users then that might be a reason but... 
that's now so niche even I'm not sure that such a thing would happen.

> 3) Add a Font_UseCarriageReturn in parallel to Font_UseLinefeed.

This is another option I guess is ok, but it would obviously also require 
that there be a description on the UseLineFeed one that said "Don't use 
this, it's a lie"... which is really just more justification for going for 
option 2.

> I'd probably go for 2) or 3), with a leaning towards 2) if it were my own
> library but 3) in the case of OSLib because it's not. And assuming that
> different names for the same bit won't break anything (it seems to build
> OK).
> 
> Is there a policy on making breaking changes?

In the past, typos appear to have been retained and provided with 
corrected labels, which is ok for typos where the /intent/ was obviously
the same. In this case, the intent of 'UseLinefeed' and 
'UseCarriageReturn' is quite different, so replacement with the correct 
one seems a reasonable choice.

-- 
Charles Justin Ferguson
[ All information, speculation, opinion or data within, or attached to,
  this email is private and confidential. Such content may not be
  disclosed to third parties, or a public forum, without explicit
  permission being granted. ]