Re: @itemize @asis is not well supported

Gavin Smith wrote: > it is not worth changing and making practically every use of > @itemize in a Texinfo manual being flagged as incorrect, in my opinion. I agree. Counting the number of existing usages in Debian [1][2]: - 8753 times '@itemize @bullet' without braces, - 288 times '@itemize

Re: @itemize @asis is not well supported

Patrice Dumas wrote: > > The command after @itemize should not require an argument, but @asis > > needs an argument. Try @asis{} instead. > > The command after @itemize should not require an argument, but @code > > needs an argument. Try @code{} instead. > > What about > > @itemize

Re: @itemize @asis is not well supported

Andreas Schwab wrote: > It's not a might, it's a don't do it. It's a misuse of a command that > requires an argument, in a place that doesn't pass one. Thanks for the succint formulation. Can we use it in the warning? The command after @itemize should not require an argument, but @asis needs

Re: @itemize @asis is not well supported

Patrice Dumas wrote: > Ok, I propose as warning message : > > "non-mark brace command `\@%s' as \@%s argument should have braces" > > leading to something like > > non-mark brace command `@asis' as @itemize argument should have braces This is not easy to understand. How about @itemize

Re: @itemize @asis is not well supported

Patrice Dumas wrote: > @itemize @asis is definitely not the same as @table @asis. Indeed, > @table argument is applied to the @item argument, while @itemize > argument precedes the @item argument. Ah, thanks for explaining. It also explains why @itemize @code did not have the desired effect,

@itemize @asis is not well supported

@itemize @asis seems to work in HTML and info mode only, not in TeX mode. How to reproduce (with texinfo-7.1): $ git clone git://git.savannah.gnu.org/gnulib.git $ cd gnulib $ git checkout f52d4a7b78be73060cf01640b40ebc88193c12e8 $ cd doc $ make pdf ... /tmp/gnulib/doc/gnulib-tool.texi:472:

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Gavin Smith wrote: > It is surprising it worked as well as it did with mixing the two different > struct definitions. Yes. Probably because the alignment only matters on sparc64 and ia64 machines, and because no new features were added to this module in 20 years. > Thanks for the detailed

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Sam James wrote: > > It appears that the obstack gnulib module is the culprit. I replied: > Therefore, if it is a bug in gnulib, it is also a bug in glibc. Sam was right. I was wrong. It is a bug in the 'obstack' gnulib module. The scope - It is visible on CPUs that are -

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Hi Jeffrey, > On SPARC, 64-bit words can be loaded and saved through one of two > instructions. The first version is optimized, the second version is > not. The optimized version is faster, but the 64-bit words have to be > aligned to 8-byte boundaries. I.e., naturally aligned. > > If you are

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Sam James wrote: > It appears that the obstack gnulib module is the culprit. When I compile texinfo-7.1 in such a way that is uses the obstack facility from glibc (via 'gl_cv_func_obstack=yes ../configure ...'), I see the same bus error as in a build where the obstack facility comes from gnulib.

CC and CFLAGS are ignored by part of the build

Hi, I'm trying to build texinfo-7.1 on Linux/sparc64, in order to debug a problem. I configured the package with CC="gcc -fsanitize=undefined" \ CFLAGS="-O0 -fno-omit-frame-pointer -ggdb" \ gl_cv_func_obstack=yes \ ../configure --prefix=$HOME/prefix64 \

Re: c32width gives incorrect return values in C locale

[CCing bug-libunistring] Gavin Smith wrote: > I did not understand why uc_width was said to be "locale dependent": > > "These functions are locale dependent." > > - from > . That's because some

Re: c32width gives incorrect return values in C locale

[CCing bug-gnulib] Gavin Smith wrote: > > I guess you will need to look at the Unicode characters that you pass to > > c32width, > > and whether you get return values < 1 for some of them. > > It is locale-dependent! > > It looks like c32width is simply being redirected to wcwidth which then >

Re: Locale-independent paragraph formatting

> > From: Gavin Smith > > Date: Thu, 9 Nov 2023 21:26:11 + > > > > I have just pushed a commit (e3a28cc9bf) to use gnulib/libunistring > > functions instead of the locale-dependent functions mbrtowc and wcwidth. > > This allows for a significant simplification as we do not have to try > > to

Re: MinGW "info" program broken?

Eli Zaretskii wrote: > > It happens also with the mingw-w64 version 5.0.3 build. Let me > > investigate... > > Is this build with UCRT or with MSVCRT? The mingw-w64 5.0.3 built ginfo.exe is linked with MSVCRT. Only the MSVCRT built ginfo.exe is linked with the various api-ms-win-crt-*.dll,

Re: Texinfo 7.0.94 on native Windows

Eli Zaretskii wrote: > _popen accepts a MODE argument which can be used to control that, see > > > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/popen-wpopen?view=msvc-170 > > We use this in the stand-alone Info reader, for example, in this > snippet from info/filesys.c: >

Re: MinGW "info" program broken?

Eli Zaretskii wrote: > The stand-alone Info reader built with MinGW works > flawlessly for me. > > > I had understood that "info" was running well on MinGW so it would be worth > > understanding any differences between yours and Bruno's setup. > > I'm indeed curious why this happens with the

Re: MinGW "info" program broken?

Gavin Smith wrote: > I had understood that "info" was running well on MinGW so it would be worth > understanding any differences between yours and Bruno's setup. I'm usually building with mingw-w64 5.0.3. Whereas Eli (AFAIK) often builds with the older mingw from the now-defunct mingw.org site.

Re: Texinfo 7.0.94 on native Windows

Eli Zaretskii wrote: > > For 'popen' and 'pclose', one needs the gnulib modules 'popen' and 'pclose', > > respectively. > > Windows has _popen and _pclose, which can be used instead. _popen uses text mode, not binary mode, by default, AFAIK. This can be problematic. Bruno

Re: Texinfo 7.0.94 on native Windows

aviour changes. Rather, this is post-7.1 stuff IMO. Bruno 0001-MSVC-port-part-1-Ran-gnulib-tool-add-import-popen-pc.patch.gz Description: application/gzip >From c89961391cd3ad616cdd457c89c25f22c3213713 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sun, 15 Oct 2023 12:30:04 +0200 Subject: [P

Re: Texinfo 7.0.93 pretest available

Hi Gavin, > The module shouldn't load if it can't switch to a UTF-8 locale. xspara_init > returns a different value if these attempts fail leading the code loading > the module (in Texinfo::XSLoader) to fall back to the pure Perl version. Ah, maybe this is what did not work in Eli's case on

Re: Texinfo 7.0.93 pretest available

Eli Zaretskii wrote: > I think we should first explore a better > alternative: use UTF-8 functions everywhere, without relying on the > locale-aware functions of libc, such as wcwidth. For example, instead > of wcwidth, we could use uc_width. > > Is it feasible to use UTF-8 in texi2any

Re: Texinfo 7.0.93 pretest available

Gavin Smith wrote: > It is supposed to attempt to force the locale to a UTF-8 locale. You > can see the code in xspara_init that attempts to change the locale. There > is also a comment before xspara_add_text: > > "This function relies on there being a UTF-8 locale in LC_CTYPE for > mbrtowc

Re: Texinfo 7.0.93 pretest available

Eli Zaretskii wrote: > > From: Bruno Haible > > Cc: bug-texinfo@gnu.org > > Date: Mon, 09 Oct 2023 18:15:05 +0200 > > > > Eli Zaretskii wrote: > > > unless the locale's codeset is UTF-8, any character that is not > > > printable _in_the_c

Re: Texinfo 7.0.93 pretest available

Eli Zaretskii wrote: > unless the locale's codeset is UTF-8, any character that is not > printable _in_the_current_locale_ will return -1 from wcwidth. I'm > guessing that no one has ever tried to run the test suite in a > non-UTF-8 locale before? I just tried it now: On Linux (Ubuntu 22.04), in

Re: Texinfo 7.0.93 pretest on CentOS Stream 9

On CentOS Stream 9, the configuration aborts right away: checking Perl version and modules... no configure: error: perl >= 5.8.1 with Encode, Data::Dumper and Unicode::Normalize required by Texinfo. This is an improvement, compared to my previous report

Re: Texinfo 7.0.93 pretest

The compilation succeeds, and "make check" has all tests pass on: * Linux: - Ubuntu 22.04 - Debian 9.1 - Debian 12 - OpenSUSE Leap 15.5 - Slackware 15 - CentOS 8-stream (This means the previously reported failure

Re: Texinfo 7.0.92 pretest on AIX 7.3.1

Gavin Smith wrote: > Once a pretest is out and tested, and builds successfully on some platforms, > I am loth to update gnulib again and risk breaking the build. > ... > At the time of a release, the Gnulib checkout is set in stone. It will not > be updated as a matter of course for any bug-fix

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

Hi Patrice, > As a side note, it would have been better to have a specific variable > like LTLIBUNISTRING instead of using the global CPPFLAGS, but it is not > a big deal either. The absence of such a variable INCLIBUNISTRING is a trade-off between convenience and complexity. -L and -Wl options

Re: Texinfo 7.0.92 pretest on CentOS 8-stream

Patrice Dumas wrote: > > So, as I understand it, this test failure will remain. > > Actually it should not, the test should have been skipped, it was > supposed to be fixed by this commit: > > https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=e34a8d6b66d0518a2c1673da62c56b60f87151e3 This

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

Patrice Dumas wrote: > > FAIL: different_encodings.sh > > There was the same kind of errors on N Beebe builds (I missed your > original report). It is is supposed to be fixed by > https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=e34a8d6b66d0518a2c1673da62c56b60f87151e3 I confirm: With

Re: Texinfo 7.0.92 pretest on other platforms

The compilation succeeds, and "make check" has all tests pass on: * Linux: - Ubuntu 22.04 - Debian 9.1 - Debian 12 - OpenSUSE Leap 15.5 - Slackware 15 - Manjaro 17 (both in 32-bit and 64-bit mode) * Alpine Linux 3.14 * GNU/Hurd * macOS 12.5 * FreeBSD 13.2 * OpenBSD 7.2 * AIX 7.1 and

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

On NetBSD 9.0, with a GNU libiconv 1.0 installed, I see this build failure: $ gmake ... /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../../../tp/Texinfo/XS/gnulib/lib -I../.. -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef

Re: Texinfo 7.0.92 pretest on CentOS Stream 9

On CentOS Stream 9, "make check" fails with 52 test failures. Find attached the log files. centos9-logs.tar.gz Description: application/compressed-tar

Re: Texinfo 7.0.92 pretest on CentOS 8-stream

On CentOS 8-stream, I still see this test failure: FAIL: different_encodings.sh Already reported in https://lists.gnu.org/archive/html/bug-texinfo/2023-08/msg00053.html Last time, you wrote: > Even though there is > a stub for Unicode::Collate, the tests will not all pass without it. >

Re: Texinfo 7.0.92 pretest on AIX 7.3.1

On AIX 7.3.1, I see a compilation error: /opt/freeware/bin/gcc -maix64 -DHAVE_CONFIG_H -I. -I../../../gnulib/lib -I../.. -I/home/haible/prefix64/include -Wall -D_THREAD_SAFE -Wno-cast-qual

Re: "error: too deeply nested expressions" for large Perl input file

Gavin Smith wrote: > In gettext 0.22, there is an error running xgettext with a large input > file: > > $ /usr/local/bin/xgettextHTML.pm > HTML.pm:8052: error: too deeply nested expressions > > This makes "make update-po" break in the Texinfo package. Thanks for the report. Fixed

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

Gavin Smith wrote: > > On CentOS 8 and CentOS 8-stream, the build now succeeds, but there is 1 test > > failure: > > > > FAIL: different_encodings.sh > > > > Find attached the tp/tests/many_input_files/test-suite.log. > > > > Can you please send the contents of the file

fix syntax error in doc/Makefile.am

Some 'make' programs give a syntax error when the lines that define the commands for a target don't all start with a tab. The text editor that I use (KDE kate) highlights such lines. This patch provides a fix. Bruno diff --git a/doc/Makefile.am b/doc/Makefile.am index 69dc082a6e..e0d5209f84

Re: "make dist" error

Gavin Smith wrote: > I've added rules for these and checked that they work in out-of-source > builds, and with make distcheck. Thanks. Note that this Makefile.am does not have a .NOTPARALLEL pseudo-target, therefore if people (not me, but someone else :) ) runs "make -j 4 dist", two different

Re: Texinfo 7.0.90 pretest on AIX 7.3

Gavin Smith wrote: > I have committed a > change to use a temporary file in the same directory as the dir file, > which is done by extending the name of the dir file. Thanks. "make check" on AIX 7.3 now passes. No test failures. Bruno

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

Gavin Smith wrote: > I've added such a stub and added a test to configure, so that a visible > warning will be printed at the end of a configure run warning about missing > Unicode::Collate. On CentOS 8 and CentOS 8-stream, the build now succeeds, but there is 1 test failure: FAIL:

"make dist" error

Hi, I'm trying to create a texinfo tarball from the current git (for testing on CentOS 8-stream...) and am getting this error: $ ./autogen.sh ... $ ./configure ... $ make ... $ make dist ... make[3]: Entering directory '/media/develdata/www-archive/source/newest/texinfo-git/texinfo/doc' make

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

Patrice Dumas wrote: > > https://lwn.net/Articles/348090/ "Re: Redhat perl != perl" > > https://lwn.net/Articles/348084/ "On properly packaging perl" > > This seems to be an old change that was reverted afterwards. This thread was in 2009. Since things are fine in CentOS 6 and 7, probably they

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

Gavin Smith wrote: > As the log file shows, the Unicode::Collate module is not found. Indeed: just running perl with a 1-line input $ perl use Unicode::Collate; produces an error on CentOS 8-stream, but not e.g. on Ubuntu. When I manually search for it in @INC, I don't see it installed:

Re: ISO C99 mixed declaration and statements

Gavin Smith wrote: > It may have been some MS-Windows compiler (MSVC?) that didn't support it, Yes, I too have some recollection of MSVC (9 perhaps?) not supporting it. But since MSVC 14 (released in 2015) there is no problem any more. > I am going to take out the recommendation that we check

ISO C99 mixed declaration and statements

Hi Gavin, I see this commit: * install-info/install-info.c (output_dirfile): Avoid mixed declaration and statements. Is it possible nowadays to assume ISO C99 mixed declaration and statements are supported by the C compiler? I don't know about the portability targets of TeXinfo,

Re: Texinfo 7.0.90 pretest on mingw

Eli Zaretskii wrote: > > On mingw 5.0.3, I see 56 test failures: > > > > FAIL: ii-0001-test > > FAIL: ii-0002-test > > Isn't this a problem with different EOL conventions in the expected > results and in what install-info compiled for Windows produces? That was the problem last time [1].

Re: Texinfo 7.0.90 pretest on CentOS 8-stream

Find attached the mail body (body.txt), log file (tp/tests/test-suite.log), and some info (info.txt), which I can't include in the mail body if I want this mail to pass the spam filters. Bruno attachments.tar.xz Description: application/xz-compressed-tar

Re: Texinfo 7.0.90 pretest on other platforms

The build succeeds and "make check" passes on - Linux: Debian 9.1, Debian 12, OpenSUSE Leap 15.5, Manjaro 17, Alpine Linux 3.14 - GNU/Hurd - macOS 12.5 - FreeBSD 13.2 - NetBSD 9.0 - OpenBSD 7.2 - Solaris 11.4 - Cygwin 2.9.0 Bruno

Re: Texinfo 7.0.90 pretest on mingw

On mingw 5.0.3, I see 56 test failures: FAIL: ii-0001-test FAIL: ii-0002-test FAIL: ii-0003-test FAIL: ii-0004-test FAIL: ii-0005-test FAIL: ii-0006-test FAIL: ii-0007-test FAIL: ii-0008-test FAIL: ii-0009-test FAIL: ii-0010-test FAIL: ii-0011-test FAIL: ii-0012-test FAIL: ii-0014-test FAIL:

Re: Texinfo 7.0.90 pretest on AIX 7.3

On AIX 7.3.1, the build succeeds (with ibm-clang), but there are 58 test failures: FAIL: ii-0001-test FAIL: ii-0002-test FAIL: ii-0003-test FAIL: ii-0004-test FAIL: ii-0005-test FAIL: ii-0006-test FAIL: ii-0007-test FAIL: ii-0008-test FAIL: ii-0009-test FAIL: ii-0010-test FAIL: ii-0011-test FAIL:

Re: Take account of splitting option in gendocs.sh

Gavin Smith wrote: > I've made minor changes to the patch as specified in Karl's response below. > Please can this be applied? Thanks for having taken into account both my and Karl's comments. I have applied your patch. Bruno

Re: makeinfo no longer validates the menu structure

Patrice Dumas wrote: > It is on purpose that CHECK_NORMAL_MENU_STRUCTURE is needed, because > with manually made menus and node directions, it is not really possible > to be sure that an irregular structure is not done on purpose. Are you serious about that? Reading an info file should not be an

makeinfo no longer validates the menu structure

Hi, In .info files, the @menu items are essential for a good navigation experience. Thus, it is helpful if 'makeinfo' reports ./strings.texi:21: node `Strings' lacks menu item for `String Functions in C Locale' despite being its Up target makeinfo did so up to version 6.7. In versions 6.8

