On Fri, Nov 01, 2024 at 03:45:43PM +0200, Eli Zaretskii wrote:
> So we now encourage not to use @documentencoding at all if it's UTF-8?
Indeed.
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#g_t_0040documentencoding
"In the default case, the input and output document encoding a
On Fri, Nov 01, 2024 at 02:03:13PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 01 Nov 2024 08:42:50 + (UTC)
> > Cc: bug-texinfo@gnu.org
> > From: Werner LEMBERG
> >
> > > Shouldn't you use @documentencoding if you include UTF-8 encoded
> > > characters verbatim? (I have no idea if that affect
On Tue, Oct 29, 2024 at 03:21:48PM +, Werner LEMBERG wrote:
>
> Folks,
>
>
> why are `@anchor` and friends discouraged on an `@item` line? AFAICS,
> the reason for this restriction is not documented in the manual, and
> it seems to work just fine...
Do you have a specific output showing it
On Mon, Oct 28, 2024 at 08:21:01PM +, Gavin Smith wrote:
> I was only opposed to skipping the tests, not to allowing customizing the
> shell. I haven't got an opinion on the use of SHELL as mentioned at
> the referenced message,(*) as I haven't researched the implications of this.
> It seems l
On Sun, Oct 27, 2024 at 11:32:18PM +0100, Bruno Haible via Bug reports for the
GNU Texinfo documentation system wrote:
> Gavin Smith wrote:
> > This appears to be a similar error to
> > that which you reported earlier for Solaris 11 OmniOS for an earlier
> > version of the code, Texinfo pretest 7.
On Sun, Oct 27, 2024 at 04:00:19PM +, Gavin Smith wrote:
> > There is a new dependency for pod2texi and Pod-Simple-Texinfo,
> > Pod::Simple::XHTML.
> >
> > I think that it would be important to have this change in the release,
> > and maybe this could justify a new pretest, after there has bee
On Fri, Oct 25, 2024 at 04:10:55PM +0100, Gavin Smith wrote:
> texi2any will issue more warnings by default
> for unknown web URLs for cross-references in HTML output.
With this change, the Texinfo manual had warnings for manuals in
pod2texi. To avoid this issue, I changed pod2texi to generate @u
On Sat, Oct 26, 2024 at 12:03:19AM +0200, Bruno Haible wrote:
> Would you mind marking them as expected failures?
Why not. I'll let Gavin give his advice too.
> This would have the effect
> that occasional testers like me don't report these failures again, and that
> the CI on mingw does not co
On Fri, Oct 25, 2024 at 10:44:40PM +0200, Bruno Haible via Bug reports for the
GNU Texinfo documentation system wrote:
> On mingw (both 64-bit and 32-bit) there are 6 test suite failures.
> Find attached the log file tp/tests/test-suite.log for 64-bit mingw.
Those errors are expected. The one ab
On Fri, Oct 25, 2024 at 01:36:00PM +0100, Gavin Smith wrote:
> I found that SILENT was reported as missing in one of the check scripts
> under doc/refcard:
>
> make vcheck:
>
> man only 1: SILENT
>
> txivarcheck was changed to ignore this variable in texi2any on
> 2024-04-06 (fdc9653fa8adf13a)
On Mon, Oct 21, 2024 at 03:28:35PM +0100, Gavin Smith wrote:
> For shorter files like default_special_unit_info.csv and
> default_direction_strings.csv it is less clear that it offers a net
> benefit. To be honest, the function of these files is not particularly
> clear to me other than one of the
On Fri, Oct 18, 2024 at 09:49:00PM +0100, Gavin Smith wrote:
> /opt/csw/bin/perl ./../../maintain/generate_code_convert_data.pl \
> < ./main/command_data.c \
> ./../Data/default_css_element_class_styles.csv \
> ./../Data/default_direction_strings.csv \
>
On Fri, Oct 18, 2024 at 08:56:24PM +0100, Gavin Smith wrote:
> > Removing gettext.m4 was a mistake, as far as I can tell.
>
> I've attempted to revert the change although it may not be enough as
> you have made other changes involving gnulib and/or gettext at the
> same time.
>
> Another commit w
On Sat, Oct 19, 2024 at 09:34:49AM +0200, Patrice Dumas wrote:
> Actually, I am also confused by the lack of AC_CONFIG_MACRO_DIR in the
> main directory, as I do not understand how autoreconf/aclocal can
> determine that gnulib autoconf macros come from gnulib/m4.
Found it, there is a
On Fri, Oct 18, 2024 at 10:10:03PM +0100, Gavin Smith wrote:
> tp/Texinfo/XS/gnulib/m4/gettext.m4 was added in commit 2cd1cfc788d207c,
> (Gavin Smith, 2019-03-17), as a result of running gettextize. Some of
> the confusion may come from the fact that gettextize places files in
> gnulib/m4 even tho
On Fri, Oct 18, 2024 at 08:35:11PM +0100, Gavin Smith wrote:
> On Sun, Oct 06, 2024 at 07:45:20PM +0200, Patrice Dumas wrote:
> > Hello,
> >
> > I removed some gettext macros installed by gnulib or gettextize in 2021
> > when updating gnulib (when I updated
On Fri, Oct 18, 2024 at 07:56:14PM +0100, Gavin Smith wrote:
>
> Do you think we should mention get_build_constant in NEWS? Are there
> any other changes for init files that should also be mentioned in
> NEWS?
I think that it is too early to mention changes in the HTML
customization API in NEWS.
On Thu, Oct 17, 2024 at 07:24:26PM +0100, Gavin Smith wrote:
> On Wed, Oct 16, 2024 at 12:50:01AM +0200, Patrice Dumas wrote:
> > On Tue, Oct 15, 2024 at 12:31:07PM +0100, Gavin Smith wrote:
> > > On Mon, Oct 14, 2024 at 11:16:58PM +0200, Patrice Dumas wrote:
> > > >
On Thu, Oct 17, 2024 at 07:24:26PM +0100, Gavin Smith wrote:
> On Wed, Oct 16, 2024 at 12:50:01AM +0200, Patrice Dumas wrote:
> > On Tue, Oct 15, 2024 at 12:31:07PM +0100, Gavin Smith wrote:
> > > On Mon, Oct 14, 2024 at 11:16:58PM +0200, Patrice Dumas wrote:
> > > >
On Thu, Oct 17, 2024 at 01:04:48PM +0100, Gavin Smith wrote:
> Now there are only 3 files installed under DATADIR/texinfo:
>
> texinfo/texindex.awk
> texinfo/htmlxref.cnf
> texinfo/texinfo.dtd
>
> texinfo.dtd is coupled to the exact version of texi2any that is installed
> although texi2any does n
On Tue, Oct 15, 2024 at 12:31:07PM +0100, Gavin Smith wrote:
> On Mon, Oct 14, 2024 at 11:16:58PM +0200, Patrice Dumas wrote:
> > This looks good to me, it is quite simple. Maybe the number of buckets
> > could be set based on the number of sections + nodes + index entries?
>
&
On Tue, Oct 15, 2024 at 09:34:08PM +0100, Gavin Smith wrote:
> On Tue, Oct 15, 2024 at 12:36:59PM +0200, Vitezslav Crhonek wrote:
> > From f9e62115a2ae91e721021f52bdf2c76fe717a5eb Mon Sep 17 00:00:00 2001
> > From: Vitezslav Crhonek
> > Date: Tue, 15 Oct 2024 11:07:06 +0200
> > Subject: [PATCH 3/7
On Tue, Oct 15, 2024 at 10:07:24PM +0100, Gavin Smith wrote:
> On Sun, Oct 06, 2024 at 03:43:17PM +0200, Patrice Dumas wrote:
> > Hello,
> >
> > I did the timings on elisp, glibc and texinfo manuals and I get about
> > * 2 between C only and Perl with TEXINFO_XS_CONV
On Tue, Oct 15, 2024 at 12:36:59PM +0200, Vitezslav Crhonek wrote:
> Hi,
>
> Please review proposed fixes of issues found by static analysis
> of texinfo-7.1 in the attached patch and consider applying them.
>
> @@ -2949,7 +2949,7 @@ DECLARE_INFO_COMMAND (info_menu_sequence,
> static int
> info
On Mon, Oct 14, 2024 at 10:29:30AM +0200, Thérèse Godefroy wrote:
> Hello Arnold, hello all,
>
> Le 14/10/2024 à 05:40, arn...@skeeve.com a écrit :
> > Hello.
> >
> > Your patch, unfortunately, is not correct, as it ends up putting
> > regular text into @code even for non-HTML outputs, so I canno
On Mon, Oct 14, 2024 at 09:21:50PM +0100, Gavin Smith wrote:
> I may as well post what I've been able to come up with. The new
> code is about 150 lines of C, in the file convert/hashmap.c (patch
> below). Probably not perfect but hopefully simple enough to be
> maintainable.
>
> If this approac
On Mon, Oct 14, 2024 at 06:33:21PM +0100, Gavin Smith wrote:
> > If we continue removing the extension, it should be mentioned in the
> > manual in the HTML Xref specification, I think as an exception that
> > other implementations do not need to follow, as it should be mentioned
> > and also becau
On Mon, Oct 14, 2024 at 03:54:32PM +0200, Patrice Dumas wrote:
> This is a pain, but I think that the simplest would be having a call to
> Texinfo::Translations::translate_string replace translate_string in
> tp/Texinfo/XS/main/translations.c, similar to what is done already with
> the
On Mon, Oct 14, 2024 at 12:40:42PM +0100, Gavin Smith wrote:
> Hovever, I remember that there was more dependencies on gettext in XS
> code after the 7.1 release, so this may not be possible. (I'd have to
> go back to old emails to remember the details - it may have been
> for the rarely used "obj
On Sun, Oct 13, 2024 at 03:30:14PM +0100, Gavin Smith wrote:
> We have had memory errors with setenv in XS code before.
Might indeed be related, though the issues were much less severe who
knows what could happen on other platforms.
> I wrote on November 16, 2023 (private mail):
>
> > I found th
On Sun, Oct 13, 2024 at 01:57:24PM +0100, Gavin Smith wrote:
> On Tue, Sep 10, 2024 at 09:10:27AM +0200, Patrice Dumas wrote:
> > On Fri, Sep 06, 2024 at 12:28:48PM +0200, Patrice Dumas wrote:
> > > Hello,
> > >
> > > I propose to set the following in
On Sat, Oct 12, 2024 at 10:36:09PM +0100, Gavin Smith wrote:
>
> I don't like the requirement for the user to replicate everything in
> MATHJAX_CONFIGURATION. I think they should just be able to specify
> settings they want to override or add. Here's sample code for :
>
> Here is a patch to the
On Sat, Oct 12, 2024 at 08:51:08PM +0100, Gavin Smith wrote:
> Here's an attempt at explaining it:
>
> pl_chars is the current column. We want to find the next multiple of 8
> after the current column, assuming a tab is 8 spaces. We add 8 to the
> current column, and then subtract the remainder
Hello,
This is not important, but in the info code, in info/util.c in the
printed_representation function, which returns a pointer to string that
is the printed representation of character (or other logical unit) if it
were printed at a given screen column.
l 226 for tab there is a code that I do
On Fri, Oct 11, 2024 at 08:27:10AM +0300, Eli Zaretskii wrote:
This requires a direct access to the platform, which I have not. I will
add the link to your mail in the CI and somewhere in Texinfo to help a
tester who would want to debug further.
> You can verify that element_command_name is inde
On Fri, Oct 11, 2024 at 04:12:05PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 11 Oct 2024 14:36:24 +0200
> > From: Patrice Dumas
> > Cc: bug-texinfo@gnu.org
> >
> > On Fri, Oct 11, 2024 at 08:27:10AM +0300, Eli Zaretskii wrote:
> >
> > > P.S. Is l
On Sun, Oct 06, 2024 at 09:17:38PM +0300, Eli Zaretskii wrote:
> > https://github.com/gnu-texinfo/ci-check/actions/runs/11203321204/job/31140537432
> > libtool: link: gcc -shared main/.libs/libtexinfoxs_la-build_perl_info.o
> > main/.libs/libtexinfoxs_la-get_perl_info.o
> > main/.libs/libtexinfo
On Thu, Oct 10, 2024 at 07:38:39PM +0100, Gavin Smith wrote:
> On Sun, Aug 25, 2024 at 02:13:07PM +0200, Patrice Dumas wrote:
> > > > This is already possible, it is CHECK_HTMLXREF (which is set to 1 in the
> > > > default case for EPUB as relative pat
On Thu, Oct 10, 2024 at 04:29:21PM +0100, Gavin Smith wrote:
> > I propose in the patch to separate the information set by -1 from the
> > goal_column value, by setting this information in the window->flags
> > separately from the goal_column. This is for two reasons, first I think
> > that using
Hello,
I get this warning:
In file included from ../../info/doc.h:59,
from ../../info/infokey.c:21:
../../info/infokey.c: In function ‘compile’:
../../info/infomap.h:105:29: warning: comparison is always true due to limited
range of data type [-Wtype-limits]
105 | #define KEYMA
Hello,
There are warnings with -Wmissing-field-initializers for info/variables.c
VARIABLE_ALIST info_variables where the where_set field is never
explicitely set. This code is from Gavin, and is by design, as there
is this comment:
/* Note that the 'where_set' field of each element in the array i
Hello,
Here is a patch that I would like to propose, but it could be
controversial so I prefer to ask here first. This is in info code,
currently window->goal_column is set to -1 to mean that the
column to place the cursor in when moving it up is the column it is
currently in.
I propose in the p
On Tue, Oct 08, 2024 at 09:11:00PM +0100, Gavin Smith wrote:
>
> I've committed the change.
>
> One command that removes all untracked header files is:
>
> git status -u | grep '\.h$' | xargs rm
This is somewhat dangerous, though, as it removes .h in out of source
build directories, and if ther
On Tue, Oct 08, 2024 at 08:13:12PM +0100, Gavin Smith wrote:
> It could only be because I switched from the master branch and there
> is something left over from building from the master branch.
ALl the more likely that the gnulib versions of 7.1 and master are
probably substantially different now
On Tue, Oct 08, 2024 at 05:05:59PM +0100, Gavin Smith wrote:
> On Tue, Oct 08, 2024 at 01:46:56AM +0200, Patrice Dumas wrote:
> > Hello,
> >
> > In the info reader, as part of an effort to avoid comparison of signed
> > and unsigned integers, and also to have a cle
Hello,
In the info reader, as part of an effort to avoid comparison of signed
and unsigned integers, and also to have a clearer code, I am considering
setting SEARCH_BINDING start and end offsets to size_t instead of long.
Indeed, this should be a bug if they are negative (although there were
plac
On Sun, Oct 06, 2024 at 09:17:38PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 6 Oct 2024 20:04:20 +0200
> > From: Patrice Dumas
> >
> > In Bruno CI, previously the cygwin32 tests did not really check the XS/C
> > code, as iconv was missing. Now it is installed a
On Sun, Oct 06, 2024 at 07:16:21PM +0100, Gavin Smith wrote:
>
> If it's accepted as part of the Texinfo code base it is the responsibility
> of the Texinfo developers to maintain it, fix reported bugs, keep it
> working with other changes in the code etc., at least if we want to still
> be able t
Hello,
In Bruno CI, previously the cygwin32 tests did not really check the XS/C
code, as iconv was missing. Now it is installed and the XS/C code is
tested. There are many errors of missing symbols when linking,
corresponding to all the symbols that are in libtexinfo.dll.a, as if
libtexinfo.dll.
Hello,
I removed some gettext macros installed by gnulib or gettextize in 2021
when updating gnulib (when I updated the setup of the gnulib po
directories), in this commit (there is a similar one for tp/Texinfo/XS
gnulib):
https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=a46d1f492047615340
On Sat, Oct 05, 2024 at 06:37:45PM +0100, Gavin Smith wrote:
>
> And that is precisely what I DON'T want to happen. I am not willing to
> work on texi2any any more if parts of it start being written in C++.
While I agree that there is no point in rewritting in C++ the existing C
code, I see no p
On Sat, Oct 05, 2024 at 06:00:40PM +0100, Gavin Smith wrote:
> On Sat, Oct 05, 2024 at 02:52:55PM +0200, Patrice Dumas wrote:
> > On Sat, Oct 05, 2024 at 11:00:05AM +0100, Gavin Smith wrote:
> > > I'd also like to know how many more of these commits are coming.
> >
&
On Sun, Oct 06, 2024 at 03:43:17PM +0200, Patrice Dumas wrote:
> > There are also error messages about locales and collation:
> >
> > $ ../teximakehtml ../../../../doc/texinfo.texi
> > BUG: no Perl collation
> > texi2any: warning: collation locale not found: en_US
Hello,
I did the timings on elisp, glibc and texinfo manuals and I get about
* 2 between C only and Perl with TEXINFO_XS_CONVERT=1 and
* 4 between Perl with TEXINFO_XS_CONVERT=1 and Perl with XS for
parser only.
> There are also error messages about locales and collation:
>
> $ ../teximakehtm
On Sun, Oct 06, 2024 at 12:09:45PM +0100, Gavin Smith wrote:
> Does it scale with the size of the input? Perhaps a certain part of
> this 0.07 sec is fixed regardless of the size of the input file. Have
> you tried it with a larger manual like glibc or elisp?
For libc, I get:
1.13s with hashmap
On Sun, Oct 06, 2024 at 02:48:25PM +0200, Patrice Dumas wrote:
> On Sun, Oct 06, 2024 at 02:40:42PM +0200, Patrice Dumas wrote:
> >
> > The @iftex sections are expanded, that's why there are all those errors.
> > They probably do not mess that much the timing, but still
On Sun, Oct 06, 2024 at 02:40:42PM +0200, Patrice Dumas wrote:
>
> The @iftex sections are expanded, that's why there are all those errors.
> They probably do not mess that much the timing, but still this should
> not happen. Strangely I have not seen that when compa
On Sun, Oct 06, 2024 at 12:47:42PM +0100, Gavin Smith wrote:
>
> I've tried it myself although have been unable to run it on anything
> but texinfo.texi for the manuals I tried.
>
> I did not see anything in teximakehtml.c about which converter was used
> so I patched the code in converter_conver
On Sun, Oct 06, 2024 at 12:09:45PM +0100, Gavin Smith wrote:
> On Sun, Oct 06, 2024 at 09:53:22AM +0200, Patrice Dumas wrote:
> > > How much slower would the linear search actually be?
> >
> > It is much slower (if I recall well, it was something like 100 times
> >
On Sat, Oct 05, 2024 at 11:22:06AM -0600, arn...@skeeve.com wrote:
> Hi.
>
> Apologies for the delay in replying, I've been offline for several
> days.
>
> Thank you for the report. I have fixed all the cases in the manual
> and will push it to Git shortly. The HTML manual will be updated
> when
On Sat, Oct 05, 2024 at 06:45:27PM +0100, Gavin Smith wrote:
> On Sat, Oct 05, 2024 at 11:22:06AM -0600, arn...@skeeve.com wrote:
> > IMHO this is really a makeinfo bug (and indeed, the Info file doesn't
> > change after this update), so I'm cc-ing the texinfo folks.
>
> I am not sure what the bug
On Sat, Oct 05, 2024 at 06:25:15PM +0100, Gavin Smith wrote:
> > There are three alternatives:
> > * Perl hashmap directly used from C
> > * linear search in C
> > * C++ hashmap used from C
> >
> > My understanding is that there is no other way than using C++ to have an
> > hash map in C, as was d
On Sat, Oct 05, 2024 at 02:38:14PM +0100, Gavin Smith wrote:
> On Sat, Oct 05, 2024 at 01:57:49PM +0100, Gavin Smith wrote:
> > Here's a change to adjust-translations.pl to do this:
>
> ...
>
> > I will commit this once I have updated the test results.
>
> I've commited a change for this script,
On Sat, Oct 05, 2024 at 11:00:05AM +0100, Gavin Smith wrote:
> I'd also like to know how many more of these commits are coming.
Another thing remaining on my TODO list would be an implementation of
XDG base directory for pure C. Not important at all as it would only be
used in the demonstrator pr
On Sat, Oct 05, 2024 at 11:00:05AM +0100, Gavin Smith wrote:
> I'd also like to know how many more of these commits are coming.
I still have some conflict/rebasing/cherry picking anomalies that may
require one or two small commits.
After that, there are 4 commits that are still pending, correspon
On Sat, Oct 05, 2024 at 11:28:53AM +0100, Gavin Smith wrote:
> I see that this was fixed in commit b0eb920e16320727196c (2024-10-03);
> however the effect of this is that all the translated versions of these
> strings will now be wrong:
>
> - - Variable d\'instance de fr : BBB CCC
> + -- Variable
On Sat, Oct 05, 2024 at 11:12:58AM +0100, Gavin Smith wrote:
> libintl-perl was recently upgraded in the Texinfo sources under
> tp/maintain/lib, to version 1.33, but the README file still says:
>
> We ship this version of libintl-perl to be sure that it is available, and
> also to have a cons
On Thu, Oct 03, 2024 at 09:03:16PM +0100, Gavin Smith wrote:
> Currently, when I run "make" there are a slew of error messages (see below).
I can't reproduce, maybe because of a different Perl?
Maybe a (SV *) cast is needed like
const char *direction_name = SvPVutf8_nolen ((SV *)
On Wed, Oct 02, 2024 at 10:44:16PM +0300, Eli Zaretskii wrote:
> > AFAICT, it changed from a single hyphen to 2 hyphens in or before
> > Texinfo 4.8.
>
> Looks like it's this discussion:
>
> https://lists.gnu.org/archive/html/bug-texinfo/2004-02/msg00021.html
>
> and this ChangeLog entry:
>
>
On Wed, Oct 02, 2024 at 07:06:36PM +0100, Gavin Smith wrote:
> I saw this line had been added to NEWS:
>
> . Info:
> . Output a single hyphen at the start of a definition line
>
> This change was in commit 3ee7ac39a8 (dated 2024-07-06, applied 2024-09-29).
>
> The effect of this change is to h
On Sun, Sep 29, 2024 at 05:18:58PM +0300, Eli Zaretskii wrote:
> Why do I suddenly receive from texinfo-comm...@gnu.org a very long
> series of commits from June and July? I've received about 400 mails
> like that already since noon, and it doesn't show any signs of
> stopping.
That are commits t
On Sat, Sep 28, 2024 at 01:54:12PM +0100, Gavin Smith wrote:
> New:
>
> ‘./’
> (the current directory)
>
> ‘leading input file path directory’
> If there is a leading directory and it is not the current
> directory. For example, if the input file is
>
On Thu, Sep 26, 2024 at 10:15:13PM +0100, Gavin Smith wrote:
> > My understanding is that if you want to install on non-standard
> > locations and want to have this non-standard location being searched for
> > before other directories, then you should put first in XDG_DATA_DIRS (or
> > XDG_CONFIG_D
On Thu, Sep 26, 2024 at 07:54:37PM +0200, Patrice Dumas wrote:
> I actually think that using @nodedescription/@nodedescriptionblock is a
> good idea, as it is well suited for meta description (after
> @documentdescription).
Done in:
https://git.savannah.gnu.org/cgit/texinfo.git/c
On Thu, Sep 26, 2024 at 12:01:48PM -0400, Benjamin Kalish wrote:
> 1. Use the value from @node or @nodedescription as appropriate instead of
> content from sectioning commands. Are there instances where this
> substitution wouldn't work? No author is going to need raw formatters in
> node names, an
On Wed, Sep 25, 2024 at 06:54:12PM +0100, Gavin Smith wrote:
> I understand the idea of files in datadir not being edited, although
> I am still not really sure what the purpose of XDG_DATA_DIRS is (in
> general, not just as it relates to Texinfo). According to the XDG
> Specification, this is /us
On Wed, Sep 25, 2024 at 07:43:10PM -0400, Benjamin Kalish wrote:
> Thanks. I can see it both ways, but still lean towards it being a bug.
> Headings in HTML can contain HTML and I don't think the user has any reason
> to expect that the content of a heading would end up anywhere else. If it
> were
On Mon, Sep 23, 2024 at 06:35:37PM +0100, Gavin Smith wrote:
>
> I don't know if TEXINFO_LANGUAGE_DIRECTORIES is necessary, but if so
> the name is confusing, as you would think it is something to do with
> human languages like English or French, not the "Texinfo language".
The variable is necess
On Sun, Sep 22, 2024 at 05:27:34PM -0400, Benjamin Kalish wrote:
> It looks like the problem occurs only with the use of raw HTML, directly
> (as in the minimal example here), or indirectly through a macro (as I first
> encountered it):
I can reproduce with your example (in inline_in_chap.texi fil
On Sun, Sep 22, 2024 at 01:25:11PM +0100, Gavin Smith wrote:
> It would be better not to have rounded corners at all, as with the
> old output "cartouche-borders.png".
The new relative border indeed looks wrong but the previous output was
not very good either.
> Alternatively, using an absolute v
On Sat, Sep 21, 2024 at 05:54:15PM -0400, Ken Brown wrote:
> On 9/21/2024 8:07 AM, Gavin Smith wrote:
> > On Sat, Sep 21, 2024 at 12:10:33PM +0200, Patrice Dumas wrote:
> > > This platform does not test the native Windows Info reader, it is the
> > > cygwin info reader
On Sat, Sep 21, 2024 at 02:29:13PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 21 Sep 2024 12:44:38 +0200
> > From: Patrice Dumas
> >
> I didn't have time to build anything after Texinfo 7.1 (neither 7.1.1
> nor the current release/7.1 branch). In 7.1, the
> spl
Hello,
The CI for the master branch for FreeBSD shows errors related to in
document translations in the XS/C code. These errors seem to trigger
some kind of memory corruption, with an errno code that is not supposed
to be issued by setenv 'Bad address' and those errors seem to propagate
across pr
?
On Fri, Sep 20, 2024 at 06:56:03PM +0200, Patrice Dumas wrote:
> Hello,
>
> I am looking at mingw (on cygwin) GNU Texinfo 7.1 tests failures using
> Bruno CI
> https://github.com/gnu-texinfo/ci-check
>
> formatting_cpp_lines
> with a diff in results
> -accentêd:7: wa
On Fri, Sep 20, 2024 at 10:05:57PM +0300, Eli Zaretskii wrote:
> > The shell is not MSYS, it is:
> > shell: C:\cygwin\bin\bash.exe -eo pipefail -o igncr '{0}'
>
> Using the Cygwin tools to build MinGW ports is an uncharted territory
> for me: I never did that. MSYS was created (as a fork of Cygwi
On Sat, Sep 21, 2024 at 10:57:33AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 21 Sep 2024 00:32:43 +0200
> > From: Patrice Dumas
> >
> > On Fri, Sep 20, 2024 at 08:14:33PM +0200, Patrice Dumas wrote:
> > > On Fri, Sep 20, 2024 at 08:42:18PM +0300, Eli Zaretskii
On Sat, Sep 21, 2024 at 10:32:07AM +0300, Eli Zaretskii wrote:
> > Date: Fri, 20 Sep 2024 23:43:16 +0200
> > From: Patrice Dumas
> > Cc: bug-texinfo@gnu.org
> >
> > On Fri, Sep 20, 2024 at 10:21:01PM +0300, Eli Zaretskii wrote:
> > > > Date: Fri, 20 Sep
On Sat, Sep 21, 2024 at 10:53:55AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 21 Sep 2024 00:16:45 +0200
> > From: Patrice Dumas
> >
> > On Fri, Sep 20, 2024 at 11:00:22PM +0100, Gavin Smith wrote:
> > > On Fri, Sep 20, 2024 at 11:43:16PM +0200, Patrice Dumas wr
On Fri, Sep 20, 2024 at 09:45:09PM +0100, Gavin Smith wrote:
> On Thu, Aug 29, 2024 at 09:11:20AM +0200, Patrice Dumas wrote:
> > I do not think that this is the right way to look at this. To me the
> > logic is that we search both in "config" locations, as it is wher
On Fri, Sep 20, 2024 at 08:14:33PM +0200, Patrice Dumas wrote:
> On Fri, Sep 20, 2024 at 08:42:18PM +0300, Eli Zaretskii wrote:
> > And if not, does the
> > Strawberry Perl's bin/ subdirectory appear on your PATH?
>
> I think so, there is:
> Path: C:\cygwin\bin
>
On Fri, Sep 20, 2024 at 11:00:22PM +0100, Gavin Smith wrote:
> On Fri, Sep 20, 2024 at 11:43:16PM +0200, Patrice Dumas wrote:
> > On Fri, Sep 20, 2024 at 10:21:01PM +0300, Eli Zaretskii wrote:
> > > > Date: Fri, 20 Sep 2024 20:43:45 +0200
> > > > From: Patrice
On Fri, Sep 20, 2024 at 10:21:01PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 20 Sep 2024 20:43:45 +0200
> > From: Patrice Dumas
> >
> > Many info tests on cygwin-32 fail (release 7.1 branch). I attach the
> > info tests log, I can provide more information on
On Fri, Sep 20, 2024 at 10:53:12PM +0200, Patrice Dumas wrote:
> If we use the current date, the dcterms:modified, in theory, should
> never be set in the past of the current date for the same publication
> identifier. The current specification
> https://www.w3.org/TR/epub-33/#sec-m
On Fri, Sep 20, 2024 at 09:09:33PM +0100, Gavin Smith wrote:
>
> SOURCE_DATE_EPOCH would give the user a chance to override the value
> and is a standard variable that users might be familiar with, unlike
> any other variable or option that we might invent.
To me SOURCE_DATE_EPOCH is for reproduc
On Fri, Sep 20, 2024 at 10:21:01PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 20 Sep 2024 20:43:45 +0200
> > From: Patrice Dumas
> >
> That's most probably the side effect of using Cygwin tools again: the
> native port of info cannot run many of the tests because the
Hello,
Many info tests on cygwin-32 fail (release 7.1 branch). I attach the
info tests log, I can provide more information on configure output, and
some other logs if needed.
--
Pat
=
GNU Texinfo 7.1.1-20240920: info/test-suite.log
On Fri, Sep 20, 2024 at 08:54:09PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 20 Sep 2024 19:29:14 +0200
> > From: Patrice Dumas
> >
> > Is this issue also happening with native builds? Would it be safe to
> > always remove carriage returns?
>
> What do y
On Fri, Sep 20, 2024 at 08:42:18PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 20 Sep 2024 19:14:46 +0200
> > From: Patrice Dumas
> >
> > Hello,
> >
> > I would like to have more tests for mingw (on cygwin) using Bruno CI
> > https://github.com/gnu-tex
Hello,
An issue with XS modules configure for mingw (on cygwin) using Bruno CI
https://github.com/gnu-texinfo/ci-check
In tp/Texinfo/XS/configure.ac, we use perl -V:var to get information on
Perl configuration for the var. The perl output in that case has ^M
carriage returns at end of lines. Th
Hello,
I would like to have more tests for mingw (on cygwin) using Bruno CI
https://github.com/gnu-texinfo/ci-check
However, 'prove' is not found by configure, by
AC_CHECK_PROGS([PROVE], [prove], [])
while perl is found with
AC_PATH_PROG([PERL], [perl])
I checked the binary zip provided for stra
1 - 100 of 1106 matches
Mail list logo
