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:
> > ../gnulib/lib/libgnu.a(l
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 exist
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
>
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 @-comman
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]
w
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 s
identified the 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/
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 envi
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 properly
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 f
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
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
> >
>
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 ISO-
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 Detai
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 coul
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
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
diff's
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
../../
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 -Wno-unused-par
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 wcwidth.
Eli Zaretskii wrote:
> > > A possible fix is to replace
> > > grep 't/infodir/file1.info$'
> > > with
> > > tr -d '\r' | grep 't/infodir/file1.info$'
> > > Then the test passes.
> > >
> >
> > Yes but I'd rather not complicate the code to deal with s.
>
> Would it be possible to use 't/infodi
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, nam
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: applicat
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
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
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.
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 Min
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 -Wno-float-conver
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)
archname=x86_64-cygwin-threads-m
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
>
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'
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 fi
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
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
> >> 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' -e
> 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
+
> 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 tarb
> https://alpha.gnu.org/gnu/texinfo/texinfo-6.7.90.tar.xz
A VPATH build on Solaris 10, with Solaris 'make', fails during "make check":
Making check in texindex
make check-TESTS
FAIL: tests/ti-helpversion.sh
Why is that? Because the 'texindex' script is not executable.
How come that the 'texind
Hans-Bernhard Bröker wrote:
> there's still gnulib and its autoconfigury
> potentially getting in between the two.
It's unlikely that gnulib is relevant in this case, because on the
platforms we are discussing, it does not have an effect on the definition
of strncat [1].
Bruno
[1] https://www.gn
Eli Zaretskii wrote:
> > > One other issue is that GCC 8 flags many uses of strncat in
> > > install-info.c as unsafe:
> > >
> > > install-info.c: In function 'split_entry':
> > > install-info.c:1624:17: warning: 'strncat' specified bound 2 equals
> > > source length [-Wstringop-overflo
Eli Zaretskii wrote:
> One other issue is that GCC 8 flags many uses of strncat in
> install-info.c as unsafe:
>
> install-info.c: In function 'split_entry':
> install-info.c:1624:17: warning: 'strncat' specified bound 2 equals
> source length [-Wstringop-overflow=]
>
Hi Gavin,
> > Different systems have different terminal emulators, and accordingly
> > also different wcwidth functions.
>
> Without knowing anything about the terminal emulators in question, it
> seems to me likely that there would be several terminal emulators with
> different behaviour on t
Hi Gavin,
> I wondered if there has been any change since this report:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2008-08/msg00209.html
>
> The issue is that on Solaris 10 and Solaris 11, wcwidth returns 2
> instead of 1 for some characters, for example, opening double quote “.
>
> Some
Hi Gavin,
> > FAIL: test_scripts/nested_formats_texi_nested_formats.sh
> >
> >
> > ../../../tp/tests/run_parser_all.sh[361]: 27268 Segmentation Fault(coredump)
> > F: nested_formats//out_parser/texi_nested_formats/nested_formats.2
> >
> >
find it better to
execute a test when possible rather than to skip it.
Patch attached. With it, all tests in this directory pass.
Bruno
>From 4f8f09747d1664a9a61f7dcbfcddc6882ef401fd Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Sun, 20 Jan 2019 13:37:54 +0100
Subject: [PATCH] Fix test failures on HP-UX.
I wrote:
> On Mac OS X 10.5 (both in 32-bit and 64-bit mode):
>
> - Build error
> no fallback module for Texinfo::Parser at ../../tp/Texinfo/XSLoader.pm line
> 242.
> BEGIN failed--compilation aborted at /loader/0x8427c4/Texinfo/Parser.pm line
> 454.
> Compilation failed in require at ../../tp/T
Hi Gavin,
> I have made a change to make it fall back to the pure Perl module if
> the XS parser module couldn't be loaded.
Thanks. I confirm the problem is fixed in texinfo-6.5.91.
Bruno
I wrote:
> On a Solaris 10 machine (with GNU libiconv installed), the build
> fails:
>
> "../../../../../tp/Texinfo/XS/parsetexi/input.c", line 113: warning: no
> explicit type given
> "../../../../../tp/Texinfo/XS/parsetexi/input.c", line 113: syntax error
> before or at: iconv_from_latin1
Thi
Hi Gavin,
> I've taken that call to isatty out.
Thanks. In texinfo-6.5.91, now, the tests no longer hang.
There are two test failures:
FAIL: ii-0041-test
FAIL: ii-0050-test
The log for ii-0041-test contains this:
+ findprog zdiff
+ zdiff ../../../install-info/tests/ii-0041-expected-dir-file.g
I wrote:
> On GNU/Hurd 0.9:
> Build fails with "/usr/bin/ld: cannot find -lperl".
The issue is fixed in texinfo-6.5.91.
Bruno
Hi Gavin,
> However, on CentOS it appears to be in a different package.
>
> https://centos.pkgs.org/7/centos-x86_64/perl-Data-Dumper-2.145-3.el7.x86_64.rpm.html
>
> So it looks like we would need to check for that particular module
> being available.
In 6.5.91, the error message comes upfront f
Hi Gavin,
> > But the build fails:
>
> > /usr/bin/ld: cannot find -lperl
>
> Thanks for testing it. I suspect that it is not necessary for -lperl
> to be passed (except maybe on Microsoft Windows). In
> tp/Texinfo/XS/Makefile.am passing -lperl was conditional but under
> tp/Texinfo/XS/parsetexi/
I wrote:
> On OpenBSD 6.3
> - "awk: syntax error at source line 173 source file ../../texindex/jrtangle"
This error is still present in texinfo-6.5.91.
> - all tests fail!
But the tests now pass.
Bruno
Gavin Smith wrote:
> It uses the output of "perl -V:cc" as $CC because the perl interpreter
> may have been built with a different compiler...
> It is possible to override the C compiler given by Perl by setting
> PERL_EXT_CC when configure is run. There are also PERL_EXT_CFLAGS,
> PERL_EXT_CPPFLAG
> In spite of the comment in the code, the 'iconv'
> gnulib is already supposed to be in use.
Indeed, both the files
gnulib/m4/gnulib-cache.m4
tp/Texinfo/XS/gnulib/m4/gnulib-cache.m4
show that the gnulib module 'iconv' is already in use.
> I am not sure that gnulib actually does take care of
Gavin Smith wrote:
> I suspect TEXINFO_XS_PARSER was set in the environment here.
Yes, I set this environment variable (as you suggested in the announcement).
Bruno
> The tests are not supposed to hang even if the
> program being tested does.
The process hierarchy (from top to bottom) is:
gmake check
gmake check-am
gmake check-TESTS
/bin/sh -c set +e; bases='t/file.sh.log t/file-node.sh.log
t/file-nodes.sh.log t/file-node-with-dot.sh.log t/file-index
Gavin Smith wrote:
> On 1/4/19, Bruno Haible wrote:
> > On OpenBSD 6.3
> > - "awk: syntax error at source line 173 source file
> > ../../texindex/jrtangle"
> > - all tests fail!
> >
> > Logs attached.
> >
>
> Thanks for testing this
On
- CentOS 5.8
- CentOS 6.9
the build and tests complete fine.
On a Solaris 10 machine (with GNU libiconv installed), the build
fails:
"../../../../../tp/Texinfo/XS/parsetexi/input.c", line 113: warning: no
explicit type given
"../../../../../tp/Texinfo/XS/parsetexi/input.c", line 113: syntax error before
or at: iconv_from_latin1
Looks like the 'iconv_t' t
On Mac OS X 10.5 (both in 32-bit and 64-bit mode):
- Build error
no fallback module for Texinfo::Parser at ../../tp/Texinfo/XSLoader.pm line 242.
BEGIN failed--compilation aborted at /loader/0x8427c4/Texinfo/Parser.pm line
454.
Compilation failed in require at ../../tp/Texinfo/Report.pm line 45.
On AIX 7.1, there are two problems:
1) Link errors:
xlc -g -L/home/haible/prefix32/lib -o ginfo dir.o display.o dribble.o
echo-area.o filesys.o footnotes.o indices.o info-utils.o info.o infodoc.o
infokey.o infomap.o infopath.o m-x.o man.o nodemenu.o nodes.o search.o
session.o signals.o
On HP-UX 11.31 ia64 (both 32-bit and 64-bit mode):
- The build succeeds.
- The test execution hangs during execution of info/t/malformed-split.sh .
On OpenBSD 6.3
- "awk: syntax error at source line 173 source file ../../texindex/jrtangle"
- all tests fail!
Logs attached.
openbsd63-logs.tar.gz
Description: application/compressed-tar
On GNU/Hurd 0.9:
Build fails with "/usr/bin/ld: cannot find -lperl".
Logs attached.
hurd09-logs.tar.gz
Description: application/compressed-tar
On CentOS 7.3.1611:
- Build fails: "Can't locate Data/Dumper.pm"
- All tests fail
Logs attached.
centos73-logs.tar.gz
Description: application/compressed-tar
On Ubuntu 16.04, with package libperl5.22 installed but
package libperl-dev *not* installed:
configure succeeds, printing
checking Perl configuration value ccflags... -D_REENTRANT -D_GNU_SOURCE
-DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_B
Hi Gavin,
> I'll make this change and upload the new file.
Here are more changes in the same spirit. And a few doc locations are
outdated; I could find the new location instead.
2017-12-11 Bruno Haible
* util/htmlxref.cnf: Use https for sourceware.org, puszcza.gn
Hi Gavin,
> The URL comes from the htmlxref.cnf file, under util/ in the Texinfo
> distribution and installed as /usr/share/texinfo/htmlxref.cnf or
> similar. I guess that the following change is needed:
>
> Index: htmlxref.cnf
> ===
Hi,
The internet is moving from http:// URLs to https:// for a while already.
Therefore in HTML documentation generated from texinfo sources, I'd like to
have https:// URLs instead of http:// URLs where possible.
In gnulib I have this piece of texinfo input:
@ref{Options,,Changing Automake's Be
As a workaround, until the next gettext release, I would suggest that
- you continue to use gettextize
- but additionally you run the command
gnulib-tool --copy-file m4/intlmacosx.m4 gnulib/m4/intlmacosx.m4
Bruno
Gavin Smith wrote:
> I ran gettextize again, but it didn't install the extra files:
>
> $ gettextize -f --po-dir=po --po-dir=po_document
> Copying file ABOUT-NLS
> Copying file build-aux/config.rpath
> Not copying intl/ directory.
> Copying file po/Makefile.in.in
> Copying file po/Makevars.templ
Gavin Smith wrote:
> Originally reported here:
> http://lists.gnu.org/archive/html/bug-texinfo/2017-07/msg00026.html
Looking at the gnulib-cache.m4 and gnulib-comp.m4 from said package:
* gettext.m4 does NOT come from gnulib.
* You are using gnulib module 'gettext-h', not 'gettext'. (Which is
Hi Eli,
> > Similarly, in version 6.3 with TERM=xterm, in KDE konsole, when I try
> >
> > M-x set-variable RET mouse RET normal-tracking RET
> >
> > it has no effect: Even after this operation, the mouse wheel scrolls.
>
> In both versions you mentioned, the effect of setting the 'mouse'
>
Hi Gavin,
Thanks for having turned off the mouse mode by default in 6.1.
The new default mode fits well with all possible habits:
scroll through cursor key movements, scroll through mouse whell,
AND allow marking a region with mouse-left.
Thanks also for having documented the trick with Shift-mou
Hi Eli,
> Doesn't xterm offer a way of invoking the selection by mouse through
> its menus, i.e. not by clicking on the text area of the xterm window?
xterm (or KDE's konsole in my case) offers a menu action "Copy", but first
the user has to mark a region on the screen - which is precisely what I
Hi,
Occasionally I need to copy&paste the rendered output of a GNU manual
into a text file or mail. The easiest way to do this is to use the
'info' reader with TERM=vt100 or TERM=vt220. With the usual TERM=xterm
setting it does *not* work because info then intercepts the mouse events.
Could this
Eli Zaretskii wrote:
> The situation I have in mind is this:
>
> . you have a program FOO in /usr/local/bin
>
> . you have a manual for that program in /usr/local/share/info
>
> . you also have an old manual for a previous version of FOO in
>/opt/gnu/share/info, but no corresponding binar
Eli Zaretskii wrote:
> > This is precisely what I'm asking to be fixed
>
> Fix how? By explicitly searching both PATH and INFOPATH?
It can be fixed by the approach that I explained through pseudo-code and
of which you said that "it will probably work". [1]
Bruno
[1] https://lists.gnu.org/archi
Eli Zaretskii wrote:
> Left-overs from previous installations can easily break that assumption.
This is precisely what I'm asking to be fixed, because ...
> IOW, this will work reliably only if "someone" (a person) is carefully
> managing her installations, making sure there's only one instance o
Eli Zaretskii wrote:
> still asking Info for the manual of FOO version X.Y is not
> possible, if all the versions of FOO have the same entries in their
> 'dir' files.
This is not a particularly important use-case. Those people who
want to use specific versions can install them in different directo
Eli Zaretskii wrote:
> it's a flaw in the basic design of the Info system: it doesn't
> cope well, to say the least, with several versions of the same manual
> that are accessible from the same Info session.
OK, now where to put the improvement/fix?
Inside 'install-info', it's too early to detect
Eli Zaretskii wrote:
> > Apparently 'info' has used the information found in the 'dir' file of
> > $dir1 (namely the reference to node "Invoking Automake") while using
> > the .info file from $dir2.
>
> Actually, all 'dir' files are concatenated into a single DIR node, and
> only then used as a wh
Hi,
You would think that concatenating INFOPATH values will produce results
that are at least as good as the results from the individual constituents?
This is what I thought. But it is wrong!
How to reproduce:
0) $ info --version
info (GNU texinfo) 4.13
1) Install a copy of Automake 1.11.2
LC_ALL=$l
grep '[^A-Z]' > /dev/null ; then echo $l; fi; done
et_EE
et_EE.iso885915
et_EE.utf8
tk_TM
/packages/gnu/bin/grep-2.7: unbalanced [
Here's a fix:
2011-05-28 Bruno Haible
texi2dvi: Enforce C locale when passing range expression to egrep.
* util/tex
Hi Karl,
When @var occurs inside @code or @file, the italic or slanted font change
extends until the end of @code or @file. This is a bug because it's not
desired, and in the INFO output it's correct.
How to reproduce:
- Save this file:
bug.texi =
Karl Berry wrote:
> I don't see how anything can make this paragraph look decent except
> either allowing line breaks within the url or rewriting. Just a few
> more words before the url and it comes out ok.
Thank you for investigating. I agree that nothing can make this paragraph
look decent. But
An update on this one:
When I define the macro through
@macro texnl{}
@end macro
and invoke it through
@texnl
then it eats up all text until the next newline, like @c.
When I define the macro through
@macro texnl
@end macro
and invoke it through
@texnl
then it eats up all spaces immed
Hello Karl,
> For TeX, only:
>
> Markus Kuhn's UTF-8 and Unicode FAQ: @h...@penalty9000@hfilneg
> @url{http://www.cl.cam.ac.uk/~mgk25/unicode.html}
Perfect!! Many thanks. I've put this into a macro, like this:
@iftex
@macro texnl
@h...@penalty9000@hfilneg
@end macro
@end iftex
@ifnottex
@ma
Hi Karl,
Using texinfo.tex from texinfo-4.13 (version 2008-04-18.10).
My .texi file contains this paragraph:
Markus Kuhn's UTF-8 and Unicode FAQ:
@url{http://www.cl.cam.ac.uk/~mgk25/unicode.html}
The URL cannot be broken; this is fine. But it has the effect that TeX
will render the paragrap
Hi Karl,
I'm using texinfo.tex from texinfo-4.13 (labeled version 2008-04-18.10).
In my .texi source file I have this paragraph:
This is a more low-level API. The word break property is a property defined
in Unicode Standard Annex #29, section ``Word Boundaries'', see
@url{http://www.unic
Hi,
I'm using makeinfo-4.13, and define a macro that should take no arguments
and should produce an empty expansion. The texinfo doc says:
If a macro needs no parameters, you can define it either with an empty
list (`...@macro foo {}') or with no braces at all (`...@macro foo').
When I def
Hi,
Using texinfo-4.13.
While "makeinfo --macro-expand" produces a good .texi output,
"makeinfo --html --macro-expand" does not: Its output is lacking the node
names in all @node lines. When texi2html is then run on the output, it leads
to lots of "*** Undefined node" errors.
How to reproduce:
e default search
path of the TeX distribution".
That's a bug in texi2dvi, IMO. Indeed, the attached patch fixes the problem.
For texinfo, this is only half of the required work. The other half should be
to add a unit test against this bug.
For automake, the workaround is simple: Add
Hi,
After installing texinfo-4.13: texi2pdf pretends that it is texi2dvi.
$ texi2pdf --version | head -n 1
texi2dvi (GNU Texinfo 4.13) 1.135
Likewise, "texi2pdf --help" outputs the help of texi2dvi.
Bruno
variant Sections, with no
Front-Cover Text, and with no Back-Cover Texts.
A copy of the license is included in @ref{GNU FDL}.
@end copying
@end ifinfo
@comment %**end of summary and copyright
@comment %**start of title and copyright
@titlepage
@title GNU libunistring, version
@author Bruno Haible
Hi,
The attached texinfo input file looks superficially correct, but is rejected by
makeinfo:
$ makeinfo --version
makeinfo (GNU texinfo) 4.13
...
$ makeinfo foo.texi
/tmp//foo.texi:34: `Unicode' has no Up field (perhaps incorrect sectioning?).
makeinfo: Removing output file `/tmp/libunistring.
Hi Karl,
On 2005-03-07, I reported to bug-texinfo [1]:
> In makeinfo-4.8, in info mode, a @noindent command is ignored after a
> @smallexample.
and you replied:
> Thanks for the report, I will see what I can do.
The bug is still present in texinfo-4.13, and is still damaging the 'info'
Patrice Dumas wrote:
> ... have cross manual references from other manuals to work
> reproducibly and use file name that correspond as much as possible with
> node names.
Yes, I understand that it is unwelcome to change the mapping from node name
to HTML file name, because hyperlinks coming from
de 'index' indeed gets generated into a
file 'inde_0078.html', and all hyperlinks are correct.
Bruno
2008-11-20 Bruno Haible <[EMAIL PROTECTED]>
Fix collision of filename 'index.html' used for two different purposes.
* makeinfo/html.c (nodename_to
101 - 200 of 227 matches
Mail list logo
