Re: enhancement proposal

On Thu, May 19, 2022 at 4:49 PM Patrice Dumas wrote: > > On Thu, May 19, 2022 at 08:05:00AM +, Ilari Jääskeläinen wrote: > > Can you include ”autogen.sh” in release source tarballs? > > That looks ok to me. I just checked that ./autogen.sh seems to be > working ok from the release tarball.

Re: Duplicate files just differing in lower/upper case in infog/test-infodir/texinfo_html

On Mon, Apr 11, 2022 at 10:22:03PM +0200, Hans-Bernhard Bröker wrote: > Hello folks, > > there are currently two pairs of files in the repository, in subdirectory > > infog/test-infodir/texinfo_html. > > which only differ by upper/lower case in their filenames: > > -rw-r--r--

Re: [PATCH] Use `grep -E/-F` instead of `egrep` and `fgrep`

On Mon, Nov 15, 2021 at 12:04:40AM +0200, Ville Skyttä wrote: > `egrep` and `fgrep` have been deprecated in GNU grep since 2007, and in > current post 3.7 Git they have been made to emit obsolescence warnings: >

Re: Name and purpose of CONVERT_TEXINFO_MATH_TO_LATEX variable

On Mon, Apr 11, 2022 at 11:38:52AM +0100, Gavin Smith wrote: > CONVERT_MATH_TEXINFO_TO_LATEX might be a good choice. Another idea: CONVERT_TO_LATEX_IN_MATH.

Name and purpose of CONVERT_TEXINFO_MATH_TO_LATEX variable

I was confused by the purpose of the CONVERT_TEXINFO_MATH_TO_LATEX setting. As I understand it, it tries to convert any Texinfo commands in @math or @displaymath to LaTeX equivalents. For example, @math{a+b @b{foo}} being converted to HTML as \(a+b \mathbf{foo}\) The name is confusing because

Re: problem with info and indices

On Sun, Apr 10, 2022 at 06:16:29PM +, Werner LEMBERG wrote: > > [texinfo a77151c624c0 from April 10th] > > In `info.info`, section 'Index Commands', there is the following text. > > The most efficient means of finding something quickly in a manual > is the ‘i’ command

Re: `@raggedright` and `@multitable`

On Sat, Apr 09, 2022 at 05:14:41AM +, Werner LEMBERG wrote: > > > Thanks for the report. I found it was due to the reassignment > > of \rightskip inside @multitable. > > > > I've attempted a fix in commit beb67a5f97219. I checked the output > > for some of the @multitable's in the Texinfo

Re: bug in texi2dvi, on Windows/Msys2 it cannot find tex

On Fri, Apr 08, 2022 at 10:50:19PM +0300, Eli Zaretskii wrote: > > Date: Fri, 8 Apr 2022 15:53:31 +0200 > > From: Tomas Kalibera > > > > Would this be an acceptable fix? (turn OSTYPE to uppercase when setting > > MSYSTEM) > > > >    MSYSTEM=$(echo $OSTYPE | tr [a-z] [A-Z]) uname | $EGREP -iv

Re: bug in texi2dvi, on Windows/Msys2 it cannot find tex

On Fri, Apr 08, 2022 at 06:07:01PM +0200, Tomas Kalibera wrote: > Works for me on all those 3 systems (just needed to add \ at the end of the > line after "/dev/null "). And checking OSTYPE against "msys" is a common > pattern in Msys2 patches, so I assume it is correct for Msys2. Commited in

Re: bug in texi2dvi, on Windows/Msys2 it cannot find tex

On Fri, Apr 08, 2022 at 04:30:12PM +0200, Tomas Kalibera wrote: > I am not sure what is the correct name of it. I executed > C:\MinGW\msys\1.0\msys.bat to get the shell. > It uses : as path separator. > > > Have you found that running texi2dvi fails in such an environment, with > > my patch

Re: correctly placed @part before @node can be in ignored Top node

On Fri, Apr 08, 2022 at 05:02:11PM +0200, Patrice Dumas wrote: > > The ignoring starts at '@node Top' and continues until the next @node or > > @part command. > > Then it is different from texi2any. In texi2any in the following > @part part Intro and @chapter intro content is ignored: > >

Re: bug in texi2dvi, on Windows/Msys2 it cannot find tex