Re: Take account of splitting option in gendocs.sh

Gavin Smith wrote: > Here's an updated patch that does not affect the behaviour when > used with texi2html. Thanks for the improvement. Bruno

Re: Take account of splitting option in gendocs.sh

Gavin Smith wrote, re : > > OK it doesn't do any harm to keep the texi2html support in. > > > > The patch I sent applied for both texi2html and texi2any, although I > > hadn't tested it with texi2html. > > Is there any progress

Re: Take account of splitting option in gendocs.sh

Gavin Smith wrote: > I notice that this script also still supports texi2html, which is no > longer developed. I could produce a patch to remove this support if > it was very likely that nobody was relying on it. A web search on www.gnu.org shows that the manuals of at least the following

Re: info may stress-test the terminal emulator

Hi Gavin, > There's no way for me to reproduce this. Neither can I. The next time it occurs, I hope I'll think at launching gdb immediately. Thanks for listening anyways. Bruno

Re: info may stress-test the terminal emulator

Andreas Schwab wrote: > > Is there a way to fix/improve this erratic behaviour of the 'info' program, > > please? > > Are you sure it's not the terminal emulator erratically sending an > endless stream of characters to the inferior? The info program normally > emits a BEL when it receives a

info may stress-test the terminal emulator

Hi, This is a bug report about the 'info' program (GNU texinfo 6.8). In a terminal emulator, I ran 'info m4', searched for m4_provide_if, then attempted to abort this search by pressing some of the characters ESC, Enter, Ctrl-Q, repeatedly. (I can't remember which character sequence exactly.) At

Re: VirtualBox tricks (was: texinfo-7.0.1 on OpenSolaris)

Gavin Smith wrote: > somehow harder to get access to local files. > > The solution appears to be to install something called the Guest Additions. Alternatively, one can use 'scp' between the guest and the host (at IPv4 address 10.0.2.2). Bruno

Re: texinfo-7.0.1 on OpenSolaris

Gavin Smith wrote: > I will be deleting the disk image as soon as this is finished due > to the amount of space it takes up. I will not be testing routinely > on OpenIndiana using VirtualBox. That's OK, as I will be routinely testing on Solaris OpenIndiana when you ask. > > After the system it

Re: texinfo-7.0.1 on OpenSolaris (was: texinfo-6.8.90 pretest on OpenSolaris)

Building GNU texinfo 7.0.1 on OpenSolaris 2022.10, I get the same failure as reported in : FAIL: t/dir-file-sloppily.sh Gavin Smith wrote: > I don't know what is causing this and would need access to a system with > either

Re: namespacing issues with Gnulib

Eli Zaretskii wrote: > > Attempting to --whole-archive link on that platform grants us: > > > > $ x86_64-linux-musl-gcc -o ginstall-info install-info.o \ > > -Wl,--whole-archive ../gnulib/lib/libgnu.a -Wl,--no-whole-archive > > /usr/libexec/gcc/x86_64-linux-musl/ld: > >

Re: -Wlto-type-mismatch warning in error()

Gavin Smith wrote: > I expect it is not a gnulib problem. install-info/install-info.c declares > a function called "error" which appears to clash with a function from glibc. > ... The "error" module is brought in by "xalloc" (which we > ask for explicitly). Yes, I think the problems already

Re: Texinfo translation error, texinfo_document domain

Patrice Dumas wrote: > Beware that this has changed in the forthcoming release in which UTF-8 > is considered as preferred. Cool! > > 3) "For maximum portability of Texinfo documents across the many different > > user > > environments in the world, we recommend sticking to 7-bit ASCII in the >

