bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TRAMP User Manual problems with Texinfo 5.0


From: Patrice Dumas
Subject: Re: TRAMP User Manual problems with Texinfo 5.0
Date: Sat, 23 Feb 2013 20:27:03 +0100
User-agent: Mutt/1.5.20 (2009-12-10)

On Sat, Feb 23, 2013 at 08:56:43PM +0200, Eli Zaretskii wrote:
> > 
> > No, it isn't.  In general the only customizable output format is HTML.
> > Here it also affects DocBook, but that's merely a coincidence.  I guess
> > this could be clearer.  Karl, I let the wording to you?
> 
> I'd rather prefer that Info output could also be controlled.  Who
> should I beg for it to be done?

If I recall well, it was Karl decision.  My point of view is that having
an API for output control similar with what is available for HTML is not
a good idea, but maybe some minor customization set through varaibles
may be right.  In the case of OPEN_QUOTE_SYMBOL it is not that easy
because there is already an 'automatic' customization of using unicode
quotes in some cases.  I'll see what I can do.

> > These files are perl files and should follow an API that is not
> > final for now.  Should be along
> > 
> >   set_from_init_file('OPEN_QUOTE_SYMBOL', '`');
> 
> I certainly hope the syntax will become less Perl-specific.

I don't think so, I can't imagine that we would develop a new 
language for customization of makeinfo output.  It doesn't mean 
that using perl to customize the output will be the only possiblity 
ever, I hope that new converters will be written, some day, taking 
as starting point an intermediary format (Texinfo XML/SXML, IXIN).
I have, for instance, hopes that some nice guile/lisp based converters 
are done based on IXIN in a not so distant future.

> > We intentionally let everything related to init files out of the
> > documentation, to avoid that people use it before it is stable.
> 
> I'm sorry, but I think those were wrong decisions.  There was nothing
> urgent in releasing Texinfo 5.0, which could have caused the release
> to be made before making sure that these issues are finalized,
> implemented in user-friendly ways, and well documented.  On the
> contrary, releasing the package in this state runs a high risk of
> alienating users, something that IMO should be avoided after such a
> major redesign.

I disagree.  The goal was to have a backward compatible release,
with changes not backward compatible being only bug fixes that should 
have been part of the next release of makeinfo in C (this includes 
some changes in the use macro expansion, ' instead of ` for Info 
quotes, some stricter checks).  There were no features removed, only 
features added, so I don't think there was a need to wait for even 
more features for the release.

There are some unintentional incompatibilities that have crept in, as
the tramp manual amply demonstrates, and, indeed, these need to be 
fixed as soon as possible, and then a bug fix release would be 
nice, in order not to alienate users.  But it is also hard to find 
those incompatibilities if we don't do releases and get more user 
testing coverage.

-- 
Pat



reply via email to

[Prev in Thread] Current Thread [Next in Thread]