On Fri, Apr 08, 2022 at 03:53:31PM +0200, Tomas Kalibera wrote: > > On 4/8/22 15:31, Gavin Smith wrote: > > On Fri, Apr 08, 2022 at 03:15:01PM +0200, Tomas Kalibera wrote: > > > > What happens if we don't set MSYSTEM at all? > > > > > > >

Re: correctly placed @part before @node can be in ignored Top node

On Fri, Apr 08, 2022 at 03:36:59PM +0200, Patrice Dumas wrote: > On Fri, Apr 08, 2022 at 02:22:30PM +0100, Gavin Smith wrote: > > On Sun, Mar 20, 2022 at 11:47:41PM +0100, Patrice Dumas wrote: > > > On Sun, Mar 13, 2022 at 07:11:11PM +, Gavin Smith wrote: > > > >

Re: bug in texi2dvi, on Windows/Msys2 it cannot find tex

On Fri, Apr 08, 2022 at 03:15:01PM +0200, Tomas Kalibera wrote: > > What happens if we don't set MSYSTEM at all? > > > > diff --git a/util/texi2dvi b/util/texi2dvi > > index 1f42b41907..c506bbad37 100755 > > --- a/util/texi2dvi > > +++ b/util/texi2dvi > > @@ -85,7 +85,7 @@

Re: correctly placed @part before @node can be in ignored Top node

On Sun, Mar 20, 2022 at 11:47:41PM +0100, Patrice Dumas wrote: > On Sun, Mar 13, 2022 at 07:11:11PM +0000, Gavin Smith wrote: > > > > Do you think you can do something similar for texi2any, i.e. not include > > the @part line in the preceding node? > > Should be don

Re: bug in texi2dvi, on Windows/Msys2 it cannot find tex

On Wed, Apr 06, 2022 at 05:24:01PM +0300, Eli Zaretskii wrote: > > Date: Wed, 6 Apr 2022 14:39:30 +0200 > > From: Tomas Kalibera > > > > texi2dvi on Msys2 doesn't find tex, because it incorrectly detects ";" > > as path separator (it is ":"). > > > > The problem is in the following code. With

Re: `@raggedright` and `@multitable`

On Tue, Mar 22, 2022 at 06:01:20AM +, Werner LEMBERG wrote: > > [texinfo.tex 2022-02-16.13] > > > Consider the following example > > ``` > \input texinfo.tex > > @multitable @columnfractions 0.2 0.2 0.2 > @item foofoo foofoo foofoo foofoo > @tab barbar barbar barbar barbar > @tab

Re: po/POTFILES.in refers to ../info/info-utils.c, being not available

On Wed, Mar 30, 2022 at 07:44:22AM +0200, stefan-husm...@t-online.de wrote: > > Hello, > > recent builds fail with a message "no rule to make target > ../info/info-utils.c, needed by texinfo.pot-update". Indeed there is no such > file.It works when I change info-utils.c to util.c, which was

Re: t/index-paren.sh fails

On Mon, Mar 21, 2022 at 5:15 PM Patrice Dumas wrote: > the info t/index-paren.sh test fails. Ends with > > + initialization_done=0 > + ./ginfo --init-file ./t/Infokey-config index-paren ( > + grep Node: Node 2 > info: "./t/Infokey-config", line 2: unknown action `xxx-not-recognized' > info:

Re: bug in texi2dvi

On Sun, Mar 20, 2022 at 10:22:32AM +0100, Wybo Dekker wrote: > On line 464: > > ldta_result="$ldata_result \"$dir\"" > > ldata should probably be ldta Thank you for the report. The bug was probably introduced by me when I added prefixes to the variable names. There is a comment above the

Re: The HTML-Info initiative

On Mon, Dec 27, 2021 at 8:49 PM Gavin Smith wrote: > > On Mon, Dec 27, 2021 at 09:07:21AM -0800, Per Bothner wrote: > > I tried building the webkitgtk-info branch, but failed: > > > > In file included from hard-locale.c:23: > > ./locale.h:718:11: fatal error:

Re: correctly placed @part before @node can be in ignored Top node

On Sun, Mar 13, 2022 at 05:31:37PM +0100, Patrice Dumas wrote: > Hello, > > @part is naturally placed before @node and therefore would be ignored > for the first node after the Top node. Here is an example: > > @node Top > @top top > > @part Part 0 > > @node chapter node > @chapter