Re: Texinfo translation error, texinfo_document domain

Hi Patrice, Patrice Dumas wrote: > > My complaint was only about the (apparent / confused) need to use TeXinfo > > syntax *for non-ASCII characters*. > > It should only be required for non-ASCII characters if the encoding of the > po file is us-ascii, for example in pt_BR.us-ascii.po the

Re: Avoid gnulib redefinitions - MDA

Gavin Smith wrote: > so it sounds like we are better off using #undef before > including the Perl headers to avoid depending on undocumented > functionalities. Thanks. Using #undef means to decline all corrections done by Gnulib. These are documented in the manual. For example, for 'fdopen' [1]

Re: [platform-testers] texinfo-6.8.91 pretest

Gavin Smith wrote: > https://alpha.gnu.org/gnu/texinfo/texinfo-6.8.91.tar.xz The build succeeds and all tests pass on: * various Linux distros with glibc (Ubuntu 22.04, Debian 9.1, Debian 11.1, CentOS 8-stream, OpenSUSE Leap 15.2, Manjaro 17) * GNU/Hurd (although 'info' wasn't built

Re: Avoid gnulib redefinitions - MDA

following change as potentially being responsible: > > 2021-04-11 Bruno Haible > > Support several gnulib-tool invocations under the same configure.ac. > Reported by Reuben Thomas in > > <https://lists.gnu.org/archive/html/bug-gnulib/2021-04/msg0010

