Bug#694067: Invalid
PDFDocEncoding is a Latin-1 subset or UTF16BE with BOM. LilyPond correctly encodes this since version 2.13.61. Evince is wrong in expecting UTF-8 here according to the pdfmark specification. Neither xpdf nor pdfinfo have a problem. -- David Kastrup -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694067: Additional info:
The file umlaut.ly included in the report is wrongly encoded as Latin-1 instead of UTF-8. Encoding it as UTF-8 (the standard input encoding of LilyPond) leads to the correct PDF which Evince incorrectly still flags erroneous because of trying to interpret the pdfmark strings as as UTF-8 rather than the standard-prescribed PDFDocEncoding (Latin-1) with UTF16BE+BOM fallback. -- David Kastrup -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#428908: ["José Manuel Pérez" <[EMAIL PROTECTED]>] Bug#428908: Problem whit the installation of auctex on testing
Frank Küster <[EMAIL PROTECTED]> writes: > severity 428908 serious > > "Davide G. M. Salvetti" <[EMAIL PROTECTED]> wrote: > >>>From the bug submitter. > >>configure: error: LaTeX not found, aborting! >>You must install LaTeX for preview to work. >> >>so, i decided to purge all about emacs and install firts : >> >>apt-get install texlive. > > I think we've already discussed this in some older bugreport. I repeat > from memory: > > - auctex needs to Depend on a package which provides the latex format, > i.e. texlive-latex-base, hence the severity serious > > - preview-latex-style only depends on texlive-base, which makes sense > because you can also use it with plain TeX or ConTeXt. But I suggest > that it should Recommend texlive-latex-base preview-latex-style is not usable with anything but LaTeX. Would be nice if it were, but that's how it is. > - please please drop all references to tetex-*. In particular, > tetex-base is now an empty package which depends on nothing. -- David Kastrup
Bug#428908: ["José Manuel Pérez" <[EMAIL PROTECTED]>] Bug#428908: Problem whit the installation of auctex on testing
Frank Küster <[EMAIL PROTECTED]> writes: > David Kastrup <[EMAIL PROTECTED]> wrote: > >> Frank Küster <[EMAIL PROTECTED]> writes: >> >>> - auctex needs to Depend on a package which provides the latex format, >>> i.e. texlive-latex-base, hence the severity serious >>> >>> - preview-latex-style only depends on texlive-base, which makes sense >>> because you can also use it with plain TeX or ConTeXt. But I suggest >>> that it should Recommend texlive-latex-base >> >> preview-latex-style is not usable with anything but LaTeX. Would be >> nice if it were, but that's how it is. > > Ah, okay. But if preview-latex-style depends on tl-latex-base, It doesn't, really. It makes little enough sense without it, but there is nothing that it would actually load or use. AUCTeX can support either LaTeX, plain TeX, ConTeXt, Texinfo, AMSTeX. For its support of LaTeX, it needs preview-latex-style. So, uh, AUCTeX depends on preview-latex-style iff tl-latex-base is installed. Or something like that. (auctex & tl-latex-base) => preview-latex-style > I think auctex still should get the same depends, because it does > need it itself (and preview.sty might become a preview.tex sister in > the future). AUCTeX can be used not just for LaTeX, though _iff_ you have LaTeX installed, it would be somewhat surprising not to use AUCTeX for it. -- David Kastrup
Bug#428908: ["José Manuel Pérez" <[EMAIL PROTECTED]>] Bug#428908: Problem whit the installation of auctex on testing
Frank Küster <[EMAIL PROTECTED]> writes: > David Kastrup <[EMAIL PROTECTED]> wrote: > >> So, uh, AUCTeX depends on preview-latex-style iff tl-latex-base is >> installed. Or something like that. >> >> (auctex & tl-latex-base) => preview-latex-style > > Which can in practice well expressed by letting preview-latex-style > depend on latex. > >>> I think auctex still should get the same depends, because it does >>> need it itself (and preview.sty might become a preview.tex sister in >>> the future). >> >> AUCTeX can be used not just for LaTeX, though _iff_ you have LaTeX >> installed, it would be somewhat surprising not to use AUCTeX for it. > > Yes, but the Debian auctex package needs latex for installation, because > it reruns "./configure", which fails without latex. Because LaTeX (and other stuff) is used for generating the documentation. But it is probably not a hard requirement for the finished package. -- David Kastrup
Bug#428908: ["José Manuel Pérez" <[EMAIL PROTECTED]>] Bug#428908: Problem whit the installation of auctex on testing
Frank Küster <[EMAIL PROTECTED]> writes: > David Kastrup <[EMAIL PROTECTED]> wrote: > >>> Yes, but the Debian auctex package needs latex for installation, because >>> it reruns "./configure", which fails without latex. >> >> Because LaTeX (and other stuff) is used for generating the >> documentation. But it is probably not a hard requirement for the >> finished package. > > Then a --no-generate-docs option would be nice. The tarball comes with pregenerated docs. If you don't touch their sources, they are not regenerated. One can also, if one really must, pass LATEX=: PDFLATEX=: and similar to configure, and it will then pretend regenerating the docs. -- David Kastrup
Bug#425085: [tex-live] Bug#425085: texlive-doc-en: catalogue entries with dangling links
[EMAIL PROTECTED] (Karl Berry) writes: > Doesn't look straightforward to fix - any ideas? > > We will probably reinstate the Catalogue in TL, and when we do, I guess > we should not just copy the files, but set up some kind of "conversion" > process. Ugh. > > Does MiKTeX contain the Catalogue? If so, are the links properly > transformed? If so, maybe we could just work from that. > > If someone wants to take this up, great. I'll try massaging an Emacs script in my free time. This sounds like a reasonably doable job, and since it is a one-time exercise, my choice of scripting engine should not really matter. Could mean that at one time I would need write access to TeXlive, though. -- David Kastrup -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425085: [tex-live] Bug#425085: texlive-doc-en: catalogue entries with dangling links
[EMAIL PROTECTED] (Karl Berry) writes: > since it is a one-time exercise, > > I don't understand. Any massaging process will be rerun a zillion > times, since of course the Catalogue is being updated constantly. (Not > that I have any objection to Elisp myself.) But it is going to be run by people maintaining TeXlive, not people fetching TeXlive. Similar to ls-R regeneration, I would guess. Could probably be rewritten at some time in Lua, but Lua seems less convenient for in-place text manipulation. And I know I'll be faster with prototyping in Elisp. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425085: [tex-live] Bug#425085: texlive-doc-en: catalogue entries with dangling links
David Kastrup <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Karl Berry) writes: > >> Doesn't look straightforward to fix - any ideas? >> >> We will probably reinstate the Catalogue in TL, and when we do, I guess >> we should not just copy the files, but set up some kind of "conversion" >> process. Ugh. >> >> Does MiKTeX contain the Catalogue? If so, are the links properly >> transformed? If so, maybe we could just work from that. >> >> If someone wants to take this up, great. > > I'll try massaging an Emacs script in my free time. This sounds like > a reasonably doable job, and since it is a one-time exercise, my > choice of scripting engine should not really matter. Ok, I think I have this more or less finished (though only tested the diagnosis functions so far). It is actually rather instructive to run this over the whole TeXlive tree as both source and target with a single C-u argument (which omits the "fixable" things in the report). We have a freak show of broken links here. I'd recommend that somebody run this over the original catalog, thus making sure that we start with something more or less consistent. Then the "fixing run" in TeXlive should be able to resolve most stuff. Usage: put this file somewhere, use M-x byte-compile-file RET fixtexlive.el RET M-x load-file RET fixtexlive.elc RET M-x fix-html-tree RET /usr/TeX/2007/texmf-doc/doc/english/catalogue RET /usr/TeX/2007 RET (or, of course, your subversion tree equivalents). This will report all problems and purported changes. Using C-u M-x fix-html-tree RET ... will just report the problems. And C-u C-u M-x fix-html-tree RET ... will report the problems and _perform_ the changes. I am no longer sure whether that is the best idea. Maybe one should just output a diff. But then you can just let Emacs do the work, let subversion generate the diff, revert to the last checked-in version, edit the diff and apply it. fixtexlive.el Description: application/emacs-lisp -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Bug#446476: [tex-live] [texhax] Bug#446476: Bug#446476: Bug#446476: natbib cannot handle utf8
Sebastian Rahtz <[EMAIL PROTECTED]> writes: > Personally, I gave up on all this ucs.sty/inputenc stuff last year > and switched to xelatex instead. Now it's native Unicode joy every > time, instead of endless problems once you stray beyond the latin > world Does it do PassiveTeX? -- David Kastrup -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481371: [tex-live] mktexlsr should exclude more VCS dirs
Norbert Preining <[EMAIL PROTECTED]> writes:
> We got the following suggestion concerning mktexlsr:
>
> On Do, 15 Mai 2008, Michael Schutte wrote:
>> /usr/bin/mktexlsr currently excludes .svn directories only. I???d like to
>> maintain parts of my ~/texmf tree in Git, which badly clutters ls-R at
>> the moment. The attached patch supports the most usual DVCSes; it would
>> be great if you could review and probably apply it for the next
>> revision.
>>
>> Cheers,
>> --
>> Michael Schutte <[EMAIL PROTECTED]>
>
>> --- a/mktexlsr 2008-04-22 19:37:01.0 +0200
>> +++ b/mktexlsr 2008-05-15 17:08:59.0 +0200
>> @@ -154,10 +154,11 @@
>># We do not try to support colons in directory names.
>>#
>>echo "./:" >>"$db_file_tmp"
>> + VCSDIRS='\(\.svn\|\.git\|\.bzr\|\.hg\|_darcs\)'
>>(cd "$TEXMFLS_R" && \ls -LRa 2>/dev/null) \
>> - | sed -e '/^$/{n;s%^\./%%;s%^%./%;}; /^\.$/d; /^\.\.$/d; /^\.svn$/d;' \
>> + | sed -e '/^$/{n;s%^\./%%;s%^%./%;}; /^\.$/d; /^\.\.$/d;
>> /^'$VCSDIRS'$/d;' \
>> -e '/^[\.\/]*lsR[0-9]*\.tmp:*$/d' \
>> - | sed -e '/\.svn.*:$/,/^$/d' \
>> + | sed -e '/'$VCSDIRS'.*:$/,/^$/d' \
>> >>"$db_file_tmp"
>>
>>cat "$db_file_tmp" > "$db_file"
>
>
> THis patch actually looks quite reasonable to me, so what about
> including it in our texlive repository?
>
> Any comments/remarks/objections please?
What about CVS and RCS subdirectories (no initial dot in their name)?
Also it may be more efficient to not have alternatives starting with a
common character, something like
\.\(bzr\|git\|hg\|svn\)\|CVS\|RCS\|_darcs
--
David Kastrup
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458059: [NTG-pdftex] Bug#458059:
Frank Küster <[EMAIL PROTECTED]> writes:
> There is a configuration variable nest_size level, but it doesn't seem
> to help in this case: The attached file gives an error
>
> ! TeX capacity exceeded, sorry [grouping levels=255].
>
> although my texmf.cnf has nest_size=500.
I find it awfully hard to reliably trigger a semantic nest size
overflow. The best I have been able to come up with was
[EMAIL PROTECTED]:~$ tex
This is TeX, Version 3.141592 (Web2C 7.5.6)
**\def\x{\vbox\bgroup x\x}\x
! TeX capacity exceeded, sorry [semantic nest size=500].
\bgroup
\x ->\vbox \bgroup
x\x
<*> \def\x{\vbox\bgroup x\x}\x
No pages of output.
Transcript written on texput.log.
But this only barely triggers, since 500 is less than 2*255, the
grouping level limit. And I can't at the moment think of a way to get
more than two semantic nests per grouping level.
Can anybody think of a semantic nest without grouping apart from
unrestricted hmode (which I use above)?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458059: [NTG-pdftex] Bug#458059:
Taco Hoekwater <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>> Frank Küster <[EMAIL PROTECTED]> writes:
>>
>>> There is a configuration variable nest_size level, but it doesn't seem
>>> to help in this case: The attached file gives an error
>>>
>>> ! TeX capacity exceeded, sorry [grouping levels=255].
>>>
>>> although my texmf.cnf has nest_size=500.
>>
>> I find it awfully hard to reliably trigger a semantic nest size
>> overflow. The best I have been able to come up with was
>>
>> Can anybody think of a semantic nest without grouping apart from
>> unrestricted hmode (which I use above)?
>
> The example that was attached by Frank (or Stijn?) does just fine.
But that's not without grouping as far as I can see, so it is not really
different from what I had. If you put a line
{
before the problem, then it will again bomb out with a grouping error
instead. At least that is what I think I see when looking at the error
message and context.
In short: I don't see how one can trigger semantic nest errors when the
semantic nest limit is more than twice the grouping limit (which it
isn't right now). I might still be overlooking something, though.
Already the single possibility to switch between semantic lists without
a corresponding group switch that I can think of (basically
\leavevmode/\par) escaped Knuth in the TeXbook Appendix D. As a result,
the next edition (if we will see it) will have a quite simpler version
of \removevboxes in it than previous ones.
But there may be some rationale behind the current semantic nest size
limit...
> [EMAIL PROTECTED] ...nd \z@ [EMAIL PROTECTED]@@p \boldmath {{b^c}}
> }
> \makebm #1$->\bm {#1}
> $
> [EMAIL PROTECTED] ... {\hbox {#1$\displaystyle [EMAIL PROTECTED] #2$
> }}{\hbox
> {#1$\textstyle \m...
>
> [EMAIL PROTECTED]@@p ...fmmode [EMAIL PROTECTED] #1{#2}{#2}{#2}{#2}
> \else \bfseries #1#2\fi
> [EMAIL PROTECTED] ...nd \z@ [EMAIL PROTECTED]@@p \boldmath {{b^c}}
> }
> \makebm #1$->\bm {#1}
> $
> [EMAIL PROTECTED] ... {\hbox {#1$\displaystyle [EMAIL PROTECTED] #2$
> }}{\hbox
> {#1$\textstyle \m...
>
> [EMAIL PROTECTED]@@p ...fmmode [EMAIL PROTECTED] #1{#2}{#2}{#2}{#2}
> \else \bfseries #1#2\fi
> [EMAIL PROTECTED] ...30049 [EMAIL PROTECTED]@@p \boldmath {{b^c}}
> }
> \makebm #1$->\bm {#1}
> $
> \makelabel ...h {\makebm }\normalfont \bfseries #1
> :}
> \sbox #1#2->\setbox #1\hbox [EMAIL PROTECTED] #2
>[EMAIL PROTECTED] }
> [EMAIL PROTECTED] ...i \fi \sbox [EMAIL PROTECTED] {\makelabel {#1}}
> \global \setbox
> [EMAIL PROTECTED] \...
> l.11 \item[$a^{b^c}$]
> $a^{b^c}$
> ! ==> Fatal error occurred, no output PDF file produced!
--
David Kastrup
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#483731: auctex: postinst failed with emacs-snapshot
Sven Joachim <[EMAIL PROTECTED]> writes: > On 2008-06-02 14:24 +0200, Sven Joachim wrote: > >> On 2008-05-31 15:31 +0200, Sebastian P. Luque wrote: >> >>> I did a `check-parens' on tthe offending file >>> (/usr/share/emacs/site-lisp/auctex/tex-jp.el), which indicated that >>> there is at least one unmatched parenthesis. >> >> Actually, that is not the problem. Rather, emacs-snapshot misreads this >> file as UTF-8 instead of iso-2022-jp. > > Which is a regression in this snapshot that has just been fixed in the > Emacs trunk. > >> I don't know which changes in Emacs are responsible for that (the >> problem did not exist in the 20080510-1 snapshot and earlier versions), >> but in any case tex-jp.el should have a coding cookie, e.g. a first line >> that reads like this: >> >> ;;; -*- coding: iso-2022-jp -*- >> >> Adding this at the beginning of tex-jp.el lets emacs-snapshot configure >> itself successfully. > > I still think that adding the cookie would be best, but that's for > upstream to decide; the Debian bug can probably be closed anyway. The upstream AUCTeX maintainer (well, I) wants to leave things as they are. Next time this problem triggers, we will be able to report it timely to Emacs upstream. One problem with coding cookies is that the files are also compiled when using XEmacs, and XEmacs partly has different coding names. So a change here could also break things, while merely pasting over a transitory problem. -- David Kastrup -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441595: [Dev-luatex] building luatex with external lua headers/libs
Taco Hoekwater <[EMAIL PROTECTED]> writes: > Norbert Preining wrote: >> Hi Taco! >> >> First of all, thanks for the rework of the zzlib stuff, now it is easy >> to compile luatex with external zlib libs/headers. >> >> Now there is the wish that we compile luatex also with the external lua >> (5.1) libs/headers. > > You can't, and shouldn't. I am not using a not-quite stock lua51. I bet you _are_... -- David Kastrup -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#746005: Message from upstream
Hi, I'm probably the LilyPond developer most involved with GUILE 2.0 migration and I'm pretty annoyed at the current situation and the manner GUILE developers deal with it. Several months back even Richard Stallman intervened and stressed the importance of getting LilyPond moved to GUILE 2.0. Like several times before, GUILE developers promised to get actively involved only to drop out of the discussion once they were provided with instructions, an up-to-date branch/source to work with and current problem descriptions. The current situation is such that 2.0 garbage collection API is unreliable (see GUILE bug report http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19883> with the basic recommendation "don't try using the smob mark mechanism any more" but no real resolution). It may well be that the current workarounds implemented in LilyPond may be successful. However, this is hard to test since there is _no_ released version of GUILE 2.0 where the encoding problems in issues http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20200> (workaround in LilyPond codebase, will get fixed in 2.0.12) and http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20209> (workaround in LilyPond codebase, will get fixed in 2.0.12) and http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20302> (unfixed so far, and since this usage _was_ already a workaround for previous problems and reverting back to the old code does not work either, this remains a roadblock) have been addressed. With the ongoing trail of suggested workarounds failing for new reasons, there has not been the possibility to actually get to the stage where it would be possible to do any serious testing with GUILE 2.0, like running the regtest suite. So it is very likely that there are more surprises lurking (particularly regarding garbage collection) once the GUILE developers get around to fixing the pending bugs in the bytevector stream port implementation. Or get around to actually following on their promises and try working on figuring out why the old workarounds for getting GUILE reproduce a byte stream stopped working. But since they decided to break them anyway in GUILE 2.1 it would likely make more sense to make the "please use bytevectors for this from now on" approach actually work and then let LilyPond switch to this mechanism once there is a working version of GUILE released with them. By the way: I was of the impression that TeXmacs did not work with GUILE 2.0 either. Has this changed? Is it also going to get removed from Debian? -- David Kastrup -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#317610: Intention to NMU
Luk Claes <[EMAIL PROTECTED]> writes: > Attached the patch for the version I intend to upload. Please > respond if you don't want this NMU to happen, if you are working > yourself on a patch or if you think that the attached patch won't > work. I think that it would be more important to get out a working version of AUCTeX >= 11.80 since that already includes preview-latex (upstream version is at 11.82 at the moment). As it stands, this NMU is bound to be obsoleted by the next AUCTeX release, which would be more important to focus on. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337447: Bug#317610: Intention to NMU
OHURA Makoto <[EMAIL PROTECTED]> writes: > From: Luk Claes <[EMAIL PROTECTED]> > Subject: Bug#317610: Intention to NMU > Date: Sun, 01 Jan 2006 02:14:31 +0100 >> > I think that it would be more important to get out a working version >> > of AUCTeX >= 11.80 since that already includes preview-latex (upstream >> > version is at 11.82 at the moment). >> > >> > As it stands, this NMU is bound to be obsoleted by the next >> > AUCTeX release, which would be more important to focus on. >> >> This might be true, though it isn't reflected in the fime that has >> passed since this RC bug is opened... nor is it mentioned over >> there till now... So I propose to see this NMU as a temporary >> solution if that is OK with you? > > Debian AUCTeX maintainer is planning to upload next > release. I was waiting his work. So, I've not uploaded new > preview-latex revision. > > O.K. I'll upload next revision in a few days with your patches > to close RC bug, if he won't upload next release. I presume that the next AUCTeX will have a "provides preview-latex" dependency or something like that (don't know the Debian package system). So it won't matter if there are newer preview-latex packages around. I also don't know whether Davide will model the new AUCTeX dependencies on existing preview-latex dependencies. Davide has a bit of a history of being overworked with regard to releasing AUCTeX: there were several other times where NMUs were looming. So as long as the responsibilities are distributed as they are, and if it is not too much work for you, it might still be worth updating preview-latex's dependencies as it is unclear when AUCTeX will actually get updated, and when this change will make it from unstable to other parties. After all, there is a number of Debian-derived distributions around. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#702871: [Bug-AUCTeX] Bug#702871: Regarding forward and backward search with evince.
can...@free.fr writes: > OK, this is odd - I now tested the version with raise-frame and it works > with gnome-shell 3.4 (Debian/sid) and 3.8 (experimental), as well as the > xfce wm, and it works, without wmctrl. When using a version of auctex with > the odd timestamp calculation when calling evince, this still works, but only > after I somehow switched several times "by hand" between emacs and > evince... (?!) Is your variable focus-follows-mouse set/customized correctly? Emacs can't reliably guess the proper setting. -- David Kastrup -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#715187: Fw: [Markus Redeker ] Bug#715187: auctex: TeX-doc function cannot handle compressed files
Markus Redeker writes: > Date: Thu, 18 Jul 2013 14:48:09 +0200 > From: Tassilo Horn > To: Markus Redeker > Cc: bug-auctex > Subject: Re: [Markus Redeker ] > Bug#715187: auctex: TeX-doc function cannot handle compressed files > > > Markus Redeker writes: > > Hi Markus, > >> I do not know whether that helps you, but on my system there are _two_ >> files 'scrguide.pdf', > > I've found out what I have to do, and now I know what causes the > problem. It's not AUCTeX's fault. Try "texdoc pgfmanual" in a > terminal, it will fail the very same way. > > Texdoc can be configured to unzip zipped files automatically. It then > simply unzips them to /tmp, then calls the viewer, and when the viewer > returns, it deletes the unzipped version from /tmp again. > > Now the problem is that texdoc seems to use `xdg-open' for opening > files. On the one hand, that's a good thing cause xdg-open will fire up > whatever program you've associated with the given file type in KDE or > GNOME or whatever. But on the other hand, xdg-open simply spawns the > appropriate program and then returns immediately. Sounds like a bug to me. Possibly by ill-thought-through design, but when xdg-open is supposed to be a suitable replacement for a viewing application, it can't have different exit/terminal behavior. -- David Kastrup -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658264: Summary:
In order to avoid possible security problems due to separately maintained libpoppler and xpdf libraries, the approach chosen by Debian is to fantasize about the APIs not having seriously diverged and deliver a crashing binary. A proposed patch that would cater for the diverged APIs is rejected because of its size, the size being proportional to and catered to the difference in APIs. Dealing with a less than optimal situation by choosing to deal with an nicer imaginary situation instead and calling "Somebody Else's Problem" (TM) on the results of this discrepancy is not just ridiculous but rather lunatic. A really sad state of affairs. -- David Kastrup -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767324: Error running timer `font-latex-jit-lock-force-redisplay'
"Davide G. M. Salvetti" writes: > tag 767324 + moreinfo > thanks >>>>>> AK == Antti-Juhani Kaijanaho [2014-10-30] > > AK> After a recent upgrade of both auctex and emacs24, I've started to get > random > > AK> Error running timer `font-latex-jit-lock-force-redisplay': > AK> (wrong-number-of-arguments (2 . 2) 3) > > AK> notices when I work with large TeX files. For example, just opening the > AK> test file will trigger the notice. > > Hi, thanks for the report. At the moment I am not able to reproduce it. > Would you please also test it with the prerelease package of 11.88-1 > which you find on people.debian.org in /home/salve/ajk/? > > AK> Package: auctex > AK> Version: 11.87-2 > AK> Severity: normal > > I think severity: minor is more appropriate to this bug; do you agree? It's my experience that these kind of timer error render serious work almost impossible at least when debug-on-error is set. So depending on how frequently this problem triggers for Antti-Juhani, his original choice might not be exaggerated. -- David Kastrup -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#370659: auctex: preinst warning: Debconf passed unknown value
"Davide G. M. Salvetti" <[EMAIL PROTECTED]> writes: > checking for gs... no > checking for GSWIN32C.EXE... no > configure: error: Ghostscript not found! Aborting! > You need Ghostscript in your PATH for preview to work. > configure: error: /bin/sh './configure' failed for preview > --8<---cut here---end--->8--- > > Then I retested the whole thing doing an "apt-get install gs-gpl" before > "apt-get install auctex": > --8<---cut here---start->8--- > [...] > Setting up emacs21 (21.4a-6) ... > emacs-install emacs21 > install/auctex: Setting up for emacs21... done. > update-auctex-elisp[12015]: Further output will appear in: > /tmp/update-auctex-elisp.lqk6669. > [...] > Setting up auctex (11.83-1) ... > install/auctex: Setting up for emacs21... done. > update-auctex-elisp[13515]: Further output will appear in: > /tmp/update-auctex-elisp.Fs12132. > --8<---cut here---end--->8--- > > It seems we need a "Pre-Depends: gs-gpl | gs" (I think this is because > "/usr/bin/gs" is managed through the alternatives mechanism, so that it > does not exist until a Ghostscript providing package has been > configured). > > Can you confirm that installing a Ghostscript providing package will > solve the issue? Since on Debian Ghostscript is not going to be called GSWIN32C.EXE ever, one could override detection by calling ./configure with the additional argument "GS=gs". The test in the configure script is mainly there for prodding Windows users to actually fix their PATH environment variable. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366505: [tex-live] Source and Copyright question concerning cspsfonts
Zdenek Wagner <[EMAIL PROTECTED]> writes:
> On Tue, 9 May 2006, Norbert Preining wrote:
>
>> You are listed in license.eng from the cstex package as authors of the
>> CSfonts. While analyzing the license/source situation of teTeX and TeX
>> live for Debian, we found that the following files:
>> ntimes.sty
>> nhelvet.sty
>> cspsfont.{il2,tex,xl2}
>
> I have found my private copy of cspsfont.doc and now I understand why it
> disappeared. It is written in Czech in 1995 and modified in 1998. I do not
> remember details but now it seems to me that I gave the generated files
> for testing and planned to provide the documentation later and forgot to
> do it. I know that some bugs were fixed in the generated files later so
> distribution of my ancient cspsfont.doc will not be a good idea. I will do
> my utmost to resolve the license problem.
>
>> contain the follwoing statement:
>> -
>> %% The original source files were:
>> %%
>> %% cspsfont.doc (with options: `fonts,IL2')
>> %%
>> %% IMPORTANT NOTICE:
>> %%
>> %% For the copyright see the source file.
>> %%
>> %% You are *not* allowed to modify this file.
>> %%
>> %% You are *not* allowed to distribute this file.
>> %% For distribution of the original source see
>> %% the terms for copying and modification in the file cspsfont.doc.
>> ---
There are several solutions: get the other authors to agree to release
the generated files under a different license. Reimport the changed
edited files into the source file and distribute that (depends on the
agreement of the editor of the changed files, but considering that he
has been in violation of the license, this should probably be easy to
assure), Czech or not. Add a notice that translations would be very
much appreciated.
Stuff like that.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378577: auctex: installation may not ignore everything except emacs21|emacs-snapshot
Frank Küster <[EMAIL PROTECTED]> writes: > Daniel 'NebuchadnezzaR' Dehennin <[EMAIL PROTECTED]> wrote: > >> Package: auctex >> Version: 11.83-2 >> Severity: wishlist >> >> Hello, >> >> The installation and removal scripts may ignore specific targets. [...] > This would have the effect that it would try to configure for > xemacs, too. Personally, I am very much in favor of that, but it's > up to Davide (the AUCTeX maintainer) to decide this. The Debian package setup is such a mess (just try M-x list-load-path-shadows RET) with its separation of .el and .elc files into separate places in the load-path that it seems like a rather imprudent thing to have several versions of a package in load-path. Providing AUCTeX via both XEmacs' Sumo tarball as well as with the Debian package is asking for trouble. The version in the XEmacs Sumo tarball is rather outdated by now (and does not contain preview-latex, for one thing): the person responsible for checking AUCTeX into the XEmacs package CVS has not done so for a long time and it is not clear whether he will do so eventually. The AUCTeX project provides an XEmacs package which can be installed into the XEmacs package tree on its download page: this integrates well with the XEmacs package system. The Debian way of providing packages for both Emacs and XEmacs doesn't. The most drastic and seamless way to integrate AUCTeX for XEmacs would be to "patch" the Sumo package tree when creating its Debian packaging by deleting the AUCTeX tree (which can be done by rm `cat pkginfo/MANIFEST.auctex` in the XEmacs package tree) und unpacking the XEmacs package from the AUCTeX project instead. Not sure this is a good idea. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Bug#324358: preview-latex with emacs-snapshot
That is actually _not_ the future. The future would be AUCTeX-11.81 (well, in a few days we should have 11.82) out which would include preview-latex. I have no idea how the AUCTeX and preview-latex Debian maintainers are planning to deal with it. Personally, I don't think it makes much sense to keep preview-latex unbundled as it is now: that was the reason for bundling the stuff upstream. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341226: auctex: emacs freezes with fly spell chequer activated
Do you have Emacspeak installed? A similar effect has been experienced with outdated Emacspeak versions that come with an ancient and buggy regexp-opt.el library. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340555: [tex-live] Re: XyMTeX in TeX live
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > Karl Berry wrote: >> Regretfully, Dr. Shinsaku unambiguously replied to me that he wishes to >> restrict XyMTeX distribution. So I'll be taking it out of TeX Live for >> next year. > > I'm very sorry to hear that my inquiry resulted in the removal of XyMTeX > from TeXLive. :-( Your inquiry resulted in Dr. Shinsaku's wishes being heeded. That's nothing to be sorry for. It is a pity that such are his wishes, but that certainly is not a fault of yours. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293161: 51preview-latex.el loaded twice -- not
The load report does not have a "done" after the "..." in the first line indicating the loading of 51preview-latex.el since preview-latex.el is loaded nested. The line with the "...done" comes later. So this is a normal output for a single nested load. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#130397: Bug 130397
"Eli Zaretskii" <[EMAIL PROTECTED]> writes: >> Date: Sat, 8 Jan 2005 22:29:21 +0900 >> From: Miles Bader <[EMAIL PROTECTED]> >> Cc: Geoff Kuenning <[EMAIL PROTECTED]>, [EMAIL PROTECTED], >> [EMAIL PROTECTED], [EMAIL PROTECTED], >> Kenichi Handa <[EMAIL PROTECTED]>, [EMAIL PROTECTED], >> [EMAIL PROTECTED], Ken Stevens <[EMAIL PROTECTED]>, >> Stefan Monnier <[EMAIL PROTECTED]> >> >> If ispell wants utf-8, it's easy enough to convert each input line to >> utf-8 and deal with offsets into that in the event of a mispelling; > > Or account for byte offsets by (variable) multibyte lenght of each > character, which Emacs knows. I don't remember for the moment whether > the multibyte length of the UTF-8 encoding can be gotten at by a Lisp > program, but if not, we could add some primitive to do that. Just encode the line to utf-8, find the correct point in the byte string, cut off the line there, convert back and check the length of the string. This works unless you are in the middle of a character. But it would be much saner if our conversion facilities would preserve markers (which they don't do right now): encode to utf-8, place a marker at the right byte offset, undo the conversion. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#130397: Bug 130397
Kenichi Handa <[EMAIL PROTECTED]> writes: > PS. I personally feel it's a waste of time to struggle with > charset matters in ispell that much because emacs-unicode > should not have such a problem. Oh, but in the 5+ years until it gets released, people might still be glad to have a fix. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294798: This is completely normal and expected behavior.
The behavior wanted by the reporter of this "bug" only applies to an "active region". In Emacs-21.3, you never have such a beast unless you have explicitly enabled transient-mark-mode or one of its encompassing modes (pc-selection-mode, delete-selection-mode, cua-mode and probably others). The corresponding zmacs-region-mode (sp?) in XEmacs is on by default, in contrast. Emacs-CVS (what will probably be released as 22.1 according to latest developments) is also available somewhere as a Debian package unless I am mistaken. It has an additional _temporary_ transient-mark-mode which can be enabled using C-u C-x C-x (to make the current region temporarily an "active" one) or C-u C-SPC (to place the mark of what is supposed to become an active region after moving point to the other side), or by using mouse-dragging. In my mind, it is the best-of-all-worlds combination, but then I might be partial. So unless the reporter has been enabling one of those modes including transient-mark-mode (which it would be nice to hear from him), the report is not a bug, but normal and intended behavior for Emacs-21.3. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318114: preview-latex-style: Wrong equation numbers with option auctex
Braun Gabor <[EMAIL PROTECTED]> writes:
> Package: preview-latex-style
> Version: 0.9.1-1
> Severity: normal
> Tags: patch
[...]
> I have reported this bug to preview-latex-style instead of
> preview-latex because I think the bug is in the prauctex.cfg file
> of the former package.
Reporting upstream would have made more sense, since Debian did not
change the default.
> Patch:
>
> --- /usr/share/texmf/tex/latex/preview/prauctex.cfg 2005-04-03
> 15:28:16.0 +0200
> +++ prauctex.cfg 2005-07-13 16:35:25.784731144 +0200
> @@ -57,7 +57,7 @@
> \PreviewMacro*\thanks
> \PreviewMacro*[][#1{}]\caption
> [EMAIL PROTECTED]@[EMAIL PROTECTED]@startsection}{%
> - [EMAIL PROTECTED]
> + [EMAIL PROTECTED]
> \PreviewMacro*\index
> \endinput
> %%
After much thinking about the problem, I came up with the same
solution. Anyway, at least this made me fix the footnote macro (which
was defined uselessly) as a result, so the thinking was not in vain.
The fix will appear with the release of AUCTeX 11.80.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398210: auctex doesn't work with filenames containing spaces
Olivier Schwander <[EMAIL PROTECTED]> writes: > Package: auctex > Version: 11.83-2.1 > Severity: minor > > Hello, > > Latex (and pdflatex) reports an error when trying to compile a file whose > name contains spaces. "Doctor, it hurts when I do this." -- "Don't do this then." > It works fine if the file is given an other name. TeX is not at all comfortable with spaces in file names (and file paths). AUCTeX 11.84 will try to do a better job with those, but it remains to be seen how well it manages to work around TeX's limitations. It is likely that problems will remain, like in Source Specials or other ways of interacting with other programs. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408227: auctex does not compile with actual emacs-snapshot-gtk
Frank Küster <[EMAIL PROTECTED]> writes:
> "Davide G. M. Salvetti" <[EMAIL PROTECTED]> wrote:
>
>> Considering AUCTeX upstream wishes, I'm for the second: I don't think
>> there's much to gain by splitting the packages[*], so I think we should
>> just promote the Recommends to Depends.
>
> I agree.
>
>> Wheter we should add versioned Depends on preview-latex-style, I need to
>> ponder the question. Frank, if you already pondered it (as it looks
>> like to me), please add some more rationale to your points.
>
> Well, actually I assume that we do not really need
> "=$SourceVersion", but just some (>= $version). But this means that
> we have to closely follow upstream's changelog: Is there any change
> to preview.sty that requires the versioned dependency to be bumped?
> On the other hand, if we use $SourceVersion, we're on the safe side
> - and preview-latex-style is a tiny package, so I don't really see a
> downside of forcing its upgrade.
Changes to preview.sty should be upwards-compatible. In order to
facilitate updating preview-latex-style without requiring an update of
AUCTeX, I think ">=$SourceVersion" would be quite safe.
">=$someversion" would require manual maintenance, of course.
preview-latex contains the variable
preview-default-preamble is a variable defined in
`/usr/share/emacs-snapshot/site-lisp/auctex/preview.elc'.
Its value is
("\\RequirePackage["
("," . preview-default-option-list)
"]{preview}[2004/11/05]")
Documentation:
*Specifies default preamble code to add to a LaTeX document.
If the document does not itself load the preview package, that is,
when you use preview on a document not configured for preview, this
list of LaTeX commands is inserted just before \begin{document}.
You can customize this variable.
[back]
This is supposed to specify the required >= version information.
However, I think it is not a sensible idea to let preview-latex-style
fall back behind the version of auctex by default: people updating
auctex will expect to get the whole bundle (and all fixes) with a
current version. So ">= $SourceVersion" seems like a better idea than
">= $bareminimum".
An alternative is to compile the auctex package with a
"--without-texmf-dir" configure setting in which case the
preview-latex-style package would be independent of auctex, since
auctex would then use its own private version.
--
David Kastrup
Bug#420394: [tex-live] How to handle interdependencies of collections
[EMAIL PROTECTED] (Karl Berry) writes: > That sounds reasonable in general, if you want to make a general > statement. Other possibilities would be to move acronym to > humanities, or bigfoot to latexextra. I don't have strong feelings > about it. Where is bigfoot now? It consists of "perpage.sty", a way of numbering footnotes and other counters per page (also called upon by some other packages), suffix.sty for defining command variants, and bigfoot.sty which makes \verb work in footnotes, provides for nicer para-style footnotes with sane page size calculations, fixes the color stack across footnotes and fixes some really awful TeX and LaTeX page break decisions in connection with footnotes broken across lines. None of that is specific to humanities at all. bigfoot also has the required power to sensibly work with several layers of footnotes in different styles (which _is_ interesting to humanities), but that it _can_ do the really contorted stuff right does not change that there are few other options to actually get the _simple_ stuff with footnotes right. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389249: patch
"Davide G. M. Salvetti" <[EMAIL PROTECTED]> writes: > tags 389249 + confirmed pending > thanks > >>>>>> fant == Frank Küster [2006-9-25] > > fant> A Mennucc <[EMAIL PROTECTED]> wrote: > >>> hi this patch fixes the problem > > fant> Thank you for the patch. I think Davide should apply it, but IMO the > fant> proper solution would be to ask upstream for a noninteractive version of > fant> TeX-submit-bugreport. What do you think, Davide? > > That I will add the patch to next upload and that you are right about a > noninteractive version of TeX-submit-bugreport. If you have some time, > can you ask for it in auctex-devel? (David, are you reading this > message? What do you think?) Well, I don't really see the need. A report such as the one required by Debian in a non-interactive way is quite uncommon, and it is quite easy to persuade reporter-submit-bug-report to not ask questions if I am not mistaken. Since many other packages use the reporter package for reporting bugs, it would seem much more sensible to provide a function in the general Debian files that will craft a non-interactive bug report from a command happens to use reporter-submit-bug-report. I have not followed the discussion: what was the problem encountered here? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