Re: more consistent ignoring before node and sections and Top node

On Fri, Mar 11, 2022 at 02:09:35AM +0100, Patrice Dumas wrote: > On Sun, Feb 20, 2022 at 10:42:25AM +0000, Gavin Smith wrote: > > > > Again I think the name of the option shouldn't contain the work "book", > > as it is too vague. > > I added a customizati

Re: Missing first index entry

On Tue, Feb 22, 2022 at 03:46:36PM +0300, Sergey Matveev wrote: > run "makeinfo foo.texi" and info ./foo.info says that no indices found > on "i"/"I" commands. If I rename "My" node to "My Index", then info > won't note about missing indices. I did not find explicit note about > that requirement.

Encoding error when reading file with ISO-8859-1 filename

Here's something that came up when I was testing filename encodings and a proposed fix to silence a warning message. Suppose you have a file the name of which is in ISO-8859-1, and which is itself encoded in ISO-8859-1. It's not easy to process this with texi2any from the command line in a UTF-8

Re: put invalid encoded file name for another locale in Makefile for DIST

On Fri, Mar 04, 2022 at 08:34:36AM +0100, Patrice Dumas wrote: > Hello, > > For some tests I use an include file with name encoded in ISO-8859-1 > to be included from a manual encoded in ISO-8859-1. The manual is > tp/tests/other/manual_include_accented_file_name_latin1.texi, the > include file

Re: different encodings for input and output file names and command line

