glossaries: Two abbreviations with identical short form deduplicated
filed https://sourceforge.net/p/clisp/feature-requests/59/
It is LISP, which uses a 32-bit unsigned integer to count seconds since 1900-01-01. date -u -d 1900-01-01 +%s -2208988800 2**32 - 2208988800 => 2085978496 date -u -d @2085978496 2036-02-07T06:28:16 UTC
xindy fails to build after 2036-02-07
Well, the log basically tells us: base.lsp is compiled to base.fas When locref.lsp shall be compiled, the Lisp system doesn't detect that this happened. It reopens base.fas (or base.lsp?) for writing and thus overwrites the result of the previous compile. Afterwards it complains that the module base is not available. Of course, because it was just overwritten. This is obviously a problem with CLISP on the compiling system. What I don't understand: The issue report explicitly tells that the building...
xindy fails to build after 2036-02-07
I should have mentioned: other files besides xindy.in have had fixes: markup.lsp, makeindex.xdy, make-inp-rules.pl, documentation files, and no doubt others. (And unfortunately our TLpatches/ subdirectory has not been kept perfectly up to date, so don't rely on it.)
tex live patches for xindy
Xindy compiled with an older version of libncurses
I think what needs to be done is to add a module no-page-ranges.xdy which holds (define-location-class "arabic-page-numbers" ("arabic-numbers") :min-range-length 100000) (define-location-class "roman-page-numbers" ("roman-numbers-lowercase") :min-range-length 100000) (define-location-class "Roman-page-numbers" ("roman-numbers-uppercase") :min-range-length 100000) (define-location-class "alpha-page-numbers" ("alpha") :min-range-length 100000) (define-location-class "Alpha-page-numbers" ("ALPHA") :min-range-length...
I think what needs to be done is to add a module no-page-ranges.xdy which holds (define-location-class "arabic-page-numbers" ("arabic-numbers") :min-range-length 100000) and then in texindy: - unshift (@modules, 'page-ranges') unless $no_ranges; + unshift (@modules, ($no_ranges ? 'no-page-ranges' : 'page-ranges')); This module would probably also help to solve https://github.com/jschrod/xindy.ctan/issues/3
I'd say "Symbols" is the most common header used for this (see also TLC2)
Is this related to https://github.com/jschrod/xindy.ctan/issues/4?
The only minor nuisance is that the markup is doubled, i.e. \EmpIn{\EmpIn{1}--\EmpIn{3}}, A way around this is (markup-range :sep "\EmpIn{--}" :attr "EmpIn") which yields \EmpIn{1}\EmpIn{--}\EmpIn{3}. I've pondered about removing the inner markup when there is a range, but this requires markup-range of the given attr to be defined, which might break old definitions.
This can be closed. LyX sets up everything automatically.
This can be closed. Texindy works out of the box with LyX.
Joachim, after another 9 years (and more than 15 years after I filed this report!) I finally sat down and got my own hands dirty. The attached patch implements the :attr option to markup-range and thus fixes the problem reported here via (markup-range :open "\EmpIn{" :close "}" :sep "--" :attr "EmpIn") The only minor nuisance is that the markup is doubled, i.e. \EmpIn{\EmpIn{1}--\EmpIn{3}}, but apart from being slightly ugly, this is only a problem for toggling macros such as \emph. I'd be very happy...
I am withdrawing this. Proper language -> xindy mapping will be implemented in LyX itself instead.
PR at https://github.com/jschrod/xindy.ctan/pull/6
Note that \see[also] entries are not linked either with their target with makeindex/hyperref, so this patch gets both on par.
xindy dataloss with hyperref (\hyperindexformat)
Cannot map memory to address
Sorry, but this project is not involved with the creation of Ubuntu packages. My recommendation is to install TeX-Live 2019, xindy comes with it. As I cannot help here, I'll close this ticket.
Cannot map memory to address
I just tried your MWE in directory .../äbc/test/ Ubuntu 18.04, texlive 2018, and runs fine. For texindy -V got: xindy release: 2.5.1 texindy script version: 1.13 xindy script version: 1.18 xindy kernel version: 3.0 CLISP version 2.49.92 (2018-02-18) (built on bulldog [127.0.0.1]) architecture: X86_64 and was able to run, without complain, in that directory: pdflatex test.tex texindy test.idx pdflatex test.tex and got test.pdf.
I just tried your MWE in directory .../äbc/test/ Ubuntu 18.04 and runs fine. For texindy -V got: xindy release: 2.5.1 texindy script version: 1.13 xindy script version: 1.18 xindy kernel version: 3.0 CLISP version 2.49.92 (2018-02-18) (built on bulldog [127.0.0.1]) architecture: X86_64 and was able to run, without complain, in that directory: pdflatex test.tex texindy test.idx pdflatex test.tex and got test.pdf.
Is there any news on this? The bug semms still to exist in the current version: $ xindy -V xindy release: 2.5.1 xindy script version: 1.18 xindy kernel version: 3.0 Here’s an MWE showing the problem in Test A and B. While in A the ref on p. 2 is dropped in B als page refs are missing in the index. Two possible workarounds are to either not use rages at all (Test C) or to add an (unknown) page attribute for the second range (Test D) \documentclass{article} \usepackage[xindy]{imakeidx} \makeindex[options...
Is there any news on this? The bug semms still to exist in the current version: $ xindy -V xindy release: 2.5.1 xindy script version: 1.18 xindy kernel version: 3.0 Here’s an MWE showing the problem: \documentclass{article} \usepackage[xindy]{imakeidx} \makeindex[options = -C utf8] \usepackage{lipsum} \begin{document} Test A \index{Test A|(} \index{Test A|)} \index{Test A|(} \newpage Test A \index{Test A|)} \newpage Test B \index{Test B|(} \newpage Test B \index{Test B|)} \index{Test B|(} \index{Test...
Is there any news on this? The bug semms still to exist in the current version: $ xindy -V xindy release: 2.5.1 xindy script version: 1.18 xindy kernel version: 3.0
I see … thanks for the detailt answer! :-)
This issue is caused by a deficiency in CLISP, the Common Lisp (CL) implementation that we use as a base. It is not solvable by any change in xindy. CLISP is all but abandoned, no new release since 2010. While there has been some work on porting xindy to a different CL system, this has not been followed through to be a part of a future release. (Please note that there are no stand-alone releases of xindy since quite some years since nobody was interested in them; any changes are released as part...
One year later and it still exists … any news, please?
Hi, ist there any news about this bug? It seems like it still exists in version 2.5.1 unfortunatly.
Broken latin.xdy with GNU grep
Add Support for MSYS
œ ignored
Add support for other common lisp implementations
The `-I omega` option makes `tex2xindy` fail to execute
xindy 2.5.0 script fails when passed a single module
Add kpathsea support or similar
Error when using texindy within paths containing diacritics/umlauts
There are two spanisch sort orders, "spanish-modern" and "spanish-traditional". These...
error when used, glossaries with xindy and the Spanish language in texlive windows
error when used, glossaries with xindy and the Spanish language in texlive windows
Error with texindy and -C utf8
texindy man page now explains explicitely that it must not be used with XeLaTeX and...
Prepare xindy.pl for inclusion in miktex
MikTeX support, as proposed by Peter Breitenlohner, has been added to xindy 2.5 that...
Prepare xindy.pl for inclusion in miktex