On a related note, maxima has a few things like "@fnindex Logical
conjunction". These show up in the info file. However, I can't find that
anywhere in the html file(s). Is that a bug too?
On Mon, Jul 25, 2022 at 3:26 PM Gavin Smith
wrote:
> On Mon, Jul 25, 2022 at 03:14:47PM -0700, Raymond To
>> IMHO, it's quite simple: All output formats, i.e., TeX, HTML, and
>> the new LaTeX backend, should produce identical output if
>> technically possible – and for LaTeX it's definitely possible :-)
>> Anything else makes texinfo harder to use.
>
> I can't see why having different output makes te
>> Compare this to a C library 'foo' that wants to have a stable ABI
>> for all of its functions, making older programs link and run
>> successfully with newer library versions: it is impossible to
>> change any public header files without breaking it.[*] Obviously, I
>> equate the ABI with texinf
On Tue, Jul 26, 2022 at 08:27:35PM +0100, Gavin Smith wrote:
> The comment from 2003 said that the groff manual needed Roman type in
> @def* line output. Examples from the groff manual would be one of the
> first things I would look at, and this might help to move this conversation
> forward more
On Tue, Jul 26, 2022 at 09:14:49PM +0100, Gavin Smith wrote:
> On Tue, Jul 26, 2022 at 08:27:35PM +0100, Gavin Smith wrote:
>
> Here's the first thing I looked at from the groff manual and it raises
> some issues:
The actual code is:
@defmac @t{.TH} title section [@r{@slanted{extra1}} [@r{@slante
> From: Gavin Smith
> Date: Tue, 26 Jul 2022 20:30:16 +0100
> Cc: w...@gnu.org, pertu...@free.fr, bug-texinfo@gnu.org
>
> On Tue, Jul 26, 2022 at 09:53:04PM +0300, Eli Zaretskii wrote:
> > > From: Gavin Smith
> > > Date: Tue, 26 Jul 2022 19:40:32 +0100
> > > Cc: pertu...@free.fr, bug-texinfo@gnu
On Tue, Jul 26, 2022 at 09:53:04PM +0300, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Tue, 26 Jul 2022 19:40:32 +0100
> > Cc: pertu...@free.fr, bug-texinfo@gnu.org
> >
> > > Yes, and I consider this as bad. As I mentioned in my previous
> > > e-mail, such a change would ruin any fine-tu
On Tue, Jul 26, 2022 at 04:58:10PM +, Werner LEMBERG wrote:
> The only way to introduce a new behaviour for a broken function 'bar'
> is to implement a new function 'bar2', declaring the old function
> 'bar' as obsolete. I think that exactly such an approach is
> appropriate for texinfo functi
> From: Gavin Smith
> Date: Tue, 26 Jul 2022 19:40:32 +0100
> Cc: pertu...@free.fr, bug-texinfo@gnu.org
>
> > Yes, and I consider this as bad. As I mentioned in my previous
> > e-mail, such a change would ruin any fine-tuning of the formatting – a
> > formatting that stayed unmodified for a very
On Tue, Jul 26, 2022 at 04:49:27PM +, Werner LEMBERG wrote:
>
> > We (I) could also propose too help and volunteer to change the
> > manuals to accompany the change. Maybe advertise it on some GNU
> > lists, in addition to the help-texinfo list.
>
> While this shows good intentions, it certa
On Tue, Jul 26, 2022 at 04:17:08PM +, Werner LEMBERG wrote:
>
> >> ... I consider this a bad idea. Whatever you are going to change,
> >> it will be backward incompatible, causing a lot of grief.
> >
> > It is only backward incompatible in term of formatting, not in term
> > of Texinfo langu
On Tue, Jul 26, 2022 at 04:43:06PM +, Werner LEMBERG wrote:
>
> > Another reason for changing the formatting is that there is a new
> > output format being implemented, to LaTeX. Should the 'flawed'
> > semantics be used for that new output format too, mimicking TeX
> > output even when it do
> The "old" commands do not have much of semantics, and when they
> have, these semantics are inconsistent in different places in the
> manual. Therefore new commands would not have better semantics,
> they would simply have semantics that are currently lacking.
> Therefore it seems wrong to me t
> I agree that some users won't be happy with the changes in
> formatting. But, in that case, I think that this is less
> problematic than keeping unclear semantics and strange formatting as
> it is now.
I beg to differ, but now you know that already :-)
> Another possibility would be to chang
> Another reason for changing the formatting is that there is a new
> output format being implemented, to LaTeX. Should the 'flawed'
> semantics be used for that new output format too, mimicking TeX
> output even when it does not make sense?
IMHO, it's quite simple: All output formats, i.e., TeX
>> ... I consider this a bad idea. Whatever you are going to change,
>> it will be backward incompatible, causing a lot of grief.
>
> It is only backward incompatible in term of formatting, not in term
> of Texinfo language or syntax
Yes, and I consider this as bad. As I mentioned in my previo
On Tue, Jul 26, 2022 at 04:58:10PM +, Werner LEMBERG wrote:
>
> Compare this to a C library 'foo' that wants to have a stable ABI for
> all of its functions, making older programs link and run successfully
> with newer library versions: it is impossible to change any public
> header files with
On Tue, Jul 26, 2022 at 04:17:08PM +, Werner LEMBERG wrote:
>
> > but the manual is not so clear on what is in typewriter and what is
> > not in @def* arguments. Also for lisp manuals which rely on &word
> > being bold, it could require some additional markup, but this is not
> > really docum
> Date: Tue, 26 Jul 2022 16:20:13 +0200
> From: pertu...@free.fr
> Cc: bug-texinfo@gnu.org
>
> On Tue, Jul 26, 2022 at 11:31:27AM +, Werner LEMBERG wrote:
> >
> > ... I consider this a bad idea. Whatever you are going to change, it
> > will be backward incompatible, causing a lot of grief.
>
On Tue, Jul 26, 2022 at 11:31:27AM +, Werner LEMBERG wrote:
>
> ... I consider this a bad idea. Whatever you are going to change, it
> will be backward incompatible, causing a lot of grief.
Another reason for changing the formatting is that there is a new output
format being implemented, to
On Tue, Jul 26, 2022 at 02:48:39PM +0100, Gavin Smith wrote:
> On Tue, Jul 26, 2022 at 03:24:34PM +0200, Patrice Dumas wrote:
> > > >* for the other @-commands, the argument is considered to be
> > > > metasyntactic variable (in code as per rule 1)).
> > > >
> > >
> > > @var should used
On Tue, Jul 26, 2022 at 04:18:51PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 26 Jul 2022 14:53:02 +0200
> > From: pertu...@free.fr
> > Cc: bug-texinfo@gnu.org
> >
> > On Tue, Jul 26, 2022 at 11:31:27AM +, Werner LEMBERG wrote:
> > >
> > > ... I consider this a bad idea. Whatever you are goi
On Tue, Jul 26, 2022 at 03:24:34PM +0200, Patrice Dumas wrote:
> > >* for the other @-commands, the argument is considered to be
> > > metasyntactic variable (in code as per rule 1)).
> > >
> >
> > @var should used to wrap function arguments or parameters. This is a more
> > straightfor
On Tue, Jul 26, 2022 at 01:53:35PM +0100, Gavin Smith wrote:
> >
> > There is one mention in the manual that gives some semantic meaning to
> > the whole @def* 'argument', it is "we think of these names as metasyntactic
> > variables". But in other places, the argument is not metasyntactic
> > va
> Date: Tue, 26 Jul 2022 14:53:02 +0200
> From: pertu...@free.fr
> Cc: bug-texinfo@gnu.org
>
> On Tue, Jul 26, 2022 at 11:31:27AM +, Werner LEMBERG wrote:
> >
> > ... I consider this a bad idea. Whatever you are going to change, it
> > will be backward incompatible, causing a lot of grief.
>
@def* commands could do with a lot of development, as seen in the TODO
file.
On Tue, Jul 26, 2022 at 11:57:12AM +0200, Patrice Dumas wrote:
> Hello,
>
> As I try to implement @def* commands better in LaTeX output, I have read
> the TeX code and the manual in more detail, and I have come to the
>
On Tue, Jul 26, 2022 at 11:31:27AM +, Werner LEMBERG wrote:
>
> ... I consider this a bad idea. Whatever you are going to change, it
> will be backward incompatible, causing a lot of grief.
It is only backward incompatible in term of formatting, not in term of
Texinfo language or syntax (nor
> Date: Tue, 26 Jul 2022 11:31:27 + (UTC)
> Cc: bug-texinfo@gnu.org
> From: Werner LEMBERG
>
>
> > Here is a proposal: [...]
>
> ... I consider this a bad idea. Whatever you are going to change, it
> will be backward incompatible, causing a lot of grief. For example,
> the adjustments to
> As I try to implement @def* commands better in LaTeX output, I have
> read the TeX code and the manual in more detail, and I have come to
> the conclusion that the design of the @def* 'argument' handling is
> flawed. [...]
While this is certainly true ...
> Here is a proposal: [...]
... I c
Hello,
As I try to implement @def* commands better in LaTeX output, I have read
the TeX code and the manual in more detail, and I have come to the
conclusion that the design of the @def* 'argument' handling is flawed.
To me there are two flaws. The first one is that the semantic context
of @def*
30 matches
Mail list logo
