On Fri, Nov 11, 2022 at 12:03:11PM +, Werner LEMBERG wrote:
> >> ```
> >> \input texinfo
> >>
> >> @code{45°}
> >>
> >> @code{45@textdegree{}}
> >>
> >> @bye
> >> ```
> >
> > It is better to be consistent in my opinion.
>
> Consistent with what exactly?
to have ° and @textdegree{} give th
On Fri, Nov 11, 2022 at 01:50:04PM +, Werner LEMBERG wrote:
>
> > You probably disagree with many renderings of similar characters,
> > then as the rendering is based on math mode, and in many case does
> > not lead to fixed width characters (for U+00AE, U+00B1, U+00B2,
> > U+00B3...).
>
> We
On Sat, Dec 10, 2022 at 07:16:23AM -0800, Raymond Toy wrote:
> On Fri, Dec 9, 2022 at 11:40 PM Eli Zaretskii wrote:
>
> > > From: Gavin Smith
> > > Date: Sat, 10 Dec 2022 00:35:19 +
> > >
> > > > d.texi:2: bad @table argument
> > >
> > > would be sufficient. It could be difficult to explain
On Sat, Dec 10, 2022 at 07:16:23AM -0800, Raymond Toy wrote:
> On Fri, Dec 9, 2022 at 11:40 PM Eli Zaretskii wrote:
>
> > How about "bad or missing @table argument: 'FOO'" ?
> >
>
> This works for me, except I'd separate out the two cases: "Missing @table
> argument." and "Bad @table argument:
On Sun, Dec 18, 2022 at 01:01:11AM -0700, arn...@skeeve.com wrote:
> Hi Patrice.
>
> Having @cartouche take an optional title and render as in
> Docbook would be a perfect solution for me. I don't need the @sidebar
> command specifically, just the fucntionality. So, I really like this
> suggesti
On Mon, Dec 19, 2022 at 10:43:08PM +, Gavin Smith wrote:
> On Sun, Dec 18, 2022 at 01:01:11AM -0700, arn...@skeeve.com wrote:
> > Hi Patrice.
> >
> > Having @cartouche take an optional title and render as in
> > Docbook would be a perfect solution for me. I don't need the @sidebar
> > command
On Tue, Dec 20, 2022 at 02:00:18AM -0700, arn...@skeeve.com wrote:
> Does makeinfo generate LaTeX these days?
Yes, and we'd welcome feedback, in particular on customization of the
LaTeX output.
> Can that be done for TeX and Info?
It is done for all the texi2any output formats:
https://git.savan
On Wed, Dec 21, 2022 at 01:41:59AM -0700, arn...@skeeve.com wrote:
>
> I've never used latex. I assume the sequence is something like
>
> makeinfo --latex gawk.texi # should have no errors / warnings
> latex gawk.tex
> latex gawk.tex # second time for xrefs and indexing
>
Hello,
The error actually comes from a construct like
@cartouche
@float Table,label
@caption{Return}
@end float
@end cartouche
My feeling is that @float should only be valid at top-level, not in a
block command, such as @cartouche, if in a block, the float cannot
float.
I would propose to ha
On Wed, Dec 21, 2022 at 09:13:08PM -0700, arn...@skeeve.com wrote:
> Hi.
>
> Thanks for figuring this out. The problem is that in this case
> there is no way to directly give the table a title and anchor for cross
> referencing from the main text except by wrapping it in @float.
>
> I suppose tha
On Thu, Dec 22, 2022 at 11:22:40AM +0100, pertu...@free.fr wrote:
> On Wed, Dec 21, 2022 at 09:13:08PM -0700, arn...@skeeve.com wrote:
> > Hi.
> >
> > Thanks for figuring this out. The problem is that in this case
> > there is no way to directly give the table a title and anchor for cross
> > ref
On Sat, Jan 07, 2023 at 09:08:56AM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Sat, 7 Jan 2023 00:35:25 +
> >
> > > Does anybody knows if nodes are correctly concatenated with case
> > > insensitive filesystems if CASE_INSENSITIVE_FILENAMES is not set?
> >
> > It would be goo
On Sat, Jan 07, 2023 at 11:54:03AM +0200, Eli Zaretskii wrote:
> > Date: Sat, 7 Jan 2023 10:38:57 +0100
> > From: pertu...@free.fr
> > Cc: Gavin Smith , torbjorn.svens...@foss.st.com,
> > bug-texinfo@gnu.org
> >
> > No, what I would like to know is whether nodes are concatenated when
> > split
On Sat, Jan 07, 2023 at 03:37:21PM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Sat, 7 Jan 2023 12:29:33 +
> > Cc: pertu...@free.fr, torbjorn.svens...@foss.st.com, bug-texinfo@gnu.org
> >
> > On Sat, Jan 07, 2023 at 01:06:41PM +0200, Eli Zaretskii wrote:
> > > How do you "set"
On Sat, Jan 07, 2023 at 05:10:39PM +0200, Eli Zaretskii wrote:
>
> How do you see that there's "a file with the two nodes concatenated".
> What I see is index.html and Node1.html. The contents of the latter
> is this:
Well, the first Node1.html that was generated had both nodes
concatenated, but
On Sat, Feb 11, 2023 at 08:30:07PM +, Gavin Smith wrote:
> >
> > How many manuals set documentlanguage? With the proliferation of
> > documentencoding set to UTF-8, I think disabling the collation for
> > "en" will be next to futile.
>
> If I understand correctly, until recently more standar
On Sun, Feb 12, 2023 at 09:47:10AM +, Gavin Smith wrote:
>
> With TEXINFO_XS=omit, it now takes 52 seconds. I tested Texinfo
> 7.0.2 and it only took 42 seconds.
>
> (I thought this was still longer than I remembered, so tested
> with Texinfo 6.8, where it came out 23 seconds without XS modu
On Sun, Feb 12, 2023 at 11:38:42AM +, Gavin Smith wrote:
> Indeed, the difference was at the first place I checked: on
> 2022-09-10, commit 46bfa18bb0, where the time came out as 43.9 sec.
>
> 2022-09-10 Patrice Dumas
>
>* tp/Texinfo/ParserNonXS.pm (_parse_texi, _process_remaining_
On Sun, Feb 12, 2023 at 12:04:38PM +, Gavin Smith wrote:
> On Sun, Feb 12, 2023 at 11:38:43AM +, Gavin Smith wrote:
> > I'll try to look at this commit more to see if I can find anything else.
>
> It's good news: we can keep the uninlined function. The slowdown almost
> goes away complete
On Wed, Mar 08, 2023 at 10:17:42PM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Wed, 8 Mar 2023 20:06:19 +
> > Cc: Patrice Dumas , bug-texinfo@gnu.org
> >
> > > > * what capitalization means could differ for locales
> > >
> > > Not for ASCII characters, right?
> >
> > A class
On Wed, Mar 08, 2023 at 10:16:02PM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Wed, 8 Mar 2023 20:11:02 +
> > Cc: Patrice Dumas , bug-texinfo@gnu.org
> >
> > It is to affect URLs, not for the main text of the document that the user
> > would read.
>
> If it's _only_ for URLs,
On Thu, Mar 09, 2023 at 09:10:13AM +0200, Eli Zaretskii wrote:
> > From: pertu...@free.fr
> > Indeed, following this change, the following two nodes will clash while
> > they did not before
> >
> > @node my node
> >
> > @node my @sc{node}
> >
> > However, I consider it better if the two nodes cl
On Thu, Mar 09, 2023 at 09:10:13AM +0200, Eli Zaretskii wrote:
> > Indeed, following this change, the following two nodes will clash while
> > they did not before
> >
> > @node my node
> >
> > @node my @sc{node}
> >
> > However, I consider it better if the two nodes clash.
>
> Do we have a good
On Thu, Mar 09, 2023 at 09:01:08AM +0200, Eli Zaretskii wrote:
> > There may be some need to modify texi2any more generally (for
> > example for upper casing, for locale dependent index keys sorting,
> > maybe for line breaking in Info output). There may be some trouble
> > with presentation of in
On Fri, Mar 10, 2023 at 09:42:19AM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Fri, 10 Mar 2023 07:19:15 +
> > Cc: pertu...@free.fr, bug-texinfo@gnu.org
> >
> > On Fri, Mar 10, 2023 at 09:05:58AM +0200, Eli Zaretskii wrote:
> > > I'm not saying that texi2any doesn't play by th
On Wed, Sep 06, 2023 at 02:53:35PM +0300, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Wed, 6 Sep 2023 02:51:47 +0100
> >
> > On Tue, Sep 05, 2023 at 09:16:47PM +0200, Patrice Dumas wrote:
> > > I think I understand what you don't understand, actually this is not
> > > about displaying th
On Thu, Oct 12, 2023 at 06:00:44PM +0100, Gavin Smith wrote:
> On Thu, Oct 12, 2023 at 09:21:45AM +0300, Eli Zaretskii wrote:
> > > From: Gavin Smith
> > > Date: Wed, 11 Oct 2023 18:15:04 +0100
> > > Cc: Patrice Dumas
> > >
> > > On Wed, Oct 11, 2023 at 06:12:51PM +0100, Gavin Smith wrote:
> > >
On Sun, Nov 05, 2023 at 09:59:44PM +0200, Eli Zaretskii wrote:
>
> I don't have any libtexinfo shared library here, and I don't see one
> being built, let alone installed, as part of Texinfo. is this
> something new in the development sources? If so, what code is linked
> into libtexinfo?
Yes,
On Mon, Nov 06, 2023 at 02:37:57PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 6 Nov 2023 09:20:37 +0100
> > From: pertu...@free.fr
> > Cc: Gavin Smith , bug-texinfo@gnu.org
> >
> > libtexinfo corresponds to the 'pure' C common code that performs the
> > computations needed for texi2any, working on
On Sun, Jan 21, 2024 at 03:13:25PM -0700, Karl Berry wrote:
> Hi Patrice,
>
> I understand the principle, but for me the lossage in practice is even
> more unfortunate (by far). It sure seems to me that the "rare" case
> should be the one to have to make the config file setting. Indeed, the
> very
On Fri, Feb 02, 2024 at 08:57:01AM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Thu, 1 Feb 2024 22:16:07 +
> > Cc: Patrice Dumas , bug-texinfo@gnu.org
> >
> > On Thu, Feb 01, 2024 at 09:01:42AM +0200, Eli Zaretskii wrote:
> > > > Date: Wed, 31 Jan 2024 23:11:02 +0100
> > > > Fr
On Sun, Feb 04, 2024 at 12:55:36PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 4 Feb 2024 11:42:52 +0100
> > From: pertu...@free.fr
> > Cc: Gavin Smith , bug-texinfo@gnu.org
> >
> > On Fri, Feb 02, 2024 at 08:57:01AM +0200, Eli Zaretskii wrote:
> > > I think en_US.utf-8 is (or at least can be by de
On Sun, Feb 04, 2024 at 12:07:17PM +0100, Andreas Schwab wrote:
> On Feb 04 2024, Eli Zaretskii wrote:
>
> > If we want collation which uses only codepoints, disregarding any
> > collation weights defined by the Unicode TR10, we could use
> > en_US.utf-8, but then, as Gavin says, using glibc colla
On Wed, Mar 06, 2024 at 01:32:16PM +, Werner LEMBERG wrote:
>
> > Here is another proposal, which seems much clearer to me, but is
> > probably too long:
>
> > @itemize command argument with omitted braces should not require an
> > argument, but @asis does. Use braces for @asis
>
> I sugge
On Wed, Mar 06, 2024 at 07:28:52PM +, Gavin Smith wrote:
> It could just be the same error message as when used outwith @itemize:
>
> @asis foo
>
> - which gives an error message like:
>
> test.texi:11: @asis expected braces
I also think that it is the best.
> Although it is very u
On Thu, Apr 11, 2024 at 09:06:05AM +0300, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Wed, 10 Apr 2024 23:53:31 +0100
> >
> > I agree that the warning is not really necessary. I don't mind
> > either way. It's up to you if you want to try to remove the warning.
> > It's questionable w
On Thu, Aug 29, 2024 at 07:43:00AM +0300, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Wed, 28 Aug 2024 21:26:55 +0100
> >
> > I'm a bit confused as I thought it was configuration files which we
> > were discussing, which would be XDG_CONFIG_DIRS, not XDG_DATA_DIRS.
> >
> > I see that ht
On Wed, Jan 27, 2021 at 09:06:30AM +0100, Werner LEMBERG wrote:
>
> > To celebrate @example language new argument I did a customization
> > file highlight_syntax.pm that uses source-highlight to do syntax
> > highlighting of @example fragments, for HTML output. [...]
>
> I guess you wanted to sh
On Fri, Feb 12, 2021 at 01:20:53PM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Fri, 12 Feb 2021 08:37:22 +
> > Cc: Patrice Dumas , bug-texinfo@gnu.org
> >
> > On Fri, Feb 12, 2021 at 08:56:23AM +0200, Eli Zaretskii wrote:
> > > > Date: Thu, 11 Feb 2021 22:45:33 +0100
> > > > F
On Fri, Jan 07, 2022 at 06:56:52AM +, Werner LEMBERG wrote:
>
> Hello Gavin and Patrice,
>
> >> `texi2html` had an option `--short-ref` [...]
> >
> > I had a look at the history and this customization never made to
> > texi2any, however, previously if the reference was to a section,
> > ther
On Sun, Jan 16, 2022 at 02:30:22PM +, Gavin Smith wrote:
>
> Hello Werner I have committed your addition to texinfo.tex as well
> as the change for HTML output (commit cbc6972b5).
The new test result seems to be the test result without the commit.
I will update it and commit, please check if
On Sun, Jan 16, 2022 at 04:05:09PM +0100, pertu...@free.fr wrote:
> On Sun, Jan 16, 2022 at 02:30:22PM +, Gavin Smith wrote:
> >
> > Hello Werner I have committed your addition to texinfo.tex as well
> > as the change for HTML output (commit cbc6972b5).
>
> The new test result seems to be the
On Sun, Jan 16, 2022 at 04:07:35PM +0100, pertu...@free.fr wrote:
> On Sun, Jan 16, 2022 at 04:05:09PM +0100, pertu...@free.fr wrote:
> > On Sun, Jan 16, 2022 at 02:30:22PM +, Gavin Smith wrote:
> > >
> > > Hello Werner I have committed your addition to texinfo.tex as well
> > > as the change
On Sun, Jan 16, 2022 at 03:41:24PM +, Gavin Smith wrote:
> On Sun, Jan 16, 2022 at 04:13:22PM +0100, pertu...@free.fr wrote:
> > Actually, there is a difference between the C parser and the perl
> > parser, the perl parser consider those spaces as space too, which is not
> > surprising given th
On Mon, Feb 14, 2022 at 03:21:59PM +, Werner LEMBERG wrote:
>
> > I reverted that change, and instead commited a fix using a
> > generation of tp_api.texi in autogen.sh, based on your earlier
> > proposal. Please check that it is ok...
>
> It works for me, too, thanks :-)
>
> Another thing:
On Sun, Feb 20, 2022 at 03:06:57PM +0200, Eli Zaretskii wrote:
>
> The only thorough solution, IMO, is to assume the file names are
> encoded in the filesystem as specified by the locale's codeset. That,
> too, can be false, but at least in the absolute majority of use cases
> it will be true. T
On Sun, Feb 20, 2022 at 03:45:37PM +0200, Eli Zaretskii wrote:
> >
> > I do not think that it is a good solution either. On Linux, unless I
> > missed something, the file name encoding should be utf-8 irrespective of
> > the locale, or the Texinfo document encoding.
>
> No, that's incorrect. Li
On Sun, Feb 20, 2022 at 02:44:13PM +, Gavin Smith wrote:
>
> > The only thorough solution, IMO, is to assume the file names are
> > encoded in the filesystem as specified by the locale's codeset. That,
> > too, can be false, but at least in the absolute majority of use cases
> > it will be tr
On Sun, Feb 27, 2022 at 09:01:51AM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Sat, 26 Feb 2022 22:23:04 +
> >
> > Don't use the locale encoding by default for encoding filenames.
>
> I think this is a mistake, and at least on Windows we must use the
> locale's encoding of fi
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
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 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 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
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: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
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 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
On Tue, Jul 26, 2022 at 09:32:15PM +, Werner LEMBERG wrote:
>
> > I can't see why having different output makes texinfo harder to use.
> > Having all output identical does not seem to me to be a goal of
> > Texinfo formatting. To me an important element of the Texinfo
> > philosophy is that t
Hello,
I looked at the libc manual and the @deftype* formatting indeed looks
wrong. The function type is in upright @code, which looks good,
but types within the function call are in slanted roman, and
metasyntactic variables are in slanted typewriter. It seems very
strange. I am actually very
On Wed, Jul 27, 2022 at 01:32:50PM +0100, Gavin Smith wrote:
> On Wed, Jul 27, 2022 at 11:29:20AM +0200, pertu...@free.fr wrote:
> > Hello,
> >
> I think it would be better for types not to be slanted by default as we
> are using slant to indicate parameters. (Perhaps slanted types should
> be us
On Tue, Jul 26, 2022 at 09:00:30PM +, Werner LEMBERG wrote:
>
> Attached is the current git version of `groff.pdf`, together with the
> source file. As an example, have a look at page 128 (image attached),
> where you can see
>
> .ft [font] [Request]
> \ff
On Thu, Jul 28, 2022 at 03:52:21PM +0100, Gavin Smith wrote:
> On Thu, Jul 28, 2022 at 04:27:28PM +0200, pertu...@free.fr wrote:
> > I tested with Texinfo TeX @t{\f[}@r{@slanted{font}}@t{]} (which is the
> > fourth line deffn name) in the argument part of @deffn, and the brackets
> > remain in roma
Hello,
I did an implementation in LaTeX.
A first possible issue. In non @deftype*, @code around metasyntactical
separators (bracket or parentheses) causes the metasyntactical
separators to become slanted. It is consistent, putting in @code remove
the automatic upright, but it is not very intuit
On Fri, Jul 29, 2022 at 05:24:53PM +0100, Gavin Smith wrote:
>
> In texinfo.tex, I have only done the cancelling of the special definitions
> of [ and ] inside @r and @t. There, the special definition entailed the
> use of a roman font. In LaTeX \EmbracOn is slightly different in that
> it uses
On Fri, Jul 29, 2022 at 11:18:20PM +0100, Gavin Smith wrote:
> On Fri, Jul 29, 2022 at 10:54:35PM +0200, pertu...@free.fr wrote:
> > This looks good to me for now, and maybe the TeX output will change
> > in after @def* are considered as code, and @deftype* are not slanted
> > anymore.
>
> I'm hav
On Sun, Jul 31, 2022 at 02:38:17PM +0100, Gavin Smith wrote:
>
> It could be tempting to use @deftype* for a case like this, if
> @deftype* is not slanted, even though there are no types.
>
> In fact, I agree with making @deftype* not slanted, and we should
> also allow in the documentation that
On Sun, Jul 31, 2022 at 03:57:39PM +0100, Gavin Smith wrote:
> On Fri, Jul 29, 2022 at 12:53:53AM +0200, pertu...@free.fr wrote:
> > Another issue. The quotes '' and dashes, such as --- are not as in the
> > main document, even with @r. They are in roman when in @r, but
> > formatted as three sepa
On Sun, Jul 31, 2022 at 02:38:17PM +0100, Gavin Smith wrote:
>
> I've got a different proposal now for the difference between
> @deftypefn and @deffn (described above).
I tried to implement that proposal (at least what I had understood...)
both in LaTeX and HTML.
In HTML, with firefox, the typew
On Sun, Jul 31, 2022 at 09:48:31PM +0100, Gavin Smith wrote:
> On Sun, Jul 31, 2022 at 09:23:54PM +0100, Gavin Smith wrote:
>
> > As you noted, the name is in a typewriter font due to rather than
> > being used. Maybe we discussed this already, but I think we
> > should reconsider this change.
On Sun, Jul 31, 2022 at 09:23:54PM +0100, Gavin Smith wrote:
> On Sun, Jul 31, 2022 at 07:46:02PM +0200, pertu...@free.fr wrote:
> > On Sun, Jul 31, 2022 at 02:38:17PM +0100, Gavin Smith wrote:
> > >
> > > I've got a different proposal now for the difference between
> > > @deftypefn and @deffn (de
On Tue, Aug 02, 2022 at 01:20:50PM +0100, Gavin Smith wrote:
> On Mon, Aug 01, 2022 at 12:56:23AM +0200, pertu...@free.fr wrote:
> > > What was the benefit of changing to
> > > ? Isn't the former much simpler?
> >
> > It is not the same, isolates from the surrounding
> > fonts, using amounts t
On Tue, Aug 02, 2022 at 02:44:18PM +0100, Gavin Smith wrote:
>
> My preference is to use and to remove the outer (corresponding
> to @r).
Looks good to me, I'll implement.
--
Pat
On Wed, Aug 03, 2022 at 04:30:49AM +, Werner LEMBERG wrote:
>
> > Also this: https://practicaltypography.com/bold-or-italic.html
>
> IMHO, these advices are not applicable for technical documentation,
> since different kinds of meta-ness *do* make sense.
I agree. Robin culd punch back, sayi
On Sun, Aug 21, 2022 at 05:16:17AM +, Werner LEMBERG wrote:
>
> [texinfo.tex 2022-08-20.19]
>
> I'm *very* unhappy that `@var` in `@example` environments no longer
> produce slanted typewriter but slanted roman – with ligatures!
> Besides being extremely ugly, it completely ruins the fixed-wi
On Sun, Aug 21, 2022 at 03:02:56PM +, Werner LEMBERG wrote:
>
> >> Honestly, I don't like that – what I want *does* transport
> >> metaness! Using `@t` would demote this to a 'fancy font change to
> >> make the author happy', which is not true.
> >
> > You want meta-mess and also formatting
On Sun, Aug 21, 2022 at 07:59:17PM +, Werner LEMBERG wrote:
>
> > It wouldn't do anything for any other output formats, so there shouldn't
> > need to be any changes to texi2any, or any new commands to be added.
>
> Mhmm. I must admit that I haven't checked how HTML output was before
> and i
On Sun, Aug 21, 2022 at 06:28:11PM +0100, Gavin Smith wrote:
>
> It wouldn't do anything for any other output formats, so there shouldn't
> need to be any changes to texi2any, or any new commands to be added. My
> preference for this switch to be limited to texinfo.tex, as we shouldn't
> force ab
On Mon, Aug 22, 2022 at 12:20:11AM +, Werner LEMBERG wrote:
>
> > In all the formats output by texi2any, except in LaTeX which is more
> > consistent with TeX, @r, @i, @b, @sansserif and @slanted switch back
> > to normal context if in code/monospace context. This is not the
> > case in LaTeX
On Fri, Aug 26, 2022 at 06:37:08PM +0100, Gavin Smith wrote:
>
> The LaTeX output will still use variable-width for @var unconditionally and
> not subject to configuration. Hence there will be an inconsistency between
> LaTeX output and texinfo.tex in this area, until after the next release.
>
>
On Mon, Sep 26, 2022 at 03:40:46PM -0600, Karl Berry wrote:
> Hi Patrice - If you write to the tex-live list, more than likely I will
> end up being the one who answers, so we might as well continue here :).
>
> What is the question? I don't understand how or why we got on to LaTeX.
There is a ne
On Tue, Sep 27, 2022 at 06:59:10AM +0100, Gavin Smith wrote:
> > As I said above, for the LaTeX output converted from Texinfo we use
> > quite a few packages to be able to output LaTeX that can express the
> > Texinfo formatting.
>
> It's not necessary to obey any of the formatting command for LaT
On Tue, Sep 27, 2022 at 04:22:45PM -0600, Karl Berry wrote:
> If the output is better with microtype on, we should try to have it on.
>
> If Texinfo has microtype on by default, I agree the LaTeX backend should
> also have microtype on by default. That's fine.
>
> microtypee off if is cau
On Tue, Sep 27, 2022 at 08:20:17PM +0100, Gavin Smith wrote:
> On Tue, Sep 27, 2022 at 09:38:30AM +0200, pertu...@free.fr wrote:
> > ... but my feeling is
> > that this is the symptom of something wrong being done with fonts
> > selection in the LaTeX output, not an issue with microtype as such.
>
On Sun, Oct 23, 2022 at 05:38:37PM +0100, Gavin Smith wrote:
> On Sun, Oct 23, 2022 at 05:25:26PM +0200, pertu...@free.fr wrote:
> > Which is right.
> >
> > > and the first two fail if it says "OK".
> >
> > Which is problematic, it means that with a correctly setup input file
> > with latin1 enco
On Sat, Oct 22, 2022 at 09:36:20PM +0100, Gavin Smith wrote:
> On Sat, Oct 22, 2022 at 09:39:14PM +0300, Eli Zaretskii wrote:
> > > If this works then we could switch to it and not use I18N::Langinfo at
> > > all.
> >
> > This works here, and produces the codepage number. But (due to the
> > Wind
On Sun, Oct 23, 2022 at 08:56:13AM +0300, Eli Zaretskii wrote:
> AFAIU, the Win32::API module is present in all native Perl versions
> for Windows (I'm using ActiveState Perl). It is not clear to me which
> was the earliest version of Perl which came with it built-in (mine is
> 5.20.1, and it does
On Sun, Oct 23, 2022 at 02:26:22PM +0300, Eli Zaretskii wrote:
> The tests that report diffs are as follows:
>
> In 'layout', I see differences like the below:
>
> -
> -
> -
> +
> +
> +
>
> They are all due to '/' vs '\' (slash vs backslash) issue.
My guess is that it is a bug, as i
On Sun, Oct 23, 2022 at 01:42:22PM +0300, Eli Zaretskii wrote:
> On a hunch, I did two things:
>
> . created a file tp/tests/input_file_names_recoded_stamp.txt with
> the text FAILED in it;
Ok. I'll try to change the generation of input_file_names_recoded_stamp.txt
such that there is no UT
On Sun, Oct 23, 2022 at 01:55:43PM +0100, Gavin Smith wrote:
> It's quite a long patch:
I think that it could also be good to separate more perl specific from
non-perl specific code, as is done in that patch, in particular if we
want to have other language bindings one day. Can wait, but changes
On Sun, Oct 23, 2022 at 08:11:30PM +0300, Eli Zaretskii wrote:
> Yes, forward slashes should work. (They should also work on the
> command line, as long as we don't involve cmd.exe, because the
> programs we use all support forward slashes.)
This issue should be fixed, at least partly, in
https:/
On Sun, Oct 23, 2022 at 10:00:19PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 23 Oct 2022 20:22:29 +0200
> > From: pertu...@free.fr
> > Cc: gavinsmith0...@gmail.com, bug-texinfo@gnu.org
> >
> > On Sun, Oct 23, 2022 at 07:10:57PM +0300, Eli Zaretskii wrote:
> > > >
> > > > Which is problematic, it
On Sun, Oct 23, 2022 at 04:54:31PM +0300, Eli Zaretskii wrote:
> > My guess is that it is a bug, as in HTML it seems to me that there
> > should only be forward slashes.
>
> Yes.
>
> Any hints where I should look for the source of these backslashes?
I don't know. I'll have a look at this bug.
On Sun, Oct 23, 2022 at 05:54:30PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 23 Oct 2022 14:44:33 +0200
> > From: pertu...@free.fr
> > Cc: gavinsmith0...@gmail.com, bug-texinfo@gnu.org
> >
> > I think that it does not depend on other changes. You'll also need to
> > remove input_file_names_recod
On Sun, Oct 23, 2022 at 05:30:24PM +0300, Eli Zaretskii wrote:
>
> Out of 144 tests in test_scripts/, 105 pass, 31 are skipped, and 8
> fail. The failed ones are all about non-ASCII characters, it seems.
Sorry, there are 3 tests to check
formatting/manual_include_accented_file_name_latin1
form
On Sun, Oct 23, 2022 at 06:41:34PM +0100, Gavin Smith wrote:
> On Sun, Oct 23, 2022 at 08:13:24PM +0300, Eli Zaretskii wrote:
> > > I am pretty sure that this file is correctly generated, I guess that
> > > מ corresponds to the same octet than î in latin1, which is 0xEE unless I
> > > missed someth
On Sun, Oct 23, 2022 at 07:10:57PM +0300, Eli Zaretskii wrote:
> >
> > Which is problematic, it means that with a correctly setup input file
> > with latin1 encoded character in the name, something wrong is going on.
>
> The character is supposed to be encoded in Latin1, but I don't think
> it is
On Sun, Oct 23, 2022 at 05:54:30PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 23 Oct 2022 14:44:33 +0200
> > From: pertu...@free.fr
> > Cc: gavinsmith0...@gmail.com, bug-texinfo@gnu.org
> >
> > I think that it does not depend on other changes. You'll also need to
> > remove input_file_names_recod
On Sun, Oct 23, 2022 at 05:53:01PM +0100, Gavin Smith wrote:
> On Sun, Oct 23, 2022 at 04:47:50PM +0200, pertu...@free.fr wrote:
> >
> > I tracked it down to tp/ext/epub3.pm and there is actually already a
> > FIXME, I knew that something like that was bound to happen:
> >
> > # FIXME INFO_JS
On Sun, Oct 23, 2022 at 06:19:19PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 23 Oct 2022 17:15:45 +0200
> > From: pertu...@free.fr
> > Cc: gavinsmith0...@gmail.com, bug-texinfo@gnu.org
> >
> > On Sun, Oct 23, 2022 at 05:30:24PM +0300, Eli Zaretskii wrote:
> > >
> > > Out of 144 tests in test_scr
On Sun, Oct 23, 2022 at 11:45:15AM +0100, Gavin Smith wrote:
> With your setup, it breaks at the very beginning, in the Makefile
> rule. It would seem to be simple to eliminate the reference to
> "included_latîn1.texi" from the Makefile. Then we have to make
> sure the tests are skipped.
I elimi
1 - 100 of 187 matches
Mail list logo
