Re: a scheduled compatibility handling in the Texinfo language?

[Patrice Dumas]

On Fri, Oct 28, 2011 at 11:26:15PM +0000, Karl Berry wrote:
> My basic idea about compatibility (wrt Texinfo) is that we should always
> intend to be completely compatible.

Agreed.

> The things we cleaned up in the
> process of the Perl implementation notwithstanding -- I don't see such a
> thing happening again.

This has happened in the past, this will happen again.  Although it is right
to try at best to be completly compatible, sometime obsoleting parts of the
language is also a good thing in my opinion.  For an example of a radical
change that could have happened, there was the obsoletion of @rmacro, or 
change of its behaviour (although in the end it is still there).

Some future changes that could make sense (I am not proposing them right 
now, but I noticed shortcomings of these constructs while implementing
the output) there is replacing @item with different commands based on the
line orientation or not of the context (that is a different command in 
@table, @vtable, @ftable than in other contexts) or replacing @center 
with a command that may be used in more context and a less ambiguous end 
than end of line.

So, my proposal tried to have a balance between infinite compatibility, 
which I think, based on past experience is impossible, and changes 
impacting the user by doing this 2 stageg obsolescence procedure, with
the time duration long enough (10 years?) such that this pproaches infinity.

Also, please note that at the end of this period we would only stop making
promises that the initial feature is still there, but we still could keep
it until the end of time until we need to decrease the code complexity
or do a new implementation.

> These are problems but I don't see how compatibility commands would ease
> the pain for users.  Giving a warning is, in a sense, a compatibility
> decision -- not making it an error, that is.

I tend to disagree, warnings, especially high amounts of warning are
very annoying since they may hide problematic warnings which result
in bad outputs.

> Users are going to hate the warnings about :'s in index entries,
> especially when we have no good solution for them to adopt.  Granted the
> resulting Info is invalid, but ... I'm still thinking it would be better
> to wait on the warnings on that until there is a clean way users can fix
> their documents?

That's the kind of situation my proposal was trying to address: the new
feaature, "warnings for index entry with :" is only enabled explicitly
for X years and become the default for Y years, but at that point we
should have come up with a solution.

>     * deprecation warnings for @refill
> 
> Well, when I run (Perl) makeinfo on texinfo.txi, there aren't
> deprecation warnings for the zillions of @refill cmds it still has.  And

Of course, this is a future feature...  I think it is important, especially
for manuals that may be used as starting points for other manuals not to
have old constructs that, even though they are not problematic, may lead
the manual source reader to think that the construct is important.  So I think
that having warnings for @refill would be a very interesting feature.  With
my proposal, they would not be on by default for X years, and when they become
on after the X years, it would still be possible to turn the warning of with
the compatibility command.

> I don't think there should be such a warning.  I'd rather retain the
> historical baggage than make users deal with warnings for no practical
> purpose.

Having manuals tidy is, in my opinion, a practical purpose.  Also obsoleting
features allow to avoid a code complexity that ever grows and could also
impact performances.


Anyway since you don't like it, lets forget about that idea.

-- 
Pat