Re: texinfo-6.8.90 pretest on mingw

I had reported: > On mingw (the 'w64' flavour, that can be installed with Cygwin 2.9.0) > - the compilation succeeds, > - there is 1 test failure for 'info', > - nearly all of the 'ii--test' tests fail, > - no test failures in tp/tests/. Now, in texinfo-6.8.91, all tests pass (in the same

Re: texinfo-6.8.90 pretest on mingw

Gavin Smith wrote: > On Sun, Oct 23, 2022 at 11:55:09AM +0100, Gavin Smith wrote: > > There doesn't appear to be a similar option for 'grep'. However, > > since it is just the one test, we can easily work around the problem > > by taking the '$' out - the test in question would still work

Re: texindex awk syntax error

Gavin Smith wrote: > AC_PATH_PROGS_FEATURE_CHECK does the job Nice one; thanks for the lesson. > although it is slightly complicated to use: > > AC_CACHE_CHECK([for awk], [ac_cv_path_TI_AWK], > [AC_PATH_PROGS_FEATURE_CHECK([TI_AWK], [awk gawk mawk nawk], > [[$ac_path_TI_AWK 'function

Re: macOS test failures - LC_ALL / LC_CTYPE / LC_MESSAGES

Gavin Smith wrote: > I fixed this by changing LC_ALL to LC_MESSAGES in gdt, as that was > the only locale category we needed to change. I confirm that it's fixed in 6.8.91. Bruno

Re: texinfo-6.8.90 pretest and BSD make

Gavin Smith wrote: > > Texinfo/Commands.pm: Texinfo/XS/parsetexi/command_data.txt > > $(MKDIR_P) Texinfo > > - $(srcdir)/maintain/regenerate_commands_perl_info.pl < $< > > + $(srcdir)/maintain/regenerate_commands_perl_info.pl < > > $(srcdir)/Texinfo/XS/parsetexi/command_data.txt > > >

Re: Texinfo translation error, texinfo_document domain

Hi Gavin, > > It sounds wrong to expect translators to use TeXinfo syntax for > > non-ASCII characters, for three reasons: > > > > 1) Translator tools support the common (state-free) charset encodings, > >namely UTF-8, ISO-8859-*, and so on. Not TeX with \, not TeXinfo with > >@, not

Re: Texinfo translation error, texinfo_document domain

Hi TeXinfo maintainers, This exchange is from the French translators mailing list: Jean-Charles Malahieude wrote: > Le 28/10/2022 à 19:42, Gavin Smith a écrit : > > In the translations for 'texinfo_document', fr.po: > > > > [...] > > #: tp/Texinfo/Transformations.pm:597 > > msgid " --- The

Re: texindex awk syntax error

Eli Zaretskii wrote: > > On the system that Bruno was testing, "awk" didn't work so "nawk" was > > preferred. > > So maybe we should verify that the "awk": we found satisfies our > needs, and not just rely on the name? Yes, that would be most in line with the Autoconf principles. > E.g., we

Re: texinfo-6.8.90 pretest on other platforms

It compiles fine, and all tests pass, on the following platforms: - various Linux systems (Ubuntu 22.04, Debian 9.1, Debian 11.1, CentOS 8-stream, OpenSUSE Leap 15.2, Manjaro 17), - GNU/Hurd, - OpenBSD 6.5, - Cygwin 2.9.0. Bruno

Re: texinfo-6.8.90 pretest on mingw

Gavin Smith wrote: > I wonder if the 'ii--test' failures are related to ends-of-line too. Yes, they are. > Do any of the scripts produce output when run, e.g. ./ii-0001-test run > from under install-info/tests/? Yes, they produce output. The failure occurs e.g. in ii-0045-test because

Re: texinfo-6.8.90 pretest and BSD make

On NetBSD, with the default 'make' program, the build fails: ../../build-aux/install-sh -c -d Texinfo sed -e 's|[@]USE_EXTERNAL_LIBINTL[@]|no|' -e 's|[@]USE_EXTERNAL_EASTASIANWIDTH[@]|no|' -e 's|[@]USE_EXTERNAL_UNIDECODE[@]|no|' ../../tp/Texinfo/ModulePath.pm.in >Texinfo/ModulePath.pm

Re: texinfo-6.8.90 pretest on Solaris 11.4

I reported: > On Solaris 11.4, the compilation fails: > > gcc -O2 -DHAVE_CONFIG_H -I. -I../../../gnulib/lib -I../.. > -I/export/home/bruno/prefix64/include -Wall -D_REENTRANT -Wno-cast-qual > -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef > -Wno-unused-function

Re: macOS test failures - LC_ALL / LC_CTYPE / LC_MESSAGES

Gavin Smith wrote: > When LC_ALL was restored > (for the tests, this was to "C") this overrode a change to LC_CTYPE > that had taken place elsewhere in the code, in the XS paragraph > formatting module. This broke iterating over UTF-8 strings, leading > to the wrong values being passed to

Re: texinfo-6.8.90 pretest on mingw

Eli Zaretskii wrote: > > with a line ending of , which is why > > grep 't/infodir/file1.info$' > > fails. > > I guess Grep that I have (from MSYS) is more tolerant to Windows-style > CRLF end-of-line format, because it succeeds in that case. Apparently so, yes. I use the 'grep' from Cygwin,

Re: texinfo-6.8.90 pretest on Solaris 11.4

Once the compilation error is fixed, "gmake check" fails: FAIL: tests/ti-helpversion.sh Find attached the log. On this platform, awk is /usr/bin/awk. Not GNU awk. If 'texindex' works only with GNU awk, it ought to be documented in the manual. solaris114-failures.tar.gz Description:

Re: texindex awk syntax error

Gavin Smith wrote: > It is not supposed to only run on GNU awk. In fact, it should prefer > awk to gawk. I prefer not to run texindex with gawk because mawk is > much faster. OK. > Do you have any idea why awk is saying there is a syntax error? > > awk: syntax error near line 1 > awk: bailing

Re: mingw-w64 CR handling

Gavin Smith wrote: > In info.c the file name is printed with a simple printf: > > printf ("%s\n", ref_list[i]->filename); > > We don't deal with line endings or "text mode" at all here - just > printing a string to stdout in the most straightforward way. > > It appears that there is

Re: texinfo-6.8.90 pretest on OpenSolaris

On the OpenSolaris derivates Solaris 11 OmniOS Solaris 11 OpenIndiana (both in 64-bit mode and in 32-bit mode), 1 test fails: FAIL: t/dir-file-sloppily.sh Find attached the log file. When I redirect the output of the command $ginfo --output - FiLe-M to a file, I see that is it empty.

Re: diff wrapper for install-info tests

Gavin Smith wrote: > Could you try a change like the one at the end of this mail? > > If that works, then we can make this change throughout the install-info > test suite. With the attached patch, all ii--test tests pass on mingw. > The test for mingw may need tweaking to include/exclude

Re: texinfo-6.8.90 pretest on Solaris 11.4

On Solaris 11.4, the compilation fails: gcc -O2 -DHAVE_CONFIG_H -I. -I../../../gnulib/lib -I../.. -I/export/home/bruno/prefix64/include -Wall -D_REENTRANT -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function -Wno-unused-parameter

Re: texinfo-6.8.90 pretest on mingw

Eli Zaretskii wrote: > Which version of Perl did you use in this build? It's the perl built for and shipped by Cygwin: $ perl -V Summary of my perl5 (revision 5 version 26 subversion 1) configuration: Platform: osname=cygwin osvers=2.9.0(0.31853)

Re: texinfo-6.8.90 pretest on mingw

Eli Zaretskii wrote: > > - nearly all of the 'ii--test' tests fail, > > This could be due to Diff. I have long ago replaced the MSYS Diff > with the following shell script (and gladly forgot about this issue): > > #! /bin/sh > # diff --- like diff.exe but ignore trailing CR characters >

Re: texinfo-6.8.90 pretest on macOS

On macOS 10.13, with perl v5.28.3, two tests fail: FAIL: test_scripts/layout_formatting_info.sh FAIL: test_scripts/layout_formatting_plaintext.sh Find attached the logs. It looks like the line breaking is different than expected. In case it matters: The Gnulib replacement function 'rpl_wcwidth'

Re: texinfo-6.8.90 pretest on mingw

On mingw (the 'w64' flavour, that can be installed with Cygwin 2.9.0) - the compilation succeeds, - there is 1 test failure for 'info', - nearly all of the 'ii--test' tests fail, - no test failures in tp/tests/. The failing 'info' test is: FAIL: t/where-dir-file.sh Find attached the log

Re: conditional "LIBUNISTRING_COMPILE_UNIWIDTH_WIDTH" was never defined.

tch fixes it. The cause is that texinfo is using the gnulib-tool option --conditional-dependencies, and a couple of days ago I made this option more effective. 2022-01-14 Bruno Haible Avoid error "conditional LIBUNISTRING_COMPILE_... was never defined" when o

Re: texinfo-6.7.90 tarball contains files that "make distclean" erases

Hi Gavin, Jacob, > > > > Also the files MiscXS.c, TestXS.c, XSParagraph.c were included in the > > > > tarball, although "make clean" or "make distclean" deletes them. There > > > > are two possible ways to fix this: > > > > > > I think option B below would be the safer one. We check for xsubpp

Re: texinfo-6.7.90 pretest on Solaris

> >> How come that the 'texindex' script is not executable? The Makefile has > >> built the 'texindex' script like this: > >> > >> Making all in texindex > >> sed -e 's,[@]pkgdatadir[@],/home/haible/prefix-sparc64/share/texinfo,g' > >> -e 's,[@]TI_AWK[@],awk,g' -e 's,[@]PACKAGE[@],texinfo,g'

Re: texinfo-6.7.90 pretest on AIX

> https://alpha.gnu.org/gnu/texinfo/texinfo-6.7.90.tar.xz On AIX 7.1, during "make check", one test fails: Making check in texindex make check-TESTS FAIL: tests/ti-helpversion.sh Let's look at the log file of this test: $ cat tests/ti-helpversion.sh.log + SHELL=/bin/sh + export SHELL

texinfo-6.7.90 tarball contains files that "make distclean" erases

> So, the cause is that an autogenerated and platform-dependent 'texindex' > script was included in the tarball. Removing it from the tarball will fix > the issue. Another way to find this problem is: After unpacking the tarball, $ ./configure && make && make distclean should leave the same

  1   2   >