On Fri, Mar 04, 2022 at 08:15:54AM +0100, Patrice Dumas wrote: > > + if ($self->get_conf('DOC_ENCODING_FOR_INPUT_FILE_NAME')) { > > +my $document_encoding; > > +$document_encoding = $self->{'parser_info'}->{'input_perl_encoding'} > > + if ($self->{'parser_info'} > > +and

Re: different encodings for input and output file names and command line

On Tue, Mar 01, 2022 at 01:42:50AM +0100, Patrice Dumas wrote: > I commited an implementation. The XS parser part is incomplete, I coded > passing the informations, but not using the information, for instance in > encode_file_name(). Also encode_file_name() should be used for CPP file >

Re: different encodings for input and output file names and command line

On Thu, Mar 03, 2022 at 11:09:20AM +0100, Patrice Dumas wrote: > I have understood why the test changed, the problem is that > reverse_iconv in input.c is not reinitialized between two calls > of the parser. It should probably be reset in reset_parser_except_conf > in api.c. I've fixed this.

Re: different encodings for input and output file names and command line

On Wed, Mar 02, 2022 at 10:42:34AM +0100, Patrice Dumas wrote: > I just tested that it does not happen with the perl Parser. I let you > look in more details, maybe the issue is that top->source_info is not > current_source_info at the point of the line directive. It's actually nothing to do

Re: different encodings for input and output file names and command line

On Tue, Mar 01, 2022 at 01:42:50AM +0100, Patrice Dumas wrote: > I commited an implementation. The XS parser part is incomplete, I coded > passing the informations, but not using the information, for instance in > encode_file_name(). Also encode_file_name() should be used for CPP file >

Re: different encodings for input and output file names and command line

On Mon, Feb 28, 2022 at 10:29:02AM +0100, Patrice Dumas wrote: > Hello, > > First, some tests with locales different from the @documentencoding made > me realize that it would make sense to have a different encoding of > file names for output than for input. Indeed, it may make sense for the >

Re: Non-ASCII characters in @include search path

On Sat, Feb 26, 2022 at 11:09:53PM +0100, Patrice Dumas wrote: > On Sat, Feb 26, 2022 at 09:29:15PM +0000, Gavin Smith wrote: > > On Sat, Feb 26, 2022 at 9:11 PM Patrice Dumas wrote: > > > The whole output file is encoded, the problem is that you encoded > >

Re: Non-ASCII characters in @include search path

On Sat, Feb 26, 2022 at 9:11 PM Patrice Dumas wrote: > The whole output file is encoded, the problem is that you encoded > $image_file, it should not be, it is assumed to be decoded from the > document. image_path could be encoded, but then the encoding should be > passed such that it can be

Re: Non-ASCII characters in @include search path

On Sat, Feb 26, 2022 at 08:06:52PM +, Gavin Smith wrote: > Does that fix the issue with this test? I think there needs to be some encoding in the URLs so there is not output like 1 Chapteùr I suppose it should just be the file encoding, always UTF-8 for XML output.

Re: Non-ASCII characters in @include search path

On Sat, Feb 26, 2022 at 06:57:34PM +, Gavin Smith wrote: > > I do not think so. I think that it needs to be encoded if mixed with > > non ascii strings. (Also, it could be set to something non ascii, as > > customization but this should be pretty rare). >

Re: Non-ASCII characters in @include search path

On Sat, Feb 26, 2022 at 06:50:10PM +0100, Patrice Dumas wrote: > You don't need a non-UTF-8 locale for the issue above, or for the issue > that prompted me to try to look seriously at the issue, which is > tests/formatting/list-of-tests non_ascii_test_epub. Having an accented > letter in the

Re: Non-ASCII characters in @include search path

On Sat, Feb 26, 2022 at 12:17:46AM +0100, Patrice Dumas wrote: > On Mon, Feb 21, 2022 at 08:46:56PM +0000, Gavin Smith wrote: > > On Sun, Feb 20, 2022 at 10:32:00PM +0100, Patrice Dumas wrote: > > > On Sun, Feb 20, 2022 at 05:27:51PM +, Gavin Smith wrote: > > > &g

Re: extra keys from XS parser not decoded?

On Fri, Feb 25, 2022 at 11:20:58AM +0100, Patrice Dumas wrote: > > I think you're right. Any time a string is created it should probably > > have the UTF-8 flag set, unless it represents a filename. > > It is ok too, I think, if we know that it can only be ascii, like > @-command names or type.

Re: extra keys from XS parser not decoded?

On Thu, Feb 24, 2022 at 11:50:51PM +0100, Patrice Dumas wrote: > Hello, > > I have some differences between the perl Parser and the XS parser for > non ascii strings for extra values. The perl Parser seems to be ok. > > My feeling is that the strings are not properly decoded. An analysis, >

Re: Feature request: api docs

On Fri, Feb 04, 2022 at 08:19:24AM +, Reißner Ernst wrote: > Hello all, > I know that texinfo offers some commands to document a function which can be > used for various computing languages. > One can document the signature: specify name of function, return variable and > input parameters. >

Re: Non-ASCII characters in @include search path

On Thu, Feb 24, 2022 at 02:33:11PM +0100, Patrice Dumas wrote: > It fixes the NonXS parser (I modified where it is done, such as to do it > it before locate_include_file but kept your code), but not for the XS > parser. In the XS parser, the @include file name is converted to utf-8 > upon

Re: configure enable xs fails because Texinfo/ModulePath.pm not found

On Thu, Feb 24, 2022 at 01:50:15PM +0100, Patrice Dumas wrote: > Hello, > > A ./configure in a devel pristine source shows > > Can't locate Texinfo/ModulePath.pm in @INC (you may need to install the > Texinfo::ModulePath module) (@INC contains: . ../.. >

Re: Non-ASCII characters in @include search path

On Wed, Feb 23, 2022 at 09:52:21PM +0200, Eli Zaretskii wrote: > > E.g. - UTF-8 Texinfo file, processed under KOI-8 locale on Windows, > > accessing filenames named with UTF-16 filenames on Windows filesystem. > > Then the UTF-8 filenames would be encoded to KOI-8, and then some file > > access

Re: Non-ASCII characters in @include search path

On Wed, Feb 23, 2022 at 03:39:23PM +0100, Patrice Dumas wrote: > On Tue, Feb 22, 2022 at 08:52:56PM +0000, Gavin Smith wrote: > > > > I've done more tonight but I still have more to do. There will have to > > be some decoding of filenames when they are being put into >

Re: Non-ASCII characters in @include search path

On Mon, Feb 21, 2022 at 11:34:00PM +0100, Patrice Dumas wrote: > On Mon, Feb 21, 2022 at 09:29:06PM +0000, Gavin Smith wrote: > > > > Done in commit 73e922d68b. > > I would prefer to have the line numbers in tests, I'll have a look at > it, but this should be doable wit

Re: Missing first index entry

On Tue, Feb 22, 2022 at 03:46:36PM +0300, Sergey Matveev wrote: > run "makeinfo foo.texi" and info ./foo.info says that no indices found > on "i"/"I" commands. If I rename "My" node to "My Index", then info > won't note about missing indices. I did not find explicit note about > that requirement.

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 05:07:32PM +0200, Eli Zaretskii wrote: > > Do you know if TeX distributions for Windows do any handling of filename > > encodings? > > I never used non-ASCII variant of TeX (XeTeX, I guess?) on Windows, so > I don't know, sorry. It's standard TeX that processes bytes with

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 07:34:49PM +0100, Patrice Dumas wrote: > > So my best idea at the moment for fixing the encoding of the error messages > > is: > > * When calling gettext and related functions, always demand UTF-8, and > > convert > > this back into Perl's internal coding afterwards. > >

Re: Non-ASCII characters in @include search path

On Mon, Feb 21, 2022 at 08:46:56PM +, Gavin Smith wrote: > On Sun, Feb 20, 2022 at 10:32:00PM +0100, Patrice Dumas wrote: > > On Sun, Feb 20, 2022 at 05:27:51PM +0000, Gavin Smith wrote: > > > If the error message became something like > > > > >

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 10:32:00PM +0100, Patrice Dumas wrote: > On Sun, Feb 20, 2022 at 05:27:51PM +0000, Gavin Smith wrote: > > If the error message became something like > > > > "nœud « �sseul� » non référencé" > > > > then encoding this to UTF

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 07:00:23PM +0100, Patrice Dumas wrote: > I don't get it. If everything is decoded to internal perl encoding and > then the file name is encoded to the local, here Latin-1, everything > will be ok, as long as the characters in manuals can be output in > Latin-1. The point

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 04:13:43PM +0100, Patrice Dumas wrote: > Another reason for decoding and encoding everything is error messages. > I am actually a bit surprised that nobody ever complained that error > messages are not encoded. I am not sure what the best approach is. Say there is code

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 04:13:43PM +0100, Patrice Dumas wrote: > On Sun, Feb 20, 2022 at 02:53:46PM +0000, Gavin Smith wrote: > > > > Decoding command-line arguments might be a good idea for everything > > EXCEPT file names. Why go to the bother of decoding file nam

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 2:55 PM Patrice Dumas wrote: > > The byte sequences are just concatenated and used as the path to the file, > > even if it's not validly encoded. This shouldn't cause a problem. > > It will cause a problem if the include file name itself is not ASCII. > To avoid any

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 05:07:32PM +0200, Eli Zaretskii wrote: > > The locale codeset could very easily be incorrect. Suppose somebody sets > > a Latin-1 locale, should they then be unable to build Texinfo manuals > > with non-ASCII UTF-8 filenames? > > They will see garbled file names. > > You

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 02:42:04PM +0100, Patrice Dumas wrote: > On Sun, Feb 20, 2022 at 12:45:59PM +0000, Gavin Smith wrote: > > > > I made a similar change in commit e11835b62d. > > I propose another plan: > * decode arguments on the command line arguments

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 03:35:57PM +0200, Eli Zaretskii wrote: > > Date: Sun, 20 Feb 2022 14:28:23 +0100 > > From: Patrice Dumas > > > > On Sun, Feb 20, 2022 at 01:09:06PM +, Gavin Smith wrote: > > > > > > My thought was that the argument to -I co

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 03:06:57PM +0200, Eli Zaretskii wrote: > > This means that any non-ASCII characters in a filename in a Texinfo source > > file are sought in the filesystem as the corresponding UTF-8 sequences. > > This will not work on Windows. I can see that there could be an issue if

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 01:45:19PM +0100, Patrice Dumas wrote: > On Sun, Feb 20, 2022 at 01:10:16PM +0100, Patrice Dumas wrote: > > > > I think that the correct way to do that is to use > > Encode::encode($text, 'utf-8'); > > Also I think that it should be done as late as possible, so it would be

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 11:54:08AM +, Gavin Smith wrote: > I propose the following fix, which doesn't touch Perl's internal string > representation directly: > > diff --git a/tp/Texinfo/Common.pm b/tp/Texinfo/Common.pm > index 29dbf3c8c3..7babba016c 100644 > --- a/tp/Texinfo

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 10:11:09AM +, Gavin Smith wrote: > On Sun, Feb 20, 2022 at 09:11:54AM +0000, Gavin Smith wrote: > > On Sat, Feb 19, 2022 at 11:00:33PM +0100, Patrice Dumas wrote: > > > I think that there is some wrong encoding/decoding somewhere, > >

Re: more consistent ignoring before node and sections and Top node

On Sat, Feb 19, 2022 at 11:28:43PM +0100, Patrice Dumas wrote: > Hello, > > Right now there is a diversity of handling of text at the beginning of > Texinfo manuals, before the first @node and sectioning, but also for the > informations in @titlepage that are not truly title page (@insertcopying

Re: Non-ASCII characters in @include search path

On Sun, Feb 20, 2022 at 09:11:54AM +, Gavin Smith wrote: > On Sat, Feb 19, 2022 at 11:00:33PM +0100, Patrice Dumas wrote: > > I think that there is some wrong encoding/decoding somewhere, > > but I don't know where. It is particularly strange that I cannot > > reproduce

Re: Non-ASCII characters in @include search path

On Sat, Feb 19, 2022 at 11:00:33PM +0100, Patrice Dumas wrote: > I think that there is some wrong encoding/decoding somewhere, > but I don't know where. It is particularly strange that I cannot > reproduce with 6.8 but Gaël can. I reproduced with 6.8 but only with TEXINFO_XS=omit. I am going to

Re: Non-ASCII characters in @include search path

On Sat, Feb 19, 2022 at 06:04:32PM +, Gaël Bonithon wrote: > Does not work for me (I'm on Arch Linux, Texinfo 6.8): Just saw this bit. I will have to test with Texinfo 6.8 and see if the issue replicates itself. If not, then there is likely some unresolved issue.

Re: Non-ASCII characters in @include search path

On Sat, Feb 19, 2022 at 06:04:32PM +, Gaël Bonithon wrote: > Does not work for me (I'm on Arch Linux, Texinfo 6.8): > > $ makeinfo -I ./è simplest.texi > simplest.texi:10: @include: could not find toto.texi > $ makeinfo --html -I ./è simplest.texi > simplest.texi:10: @include: could not find

Re: `@image` doesn't respect top margin of text block

On Tue, Feb 15, 2022 at 09:26:13PM +, Gavin Smith wrote: > On Thu, Feb 10, 2022 at 11:12:52AM +, Werner LEMBERG wrote: > > > > As the example shows, an image located at the top of the page doesn't > > correctly respect the top margin of the text block. If this >

Re: `automake` error

On Mon, Feb 14, 2022 at 02:59:59PM +0100, Patrice Dumas wrote: > For 1, one possibility would be to generate a fake tp_api.texi from > autogen.sh suitable for automake with a timestamp in the past similar > with what Gavin proposed. It seems to work but, FWIW, it wasn't supposed to be a proposed

Re: `@image` doesn't respect top margin of text block

On Thu, Feb 10, 2022 at 11:12:52AM +, Werner LEMBERG wrote: > > As the example shows, an image located at the top of the page doesn't > correctly respect the top margin of the text block. If this > intentional it should be documented. > > > Werner It's not intentional. The top margin

Re: `automake` error

On Mon, Feb 14, 2022 at 08:06:06PM +0100, pertu...@free.fr wrote: > 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

Re: Feature request: api docs

On Mon, Feb 14, 2022 at 01:07:53PM +, Reißner Ernst wrote: > I think, if all is happy with that solution, we shall implement along the > same line, right? Somebody has to work out all the details. And it may be, once the problem is understood, that recommending another system like Doxygen

Re: `automake` error

> After saying `./autogen.sh` I see > > ``` > automake: error: cannot open < doc/tp_api/tp_api.texi: No such file or > directory > ``` I committed a fix for this but don't know if it's correct: diff --git a/doc/tp_api/Makefile.am b/doc/tp_api/Makefile.am index bd36d99372..7629b0122b 100644 ---

Re: `automake` error

> The problem is because automake is being too clever and trying to scan > the Texinfo files. > > I'm going to try upgrading automake and see what happens. Exactly the same problem with automake 1.16.5.

Re: `automake` error

On Sat, Feb 12, 2022 at 06:30:36PM +, Werner LEMBERG wrote: > > [5605c12a99493289acb39938f029a2db1cebc5bd] > > > After saying `./autogen.sh` I see > > ``` > automake: error: cannot open < doc/tp_api/tp_api.texi: No such file or directo +ry > ``` > The build works for me for some reason but

Re: Locale-related test failures

On Sat, Feb 12, 2022 at 10:09 AM Gavin Smith wrote: > > I've got test failures in the tp/t directory. They appear to be > related to translations: I found the following fixed it: diff --git a/ChangeLog b/ChangeLog index 5f4b1cf67b..dd511355c8 100644 --- a/ChangeLog +++ b/ChangeLog @@

Locale-related test failures

I've got test failures in the tp/t directory. They appear to be related to translations: $ diff t/results/misc_commands/many_lines.pl* 1773c1773 < 'error_line' => ':29: warning: unrecognized encoding name `US-ascii encoding name\' --- > 'error_line' => ':29: warning: unrecognised encoding

Re: Feature request: api docs

On Mon, Feb 7, 2022 at 8:19 AM Reißner Ernst wrote: > @Gavin Smith : the style I know is putting api docs with the code. > This turned out to be by far safest to keep docs up to date. > In java world, in c#, in c and c++ I think this is the accepted way to do it. > Also in lisp a

Re: using manual_html as output directory for HTML

On Sat, Feb 5, 2022 at 9:14 AM Patrice Dumas wrote: > > Hello, > > I think that it is not a good thing to have the base manual name, or the > base manual name with .html prepended as default directory for html > output, for three reasons: > * I think that a directory with the manual name should

Re: Feature request: api docs

On Fri, Feb 4, 2022 at 2:18 PM Reißner Ernst wrote: > > Hello all, > > I know that texinfo offers some commands to document a function which can be > used for various computing languages. > > One can document the signature: specify name of function, return variable and > input parameters. > > >

Re: '(info-stnd)Invoking Info' doesn't mention that '--show-options' requires arguments

On Sun, Jan 30, 2022 at 10:35:42AM -0500, Alfred M. Szmidt wrote: > It would be better to say "info -O emacs" -- since that is the > "standard" synopsis for commands and putting options at the end will > be slightly confusing to users, even though we allow out of order > options. info emacs -O

Re: '(info-stnd)Invoking Info' doesn't mention that '--show-options' requires arguments

On Sun, Jan 30, 2022 at 10:18:37AM +0500, Akbarkhon Variskhanov wrote: > Hmm, I see. It is indeed very confusing but thanks for clearing that up > nonetheless. > > Perhaps some other notation with an example is needed here I made the following change: @@ -487,9 +486,12 @@ @node Invoking Info

Re: '(info-stnd)Invoking Info' doesn't mention that '--show-options' requires arguments

On Thu, Jan 27, 2022 at 11:25:38PM +0500, Akbarkhon Variskhanov wrote: > doc/info-stnd.texi#n483 > > info/info.c#n1109 > > > Something like: > > >

Re: control over sectioning and splitting

On Sat, Dec 25, 2021 at 12:58:58PM +0100, Patrice Dumas wrote: > On Sun, Oct 10, 2021 at 08:56:35AM -0700, Per Bothner wrote: > > > > > > On 10/10/21 07:10, Patrice Dumas wrote: > > > I am probably missions something, but isn't what you want obtained with > > > --split=chapter and using

Re: manual organized in topics in Texinfo (similar with Mallard)?

On Mon, Jan 17, 2022 at 02:32:27PM +0100, Patrice Dumas wrote: > Hello, > > I stumbled by chance on the Mallard format which is used in the GNOME > project for their documentation: > http://projectmallard.org/about/learn/index.html > http://projectmallard.org/1.1/ > > What I found interesting is

Re: problem with gnulib tp/Texinfo/XS/gnulib/lib/stdlib.h?

On Sun, Jan 16, 2022 at 09:20:46PM +0100, Patrice Dumas wrote: > Hello, > > With the gnulib file as in git, I get, after compilation without visible > error: > $ ./texi2any.pl > perl: symbol lookup error: ../tp/Texinfo/XS/.libs/Parsetexi.so: undefined > symbol: rpl_free > > after make clean

Re: Localization and translation

On Fri, Jan 14, 2022 at 11:16:09AM +0900, Jean-Christophe Helary wrote: > Would it be possible to have the Texinfo manual available as a PO file as the > UI files are ? > > https://translationproject.org/domain/texinfo.html > https://translationproject.org/domain/texinfo_document.html > > The

Re: support figure space (U+2007)

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 that \s is used a lot in regexp where the C parser > probably check

Re: support figure space (U+2007)

On Sat, Jan 15, 2022 at 10:57:58AM +, Werner LEMBERG wrote: > >> Masamichi-san, what do you think? [...] > > > > I think it is not necessary to filter out U+3000. > > Thanks for checking. This is good news, since it makes Gavin's patch > work just fine. > > > Werner Hello Werner I

Re: error with autogen.sh probably related to gnulib update

On Sun, Jan 16, 2022 at 05:46:04AM -0800, Per Bothner wrote: > On 1/16/22 05:13, Gavin Smith wrote: > > I've tracked those files under tp/Texinfo/XS. Hope it works now. > > I got a merge conflict because gnulib/lib/malloc/dynarray-skeleton.gl.h > is now checked into git. Wa

Re: error with autogen.sh probably related to gnulib update

On Sun, Jan 16, 2022 at 02:23:45AM +0100, Patrice Dumas wrote: > Hello, > > I rerun gnulib-tool --add-import and now it seems ok. I have the > following files untracked: > > gnulib/lib/stdalign.in.h > gnulib/lib/stdio-read.c > gnulib/lib/stdio-write.c >

Re: setting up rules on produced HTML class attributes

On Sun, Jan 09, 2022 at 02:49:04PM +0100, Patrice Dumas wrote: > > > With these rules some class names already output should change. One > > > case of change is the @example arguments which would need to be changed > > > and contradicts the current manual content. According to the proposal > > >

Re: small* commands alias in classes in HTML?

On Wed, Jan 12, 2022 at 02:50:07PM +0100, Patrice Dumas wrote: > Hello, > > Currently in HTML the information that an @command is a @small variant > is completly lost. Shouldn't the small variant be added in the classes > together with the normal variant? I've no objection to this. For example

Re: conditional "LIBUNISTRING_COMPILE_UNIWIDTH_WIDTH" was never defined.

> > Avoid error "conditional LIBUNISTRING_COMPILE_... was never defined" > when option --conditional-dependencies is used (regression 2022-01-09). > Reported by Gavin Smith in > <https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg

Re: [TexInfo] Compatibility to glibc 2.34

On Fri, Jan 14, 2022 at 06:22:38PM +0100, Hilmar Preuße wrote: > Yes, I noticed that gnulib in Debian builds fine w/ glibc 2.34. However I > didn't notice that the issue is solved in texinfo repo already. I just > noticed that the files modified by my patch still look the same in texinfo >

Re: support figure space (U+2007)

On Mon, Jan 03, 2022 at 10:22:36AM +0100, Patrice Dumas wrote: > On Sun, Jan 02, 2022 at 08:20:18AM +, Werner LEMBERG wrote: > > > > The nice thing is that it would work out of the box with HTML > > browsers, too. On the other hand, maybe there could be some further > > massaging to convert

Re: [TexInfo] Compatibility to glibc 2.34

On Fri, Jan 14, 2022 at 09:02:06AM +0200, Eli Zaretskii wrote: > > Date: Thu, 13 Jan 2022 23:58:22 +0100 > > From: Hilmar Preuße > > Cc: "debian-tex-ma...@lists.debian.org" > > > > Dear texinfo maintainers, > > > > In the Debian bug tracker we got a report that TeXinfo 6.8 is > > incompatible

Re: Is any future development needed on 'dir' files?

On Mon, Jan 10, 2022 at 12:59:41AM +0100, Patrice Dumas wrote: > This TODO entry seems to me to be still relevant. But first it seems > to me that the categories in util/dir-example do not match the categories > in https://directory.fsf.org/wiki/Category/All. > And then when the categories are

Re: [htmlxref.cnf] Please update the list of Emacs manuals

On Sat, Jan 08, 2022 at 03:54:05PM +0100, Thérèse Godefroy wrote: > Hello, > > A huge number of Emacs manuals are missing from htmlxref.cnf [0]. The > attached diff tries to complete the list, based on the Emacs webpages [1]. I > also updated the ada-mode URL. > > Best regards, > Thérèse Thanks

Is any future development needed on 'dir' files?

I was looking at the TODO file for Texinfo, and reading this again: > - Monitor and improve the dir categories in existing manuals, >following the Free Software Directory categories. Much mail to >developers has already been sent, what's needed now is to check new >releases and make

<    4   5   6   7   8   9   10   11   12   13   >