emacs-devel
[Top][All Lists]
Advanced

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

Re: Interactive hat. (Patch V2)


From: Eli Zaretskii
Subject: Re: Interactive hat. (Patch V2)
Date: Wed, 29 Apr 2009 10:22:09 +0300

> Date: Tue, 28 Apr 2009 22:33:03 +0000
> Cc: address@hidden, address@hidden, address@hidden,
>   address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> On Mon, Apr 27, 2009 at 09:39:48PM +0300, Eli Zaretskii wrote:
> > > > That's an unusual use of @itemx.  Beware: it could do something you
> > > > didn't intend in some future version of Texinfo.  
> 
> > > I don't think so; at least, not if makeinfo does what its manual
> > > says.  @itemx is defined to be identical to @item, except for not
> > > inserting a blank line.  (See page "itemx" in the manual).
> 
> > That's not what I meant.  I meant that you in effect have here @item's
> > without the text after them.  A @table is not supposed to be like that,
> > so who knows what will the output be?  In particular, HTML and XML
> > outputs may assume there always be some text, and if not, fail to
> > properly close the markup.
> 
> Surely it's not unusual (in any markup language) to have a blank cell in
> a table.  I've generated HTML, and it's fine.  I've generated XML, and it
> looks fine too, as much as XML ever looks fine (though I don't know
> offhand if I've got a suitable viewing program for it).

I had no doubt you tested your changes.  That is why I said that this
might be a problem _in_some_future_version_ of Texinfo, see above.  In
particular, the next version of Texinfo is expected to toss the C
implementation of makeinfo and instead use texi2html, which is a Perl
program.  That means all the undocumented (mis)features of makeinfo
will give way to other undocumented (mis)features.

> Have you never written @example code yourself, where the enforced
> indentation has caused lines to become "too long"?

Sure, but I always find a way to break those into several lines.

> Anyhow, I've put @example in now (as requested by Miles and yourself),
> and split some more lines up.  There are, however, one or two lines which
> go over C74 which can't sensibly be split.

If you show those lines, perhaps someone can suggest a way of
splitting them that does make sense.




reply via email to

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