Re: Utilizing Emacs and AUCTeX for Large-Scale LaTeX Academic Monograph Typesetting.
Hongyi Zhao writes: > Dear AUCTeX Team, > > I am writing to you with regards to a query that I have currently. I > am considering using Emacs in combination with AUCTeX as a tool for > typesetting a large-scale academic monograph in LaTeX. This project > will likely contain a substantial number of mathematical equations, > images, tables, and bibliographic references. Also, a high degree of > customization might be required for the document, covering areas such > as defining own formats, styles, etc. > > Given that Emacs combined with AUCTeX is widely touted as a potent > editing platform, and while it is clear that it is capable of managing > intricate editing jobs, I am interested in understanding whether it > excels particularly in handling large-scale monograph typesetting and, > hence, would be a fitting choice for my use case. > > Here are the specific questions I would like to ask: > > 1. Can Emacs and AUCTeX offer stable, quick, and efficient performance > when dealing with large-scale documents? No problems with large-scale documents. > 2. Do they support numerous LaTeX packages for greater customization options? That question is gibberish. Try to be more specific. > 3. How is the input of vast amounts of mathematical equations, images, > tables, etc. handled? Again, it isn't clear what you are trying to ask with regard to "vast amounts". The amounts don't change anything. You might want to look at preview-latex (the Preview menu) for more convenient in-document handling and overview with a focus on mathematical content. Load a large document and take a look. > 4. What are the recommended strategies for managing bibliographic > references? Using BibTeX? > 5. Are there any particular advantages or potential drawbacks of Emacs > and AUCTeX that should be taken into account for such large-scale > typesetting? It works, and will handle everything that is entered using different editors/environments in case other collaborateurs would prefer other workflows. > Given the wealth of experience, knowledge, and the regard I hold for > the AUCTeX team, I am eagerly looking forward to your knowledgeable > input on this matter. Of course, I would also be more than happy to > set up a meeting at your convenience to discuss this in detail, if > need be. It is not clear what you want to be asking here. If you aim for ongoing personal support in your endeavors, you might want to consider making a formal offer/request for it and allocate appropriate resources. If you are looking for binding guarantees of suitability, I don't see that we can offer them. That the tools are generally usable for the kind of purposes you want to be using them for is not really at doubt. LaTeX has been used for larger pieces of work than you probably envision. Perhaps the main selling point of AUCTeX is that it does not import or specially treat LaTeX files. You can at any point of time, including simultaneously with different collaborateurs, use a different editing system without any loss of information. You don't need to commit to AUCTeX at all and can decide at any point of time to stop or restart using it without having to change the text corpus you are working on, and it is the individual choice of the people working on the corpus whether they prefer using AUCTeX or a different editing environment. Particularly when the body of work contains significant amounts of math, I'd really recommend trying out the preview-latex system (in AUCTeX's "Preview" menu) before deciding for a different editing environment. But it is a choice everybody entering texts can make for themselves without affecting the choices of others. On the side of the LaTeX support, for a large piece of work there may be a point in consulting with somebody well-versed with LaTeX. Sometimes you may find people with the required amount of competence and/or willingness and ability to acquire them among the kind of grad student working on your project. If not, and you have particular desires for layout/workflow/formatting, there may be a point in finding external support for providing and supporting document classes implementing your particular layout. All the best -- David Kastrup
Re: AUCTeX not honouring the local variable for correlate I/O.
Cesar Rabak writes: > I've a document which in the last lines has Local Variables, the second one > is TeX-source-correlate-mode: t, however, when I open the file and compile > it in a new Emacs session the synctex file is not generated, and in the > Command->TeXing Options->Correlate I/O it is cleared. > > So I have to manually enable this feature every time I open the file. > > I'm running GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-08-02 > and AUCTeX version 13.2.3 (from 2023-12-07). > > Is there something I doing incorrectly? You don't include an example, so how are we supposed to tell? -- David Kastrup
bug#66485: 13.2.1; preview-scale-function should be safe for numberp
Arash Esbati writes: > David Kastrup writes: > >> The question is whether this should be enough of a worry to stop such >> settings to take effect automatically. I am not saying that it should, >> just that this is the metric for making this change. > > Thanks for the clarification, now I see what you mean. In this case, I > think Philipp made a good suggestion to use another predicate like: > > (lambda (x) (and (numberp x) (> x 0) (<= x 10)) > > WDYT? Possibly (lambda (x) (and (numberp x) (<= 0.1 x 10))) ? -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#66485: 13.2.1; preview-scale-function should be safe for numberp
Arash Esbati writes: > David Kastrup writes: > >> Arash Esbati writes: >> >>> I think this is a reasonable change. What do others think? >> >> Iam not sure what happens if you put, say, 1 in there. > > Maybe I'm missing the point, but how is this related to allowing > `preview-scale-function' as a file local variable? It is allowed as a file variable. The setting is about when Emacs will ask back before setting a variable to a possibly malicious value when using Emacs as the application to view/edit externally provided files from unverified sources. And you can respond to that prompt by stating that a particular setting should always be allowed in future. > One could customize the variable globally to 1 and the result > would be the same? Sure, but that is not an attack vector. If someone has access to customize, worrying about safety is already over. > BTW, I don't know either what happens if one puts 1 there. The question is whether this should be enough of a worry to stop such settings to take effect automatically. I am not saying that it should, just that this is the metric for making this change. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#66485: 13.2.1; preview-scale-function should be safe for numberp
Arash Esbati writes: > "Philipp G. Haselwarter" writes: > >> ;;;###autoload >> (put 'preview-scale-function 'safe-local-variable 'numberp) >> >> should be added in preview.el after the definition of >> preview-scale-function. > > I think this is a reasonable change. What do others think? Iam not sure what happens if you put, say, 1 in there. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#65628: Document preview fails with long filenames
John Holman writes:
> Hi. I'm not sure that the problem was captured in the log below created
> by preview-report-bug so a few more details first:
>
> Running auctex on windows 11 with MiKTeX
>
> Test file contents (but most files containing maths seem to trigger the
> problem)
>
> \documentclass{article}
> \begin{document}
>
> \(x=y\)
>
> \end{document}
>
> Document preview works when the filename has no more than 22 characters,
> e.g. test.tex, but fails with message "Ghostscript filter: No bounding box"
> when the filename has more, e.g. 01234567890123456789012.tex. However
> buffer preview always works.
>
> When document preview fails the maths sections are replaced with the
> roadworks signs indefinitely. The 01234567890123456789012.prv directory is
> created
> containing a temp folder containing a preview.dsc file but no png
> images. The rungs.exe and mgs.exe processes don't exit until killed manually
> or emacs is closed.
>
> The contents of the *.. output* buffer are then
>
> Running `Preview-LaTeX' on `012345678901234546789012' with ``pdflatex
> -file-line-error
>
> "\nonstopmode\nofiles\PassOptionsToPackage{active,tightpage,auctex}{preview}\AtBeginDocument{\ifx\ifPreview\undefined\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}[2004/11/05]\fi}"
> "\input" "\detokenize{" "012345678901234546789012.tex" "}"''
Probably exceeding a total command line length of 256 characters or some
similar Windows restriction. I also seem to remember that some Windows
file system or API limited the length of absolute filenames you could
access even when only using relative filenames, so the length of the
directory path you are in might also play a part here.
--
David Kastrup
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: how to add a new pdf viewer?
Uwe Brauer writes: >>>> "TH" == Tassilo Horn writes: > >> Does /snap/evince/current/usr/libexec/evinced actually work or exit >> with error? And if so, is the evince demon accessible via DBUS? You >> can check using d-feet. > > > Oh, sh > I am an idiot: > > /snap/evince/current/usr/libexec/evinced > /snap/evince/current/usr/libexec/evinced: > /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found > (required by /snap/evince/current/usr/libexec/evinced) > > > End of game. My Ubuntu version is simply too old. Huh. I thought the idea behind snap packages was that they packaged their library dependencies or something in order not to rely on the host system details as much. Maybe there is a particular way in which one needs to call the binary or set up its environment? -- David Kastrup
Re: The auto-completion behavior of parenthesis.
Hongyi Zhao writes:
> On Thu, Jul 27, 2023 at 10:05 PM Arash Esbati wrote:
>>
>> Hongyi Zhao writes:
>>
>> > In AUCTeX mode, I noticed that `{', and `[' can be completed
>> > automatically, while `(' doesn't. Any tips for this behavior?
>>
>> AUCTeX provides a variable called `LaTeX-electric-left-right-brace' for
>> this purpose which is initally disabled:
>>
>> ,[ C-h v LaTeX-electric-left-right-brace RET ]
>> | LaTeX-electric-left-right-brace is a variable defined in ‘latex.el’.
>> |
>> | Its value is t
>> | Original value was nil
>> |
>> | If non-nil, insert right brace with suitable macro after typing left brace.
>> |
>> | You can customize this variable.
>> |
>> `
>>
>> See also here[1] for more information.
>
> Very strange. I've enabled this option, as shown below:
>
> [ C-h v LaTeX-electric-left-right-brace RET ]
> LaTeX-electric-left-right-brace is a variable defined in ‘latex.el’.
>
> Its value is t
> Original value was nil
>
> If non-nil, insert right brace with suitable macro after typing left brace.
>
> You can customize this variable.
>
> [back]
>
> But I still cannot observe the corresponding completion of the
> innermost `(' as shown in the attached screenshot.
This is a terminology misunderstanding.
() parentheses
[] brackets
{} braces
You want completion for parentheses, not braces. Parentheses are not
syntactic entities in LaTeX (pstricks notwithstanding). You may want to
look at the generic key sequence:
M-( runs the command insert-parentheses (found in global-map), which
is an interactive byte-compiled Lisp function in ‘lisp.el’.
It is bound to M-(.
(insert-parentheses ARG)
Enclose following ARG sexps in parentheses.
Leave point after open-paren.
A negative ARG encloses the preceding ARG sexps instead.
No argument is equivalent to zero: just insert ‘()’ and leave point between.
If ‘parens-require-spaces’ is non-nil, this command also inserts a space
before and after, depending on the surrounding characters.
If region is active, insert enclosing characters at region boundaries.
This command assumes point is not in a string or comment.
--
David Kastrup
Re: set the latex binaries, locally to different texlive distributions
Uwe Brauer writes: > Hi > > > It so happens that a share a (mercurial) repository with latex files > with a colleague. This colleague has only texlive 2019 installed why I > upgraded to 2023 (but I still have 2019 installed. I install different > texlive distributions in different directories and then set appropriate > links. Now the nicematrix.sty gives some problems. > > Somebody on the german tex group provided me with a clever if, so if the > file is compiled with texlive 2019 a certain style file is loaded and if > 2023 another style file is loaded. > > Now I have been warned that such a solution might be unstable, and this > why the following occurred to me. > > Could I set just for this file, the binaries, that auctex will use > (pdflatex or xelatex) locally to use the ones provided by texlive 2019 > (they are in my case in /usr/local/texlive/2019/bin > > So is there any variable for doing this? I used apropos and searched > for latex-program or similar but could not find anything. > > Somebody has an idea? Personally, I have the following in my .emacs file: (defun TeXlive (year) "Use TeXlive with the given year (given as string), nil if no TeXlive." (interactive (let* ((year (directory-files "/usr/local/texlive/" nil "\\`[0-9]+\\'"))) (setq year (completing-read (format "Year to use (default %s): " (car (last year))) (cons "none" year) nil t nil nil (car (last year (list (unless (string= year "none") year (let ((path (getenv "PATH"))) (while (string-match "/usr/local/texlive/[0-9]+/bin/[^:/]*:" path) (setq path (replace-match "" t t path))) (when year (let* ((dir (format "/usr/local/texlive/%s/bin" year)) (defs (directory-files dir nil "\\`[-a-zA-Z0-9_]+\\'")) (arch (cond ((null defs) (error "No architectures in %s" dir)) ((null (cdr defs)) (car defs)) (t (completing-read "Architecture? " defs nil t nil nil defs) (setq path (concat dir "/" arch ":" path (setenv "PATH" path))) I call it as M-x TeXlive RET and it looks up the TeXlive versions (under /usr/local/texlive) that have binaries installed and then asks which year to use, defaulting to the newest. In case multiple architectures are installed (I had 32bit and 64bit executables in parallel at some point of time) it also asks for the architecture. -- David Kastrup
Re: LaTeX commands and packages names autocomplete.
Arash Esbati writes:
> Hongyi Zhao writes:
>
>> I commented out the above code snippet, but nothing will be completed,
>> as shown in the attached file.
>>
>> Here I want to point out two things:
>>
>> 1. As you can see, without using company-math, it seems that fewer
>> candidates are returned.
>
> The upside is that you don't get candidates like \begin which is
> nonsense in inline math.
Huh? Things like \begin{smallmatrix} are certainly useful in inline
math. They make it hard to pick a good way of formatting the _source_,
but the output is certainly fine.
--
David Kastrup
Re: LaTeX commands and packages names autocomplete.
Hongyi Zhao writes: > Hi here, > > Some time ago, it seemed that my auctex configuration was able to > provide autocomplete for LaTeX commands and packages names. However, > currently, all of these functions are disabled. How should I enable > these features again? Undo whatever you did that disabled them. Seriously? How should we guess what you did when you provide absolutely no relevant information about your configuration or even the system and versions? You can try sending such a report after opening a .tex file using M-x TeX-submit-bug-report RET and at least get some details reported. -- David Kastrup
Re: ERROR: LaTeX Error: \caption outside float.
Hongyi Zhao writes:
> Hi here,
>
> I know this is not an auctex related problem, but I would like to see
> some experience from others in solving this problem.
>
> With the attached file as an example, I always encounter the following
> error during compiling it:
>
> ERROR: LaTeX Error: \caption outside float.
>
> --- TeX said ---
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type H for immediate help.
> ...
>
> l.9 \caption
> {Caption to table}
> --- HELP ---
>>From the .log file...
>
> You're in trouble here. Try typingto proceed.
> If that doesn't work, type X to quit.
>
> But I really can't find a way to solve this problem gracefully. Any
> tips will be appreciated.
Complain to the author of the iucr document class.
--
David Kastrup
Re: Request for Features in DocTeX mode
Jan Braun writes:
>
> \newpage
> %\end{macrocode}
> % @
> %\begin{macrocode}
>
> I wrote myself a tiny lisp function, but this has still some bugs,
> which I wasn’t able to fix yet :-(
You can try
C-a C-o % C-u C-c ]
as a first approximation.
--
David Kastrup
bug#62445: 13.1.10; bug in preview-region applied to repeated math environments
Paul Nelson writes:
> Emacs : GNU Emacs 29.0.50 (build 3, x86_64-apple-darwin21.6.0, NS
> appkit-2113.60 Version 12.6 (Build 21G115))
> of 2022-11-06
> Package: 13.1.10
>
> Take the following document:
>
> #+begin_src latex
> \documentclass{amsart}
> \begin{document}
> $x$ $x$
> \end{document}
> #+end_src
>
>
> Run ~preview-region~ on the region consisting of the first $x$. This works
> as expected.
>
> Next, run ~preview-region~ on the region consisting of just the second
> $x$. This does not preview the second $x$. Instead, it refreshes the
> overlay on the first $x$.
>
> The relevant output:
>
> #+begin_quote
> ./_region_.tex:5: Preview: Snippet 1 started.
> <-><->
>
> l.5 $
> x$
> Preview: Tightpage -32891 -32891 32891 32891
> ./_region_.tex:5: Preview: Snippet 1 ended.(282168+0x374556).
> <-><->
>
> l.5 $x$
>
> #+end_quote
>
>
> The issue here is that there's not enough context for
> ~preview-parse-messages~ to determine which $x$ to overlay.
I'd just add -file-line-error to the options you are calling TeX with.
That makes for more reliable error message interpretation.
--
David Kastrup
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: AUCTeX does not ask for width for \includegraphics macro anymore
kaykal writes: > On 3 Mar 2023, at 8:23, Thibaut Verron wrote: > >> On 03/03/2023 14:19, kaykal wrote: >>> >>> Tassilo Horn t...@gnu.org writes: >>> >>> It's not. For me using the current master version, it still >>> queries for >>> the keyval parameters (width, height, angle, scale, etc.). >>> >>> It only happens for Beamer. It works fine when using article class for >>> example. >>> >> Did you try forcing AUCTeX to refresh its scanned data with C-c C-n? >> >> I occasionally need to do that to get AUCTeX to prompt me for the >> frametitle of beamer frames, it could be a similar problem here. > > Thanks for the suggestions, yes I have done it and no luck. Which lines in the document are responsible for pulling in graphics.sty or graphicx.sty ? -- David Kastrup
Re: AUCTeX does not ask for width for \includegraphics macro anymore
Tassilo Horn writes: > kaykal writes: > > Hi Kourosh, > >> I recently noticed that when using TeX-insert-macro (C-c RET) for >> \includegraphics AUCtex does not inquire about graphics width in the >> minibuffer anymore. Can anyone comment if this is expected or not? > > It's not. For me using the current master version, it still queries for > the keyval parameters (width, height, angle, scale, etc.). > > What AUCTeX version and what's your config (check M-x > TeX-submit-bug-report RET which gathers all relevant settings)? Also > check M-x list-load-path-shadows RET to see if you have an old auctex > version somewhere messing things up. Not to mention the settings for document parsing. \includegraphics is only available via packages. -- David Kastrup
Re: Small problems with auctex
Jorge Devoto writes: > Hello > > I have been using auctex for many years. In the last week, I have had two > small problems. > The first one is that when I try to open a tex file I get a message > > font-lock-compile-keywords: Font-lock trying to use keywords before setting > them up > > I have to try a second time and then all is o.k. > > The second problem is that auctex keeps asking me to set the master file, > even > if the local variables are at the end of the file. For example: (the file > is master.tex) > > %%% Local Variables: > %%% mode: latex > %%% TeX-master: "master" > %%% TeX-master: "master" > %%% TeX-master: t > %%% End: That's an accumulation of variable settings overwriting one another. Remove the last two TeX-master lines. -- David Kastrup
Re: Set background using \special{...}
jfbu writes:
> Le 08/02/2023 à 00:15, Dimitar Dimitrov a écrit :
>> Suppose I have the following `math.tex` file
>> ```latex
>> \documentclass[12pt]{article}
>> \special{background White}
>> \usepackage[active,tightpage]{preview}
>> \begin{document}
>> \begin{preview}
>> \fontsize{14}{17}\selectfont $x$
>> \end{preview}
>> \end{document}
>> ```
>> I want to get an SVG file with a white background, so I do:
>> 1. `latex math.tex`
>> 2. `dvisvgm -o math.svg —no-fonts math.dvi`
>
> (Seems -- does transmogrified into en em-dash here, probably by your mailer)
>
> works for me after moving the `\special{background White}` inside the
> preview environment
>
> I tried with Red too to confirm
The proper way to get it into every output file is by using
\AtBeginDvi{\special{background White}}
--
David Kastrup
Re: TeX-documentation-texdoc
Greg Bognar via General discussion about AUCTeX writes: > Hi, > > When I run `TeX-documentation-texdoc' (from the menu or with C-c ?), nothing > happens. The mouse pointer does turn into busy, but it stops after a while. > Nothing is written to *Messages* or to .xsession-errors. > > The texdoc command works from the terminal, opening a PDF viewer with the > requested document. > > I'm not sure whether this is an AUCTeX, Emacs, or window manager issue. Any > ideas how I could find out what the problem is? Try M-x shell RET and run texdoc from _that_ command line. That should at least carry around some of the environment that TeX-documentation-texdoc is working with. If it fails, you'll probably get some info in the Emacs buffer used as terminal. -- David Kastrup
master 2d0fdeba: Preserve braces after @TeX and similar macros.
branch: master
commit 2d0fdebac0ec12676545dd4197171575e7489f56
Author: David Kastrup
Commit: David Kastrup
Preserve braces after @TeX and similar macros.
---
doc/macros.texi | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/doc/macros.texi b/doc/macros.texi
index 4162d052..478ac18a 100644
--- a/doc/macros.texi
+++ b/doc/macros.texi
@@ -50,30 +50,30 @@ font-latex
@end ifset
@tex
\global\let\savedTeX\TeX
-\gdef\TeX#1{\savedTeX#1}
-\gdef\LaTeX{%
+\gdef\TeX#{\savedTeX}
+\gdef\LaTeX#{%
L\kern-.36em\raise.3ex\hbox{\sc{a}}\kern-.15em\TeX}
-\gdef\previewlatex#1{%
-{\sf preview-latex}#1}
-\gdef\fontlatex#1{%
-{\sf font-latex}#1}
-\gdef\AUCTeX{AUC\TeX}
-\gdef\ConTeXt#1{%
-Con\TeX t#1}
+\gdef\previewlatex#{%
+{\textsf preview-latex}}
+\gdef\fontlatex#{%
+{\textsf font-latex}}
+\gdef\AUCTeX#{AUC\TeX}
+\gdef\ConTeXt#{%
+Con\TeX{}t}
\toks0\expandafter{\indexnofonts
- \def\TeX#1{TeX#1}%
- \def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
+ \def\TeX#{TeX}%
+ \def\LaTeX#{LaTeX}\def\previewlatex#{preview-latex}}
\xdef\indexnofonts{\the\toks0}
\ifx\commondummies\undefined \else
\toks0\expandafter{\commondummies
-\def\TeX#1{TeX#1}%
-\def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
+\def\TeX#{TeX}%
+\def\LaTeX#1{LaTeX}\def\previewlatex#1{preview-latex}}
\xdef\commondummies{\the\toks0}
\fi
\ifx\definedummies\undefined \else
\toks0\expandafter{\definedummies
-\def\TeX#1{TeX#1}%
-\def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
+\def\TeX#{TeX}%
+\def\LaTeX#{LaTeX}\def\previewlatex#{preview-latex}}
\xdef\definedummies{\the\toks0}
\fi
\ifx\acronym\undefined \gdef\acronym#1{{\smallcaps \lowercase{#1}}} \fi
Re: Running pdftex on auctex.texi with texinfo 2023-01-02.21 fails
Arash Esbati writes: > David Kastrup writes: > >> Those were defensive changes intended to make fewer assumptions. I'd be >> surprised if they didn't work with older Texinfo variants, but surprises >> are not unheard of... > > I tried it with texinfo.tex 2021-04-25.21 and no surprises. Do you want > to go ahead and push your change? Right. I tend to forget that I have push access... -- David Kastrup
Re: Running pdftex on auctex.texi with texinfo 2023-01-02.21 fails
Arash Esbati writes: > David Kastrup writes: > >> That appears to be a different problem. Maybe > > Thanks, the last change works as expected. What do you think, is your > suggestion safe enough to push? Otherwise, I will try to test with an > older texinfo.tex before installing. Those were defensive changes intended to make fewer assumptions. I'd be surprised if they didn't work with older Texinfo variants, but surprises are not unheard of... -- David Kastrup
Re: Running pdftex on auctex.texi with texinfo 2023-01-02.21 fails
Arash Esbati writes:
> David Kastrup writes:
>
>> Without too much of a clue and research, this appears to do the trick
>> for me:
>
> This is what I get:
>
> (./auctex.toc [-1]
> ! Missing control sequence inserted.
>
> @inaccessible
>
>r
> ...e Faces used by {@fam =@sffam @def r
> m{sf}@sffont font-latex}{}
> @dosubsecentry ...tskip =2@tocindent @tocentry {#1
> }{#2}@endgroup
> l.52 ...f}@sffont font-latex}{}}{3.1.5}{Faces}{47}
>
> ?
That appears to be a different problem. Maybe
>From 2d0fdebac0ec12676545dd4197171575e7489f56 Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Sat, 7 Jan 2023 17:11:49 +0100
Subject: [PATCH] Preserve braces after @TeX and similar macros.
---
doc/macros.texi | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/doc/macros.texi b/doc/macros.texi
index 4162d052..478ac18a 100644
--- a/doc/macros.texi
+++ b/doc/macros.texi
@@ -50,30 +50,30 @@ font-latex
@end ifset
@tex
\global\let\savedTeX\TeX
-\gdef\TeX#1{\savedTeX#1}
-\gdef\LaTeX{%
+\gdef\TeX#{\savedTeX}
+\gdef\LaTeX#{%
L\kern-.36em\raise.3ex\hbox{\sc{a}}\kern-.15em\TeX}
-\gdef\previewlatex#1{%
-{\sf preview-latex}#1}
-\gdef\fontlatex#1{%
-{\sf font-latex}#1}
-\gdef\AUCTeX{AUC\TeX}
-\gdef\ConTeXt#1{%
-Con\TeX t#1}
+\gdef\previewlatex#{%
+{\textsf preview-latex}}
+\gdef\fontlatex#{%
+{\textsf font-latex}}
+\gdef\AUCTeX#{AUC\TeX}
+\gdef\ConTeXt#{%
+Con\TeX{}t}
\toks0\expandafter{\indexnofonts
- \def\TeX#1{TeX#1}%
- \def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
+ \def\TeX#{TeX}%
+ \def\LaTeX#{LaTeX}\def\previewlatex#{preview-latex}}
\xdef\indexnofonts{\the\toks0}
\ifx\commondummies\undefined \else
\toks0\expandafter{\commondummies
-\def\TeX#1{TeX#1}%
-\def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
+\def\TeX#{TeX}%
+\def\LaTeX#1{LaTeX}\def\previewlatex#1{preview-latex}}
\xdef\commondummies{\the\toks0}
\fi
\ifx\definedummies\undefined \else
\toks0\expandafter{\definedummies
-\def\TeX#1{TeX#1}%
-\def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
+\def\TeX#{TeX}%
+\def\LaTeX#{LaTeX}\def\previewlatex#{preview-latex}}
\xdef\definedummies{\the\toks0}
\fi
\ifx\acronym\undefined \gdef\acronym#1{{\smallcaps \lowercase{#1}}} \fi
--
2.37.2
--
David Kastrup
Re: Running pdftex on auctex.texi with texinfo 2023-01-02.21 fails
Arash Esbati writes:
> David Kastrup writes:
>
>> It needs to be written AUC@TeX{} . Maybe the toc code errouneously
>> strips the braces? ... Oops. In doc/macros.texi, we have
>>
>> \global\let\savedTeX\TeX
>> \gdef\TeX#1{\savedTeX#1}
>>
>> This would indeed cause this problem. Maybe try
>>
>> \gdef\TeX#{\savedTeX}
>
> Thanks for your response. This is what I get with your suggestion:
>
> [2] [-1] (Executive Summary)
> ! Use of @TeX doesn't match its definition.
> @ConTeXt #1->Con@TeX t
> #1
> l.76 ...vironment for editing @LaTeX{}, @ConTeXt{}
> ,
> ?
>
> Any other idea?
Without too much of a clue and research, this appears to do the trick
for me:
>From 8f354890af4c45753b7c7b620b0d56007a435631 Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Sat, 7 Jan 2023 17:11:49 +0100
Subject: [PATCH] Preserve braces after @TeX and similar macros.
---
doc/macros.texi | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/doc/macros.texi b/doc/macros.texi
index 4162d052..5c509572 100644
--- a/doc/macros.texi
+++ b/doc/macros.texi
@@ -50,30 +50,30 @@ font-latex
@end ifset
@tex
\global\let\savedTeX\TeX
-\gdef\TeX#1{\savedTeX#1}
-\gdef\LaTeX{%
+\gdef\TeX#{\savedTeX}
+\gdef\LaTeX#{%
L\kern-.36em\raise.3ex\hbox{\sc{a}}\kern-.15em\TeX}
-\gdef\previewlatex#1{%
-{\sf preview-latex}#1}
-\gdef\fontlatex#1{%
-{\sf font-latex}#1}
-\gdef\AUCTeX{AUC\TeX}
-\gdef\ConTeXt#1{%
-Con\TeX t#1}
+\gdef\previewlatex#{%
+{\sf preview-latex}}
+\gdef\fontlatex#{%
+{\sf font-latex}}
+\gdef\AUCTeX#{AUC\TeX}
+\gdef\ConTeXt#{%
+Con\TeX{}t}
\toks0\expandafter{\indexnofonts
- \def\TeX#1{TeX#1}%
- \def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
+ \def\TeX#{TeX}%
+ \def\LaTeX#{LaTeX}\def\previewlatex#{preview-latex}}
\xdef\indexnofonts{\the\toks0}
\ifx\commondummies\undefined \else
\toks0\expandafter{\commondummies
-\def\TeX#1{TeX#1}%
-\def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
+\def\TeX#{TeX}%
+\def\LaTeX#1{LaTeX}\def\previewlatex#1{preview-latex}}
\xdef\commondummies{\the\toks0}
\fi
\ifx\definedummies\undefined \else
\toks0\expandafter{\definedummies
-\def\TeX#1{TeX#1}%
-\def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
+\def\TeX#{TeX}%
+\def\LaTeX#{LaTeX}\def\previewlatex#{preview-latex}}
\xdef\definedummies{\the\toks0}
\fi
\ifx\acronym\undefined \gdef\acronym#1{{\smallcaps \lowercase{#1}}} \fi
--
2.37.2
--
David Kastrup
Re: Running pdftex on auctex.texi with texinfo 2023-01-02.21 fails
Arash Esbati writes:
> Hi,
>
> happy new year to all. I have a problem building AUCTeX from the git
> repo where pdftex-ing the manual (auctex.texi) fails. I think this is
> an issue with the latest texinfo which is
>
> \def\texinfoversion{2023-01-02.21}
>
> provided by TeXlive. Steps to reproduce in a shell:
>
> • In doc/ directory, do 'make clean'
> • Then do 'pdftex auctex.texi'
> • And again 'pdftex auctex.texi'
>
> The first run passes, the second one says:
>
> (./auctex.toc
> ! Argument of @TeX has an extra }.
>
> @par
>
>}
> @dosecentry ...leftskip =@tocindent @tocentry {#1}
> {#2}@endgroup
> l.4 ...ntry{Overview of AUC@TeX }{1.1}{Summary}{3}
>
> ?
>
> Can others reproduce this?
It needs to be written AUC@TeX{} . Maybe the toc code errouneously
strips the braces? ... Oops. In doc/macros.texi, we have
\global\let\savedTeX\TeX
\gdef\TeX#1{\savedTeX#1}
This would indeed cause this problem. Maybe try
\gdef\TeX#{\savedTeX}
instead of the second line? That would not strip but retain the braces.
It would inhibit kerning after @TeX{}, like when writing @TeX{}O, but I
don't think that should be a relevant problem. Worth a try.
--
David Kastrup
Re: master 6b5f00bf: Unquote lambdas in font-latex.el & tex-bar.el; add some FIXMEs
David Kastrup writes:
>> The list-strings variable is let-bound around the complete defconst
>> LaTeX-symbols-toolbar-switch-contents. I guess it should become
>> (quote ("foo" "bar" "baz")) instead of (quote \, list-strings). Stefan,
>> what's the issue here?
>
> This looks like it should rather rely on lexical-binding being t and
> write
>
>:help (lambda ( _ignore)
>(concat "Turn "
>(if LaTeX-symbols-toolbar-visible-flag "off " "on ")
>"the toolbar of LaTeX symbols (current class: "
>(nth (1- LaTeX-symbols-active-menuitem)
> list-strings)
>")")))
Wait, I was thinking of `(lambda ...) but you quoted ,(lambda ...). So
this apparently already was in quasi-quoted context. So the , before
(lambda) likely needs to remain, but list-strings likely has to become
un-commaed.
--
David Kastrup
Re: master 6b5f00bf: Unquote lambdas in font-latex.el & tex-bar.el; add some FIXMEs
Tassilo Horn writes:
> Arash Esbati writes:
>
>> After this change, the compiler says:
>>
>> In toplevel form:
>> tex-bar.el:481:34: Warning: reference to free variable
>> `LaTeX-symbols-active-menuitem'
>>
>> Is anybody familiar with this code in order to pacify this?
>>
>> git grep LaTeX-symbols-active-menuitem
>>
>> doesn't show anything useful.
>
> And neither does it seem to be generated by `LaTeX-install-toolbar'. So
> it's probably a bug which Stefan's change caught.
>
> And when I enable latex-symbols-experimental in customize for
> TeX-bar-LaTeX-buttons and then run LaTeX-install-toolbar, I get this
> error:
>
> Debugger entered--Lisp error: (wrong-type-argument sequencep \,)
> #f(compiled-function ( ignore) #)()
> toolbarx-eval-function-or-symbol(#f(compiled-function ( ignore)
> #) # F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_8>)
> toolbarx-test-string-or-nil(#f(compiled-function ( ignore) # -0x1ff31a58ef856dbb>))
> toolbarx-emacs-add-button(...)
> toolbarx-emacs-refresh-process-button-or-insert-list(...)
> toolbarx-emacs-refresh(nil)
> toolbarx-refresh(nil)
> toolbarx-install-toolbar(...)
> LaTeX-install-toolbar()
> funcall-interactively(LaTeX-install-toolbar)
> command-execute(LaTeX-install-toolbar record)
> execute-extended-command(nil "LaTeX-install-toolbar" nil)
> funcall-interactively(execute-extended-command nil "LaTeX-install-toolbar"
> nil)
> command-execute(execute-extended-command)
>
>
> The byte-code of the erroring function is:
>
> byte code:
> doc: ...
> args: ( rest)
> 0 constant "Turn "
> 1 varrefLaTeX-symbols-toolbar-visible-flag
> 2 goto-if-nil 1
> 5 constant "off "
> 6 goto 2
> 9:1 constant "on "
> 10:2constant "the toolbar of LaTeX symbols (current class: "
> 11 varrefLaTeX-symbols-active-menuitem
> 12 sub1
> 13 constant (\, list-strings) ; <=== Error here!
> 14 nth
> 15 constant ")"
> 16 concatN 5
> 18 return
>
>
> That's this :help function in LaTeX-symbols-toolbar-switch-contents:
>
>:help ,(lambda ( _ignore)
> (concat "Turn "
> (if LaTeX-symbols-toolbar-visible-flag "off " "on ")
> "the toolbar of LaTeX symbols (current class: "
> (nth (1- LaTeX-symbols-active-menuitem)
> (quote ,list-strings))
> ")")))
>
> The list-strings variable is let-bound around the complete defconst
> LaTeX-symbols-toolbar-switch-contents. I guess it should become
> (quote ("foo" "bar" "baz")) instead of (quote \, list-strings). Stefan,
> what's the issue here?
This looks like it should rather rely on lexical-binding being t and
write
:help (lambda ( _ignore)
(concat "Turn "
(if LaTeX-symbols-toolbar-visible-flag "off " "on ")
"the toolbar of LaTeX symbols (current class: "
(nth (1- LaTeX-symbols-active-menuitem)
list-strings)
")")))
--
David Kastrup
Re: auctex version 11.84 (for Xemacs21.4) don't ask for master
Uwe Brauer writes: >>>> "DK" == David Kastrup writes: > >> Uwe Brauer writes: >>> Hi >>> >>> A colleague of mine still sticks with xemacs21.4 and auctex 11.84. >>> >>> >>> Now she is annoyed that every time she opens/creates a new latex file >>> she is asked Master file (default this file) >>> >>> I have set >>> >>> (setq TeX-master nil) >>> (setq-default TeX-master nil) >>> >>> But it does not help. >>> >>> How can a disable this question? > >> From the documentation of TeX-master: > > >> If this variable is nil, AUCTeX will query you for the name. > Thanks, but also sorry, > > I set it to t and it did not work, the reason was that I changed the > configuration files for GNU emacs, not for Xemacs, since I myself > switched to GNU emacs in 2015 and forget Xemacs almost. M-x customize-variable RET TeX-master RET should know which configuration file to change for the currently running Emacs. It's possible to have hand-configuration that will still stomp over Customize, but restarting Emacs/XEmacs should be all it takes to verify whether customization has worked. -- David Kastrup
Re: auctex version 11.84 (for Xemacs21.4) don't ask for master
Uwe Brauer writes: > Hi > > A colleague of mine still sticks with xemacs21.4 and auctex 11.84. > > > Now she is annoyed that every time she opens/creates a new latex file > she is asked Master file (default this file) > > I have set > > (setq TeX-master nil) > (setq-default TeX-master nil) > > But it does not help. > > How can a disable this question? >From the documentation of TeX-master: If this variable is nil, AUCTeX will query you for the name. You can read about the meanings of different settings with C-h v TeX-master . Or you can just use M-x customize-variable RET TeX-master RET and have the meaning of the various settings explained. -- David Kastrup
Re: Dependency on tex-buf.el
Uwe Brauer writes: >> Uwe Brauer writes: > >> Almost all of them in this regard because they _track_ the operations >> (like renaming a file) done while Git only records directory snapshots >> and the commit graph. But that also means that you need to be careful >> how you rearrange things in other version control systems so that they >> can track the ancestry of material, and moving material between files or >> splitting or merging files generally leads to a loss of significant >> amounts of information. > Very interesting! > > Although that gets a bit off topic: > > I do a lot of moving and or renaming in my repositories. > > Now if I use vc-annotate in either git or hg repositories, the changes > are displayed correctly, however what does not work is > vc-annotate-prev-revision for a file that I have renamed. In Git it should work (if you _combine_ renaming a file with changing its contents in a single commit, git blame may need additional options to track this). In Hg it likely depends on whether you renamed using the version control system or outside of it. > Maybe this is impossible. Unlikely... -- David Kastrup
Re: Dependency on tex-buf.el
Uwe Brauer writes: >> Ikumi Keita writes: > >> As a historic note, the awful performance of 'git blame' particularly on >> files like src/xdisp.c was a strong argument against moving Emacs >> development to Git. > > Out of curiosity, what VC system has a better performance? Mercurial > for sure not. Bazaar? Almost all of them in this regard because they _track_ the operations (like renaming a file) done while Git only records directory snapshots and the commit graph. But that also means that you need to be careful how you rearrange things in other version control systems so that they can track the ancestry of material, and moving material between files or splitting or merging files generally leads to a loss of significant amounts of information. In Git you do not need to worry about losing that information because Git does not store it in the first place. -- David Kastrup
Re: Dependency on tex-buf.el
Ikumi Keita writes: > Hi David and Tassilo, > >>>>>> David Kastrup writes: >> As a note aside: we are using Git as version control system these days. >> Git doesn't maintain change histories in the first place but computes >> them on the fly when calling "git blame" or similar. It has various >> options on how thoroughly it will track content moving across files. > > Oh, indeed! > ,[ > https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#_file_annotation ] > | Another cool thing about Git is that it doesn’t track file renames > | explicitly. It records the snapshots and then tries to figure out what > | was renamed implicitly, after the fact. One of the interesting > | features of this is that you can ask it to figure out all sorts of > | code movement as well. If you pass -C to git blame, Git analyzes the > | file you’re annotating and tries to figure out where snippets of code > | within it originally came from if they were copied from elsewhere. > ` > That's a fantastic feature. As a historic note, the awful performance of 'git blame' particularly on files like src/xdisp.c was a strong argument against moving Emacs development to Git. I was conceited enough to let myself be goaded in promising to do something about it. A number of others have put in fixes since then; my original work was good for about a factor of 5 in performance on files like that. commit 7e6ac6e4391caa0fc379cb699013d503380e4214 Author: David Kastrup Date: Sat Apr 26 01:56:49 2014 +0200 blame: large-scale performance rewrite Another commit even mentions src/xdisp.c explicitly: commit 4874f544f1574a55d787339a6455f524768c1b5d Author: David Kastrup Date: Sun May 4 19:13:57 2014 +0200 Bump core.deltaBaseCacheLimit to 96m The default of 16m causes serious thrashing for large delta chains combined with large files. Here are some benchmarks (pu variant of git blame): time git blame -C src/xdisp.c >/dev/null for a repository of Emacs repacked with git gc --aggressive (v1.9, resulting in a window size of 250) located on an SSD drive. The file in question has about 3 lines, 1Mb of size, and a history with about 2500 commits. [...] -- David Kastrup
Re: Dependency on tex-buf.el
Ikumi Keita writes: > If AUCTeX is to keep it, > (D) We should remove "(require 'tex-buf)" from at least plain-tex.el, > context.el, tex-bar.el and tex-jp.el, adding some defvar's and > declare-function's (or autoload's if necessary). > (E; optional?) It's reasonable that preview.el has "(require 'tex-buf)" > considering its nature; but maybe we should consider replacing it > with suitable autoload's (adding some defvar's). > (F; optional?) Move entire "Viewing" section from tex.el to tex-buf.el. > > My preference is to keep the "separate dependency policy" and do (D) and > (E). Doing (F) is too drastic a change and the commit history of > "Viewing" section is valuable, which doesn't seem good to lose. > > What do you think about it? As a note aside: we are using Git as version control system these days. Git doesn't maintain change histories in the first place but computes them on the fly when calling "git blame" or similar. It has various options on how thoroughly it will track content moving across files. "Losing" commit history is quite harder than you make it appear here. So that particular point should not really be a consideration. -- David Kastrup
bug#54200: 13.0.14; Preview incorrectly folds math environments with TeX-engine LuaTeX
Ikumi Keita writes: > Hi Liam and David, > > David, can you tell which is responsible for these superfluous two > characters, preview.sty or lualatex itself? Error context is produced by the TeX engine itself, so in this case it would be the fault of LuaTeX and should likely be reported to its developer list at dev-lua...@ntg.nl . -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#54200: 13.0.14; Preview incorrectly folds math environments with TeX-engine LuaTeX
Liam Hupfer via bug-auctex via Bug reporting list for AUCTeX writes: > When I run `preview-buffer` on the attached file, I get a preview that > looks like "The probability of an initial subsequence of length 3", > where multiple math environments are folded into the "3" preview. If I > move the point over the preview, it unfolds and I can see the other > previews have been generated, but they are not visible due to the > incorrect folding. Any ideas? > > ./_region_.tex:6: Preview: Snippet 1 started. > <-><-> > > l.6 ...bility of an initial subsequence of length \( [...] > ./_region_.tex:6: Preview: Snippet 3 started. > <-><-> > > l.6 ...bility of an initial subsequence of length \( Maybe you should not run everything into a single large paragraph with multiple repetitions of very long phrases? It's conceivable that one could improve on that particular example by trying to limit context searches to start after the last completed search in that line. But that could spell trouble for including the same file several times. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: GNU AUCTeX branch, master, updated. 34befcc17649fd6615fd4ef8756fb78705f7fe55
Arash Esbati writes: > "Tassilo Horn" writes: > > Hi Tassilo, > > Thanks for fixing this. I have one question: > >> diff --git a/latex.el b/latex.el >> index c332ebf4..06627c4b 100644 >> --- a/latex.el >> +++ b/latex.el >> @@ -5849,11 +5849,13 @@ returned." >>(catch 'found >> (dolist (var (list LaTeX-math-list LaTeX-math-default)) >>(dolist (e var) > > Would it make sense to drop the outer dolist and replace > >(dolist (e var) > > with >(dolist (e (append LaTeX-math-list LaTeX-math-default)) > > Or am I missing something? Performance and memory churn? Appending two lists has to create a copy of the first list. -- David Kastrup
Re: Encoding trouble
David Kastrup writes: > Denis Bitouzé writes: > >> Le 30/01/22 à 15h52, David Kastrup a écrit : >> >>> That would be pretty annoying for people working with any Latin-x >>> encoding other than Latin-1 (or in general, any encoding not in Emacs >>> default autodetection set). >> >> In case of encoding Emacs cannot detect, AUCTeX would rely of the >> `inputenc` option. That does not even make sense since all of the Latin-x options are the same in autodetection. They cannot be distinguished since they use the same code points. Essentially, a Latin-1 user would get every Latin-x except Latin-1 displayed wrongly. And the same for Latin-2 users and so on. >>> Emacs showed you what LaTeX would have shown you. >> >> I'm not sure to see your point here. > > Where is the point in letting Emacs input display different than LaTeX > would interpret it? -- David Kastrup
Re: Encoding trouble
Denis Bitouzé writes: > Le 30/01/22 à 15h52, David Kastrup a écrit : > >> That would be pretty annoying for people working with any Latin-x >> encoding other than Latin-1 (or in general, any encoding not in Emacs >> default autodetection set). > > In case of encoding Emacs cannot detect, AUCTeX would rely of the > `inputenc` option. > >> Emacs showed you what LaTeX would have shown you. > > I'm not sure to see your point here. Where is the point in letting Emacs input display different than LaTeX would interpret it? -- David Kastrup
Re: Encoding trouble
Denis Bitouzé writes:
> Hi,
>
> several years ago, I already faced the following problem and,
> unfortunately, it happened again yesterday, which made me lose quite
> some time.
>
> Let me explain myself: I had a LaTeX file encoded in latin1 that
> I wanted to encode in UTF-8. I used an external tool, in this case
> `utrac`, which confirmed the starting (latin1) and ending (UTF-8)
> encoding. But, when I opened this file in Emacs with AUCTeX enabled, the
> accented characters were wrong and it was only when I saw that the file
> contained `usepackage[latin1]{inputenc}` that I understood where the
> problem came from: changing it in `usepackage[utf8]{inputenc}` solved
> it.
>
> So, here is my request: would it be possible that, for the detection of
> the real encoding of the file, AUCTeX relies not on the `inputenc`
> package option, but rather on the Emacs heuristics and that, in case of
> discrepancy between the two, it issues a warning?
That would be pretty annoying for people working with any Latin-x
encoding other than Latin-1 (or in general, any encoding not in Emacs
default autodetection set).
Emacs showed you what LaTeX would have shown you.
--
David Kastrup
bug#44578: Investigating current preview problem
Hugo Raguet writes: > On 06/01/2022 20:53, Tassilo Horn wrote: >> Hugo Raguet writes: >> Hi Hugo, >> >>> I am not in good position to report if this version of AUCTeX is >>> working, because I actually never used AUCTeX. My attention came to >>> this problem because preview is actually used in packages such as >>> pst-pdf (see for instance https://tex.stackexchange.com/q/617229). >> I've attached it; could you and Tobias please give it a try. > > Unfortunately, it does not fix my problem ; for instance, the minimum > example on the above referenced thread fails with the exact same > problem as before if I do not apply Ulrike Fisher's workaround. Ugh. That is a really ugly workaround that looks like a whack-a-mole game. Also the shipout hooks were not introduced at the same time as output routine hooks, so one needs to hone in on some particular LaTeX version for getting this under control. Thanks for testing. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#44578: Investigating current preview problem
Tassilo Horn writes: > Hugo Raguet writes: > >>> That is what we are doing. Currently just held back by administrative >>> issues, because my employer is supposed to pay the bill, but I am not >>> sure under which tax regime this will be acceptable for its >>> accounting. >> >> Unfortunately, we could not find an agreement. If I understand well, >> David Kastrup you are willing to do the job if paid by individuals, >> but you refuse to edit a proper bill to be paid by organizations. > > AFAIK, editing a proper bill addressing all tax related things that your > organization needs is a non-trivial task and possibly more > time-consuming than the fix itself. It's more like the possible followup may become a mess if the tax related things are not done properly, and there are different tax regimes involved. Given that the original motivation to do something here was really lacking, this just did not fit a "recompense for actual effort" calculation any more and it didn't help that this was intended to become a posterchild of the "work on free software can be paid work" kind in light of what I previously invested in the project. It was a well-meant pitch but in the end did not manage to make it to my home plate. Additionally it would appear that the LaTeX team made this a really muddy and unreliable feat by trying to introduce new hooks and hide functionality (in more than one iteration) that just don't match the use case of preview.sty, and that I fail to reproduce the problem on my own computer in the first place. So there really is no clear finishing line to when this can be considered fixed in good conscience. > So it's certainly not individuals vs. organization. > > Fortunately for you guys, a small group of individuals has been found > who will pay to get your bug fixed. > >> Bug still pending... He did say that the main thing I had to fear was getting blamed on the mailing list for not doing what I had been paid for. It would appear that this does not really depend all that much on payment. > Have you tried GNU AUCTeX 13.0.15 from > > https://elpa.gnu.org/packages/auctex.html > > with the preview.sty version shipping with that, yet? Given that I am unable to reproduce the problem on my system (I have no proper idea why), that would be a welcome data point. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: cannot add \frownie to pretty-list
Uwe Brauer writes:
> Hi all
>
> I am using now emacs 29 master and enjoy Lars emoji insert menu.
>
> So I thought why not adding emoji to the pretty-symbol list.
> But this symbol seems to cause problems: ☹️.
>
> Please consider this piece of code
>
> (defun tex--prettify-symbols-compose-p (_start end _match) ; not necessary
> (or (not (eq ?w (char-syntax (char-before end
> (let* ((after-char (char-after end))
>(after-syntax (char-syntax after-char)))
> (not (or
> ;; Don't compose \alpha@foo.
> (eq after-char ?@)
> ;; The \alpha in \alpha2 or \alpha-\beta may be composed but
> ;; of course \alphax may not.
> (and (eq after-syntax ?w)
> (not (memq after-char
> '(?0 ?1 ?2 ?3 ?4 ?5 ?6 ?7 ?8 ?9 ?+ ?- ?' ?\"
> ;; Don't compose inside verbatim blocks.
> (eq 2 (nth 7 (syntax-ppss
>
> (dolist (el '(
> ;; doble stack
> ("\\smiley" . ?); works
> ("\\frowie" . ?☹️); gives error
> ("\\varrho" . ?ϱ)))
> (add-to-list 'tex--prettify-symbols-alist el))
For one thing, it would have to be called "\\frownie" rather than
"\\frowie". For another, you add an unrelated character after the
frownie (the ?☹) that Emacs identifies as
position: 1115 of 1246 (89%), column: 30
character: ️ (displayed as ️) (codepoint 65039, #o177017, #xfe0f)
charset: unicode (Unicode (ISO10646))
code point in charset: 0xFE0F
syntax: wwhich means: word
category: ^:Combining
to input: type "C-x 8 RET fe0f" or "C-x 8 RET VARIATION
SELECTOR-16"
buffer code: #xEF #xB8 #x8F
file code: #xEF #xB8 #x8F (encoded by coding system raw-text-unix)
display: by this font (glyph code)
ftcrhb:-PfEd-Unifont-normal-normal-normal-*-15-*-*-*-d-0-iso10646-1 (#xDD12)
Character code properties: customize what to show
name: VARIATION SELECTOR-16
general-category: Mn (Mark, Nonspacing)
decomposition: (65039) ('️')
and that has no place in Elisp syntax when encountered on its own. If
you cannot get your input method to refrain from that insertion, instead
of ?☹ you could just write 9785 .
--
David Kastrup
bug#44578: Investigating current preview problem
Hugo Raguet writes: > Dear David Kastrup > > I have encountered a problem involving the latex package preview. If I > understand well it is due to "a change in the latex shipout routine" > in the last versions. I read the threads on the GNU bug reports 44578 > and 45894 about the problem. It appears you are the current maintainer > of preview, but unfortunately do not currently have the ressources to > take care this problem. > > I am unable to do it myself, but there were some mention of maybe > paying for your expertise. Would you be willing to estimate a cost at > which you could take proper care of the problem, or maybe point me to > other people with enough knowledge to do it? Reading reports, analysing and understanding problem: €50 Reading up on the tools LaTeX now wants instead: €30 Devising and implementing a fix €30 Backward compatibility€10 Cleaning up and shepherding through AUCTeX repository €25 Submitting and shepherding through CTAN €25 Dealing with problem reports and feedback €25 Total: €195 Everybody will tell you that this is a total ripoff (the actual code will likely not be more than a dozen lines) and nobody will volunteer to do it for that price, judging from experience. I spent years on creating preview-latex and got probably about double that amount in return. You'll find people with the necessary skills easily on TeX/LaTeX forums and mailing lists, and maybe the outrage at my insolent demands will help motivate someone to earn a few Karma points. Just don't expect too much regarding the followup work. Good luck! -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#44578: AW: AW: AW: bug#45894: Bug report for preview-latex
"Bruckmann, Tobias" writes: > Dear Ikumi, > > 6 months ago we had the conversation below, and as Mr. Kastrup decided not > to care for the issue without getting paid, I wanted to ask whether this bug > is still on the list of the auctex team. Mr Kastrup was not motivated by the entitlement attitude that demanded he be happy to invest work, time and energy that was more than the complainant was willing to invest. And I cannot really say that the continued abuse and entitlement is doing a particularly swell job of raising motivation. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: Failed to install auctex from within Emacs with straight.
Hongyi Zhao writes: > On Tue, Aug 17, 2021 at 2:48 PM Tassilo Horn wrote: >> >> Hongyi Zhao writes: >> >> Hi, >> >> > I'm on Ubuntu 20.04.2 LTS, and use straight [1] as the Emacs package >> > manager. Now, I try to install auctex from within Emacs with straight, >> > but it always freezes at the configure stage. I describe the detailed >> > test steps as follows. >> >> I've never used straight.el but the first thing I'd try was running >> ./configure in the checkout made by straight.el. Does that finish? >> >> Then I'd try something like >> >> (let ((default-directory "~/auctex-checkout")) >> (call-process "~/auctex-checkout/configure" nil "*configure-output*" t)) > > I do another similar but more simple test, i.e., `C-x C-e' the > following code in *scratch* buffer: > > (let ((default-directory "~/auctex")) > (call-process "ls ~/auctex/configure" nil "*configure-output*" t)) That's not more simple but more complex. call-process requires an _executable_ filename as argument, not a shell command. -- David Kastrup
Re: preview-environment: No enclosing outer environment found
Tassilo Horn writes: > David Kastrup writes: > >> You can preview $...$ just fine, you just don't get to call it an >> environment. > > Yes, you are right. C-c C-p C-p on the example works with $...$. > >> C-c C-p C-p inside of an already existing (but edited) preview would >> just use the already established boundaries I think. Assuming that I >> remember this detail correctly. > > Most probably you do. The "problem" with C-c C-p C-p might be that if > you have a large document with no existing previews and then call it, > it'll generate previews for the complete buffer because the region it > considers extends forwards and backwards to the next preview. But you > can mark the region $...$ manually and then C-c C-p C-p. It needs to be pointed out that you can mark the region sloppily by including more than necessary. Like using C-x C-p for marking the current page (assuming that it's balanced with regard to previewable constructs). > That's completely alright but justifies the usage of C-c C-p C-e when > you just want to preview a single environment which then needs to be > just that, an environment. It's also worth pointing out that previewing the whole document tends to be a lot less painful than one would think it to be. preview-latex is old software from a time when computers were running an order of magnitude slower. -- David Kastrup
Re: preview-environment: No enclosing outer environment found
Tassilo Horn writes: > Hongyi Zhao writes: > >> With the point inside the math environment, I run the `Preview for >> environment' with `C-c C-p C-e', I will meet the following error: >> preview-environment: No enclosing outer environment found. I attached >> the screenshot here, just FYI. >> >> Any hints for this problem? > > Yes, that's because the array environment is an "inner" environment > (`preview-inner-environments') meaning it cannot be previewed on its own > but only as part of the surrounding math environment. But you don't > have a surrounding math environment, just $...$. So use a math or > displaymath environment instead. You can preview $...$ just fine, you just don't get to call it an environment. C-c C-p C-p inside of an already existing (but edited) preview would just use the already established boundaries I think. Assuming that I remember this detail correctly. -- David Kastrup
Re: Failed to skip from chapter tex file to master pdf file.
Hongyi Zhao writes: > On Mon, Jul 12, 2021 at 6:31 PM Tassilo Horn wrote: >> >> Hongyi Zhao writes: >> >> >> (delq nil '(nil 1 nil)) ;=> (1) >> >> (delq nil '(nil nil nil)) ;=> nil, aka, the empty list () >> >> (eq nil '()) ;=> t >> > >> > Got it. The `nil' shown in my example just means the empty result list >> > (). The `nil' in itself can be used in different context, when it's >> > used as boolean variable, it means false. But it can also be used to >> > represent an empty list (). >> >> Exactly that. :-) > > Perhaps this is one of the reasons why LISP is efficient, powerful, > abstract and highly concise. Another distinguishing feature is that it > only relies on symbol expression to do all complicated logical without > using syntax, just as many other languages do. I find myself becoming > more and more fond of this language, because I don't need to memorize > the tedious grammar rules and just think about what I want to do. Well, the absence of "tedious grammar rules" is due to LISP not actually having an input language utilising humans' ability to visually peruse linguistic and graphic conglomerates. Instead you directly enter a program's parse tree in a data representation specifically optimised for list entry. That makes it rather straightforward to use LISP itself for generating and analysing programs. It also means that LISP programs without a good indentation strategy are inordinately harder to read for humans than unformatted input in other languages. As sort of a counterthesis, an indentation-sensitive language like Python makes it in contrast quite hard to write (and parse) programs correctly from within code. -- David Kastrup
Re: Cleaning up temporal markers
Ikumi Keita writes: > Hi Arash, thanks for your reply. > >>>>>> Arash Esbati writes: >> I've checked only the 2 functions `LaTeX-env-figure' and >> `LaTeX-fill-region-as-paragraph' and my understanding is that for >> let-bound markers in a function body, you don't have to clean up as >> described above. > > Oh, really? I didn't know that! You don't have to, sure. But then the markers will get maintained until next garbage collection, won't they? That's what slowing down the editing. Unassociating them with the buffer will not garbage-collect them, but it will stop their performance implications until they get collected. The Elisp manual says this: Insertion and deletion in a buffer must check all the markers and relocate them if necessary. This slows processing in a buffer with a large number of markers. For this reason, it is a good idea to make a marker point nowhere if you are sure you don’t need it any more. Markers that can no longer be accessed are eventually removed (*note Garbage Collection::). Note that markers that can no longer be accessed (which would apply to let-bound markers) are _eventually_ removed in garbage collection. Until they are removed, the performance implications when they are associated with a buffer remain. In theory, the Elisp compiler might realise that a let-bound marker has become inaccessible and might detach it on its own. But relying on that would seem imprudent, and it would be probably a bit daring for an optimisation. >> IIRC the Emacs lisp reference is not clear about this point. It >> would be good if someone gives a definite answer about my assumption >> above. > > Yeah, I'd appreciate if someone clarifies this point. As I read the Elisp reference, it is pretty clear. What other interpretation do you read into the text? -- David Kastrup
Re: Output to directory patch
Tassilo Horn writes: > David Kastrup writes: > >>>> Tasillo, I would be grateful if you can pull those changes when you >>>> get a chance. >>> >>> Done so, although I've had to delete and recreate the branch because >>> apparently savannah seems to disallow force-pushing and it seems >>> there is no setting for that on our administration page. >> >> Yup. Always been like that. With a fine-grained hook, one could >> allow force-pushing on some branches but not on others (after getting >> Savannah admins to install the hook and enable force-pushing) but we >> never went there. > > Do you have an example of such an hook handy? No. I've written one up for use with the LilyPond project at one point of time but never tested it or had it deployed. By now the LilyPond repository has been moved to GitLab for the main development so that plan has become moot anyway. I'd have to dig through my disks to see where this writeup was, but as I said: it never saw any test or action and thus is not likely to save a lot of time, effort or pain. In the end, deleting and rewriting a branch is not all that much more effort. -- David Kastrup
Re: Output to directory patch
Tassilo Horn writes: > Al Haji-Ali writes: > > Hi Al, > >> Tasillo, I would be grateful if you can pull those changes when you >> get a chance. > > Done so, although I've had to delete and recreate the branch because > apparently savannah seems to disallow force-pushing and it seems there > is no setting for that on our administration page. Yup. Always been like that. With a fine-grained hook, one could allow force-pushing on some branches but not on others (after getting Savannah admins to install the hook and enable force-pushing) but we never went there. And force-pushing on master at least is not something one should do ever. -- David Kastrup
bug#45894: AW: AW: bug#45894: Bug report for preview-latex
"Bruckmann, Tobias" writes: > Dear David, > > this is a good question. I didn't want to push Not? > but just point out the relevance of the issue, believing that you feel > a personal appreciation (and/or certain responsibility) for a code you > officially maintain. > > If I had the expertise to fix the code on my own, I would not have > spent the time to find and bother you, but better invest it to produce > the solution and propose it to you. > > If you ask for money - that could be a problem. I have no idea on the > time needed to find the problem, to fix and to test it. Hiring a > professional is probably beyond my budget as I am just an > academics. As such, I am volunteering as well in multiple matters, > trying to improve things - so I think when it comes to projects driven > by enthusiastism, I share your engagement, but I don't think that a > spirit of needing individual payments will lead to a better future for > open source projects. I thought so. I've invested decades of my time in Free Software, living below minimum wage, with the obvious consequences for my personal future. All that buys you is people thinking they are entitled to it and argue you should do more for them. There are times when this motivational framework does not work all that well for me. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#45894: AW: AW: bug#45894: Bug report for preview-latex
"Bruckmann, Tobias" writes: > Hi Ikumi, David > > this is a bad situation. I am quite surprised I am the first (and only?) one > to stumble across this: > - Most scientific works use vector EPS graphics. psfrag is extremely popular > in this field. > - Most works are published in PDF > - You can't get around hyperref > > The combination of pstool and pdfLaTeX seems to be the most promising > approach to me to join these points in one toolchain. Living with an old > version might work for some months, but this can't be the future. > > So there's no pathway and this toolchain is dead forever? > > Thanks for your appreciated comment, So what are you willing to invest to avert the catastrophe? In terms of procuring code or paying for the time of those who do? -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: File local-variables error: (error Lisp nesting exceeds ‘max-lisp-eval-depth’)
Denis Bitouzé writes: > while it used to work nicely, Also known as: why this utter disregard of the documentation did not trigger a fatal error before as far as I remember. > I'm now facing an issue when I open my `.dtx` files, loaded with some > specific local variables. > > 2. Add the following local variables to the bottom of this file: > > %%% Local Variables: > %%% mode: tex > %%% eval: (doctex-mode) > %%% TeX-command-default: "TeX" > %%% TeX-master: t > %%% End: doctex-mode is a major mode. To trigger it _after_ first loading another mode as a major mode is a mistake. It probably now causes the local variable block to be reloaded, with obvious results. -- David Kastrup
bug#44578: AW: bug#45894: Bug report for preview-latex
Frankly, I have a problem seeing a sensible fix for "Hyperref chose to
mess with LaTeX internals in its own exclusive way incompatible with
anybody else trying to change behavior, even when done in the exactly
same manner, but will likely change doing this to a different way soon".
"Bruckmann, Tobias" writes:
> Thanks!
> Please let me know in case I can support the clarification of the bug.
>
> -Ursprüngliche Nachricht-
> Von: Ikumi Keita
> Gesendet: Sonntag, 17. Januar 2021 06:58
> An: d...@gnu.org
> Cc: Bruckmann, Tobias ; 45...@debbugs.gnu.org;
> 44...@debbugs.gnu.org
> Betreff: Re: bug#45894: Bug report for preview-latex
>
> Hi David,
>
> Could you please take care of bug#44578[1], reported by Ulrike Fischer?
> It seems that that bug is responsible for bug#45894, skimming over the
> correspondence between Tobias and Ulrike[2].
>
> In addition, the following simple document fails at preview-latex when
> TeX-PDF-mode is nil and preview-image-type is `png', although I'm not sure
> whether this is related or not. (The two math fragments "\(a\)" and "\(b\)"
> both don't render as images but instead "Do not enter" signs appear beside
> them.)
>
> In summary, it seems that latex+dvips+gs has low compatibility with
> preview.sty by recent changes in LaTeX core.
>
> Best regards,
> Ikumi Keita
>
> --
> \documentclass{article}
> \usepackage{tikz}
>
> \begin{document}
>
> \begin{itemize}
> \item \(a\)
> \item \(b\)
> \end{itemize}
>
> % pdflatex+pdf2dsc+gs OK
> % latex+dvipngOK
> % latex+dvips+gs NG
>
> \end{document}
>
> %%% Local Variables:
> %%% mode: latex
> %%% TeX-master: t
> %%% End:
> --
>
> [1] https://debbugs.gnu.org/44578
> [2]
> https://tex.stackexchange.com/questions/570404/pdflatex-fails-on-pstool-when
> -hyperref-is-included
>
>>>>>> "Bruckmann, Tobias" writes:
>> Dear Sir or Madam,
>> I reported a bug on github, and the maintainers advised me to inform
>> the authors of preview-latex:
>
>> <https://github.com/latex3/hyperref/issues/166> pdfLaTeX fails on
>> pstool when hyperref is included · Issue #166 · latex3/hyperref
>> (github.com). The original bug report, a minimum example and all
>> needed files are posted there.
>
>> I would be absolutely willing to support the clarification of the issue.
>> Please inform me how to formally submit the bug report.
>
>> Thanks and best wishes,
>
>> Tobias Bruckmann
>
--
David Kastrup
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: Slash at the end of directory (was Re: oddity with TeX-style-private ?)
Uwe Brauer writes: >>>> "DK" == David Kastrup writes: > >> Uwe Brauer writes: >>>> Pushed. Oops, sorry, I overlooked that new commits had come in. A non >>>> fast-forward merge commit was produced on savannah. Not good... >>> >>> Actually I find non fast-forward merges much easier to understand than >>> fast-forward one. ;-) > >> That's nonsensical since any non fast-forward commit consists of the >> combination of fast-forwarding (direct) commits with a subsequent merge >> commit of two branches with diverging history. Rebased commits, in >> contrast, are just what would have resulted from linear development. > > I know and that is why I don't like rebasing. > >> It may be easier on the developer, but certainly not on the reader. > > That might be so, but I think it is just a different philosophy. I'd > prefer to know where a commit comes from (I mean from which branch), and > that is why I find linearising (that is rebasing) confusing to say the > least. To me it looks like you are confusing the development of a feature with long-running parallel branches. For the latter, there is no point in rebasing. For the former, there is no point in identifying a branch that isn't in any manner reflecting anything but an arbitrary point of departure before development of a feature has finished. Rebasing does not provide a historical record. Its point is to convey a logical sequence of changes rather than a diary. For figuring out where and when and why something went right or wrong, that tends to be considerably more accessible. > But I think it boils down to a question of personal taste. (And I > admit that if there are to many no fast forward merges from many > branches that might be confusing as well). Anyhow. -- David Kastrup
Re: Slash at the end of directory (was Re: oddity with TeX-style-private ?)
Uwe Brauer writes: >> Pushed. Oops, sorry, I overlooked that new commits had come in. A non >> fast-forward merge commit was produced on savannah. Not good... > > Actually I find non fast-forward merges much easier to understand than > fast-forward one. ;-) That's nonsensical since any non fast-forward commit consists of the combination of fast-forwarding (direct) commits with a subsequent merge commit of two branches with diverging history. Rebased commits, in contrast, are just what would have resulted from linear development. It may be easier on the developer, but certainly not on the reader. -- David Kastrup
Re: Use pagecolor with preview package
Matt Huszagh writes:
> Hello,
>
> I'm trying to use pagecolor with preview. Unfortunately, preview seems
> to be ignoring the pagecolor command. Here's a minimal example.
>
> mwe.tex:
>
> \documentclass{article}
> \usepackage{xcolor}
> \usepackage[active,tightpage]{preview}
> \begin{document}
> \begin{preview}
> {\color{white}
> \pagecolor{black}
> some text
> }
> \end{preview}
> \end{document}
>
> Compiled with `pdflatex mwe.tex`.
>
> Is there a way to get preview to respect the pagecolor command?
Preview attempts respecting the color settings of your editor window.
That is in conflict with respecting color settings in the document. It
also tries fudging the document into tiny bits that are treated
semi-independently. All of that means that color handling is tricky and
differs whether you load a color package or not, and whether you are
generating DVI or PDF. Much of it is not entirely by design but a
consequence of technical details of the respective color workflows
interacting with preview-latex's color treatment.
So basically it's tricky, and that's even before figuring out what
"respecting the pagecolor command" means in the context of fragments
displayed in an editor window with a different color scheme.
Sometimes, you can configure preview-reference-face but it's unlikely
that the customisation will make you happy for more than one document.
--
David Kastrup
bug#39927: 12.2; preview-latex gs treatment off by one
can...@free.fr writes: > Hello, > > Funny bug with preview-latex. I use gs 9.50 with > preview-pdf-color-adjust-method = t. > > Whenever generating previews, I get error messages for essentially all > preview images, such as: > « Cannot find image file ‘.../_region_.prv/.../pr1-1.png’ » > > Then, one preview image (first one in document order, last one to be treated, > if I understood things correctly) fails to load, just get a big blank square. > Move the cursor a bit, and it loads as well. Particularly annoying if you > are just refreshing a single preview image and it fails to load. > > My diagnosis : in parsing the GS output, preview-gs-transact just assumes > that some prompts from GS mean that an image has been treated. I **guess** > the introduction of -dDELAYBIND could have added an extra such prompt, so now > it assumes the image is ready before it actually is. emacs complains it > cannot be found. Then when adding the next image to its overlay, emacs > realises that the previous image is there now, and loads it, so in the end, > it is only the last image to be loaded that is missing, but error messages > are displayed for all. > > Possible solution : it **seems** that GS outputs GS<1> when it has treated an > image, and GS> when it has, well, done I am not sure what. So instead of > just counting all prompts and just skip one as current code seems to do, I > would suggest to ignore the GS> prompts. > The following code does this, and solves the problem (for me). > Cheers, That doesn't seem right. GS> means that Ghostscript is waiting for input. GS<1> means that Ghostscript is waiting for input and there is one item left on its stack (which is where PostScript passes data around). I don't think that this should regularly be the case. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: XEmacs code remainder in font-latex.el
Arash Esbati writes: > David Kastrup writes: > >> Arash Esbati writes: >> >>> I'm not sure but the entire (when (fboundp 'built-in-face-specifiers) >>> clause is XEmacs related, right? Can someone with XEmacs installed on >>> HD confirm? Then we can remove it. >> >> So pretty sure that in the context of XEmacs non-support this code >> should be fine to remove. > > Thanks for your prompt reply and the clarification. I deleted that code > and pushed a change (45f0298c) to our repo. Another compilation warning > gone :-) Frankly, I find it inconvenient that a warning gets generated. This kind of guard code to check for version-specific features is not constrained to XEmacs compatibility. -- David Kastrup
Re: XEmacs code remainder in font-latex.el
Arash Esbati writes: > Hi all, > > when building AUCTeX, the compiler complains about: > > In end of data: > font-latex.el:2239:1:Warning: the following functions are not known to be > defined: face-property-instance, set-face-property > > Looking at the code, they are in `font-latex-setup': > > (defun font-latex-setup () > "Setup this buffer for LaTeX font-lock. Usually called from a hook." > (font-latex-set-syntactic-keywords) > ;; Trickery to make $$ fontification be in `font-latex-math-face' while > ;; strings get whatever `font-lock-string-face' has been set to. > (when (fboundp 'built-in-face-specifiers) > ;; Cool patch from Christoph Wedler... > (let (instance) > (mapc (lambda (property) > (setq instance > (face-property-instance 'font-latex-math-face property > nil 0 t)) > (if (numberp instance) > (setq instance > (face-property-instance 'default property nil 0))) > (or (numberp instance) > (set-face-property 'font-lock-string-face property > instance (current-buffer > (built-in-face-specifiers > ... > > I'm not sure but the entire (when (fboundp 'built-in-face-specifiers) > clause is XEmacs related, right? Can someone with XEmacs installed on > HD confirm? Then we can remove it. Christoph Wedler is the author of X-Symbol which was primarily XEmacs based (though the latest versions supported Emacs, but certainly later than this code was written). The whole specifier/instance folderol is XEmacs specific. Git blame assigns this to version 9.8g in 1997 (apparently not yet under version control, commits are per release) and a Changelog entry +Mon Oct 20 10:15:42 1997 Peter S Galbraith + + * font-latex.el: Updated to V0.504 (Oct 20 97) + + * bib-cite.el: Updated to 3.04 (Aug 25 97) + + * hilit-LaTeX.el: Updated to V1.17 (Sep 06 95) At this date, Emacs did not yet have its Emacs 21 display engine released unless I am mistaken. So pretty sure that in the context of XEmacs non-support this code should be fine to remove. -- David Kastrup
Re: reftex-reference and insert \eqref{} not (\ref{})
Uwe Brauer writes:
> Hi
>
> I have not used eqref for ages, but I just learned
> that
> \usepackage{mathtools}
> \mathtoolsset{showonlyrefs=true,showmanualtags=true}
>
>
> does some nice magic, in the sense that it will automatically enumerate
> only these equations which have a reference. That is the option most
> journals, alas, require.
>
> So I tried to play around with the reftex reference style menu but
> reftex-reference always inserts (\ref{}) not \eqref{}
Not my experience for using amsmath and document parsing enabled. Does
the mathtools package load amsmath? If it does, then maybe AUCTeX
should have an appropriate style file?
--
David Kastrup
Re: [AUCTeX-devel] TeXLive 2019 update broke preview-latex (was Re: Typeset LaTeX files with non-ascii file name in TeXLive 2018)
jfbu writes:
> Hi Keita
>
> Le 06/10/2019 à 17:43, Ikumi Keita a écrit :
>> Hi all,
>>
>> It seems that the latest TeXLive 2019 update broke preview-latex. I
>> quote a failure log of the latest pdflatex and a successful log of the
>> pdflatex with the latest update reverted, at the last of this message.
>>
>> At first, I thought that it is only related with non-ascii file names,
>> but it turned out to be not so. Just a plain file name of "abc.tex"
>> fails with the same error.
>>
>> Is this common for others? If so, I suspect that the change in the
>> internal of latex invalidated "\detokenize" that preview-latex uses to
>> input files with non-ascii names successfully.
>>
>> I haven't tested other engines (xelatex and lualatex).
>>
>> I'm afraid that we have to delay the release of AUCTeX 12.2, due to this
>> problem.
>>
>> Regards,
>> Ikumi Keita
>
> The latest LaTeX \input allows spaces in filenames. We see that preview-latex
> invocation is with added spaces at both ends of the filename. It can
> be confirmed with quick testing that \input{ abc.tex } used to work
> but now does not.
>
> Do you remember why the extra spaces added for preview-latex
> invocation?
My guess is historical accident? Plain TeX needs \input abc.tex and I
don't remember changing that, so likely somebody else did while
retaining the braces?
Of course most of the time I try to deflect blame, it turns out I was
the culprit.
Also I don't quite know whether or not "preamble caching" in the form of
mylatex.ltx use could be relevant.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [gs-devel] Asking help for preview-latex
Ikumi Keita writes:
>>>>>> David Kastrup writes:
>>>> The test would be something like
>>>
>>>> /GS_PDF_ProcSet where { pop [put old code here] } if
>>>
>>> Do you mean that the patch listed below should work?
>
>> No. The brackets in [put old code here] were part of the description,
>> not of the code.
>
> Thanks, but the code without those brackets as listed below still gives
> the same error for me.
> I'm now working on a slightly different approach attached with this
> message. The option `preview-pdf-color-adjust-method' determines the
> way how preview-latex works:
>
> (1) New method using DELAYBIND
> Good for gs > 9.27
> Fail with gs <= 9.27
> (2) Traditional method
> Good for gs < 9.27
> Fail with gs >= 9.27 if foreground color isn't trivial
> (3) Fixed "black on white" appearance
> Fallback for gs 9.27 with non-trivial foreground color
>
> Regards,
> Ikumi Keita
>
> - failed patch --
> diff --git a/preview.el.in b/preview.el.in
> index 30bf45bf..cbfeaf11 100644
> --- a/preview.el.in
> +++ b/preview.el.in
> @@ -750,10 +750,12 @@ to Ghostscript floats."
>(let ((fg (aref colors 1)))
> (if fg
> (concat
> + "/GS_PDF_ProcSet where { pop "
>"/GS_PDF_ProcSet GS_PDF_ProcSet dup maxlength dict copy dup begin\
> /graphicsbeginpage{//graphicsbeginpage exec "
>(mapconcat #'preview-gs-color-value fg " ")
> - " 3 copy rg RG}bind store end readonly store "
> + " 3 copy rg RG}bind store end readonly store "
> + "} if "
>
> (defun preview-gs-color-string (colors)
>"Return a string setting up colors"
>
> --
Ok, that's puzzling. It really should have worked.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [gs-devel] Asking help for preview-latex
Ikumi Keita writes:
>>>>>> David Kastrup writes:
>> I don't think that the drawback is necessary: in contrast to a working
>> DELAYBIND, it is easy to test for existence of the PDF dictionary at
>> runtime and use it if available.
>
>> The test would be something like
>
>> /GS_PDF_ProcSet where { pop [put old code here] } if
>
> Do you mean that the patch listed below should work?
No. The brackets in [put old code here] were part of the description,
not of the code.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [gs-devel] Asking help for preview-latex
Ikumi Keita writes:
>>>>>> Ikumi Keita writes:
>> I was just thinking to immigrate to the new code using DELAYBIND, and
>> announce the user to install patched gs-9.27 if in hurry. But it might
>> be a good idea to introduce a new user option to choose between
>> (1) No color transfer, "black on white" appearance
>> (2) New code
>> for the case preview-latex uses PDF backend. Both have own
>> disadvantage, but at least they can avoid errors with customized
>> foreground color of emacs.
>
> How about the attached patch?
>
> I'm not sure whether I'm doing right with respect to suppressing fg/bg
> colors in `preview-gs-color-string', in the above case (1). I don't
> understand what role "mask" and "border" play here, so I suppressed only
> "fg" and "bg" parameters. Maybe I should disable
> `preview-gs-color-string' altogether in the case (1).
>
> This patch brings a drawback for users who customize the background
> color of Emacs and use default foreground color, with unmodified
> gs-9.27. In that case, the background color of the generated images
> will just be white and no longer match with Emacs.
I don't think that the drawback is necessary: in contrast to a working
DELAYBIND, it is easy to test for existence of the PDF dictionary at
runtime and use it if available.
The test would be something like
/GS_PDF_ProcSet where { pop [put old code here] } if
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [gs-devel] Asking help for preview-latex
Ikumi Keita writes: > Hi David, > >>>>>> David Kastrup writes: >> I'll probably pitch in from here (if nobody else does) and write code >> that checks for the availability of any of these features and uses them. > > Do you have a plan to make a progress about this issue? If not, I'll > make a commit based on my previous patch. Well, the principal problem is that Chris stated that one cannot check for the availability of a working DELAYBIND without enabling it, and enabling it will make the document blow up. So I guess we don't have much of a feasible option for now but to disable the color transfer if it's not available, and at some suitably later "safe" point of time enable DELAYBIND (though we possibly could put code there already that can be manually enabled) and update the requirements once DELAYBIND is used by default. Something like that? -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [gs-devel] Asking help for preview-latex
Ikumi Keita writes:
> Hi Chris,
>
>>>>>> Chris Liddell writes:
>> Right, sorry for the delay, as I said, that ended up being a much more
>> involved task than I'd anticipated!
>
> Thanks, the proposed fix works well on my side! The generated image
> turns its color as expected.
>
>> First and foremost (and apologies for this), we can't do anything to get
>> this working in the 9.27 release. Your options are to use 9.26, use the
>> "in-development" code from our repo, or (on Linux systems) convince the
>> package maintainer to pick up the commits listed below.
>
> I tested the ghostscript source of 9.27 release with the three patches
> associated with the listed commits, on FreeBSD 12.0. Though there was
> one rejection when applying the patches at gs_fonts.ps, I could manually
> recover the fail it since it was just straightforward.
>
>> So, in essence, the idea is that you'll remove the stuff using
>> GS_PDF_ProcSet entirely. Add the option -dDELAYBIND to your gs command
>> line, include a suitable redefinition of initgraphics, then call
>> .bindnow, and continue as before.
>
>> The redefinition of initgraphics would look something like:
>
>> /initgraphics {
>> //initgraphics
>> /RG where {
>> pop3 copy rg RG
>> } if
>> } bind def
>
>> So, that first calls the original initgraphics operator. It then checks
>> if the name "RG" is known to any dictionary on the dictionary stack
>> (which will only be the case when being called from the PDF
>> interpreter), and if that is the case, then set fill and stroke colors
>> as you require ("R/G/B value" being place holders for the "real" numbers).
>
>> After that, and before running any more Postscript or PDF, you'd call
>> the .bindnow operator.
>
> Attached is the change I used for preview-latex, for those who are
> interested.
>
> Chris, there is a possibility that we ask you (or the Ghostscript
> development team) to agree to transfer the copyright of the above
> PostScript code of several lines to Free Software Foundation. Are you
> fine to agree if that really happens?
>
> To project admin of AUCTeX (especially David Kastrup): Could you please
> judge whether the PostScript code Chris provided above needs copyright
> assignment in order to incorporate into AUCTeX, and if so, provide
> instruction for him if he is fine to do so?
>
> (Ah, but now the message from David arrived. Maybe he writes relevant
> PS codes by himself.)
Purely straightforward functional code without any significant degree of
creativity (so it will end up looking the same whoever writes it, given
the same information) does not have copyrightable elements anyway. Of
course, that is the best kind of code you could be writing, so bad
programmers enjoy more copyright protection for their output than good
programmers do.
At any rate, I don't see that we need a copyright assignment for that
code scrap. It would not have ended up any differently if I had written
it. I actually have a hard time imagining how you could write it more
complicated than that.
With regard to dealing with the non-working -dDELAYBIND: that could end
up differently. The knowledge about how -dDELAYBIND fails is not
copyrightable, but if the path from that knowledge to code avoiding the
failure is not as straightforward as the above suggestion was, the
situation could end up differently.
All the best
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [gs-devel] Asking help for preview-latex
Chris Liddell writes:
> So, in essence, the idea is that you'll remove the stuff using
> GS_PDF_ProcSet entirely. Add the option -dDELAYBIND to your gs command
> line, include a suitable redefinition of initgraphics, then call
> .bindnow, and continue as before.
>
> The redefinition of initgraphics would look something like:
>
> /initgraphics {
> //initgraphics
> /RG where {
> pop3 copy rg RG
> } if
> } bind def
I'll probably pitch in from here (if nobody else does) and write code
that checks for the availability of any of these features and uses them.
What will be the result of trying to use the broken DELAYBIND? Can I
check/use it in a manner where the worst that will happen is, well,
nothing?
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
bug#36461: 11.90.2.2017-07-25; xemacs21.4.22 mule, problem with window too small (auctex 11.92)
Uwe Brauer writes:
> Hi
>
> I installed a colleague who is running xemacs21.4.22 on Ubuntu 16.04 the
> latest auctex version which is compatible with xemacs, namely 11.92.
>
> While everything works fine when using keys (like C-c C-c)
> when accessing the latex commands via the menu the following error pops
> up
> Debugger entered--Lisp error: (error "Window height 0 too small (after
> splitting)")
>split-window(nil 17)
>mouse-read-file-name-1(file-name-history "Master file (default this
> file): " nil "~/TODO/docencia/prufungen/prueba.tex" nil nil
> read-file-name-internal)
>byte-code("..." [initial-contents must-match default dir prompt
> history mouse-read-file-name-1 completer] 8)
>read-file-name-1(file file-name-history "Master file (default this
> file): " nil "~/TODO/docencia/prufungen/prueba.tex" nil nil
> read-file-name-internal)
>read-file-name("Master file (default this file): " nil nil)
>byte-code("..." [default read-file-name format "Master file (default
> %s): " "this file" nil] 4)
>TeX-master-file-ask()
>TeX-master-file(nil nil t)
>TeX-command-master()
>TeX-command-menu("LaTeX")
>eval((TeX-command-menu "LaTeX"))
That kind of error would happen when you are in the minibuffer when
trying to split a window. Are you sure that clicking on a menu entry
happens while point is still in the main window and the minibuffer is
still inactive?
--
David Kastrup
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#36313: Two installation schemes of AUCTeX
Ikumi Keita writes: >>>>>> Ryo Furue writes: >> I'm utterly confused! I thought the starting point of our discussion was > >> If the default value of `TeX-parse-self' is t, some emacs users who don't >> use AUCTeX will suffer from extra slow down due to the parsing of some >> directory tree. > >> Is the above statement correct or not? > > Actually, I'm not quite sure what David worries about in the quoted > statement. > > Although I can enumerate some cases as quoted below that non-nil > `TeX-parse-self' harms the users, they are more or less exceptional > cases, in my opinion. But I might be missing some critial cases. > > 1. The user who doesn't use AUCTeX opens a big TeX file inadvertently. Try opening a TeX file via Tramp on a non-local connection. >> So, I guess those elisp files in item 3 above are big ones. > > As far as I know, the item 3 is not the case. As I wrote, just > launching emacs without opening TeX files makes no difference due the > value of `TeX-parse-self', if I'm not missing something important. The "resident" portion of AUCTeX setting up the autoloads is pretty small. > (The elisp files loaded when `TeX-parse-self' is t are not so big in > general, but the number of them can be large instead, e.g., when the > opened LaTeX file uses quite many \usepackage's.) AUCTeX searches around a whole lot for finding associated autoparsed files in relation to files it loads. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#36313: 12.1.2; percent symbol in \url{}
Ryo Furue writes: > Dear David and others, > > On Fri, Jun 28, 2019 at 6:04 PM David Kastrup wrote: > >> If you use ELPA for installing it, it is enabled by default. If we >> would aim for AUCTeX only being used as a consequence of deliberate user >> action rather than system administration activity, the defaults would >> likely be different. >> > > First, I apologize in advance, if I misunderstand what you are saying. So, > please bear with me if I do misunderstand it. > >>From your argument in your previous message, I thought that > > (1) the parsing of the TeX installation tree would happen to all > emacs users if the variable is set by default. > > > But according to this latest of yours, it seems that > > (2) the parsing of the TeX installation tree would happen > to those users who explicitly install AUCTeX through ELPA. Or to users subjected to an installation installing AUCTeX in any manner through ELPA. > (The installation of AUCTeX wouldn't happen unless you explicitly do > so. Is that correct?) Who is "you"? You are assuming that maintainer and user of an Emacs binary are identical. That is not necessarily the case. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#36313: 12.1.2; percent symbol in \url{}
Ryo Furue writes: > Dear David and others, > > On Fri, Jun 28, 2019 at 4:16 PM David Kastrup wrote: > >> >> > Thinking more about this issue, I would argue that TeX-parse-self should >> be >> > set to t by default, because >> > >> > Do the right thing (DTRT) by default >> > and optimize, if it's slow. >> >> Have you bothered reading the referenced discussions? > > > Yes I have read it through. > > >> You don't appear >> to bother bringing anything new to it. >> >> Parsing a whole bunch of dependencies isn't the right default for >> someone not interested in AUCTeX or TeX. >> > > I didn't know that AUCTeX is switched on by default for everybody using > emacs. I (wrongly) assumed that AUCTeX was switched on only when you > enable it in your init.el . AUCTeX is supposed to be usable as a system default. It is not delivered as Emacs' built-in TeX mode, but using ELPA for installing it will enable it if I remember correctly, and its pre-ELPA mode for installation is also supposed to be useable in that manner. > Since AUCTeX is enabled by default for everybody and if the parsing > would occur to everybody if the variable is set, your argument is > strong. If you use ELPA for installing it, it is enabled by default. If we would aim for AUCTeX only being used as a consequence of deliberate user action rather than system administration activity, the defaults would likely be different. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#36313: 12.1.2; percent symbol in \url{}
Ryo Furue writes: > Hi Arash, > > Thank you for your kind comments! > > On Fri, Jun 28, 2019 at 4:32 AM Arash Esbati wrote: > >> Does this sentence makes more sense: >> >> If you want to make AUCTeX aware of used LaTeX package in a document >> and multi-file documents right away, insert the following in your >> .emacs file. >> >> If so, we should clarify it. >> > > I've found your rewrite somewhat more informative than the original. > > Thinking more about this issue, I would argue that TeX-parse-self should be > set to t by default, because > > Do the right thing (DTRT) by default > and optimize, if it's slow. Have you bothered reading the referenced discussions? You don't appear to bother bringing anything new to it. Parsing a whole bunch of dependencies isn't the right default for someone not interested in AUCTeX or TeX. But we should probably make it a much stronger point in the manual that people interested enough in AUCTeX to be reading the manual are very likely people wanting to enable full document parsing. > Although I'm not at all professional, I do write little software as > part of my job, and the above is what I always do. Emacs is not just AUCTeX. Emacs is a general-purpose environment, and the defaults must not make it unusable as the go-to document editor/viewer for text file types you don't actually know anything about. > (Perhaps it would be hard to scan the LaTeX directory tree once for > index search?) > Just my two cents. Have you bothered looking at the dozens of dollars already spent on that issue? It is not a new discussion. If you want to change the outcome, you need to bring a substantially new argument. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: [AUCTeX-devel] Try to colorize preview (was Re: Asking help for preview-latex)
Ikumi Keita writes: > [ Recipient lists are trimmed. ] > >>>>>> David Kastrup writes: >>> The links to the old archives of AUCTeX-related ML listed on >>> https://www.gnu.org/software/auctex/mailing-lists.html >>> are all dead (dir.gmane.org is not respoding), so it seems impossible to >>> search in these old archives... > >> The gnu list server has its own search functions. You don't need to go >> via gmane. > > I cannot find the archives of old ML in both > https://lists.gnu.org/mailman/listinfo/ > and > https://lists.gnu.org/archive/html/ > . Only the ML which have "auctex" as substring of its name are the > current ML, which store messages after March 2005. > > Do old archives with messages before March 2005 have names without > "auctex"? Or am I looking in wrong place? Ah right, sorry. preview-latex had its own mailing lists before getting folded into AUCTeX (at which time much of its more involved development had settled already). That would likely be something like <https://sourceforge.net/p/preview-latex/mailman/preview-latex-devel/>. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Try to colorize preview (was Re: Asking help for preview-latex)
Ikumi Keita writes: > Hi David, > >>>>>> David Kastrup writes: >> Ikumi Keita writes: >>> I hope that David comments on this issue. In particular, I'd like to >>> know, or to know to how to judge, whether "the initial colors set up >>> inside of Ghostscript" still interfere with color.sty or not. > >> It's been so long ago that I did this stuff that I don't really remember >> the details. What may be the case is > >> forcing the loading of color.sty is heavy-handed, may bind the output to >> a particular backend (there is, for example, dvipdf for generating PDF >> from DVI, a valid option of further DVI processing) and may be >> incompatible with other color options like using xcolor.sty (or whatever >> it was called). > >> Also color.sty produces additional special codes that may interact with >> typesetting. > >> Doing this at the Ghostscript level instead did not mess with the LaTeX >> processing. > > Thanks, I'll search some way to minimize the impact of forced loading of > color.sty along with the idea Jean proposed. > >> I am not sure whether searching in the bug mailing list will turn up the >> problems that triggered going via this path. > > The links to the old archives of AUCTeX-related ML listed on > https://www.gnu.org/software/auctex/mailing-lists.html > are all dead (dir.gmane.org is not respoding), so it seems impossible to > search in these old archives... The gnu list server has its own search functions. You don't need to go via gmane. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Try to colorize preview (was Re: Asking help for preview-latex)
Ikumi Keita writes:
> Hi Jean,
>
>>>>>> jfbu writes:
>>> I have not looked up in detail (I am still with gs 9.26, and besides I
>>> do not use that much the preview functionality -- hope that is pardonable),
>>> but this small tex file
>>>
>>> \documentclass{article}
>>> \AtBeginDocument{\RequirePackage{color}\pagecolor{yellow}\color{red}}
>>> \begin{document}
>>> \[E = mc^2\]
>>> \end{document}
>>>
>>> works as expected, hence it seems it is quite feasible to alter the PDF
>>> production as suggested by Ken.
>
>> Ah sorry for noise. Problem with fuller example actually using
>
>> \PassOptionsToPackage{active,tightpage,auctex}{preview}\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}[2004/11/05]
>
>> is as I should have expected that the ccolor ommands outside
>> the display math mode are not executed.
>
> Thanks, I was trying similar approach. The attached patch #1 (just
> adding initial TeX codes at execution of pdflatex) works only partially.
> Though the background turns its color as expected, the foreground color
> isn't affected.
>
> The situation changes by further modification in preview.sty with the
> attached patch #2, which uncomments two lines. Together with the above
> patch #1, my intent of setting both the foreground and background colors
> are reflected in the outcome of preview-latex.
>
> However, these two lines in preview.sty (actually in preview.dtx) were
> commmented out at this commit:
> --
> 5dc76f79d0fff44794262037b93f0533af78f805
> Author: David Kastrup
> AuthorDate: Mon Jan 20 00:09:00 2003 +
>
> (subsection{The internals}): comment out color
> setup. That means that one might not be able to use color.sty for
> setting up fore/background color, but it will also mean that
> loading color.sty does not interfere with the initial colors set
> up inside of GhostScript. In the long run, we will have to solve
> this differently.
> --
> If the situation of Ghostscript mentioned in the above commit message
> hasn't changed during this 16 years, the patch #2 would lose at some
> complicated situation.
>
> I hope that David comments on this issue. In particular, I'd like to
> know, or to know to how to judge, whether "the initial colors set up
> inside of Ghostscript" still interfere with color.sty or not.
It's been so long ago that I did this stuff that I don't really remember
the details. What may be the case is
forcing the loading of color.sty is heavy-handed, may bind the output to
a particular backend (there is, for example, dvipdf for generating PDF
from DVI, a valid option of further DVI processing) and may be
incompatible with other color options like using xcolor.sty (or whatever
it was called).
Also color.sty produces additional special codes that may interact with
typesetting.
Doing this at the Ghostscript level instead did not mess with the LaTeX
processing.
I am not sure whether searching in the bug mailing list will turn up the
problems that triggered going via this path.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] xemacs (sigh)
Uwe Brauer writes: >> Uwe Brauer writes: > >> The version has a lot of other changes. XEmacs has been comparatively >> unimportant for a number of years for AUCTeX and vice versa. > > Please don't remind me. It almost hurts me physically to think that such > a great software like xemacs, which had/has features 20 years ago, that > GNU emacs was relatively slow to implement, faded away into the great > abyss of oblivion[1] and that its developer did not really care about > auctex. > > >> Would that have been any different, it might have been possible to >> find someone willing to invest the time and effort for keeping >> XEmacs supported. The end of XEmacs support is not really important >> enough to single out here. > > Well as a long time Xemacs I beg to differ. We have never put any sort of NEWS item into release tags regardless of their importance, and Git release tags may actually even move (as opposed to commits which are a historic record). You just looked in the wrong place, regardless of how important XEmacs may seem to you. >> The only thing that might be worth thinking about is linking to >> (the latest?) news on AUCTeX's web page. > > That would be helpful. AUCTeX's web page is not really a lot to write home about in its current state, really. Linking to AUCTeX's news items might be a bit of improvement. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] xemacs (sigh)
Uwe Brauer writes: >> Uwe Brauer writes: > >> Like with any piece of Emacs, you check the included Info manual. In >> particular, you look in the respective "News" or "Changes" section in >> the respective manual. > > > [Snip]... > > >> Commit messages are _absolutely_ not the place for collecting >> release-relevant information. They are supposed to describe the >> particular changes affected by a particular commit, not changes by >> some unspecific series of commits preceding it. > > Ok, I will not argue with you about this issue since you have much more > experience in maintaining a software project, that I have. > > That commit has a tag (at least it appears so when converted to > mercurial, that is why I personally would have added something like > (last version which works with Xemacs, for details see the manual or so) The version has a lot of other changes. XEmacs has been comparatively unimportant for a number of years for AUCTeX and vice versa. Would that have been any different, it might have been possible to find someone willing to invest the time and effort for keeping XEmacs supported. The end of XEmacs support is not really important enough to single out here. The summary of changes is listed in a Changes/NEWS file rather than in commit messages. It has been announced with the release messages <https://lists.gnu.org/archive/html/info-auctex/2017-12/msg1.html>. It has been that way for literally dozens of years with AUCTeX, for quite longer than we have been using Git. You have been looking in a quite unusual place for the information you sought, and I should be surprised if you'd have much success with that approach for other software. The only thing that might be worth thinking about is linking to (the latest?) news on AUCTeX's web page. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] xemacs (sigh)
Uwe Brauer writes: >> On Tue, 18 Jun 2019 at 13:54, Uwe Brauer wrote: > >> You should ask your colleague why they're using such an old version :-) > > Because I did not bother to upgrade for them (since I switched to GNU > emacs and everything was fine till now. > >> We can't edit history (this principle is probably even more important >> in Mercurial than in git), I'm not sure what you expect us to do. > > Oh just some hint in the log message that 11.92 is the last version > compatible with xemacs: If you wouldn't have told me, I did not know to > figure that out (besides using google) Like with any piece of Emacs, you check the included Info manual. In particular, you look in the respective "News" or "Changes" section in the respective manual. (info "(AUCTeX) Changes") [...] News in 12.1 * AUCTeX now requires GNU Emacs 24 or higher. Support for XEmacs has been dropped. * Besides the change in the supported version of Emacs, there has been no functional change in this release, which is equivalent to version 11.92. Commit messages are _absolutely_ not the place for collecting release-relevant information. They are supposed to describe the particular changes affected by a particular commit, not changes by some unspecific series of commits preceding it. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
bug#35696: [AUCTeX-devel] bug#35696: preview-latex does not work under any Emacs themes and bug#35571: 12.1; Changing foreground breaks previews
Ikumi Keita writes: > Hi all, > > Now I have some spare time, so I'd like to continue to discuss what we > should do about this issue. > I'm now a bit inclined to take the option (2) and ask gs-devel to > provide suitable Postscript(?) code for preview-latex. What do others > think? Definitely worth a try, mentioning that this has to go through pdf2dsc . -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: [AUCTeX-devel] bug#35696: preview-latex does not work under any Emacs themes and bug#35571: 12.1; Changing foreground breaks previews
Ikumi Keita writes: > Hi all, > > Now I have some spare time, so I'd like to continue to discuss what we > should do about this issue. > I'm now a bit inclined to take the option (2) and ask gs-devel to > provide suitable Postscript(?) code for preview-latex. What do others > think? Definitely worth a try, mentioning that this has to go through pdf2dsc . -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
bug#35696: preview-latex does not work under any Emacs themes and bug#35571: 12.1; Changing foreground breaks previews
Ikumi Keita writes:
>>>>>> David Kastrup writes:
>>> Thanks for your advice, the attached patch works well. The foreground
>>> color of the generated image matches with the default face of emacs
>>> without `preview-pdf-color-string', at least for gs 9.27 on my machine.
>
> Ah, my bad, I was looking at the outcome of dvipng, not pdf2dsc. After
> I changed my setup to use pdf2dsc, the foreground color is just black.
> Especially, on the theme with dark background, math formulae are hard to
> read. So this patch does not make sense. Sorry.
>
>> Ah, that removes the functionality completely. Since this patch sets up
>> a per-page hook, it would be my guess that this was supposed to guard
>> against cases where some images set up or leave their own page-wide
>> color (possibly just using \usepackage{color} is enough to cause
>> trouble). Maybe it's the best we can do for now. No idea.
>
> Now I'm wondering where "the last change to these code lines" mentioned
> in your previous reply. The command
> "git log --grep=preview-pdf-color-string"
> shows only two entries for me:
> commit c5fe24eb9d59ff06be73f13d1a8c0a21885bc08c
> Author: Ralf Angeli
> Date: Wed Jun 8 07:16:21 2005 +
>
> commit ed3cdfa35a8fd9a3df2954ef62f93b70459d872f
> Author: David Kastrup
> Date: Tue Apr 12 15:12:39 2005 +
>
> The former involves only texinfo document change, so only meaningful
> commit is the latter. But the function `preview-pdf-color-string' was
> first introduced in the latter commit, and it already had exactly the
> same form as today at that time. I suppose the function has never
> changed since then.
Ah, you are right. Sorry for the confusion.
--
David Kastrup
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#35696: preview-latex does not work under any Emacs themes and bug#35571: 12.1; Changing foreground breaks previews
Ikumi Keita writes:
>>>>>> David Kastrup writes:
>> The current code is already a sledgehammer that looks like a "not again"
>> approach of evading yet another changed API. Looking at the history of
>> the recommended replacements, I see that the Ghostscript developers
>> state that some of those were removed in some Ghostscript versions but
>> reinstated.
>
>> So it's conceivable that reverting the last change to these code lines
>> is all that it would take to work with current Ghostscript (at the price
>> of breaking _some_ older version).
>
>> Might be worth a try.
>
> Thanks for your advice, the attached patch works well. The foreground
> color of the generated image matches with the default face of emacs
> without `preview-pdf-color-string', at least for gs 9.27 on my machine.
>
>> (at the price of breaking _some_ older version).
>
> I don't know which version of gs needs `preview-pdf-color-string'.
> Maybe we should not delete it and instead introduce a user option as a
> flag whether to disable the function or not. What do others think?
Ah, that removes the functionality completely. Since this patch sets up
a per-page hook, it would be my guess that this was supposed to guard
against cases where some images set up or leave their own page-wide
color (possibly just using \usepackage{color} is enough to cause
trouble). Maybe it's the best we can do for now. No idea.
--
David Kastrup
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#35696: preview-latex does not work under any Emacs themes and bug#35571: 12.1; Changing foreground breaks previews
Ikumi Keita writes: > [Adding auctex-de...@gnu.org in To: field may result in too many > duplicated delivery of this message, so I refrain from doing so.] > > Hi David and all, > >>>>>> David Kastrup writes: > >> It never was a problem for myself since my windows are black on white. >> This code is for people who expect preview-latex to do something more >> useful than the default on other setups. > > Thanks for confirmation. I understand your point of view. > > Then, I'd like to ask other developers what we should do. Some options > which came to my mind, in no particular order, are: > > (1) Make `preview-pdf-color-string' just a no-op and drop the feature > to match the foreground color of the generated image with the default > face of emacs. The current code is already a sledgehammer that looks like a "not again" approach of evading yet another changed API. Looking at the history of the recommended replacements, I see that the Ghostscript developers state that some of those were removed in some Ghostscript versions but reinstated. So it's conceivable that reverting the last change to these code lines is all that it would take to work with current Ghostscript (at the price of breaking _some_ older version). Might be worth a try. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#35571: bug#35696: preview-latex does not work under any Emacs themes and bug#35571: 12.1; Changing foreground breaks previews
Ikumi Keita writes: >>>>>> David Kastrup writes: >>> Are you thinking that it isn't fruitful to follow up the development of >>> ghostscript every time incompatible change is introduced? > >> No since the changes tend to be completely arbitrary. It's absolutely >> not fruitful but exasperating. That doesn't mean that it's not >> necessary. > >> In this particular case, this is partly related to _not_ using >> GhostScript as PDF interpreter but instead using pdftodsc and then >> working with the resulting not-quite-standard PostScript. This >> minimises the amount of knowledge and code required to make this work >> but necessitates working with interfaces of Ghostscript that its >> developers feel no obligation to provide some consistency for. > >> Changing the operation in a manner foregoing pdftodsc would likely make >> preview-latex less vulnerable to this kind of recurring API change. > > I infer from what you wrote that you don't have intent to fix the > problem for yourself, at least for now. Right? It never was a problem for myself since my windows are black on white. This code is for people who expect preview-latex to do something more useful than the default on other setups. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#35571: bug#35696: preview-latex does not work under any Emacs themes and bug#35571: 12.1; Changing foreground breaks previews
Ikumi Keita writes: > Hi David, > >>>>>> David Kastrup writes: >> The usual "oh, we decided change is good and clobbered over the previous >> API." Presumably one of the listed hooks can be used instead, possibly >> mimicking what the mentioned patch does to lib/pdf2dsc.ps . > > Are you thinking that it isn't fruitful to follow up the development of > ghostscript every time incompatible change is introduced? No since the changes tend to be completely arbitrary. It's absolutely not fruitful but exasperating. That doesn't mean that it's not necessary. In this particular case, this is partly related to _not_ using GhostScript as PDF interpreter but instead using pdftodsc and then working with the resulting not-quite-standard PostScript. This minimises the amount of knowledge and code required to make this work but necessitates working with interfaces of Ghostscript that its developers feel no obligation to provide some consistency for. Changing the operation in a manner foregoing pdftodsc would likely make preview-latex less vulnerable to this kind of recurring API change. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#35696: preview-latex does not work under any Emacs themes and bug#35571: 12.1; Changing foreground breaks previews
Ikumi Keita writes: > Hi Gennady and Hua, > >>>>>> Gennady Uraltsev writes: >> Hello, >> It seems to be the same problem as I posted here: > >> http://lists.gnu.org/archive/html/bug-auctex/2019-05/msg0.html > > Both confirmed. David, do you have any outlook about this problem? preview-pdf-color-string seems to be the seminal problem. > It seems that gs 9.27 is incompatible with preview-latex when the > default face has non-trivial foreground color. When the preview fails > and I right-click the "do not enter" sign to select "View error", the > *Preview-Ghostscript-Error* buffer pops up and shows the error quoted > at the last of this message. It tells that "GS_PDF_ProcSet" caused > the error and I found that the official ghostscript document says "We > eliminated GS_PDF_ProcSet" in [1]. > > Best regards, > Ikumi Keita > > [1] https://www.ghostscript.com/doc/9.27/History9.htm 2019-03-19 09:25:48 -0700 Ray Johnston ebbb3ec7d20b5f4c444eb11fc9835e07229ccbd9 Fix lib/pdf2dsc.ps to use documented Ghostscript pdf procedures. We eliminated GS_PDF_ProcSet and pdfdict, but runpdfbegin, dopdfpages, and runpdfend are still available. lib/pdf2dsc.ps The usual "oh, we decided change is good and clobbered over the previous API." Presumably one of the listed hooks can be used instead, possibly mimicking what the mentioned patch does to lib/pdf2dsc.ps . -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#35758: Build failure with Emacs master branch
Tassilo Horn writes: > Arash Esbati writes: > > Hi Arash, > >>> Anyway, `update-file-autoloads' allows to specify the autoload file >>> as third argument instead of binding `generated-autoload-file', so >>> I'm using that now. Pushed to master. I'm closing this issue. >> >> thanks for fixing this. It was also reported by Vladimir[1] and I'm >> CC'ing him to let him know that this issue is resolved. I was also >> thinking about a similar solution :-) > > Ah, I haven't read that. But now after reading that commit e08e0880f9's > message which Vladimir mentioned in his report, it all makes sense now. > Before I couldn't understand what's going on because autoload.el uses > lexical binding since 2012 according to its local variables prop line > (is lexical binding in Emacs really that old?). The local variables prop line would have to have been added in the lexical binding _branch_ already before getting folded into Emacs proper. But 7 years is short in Emacs development times. I don't think it's been much younger since it was all-in. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
Re: [AUCTeX-devel] TeX-next-error
Stefan Monnier writes: > Is there a particular reason why AUCTeX doesn't make use of > next-error-function and remaps `next-error` via the keymap instead? I don't really remember. It may have something to do with XEmacs compatibility which no longer is something we are bothered with. Though I think keybinding and implementation and functionality of TeX-next-error are much older than next-error-function, so the remap may just have been an afterthought for a closer connection to the semantics of next-error and no further work was invested after it worked. git blame shows cb75d25f1 (Ralf Angeli2005-05-28 16:21:47 + 4998) ;; Remap bindings of `next-error' 6cb1e7deb (Mosè Giordano 2017-12-17 01:34:21 +0100 4999) (define-key map [remap next-error] 'TeX-next-error) cb75d25f1 (Ralf Angeli2005-05-28 16:21:47 + 5000) ;; Remap bindings of `previous-error' 6cb1e7deb (Mosè Giordano 2017-12-17 01:34:21 +0100 5001) (define-key map [remap previous-error] 'TeX-previous-error) with commit cb75d25f1d21b84e0f99477e6cd96bd7657d683b Author: Ralf Angeli Date: Sat May 28 16:21:47 2005 + (TeX-mode-map): Remap bindings of `next-error' and `previous-error' to `TeX-next-error' and `TeX-previous-error' respectively. and commit 6cb1e7deb69a199949926f4a2b33c2bb6b250c13 Author: Mosè Giordano Date: Sun Dec 17 01:34:21 2017 +0100 Remove XEmacs compatibility code in tex.el * tex.el (TeX-source-correlate-gnuserv-p): (TeX-source-correlate-map): (VirTeX-common-initialization): (TeX-mode-map): (TeX-search-syntax-table): Remove code for compatibility with XEmacs. So XEmacs compatibility has been there initially and may have played into the concept of what was done (possibly trying to keep the system dependency confined to as small a space as possible). And the original code is from 2005. Looking at the age of next-error-function, I see commit 50f007fb09bc893294d0229e339e770e16a22f2b Author: Kim F. Storm Date: Wed Apr 21 21:36:15 2004 + From: Teodor Zlatanov (next-error-last-buffer, next-error-function): New variables for the next-error framework. (next-error-buffer-p): New function. (next-error-find-buffer): Generalize compilation-find-buffer. (next-error, previous-error, first-error, next-error-no-select) (previous-error-no-select): Move from compile.el. and in 2005 we certainly would not have wanted to depend on code introduced as recently as 2004. So the answer is very likely "historical". -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [AUCTeX-diffs] GNU AUCTeX branch, master, updated. 097084443771d6716c6870f2f8d329e9c0949d97
Ikumi Keita writes: > Hi David, > >>>>>> David Kastrup writes: > >> Uh, preview-latex already _had_ code for doing that. Doesn't it work? > > No, the previous code excluded raw 8-bit bytes which already existed in > the output of latex. It only processed raw 8-bit bytes embedded in the > form of ^^ab because of the regexp "[\x00-\x7F]+". > > I changed it to "[\x00-\xFF]+" to process all the raw 8-bit bytes > together at decoding with the relavant coding system. That does not cover raw bytes since they are not in the range 00-ff in Emacs multibyte characters. So that expression would only work for bytes in buffers decoded from files considered to be in Latin-1 encoding. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [AUCTeX-diffs] GNU AUCTeX branch, master, updated. 097084443771d6716c6870f2f8d329e9c0949d97
"Ikumi Keita" writes: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "GNU AUCTeX". > > The branch, master has been updated >via 097084443771d6716c6870f2f8d329e9c0949d97 (commit) > from 1ea64fffc1429db6b5b8712bb68499c48cf2124b (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log - > commit 097084443771d6716c6870f2f8d329e9c0949d97 > Author: Ikumi Keita > Date: Tue Oct 30 22:33:14 2018 +0900 > > Deal with partial ^^-quoting in preview-latex > > If latex outputs a multibyte character as a mixture of raw 8-bit byte > and byte with ^^-quoting, we have to decode them as a whole. > > * preview.el.in (preview--decode-^^ab): Include raw 8-bit bytes which > already exist in the string as well when decoding with the given > coding system. > * tests/latex/preview-latex-test.el: New test. Uh, preview-latex already _had_ code for doing that. Doesn't it work? A grep in the old code shows preview.el.in: "Turn STRING with potential ^^ sequences into a regexp. preview.el.in:so the character represented by ^^^ preceding extended characters preview.el.in:;; Next, bytes with value from 0x80 to 0xFF represented with ^^ preview.el.in:(preview--decode-^^ab string preview.el.in:(defun preview--decode-^^ab (string coding-system) preview.el.in: "Decode ^^ sequences in STRING with CODING-SYSTEM. preview.el.in:Sequences of control characters such as ^^I are left untouched. preview.el.in: (preview--convert-^^ab preview.el.in:(defun preview--convert-^^ab (string) preview.el.in: "Convert ^^ sequences in STRING to raw 8bit. preview.el.in:Sequences of control characters such as ^^I are left untouched. preview.el.in: ;;ok, transform ^^ sequences -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX] How to modify TeX-view-program-selection
Joost Kremers writes: > On Thu, Sep 13 2018, David Kastrup wrote: >> Joost Kremers writes: >>> Really? I mean, true, I see it a lot in (mostly older) config >>> snippets Google spits up, but I thought it was generally discouraged >>> to use a hook if there's no need for it, because it's not always as >>> harmless as this example. (In fact, I've run into problems with it >>> myself from time to time.) >> >> Well, how do you modify stuff that isn't defined yet? I don't see >> much of an option other than using a hook or its equivalent. > > Isn't that what `eval-after-load' and `with-eval-after-load' are for? "or its equivalent". It's not like I haven't mentioned that option as well here. -- David Kastrup ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] How to modify TeX-view-program-selection
Joost Kremers writes: > On Thu, Sep 13 2018, David Kastrup wrote: >> Joost Kremers writes: >> >>> (add-to-list 'TeX-view-program-selection '((output-pdf "Zathura"))) >>> >>> in your init file. >> >> Ah, but that depends on TeX-view-program-selection already being >> defined. You'd have to put this into an eval-after-load incantation >> or >> similar for this to work reliably. > > My apologies, you are of course right. I do this sort of stuff in a > use-package declaration in the :config section, which is executed > after the package is loaded, so I tend to forget about > eval-after-load. > >>> Doing it in LaTeX-mode-hook means it's executed each time you open >>> a >>> LaTeX file, which is harmless but unnecessary. >> >> But the usual way to do such stuff. > > Really? I mean, true, I see it a lot in (mostly older) config snippets > Google spits up, but I thought it was generally discouraged to use a > hook if there's no need for it, because it's not always as harmless as > this example. (In fact, I've run into problems with it myself from > time to time.) Well, how do you modify stuff that isn't defined yet? I don't see much of an option other than using a hook or its equivalent. -- David Kastrup ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] How to modify TeX-view-program-selection
Joost Kremers writes: > On Thu, Sep 13 2018, Greg Bognar wrote: >> (add-hook 'LaTeX-mode-hook'(lambda () >> (add-to-list 'TeX-view-program-selection >> '((output-pdf "zathura"))) >> )) > > There's no need to do this in LaTeX-mode-hook, it should be enough to > have > > (add-to-list 'TeX-view-program-selection '((output-pdf "Zathura"))) > > in your init file. Ah, but that depends on TeX-view-program-selection already being defined. You'd have to put this into an eval-after-load incantation or similar for this to work reliably. > Doing it in LaTeX-mode-hook means it's executed each time you open a > LaTeX file, which is harmless but unnecessary. But the usual way to do such stuff. -- David Kastrup ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX-devel] question regarding installation under Windows
michael malone writes: > I am not a programmer but I require the use of Emacs/auctex in Windows > so I can work in latex using voice recognition. > > Because I’m not a programmer the issues or questions I may have may be > very basic so apologies. > > I am following the detailed instructions for installing auctex found > here > https://www.gnu.org/software/auctex/manual/auctex/Installation-under-MS-Windows.html We probably should overhaul our installation instructions. Emacs comes with a package manager these days, and AUCTeX is available from there. So if you get an Emacs installed and do M-x package-list-packages RET you should be able to find AUCTeX in that list and install it (using "i" I think). I don't think you should be experiencing problems under Windows; be sure to report back either way. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX] Insert counter in Emacs tex file
Rodolfo Medina writes: > David Kastrup writes: > >> With regard to functions: instead of using keyboard macros, you can >> first call some complex command like query-replace-regexp, then use >> >> C-x ESC ESC (translated from C-x ) runs the command >> repeat-complex-command (found in global-map), which is an interactive >> compiled Lisp function in ‘simple.el’. >> >> It is bound to , , C-x M-:, C-x M-ESC. >> >> (repeat-complex-command ARG) >> >> Edit and re-evaluate last complex command, or ARGth from last. >> A complex command is one which used the minibuffer. >> The command is placed in the minibuffer as a Lisp form for editing. >> The result is executed, repeating the command as changed. >> If the command has been changed or is not the most recent previous >> command it is added to the front of the command history. >> You can use the minibuffer history commands M-n and M-p >> to get different commands to edit and resubmit. >> >> [back] >> >> in order to get "a Lisp form for editing" which you can copy and paste >> into a function definition. > > > Is it possible to have the same thing for any command previously given, not > only the complex ones...? Also `M-a', `C-f'...? Doesn't C-h k M-a give sufficient information for those? -- David Kastrup ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] Insert counter in Emacs tex file
Rodolfo Medina writes:
> David Kastrup writes:
>
>> Joost Kremers writes:
>>
>>> On Fri, Aug 24 2018, Rodolfo Medina wrote:
>>>> Hi all...
>>>>
>>>> In a MusiXTeX document, you insert several \bar(s) TeX commands,
>>>> that I
>>>> manually count typing a number next to each occurence of `\bar':
>>>>
>>>> \bar %1
>>>> ...
>>>> \bar %2
>>>> ...
>>>> \bar %3
>>>>
>>>> and so on. Of course, it gets very uncomfortable when editing the
>>>> document and
>>>> adding, in the middle of it, new \bar-s: then I have to re-write all
>>>> the
>>>> numbers, that may be dozens or hundreds...! So I was wondering if
>>>> was possible
>>>> to have an automatic \bar numbering within my Emacs tex file...
>>>
>>> I have a bunch of functions to help me with something similar. The
>>> following function allows me to renumber counters used as labels in a
>>> TeX document:
>>
>> [...]
>>
>> It's worth pointing out that query-replace-regexp can accept calculated
>> replacement texts.
>>
>> So one can write stuff like
>>
>> C-M-% \\bar %[0-9]+ RET \\bar %\,(+ 15 \#) RET
>>
>> in order to replace the respective statements, with the first
>> replacement getting the number 15 then (assuming that you don't need to
>> replace anything before that).
>>
>> The documentation mentions:
>>
>>For computing replacement strings for ‘\,’, the ‘format’ function is
>> often useful (*note (elisp)Formatting Strings::). For example, to add
>> consecutively numbered strings like ‘ABC00042’ to columns 73 to 80
>> (unless they are already occupied), you can use
>>
>> M-x replace-regexp ^.\{0,72\}$
>> \,(format "%-72sABC%05d" \& \#)
>>
>> which is a bit tongue-in-cheek since it refers to conventions used for
>> mitigating the damage from dropping stacks of punch cards.
>
>
> Thank you, Joost and David... Sometimes my occurrences of `\bar' do not have
> a
> number at all... So I thought that, for the moment, I can adopt the
> replace-regexp for my purposes... In two steps... So I defined two kbd
> macros: my-cancel-bar-numbers and my-number-bars, getting the following (ugly
> but working) code in my .emacs:
>
> (fset 'my-cancel-bar-numbers
>[?\M-h ?\M-x ?r ?e ?p ?l ?a tab ?r ?e tab ?g tab return ?\\ ?\\ ?b ?a ?r ?
> ?% ?\[ ?0 ?- ?9 ?\] ?+ return ?\\ ?\\ ?b ?a ?r return])
>
> (fset 'my-number-bars
>[?\M-h ?\M-x ?r ?e ?p ?l ?a ?c tab ?r ?e ?g tab return ?\\ ?\\ ?b ?a ?r
> return ?\\ ?\\ ?b ?a ?r ? ?% ?\\ ?, ?\( ?+ ? ?2 ? ?\\ ?# ?\) return])
>
> Then I defined:
>
> (defun my-reset-bar-numbers ()
> (interactive)
> (execute-kbd-macro (symbol-function 'my-cancel-bar-numbers))
> (execute-kbd-macro (symbol-function 'my-number-bars)))
>
> that acts within a single paragraph/music-piece as I want. Just two things:
> when I want to `undo' my-reset-bar-numbers, I need hitting `C-/' twice: not
> possible to undo it with a single `C-/'? (Maybe those two kbd macros may
> become one function that replaces any line including `\bar' with `\bar
> %[0-9]+'?) And secondily... well, just for eye's pleasure, I'd like to
> replace those fset(s) above with two functions...
Cf.
combine-change-calls is a Lisp macro in ‘subr.el’.
(combine-change-calls BEG END BODY)
Evaluate BODY, running the change hooks just once.
BODY is a sequence of lisp forms to evaluate. BEG and END bound
the region the change hooks will be run for.
Firstly, ‘before-change-functions’ is invoked for the region
(BEG END), then the BODY forms are evaluated with
‘before-change-functions’ and ‘after-change-functions’ bound to
nil, and finally ‘after-change-functions’ is invoked on the
updated region. The change hooks are not run if
‘inhibit-modification-hooks’ is initially non-nil.
The result of ‘combine-change-calls’ is the value returned by the
last of the BODY forms to be evaluated. BODY may not make a
different buffer current, except temporarily. BODY may not
change the buffer outside the specified region. It must not
change ‘before-change-functions’ or ‘after-change-functions’.
Additionally, the buffer modifications of BODY are recorded on
the buffer’s undo list as a single (apply ...) entry containing
the function ‘undo--wrap-and-run-primitive-undo’.
[back]
With regard to functions: instead of using keyboard macros, you can
first call some complex command like query-replace-regexp, then use
C-x ESC ESC (translated from C-x ) runs the command
repeat-complex-comma
Re: [AUCTeX] Insert counter in Emacs tex file
Joost Kremers writes:
> On Fri, Aug 24 2018, Rodolfo Medina wrote:
>> Hi all...
>>
>> In a MusiXTeX document, you insert several \bar(s) TeX commands,
>> that I
>> manually count typing a number next to each occurence of `\bar':
>>
>> \bar %1
>> ...
>> \bar %2
>> ...
>> \bar %3
>>
>> and so on. Of course, it gets very uncomfortable when editing the
>> document and
>> adding, in the middle of it, new \bar-s: then I have to re-write all
>> the
>> numbers, that may be dozens or hundreds...! So I was wondering if
>> was possible
>> to have an automatic \bar numbering within my Emacs tex file...
>
> I have a bunch of functions to help me with something similar. The
> following function allows me to renumber counters used as labels in a
> TeX document:
[...]
It's worth pointing out that query-replace-regexp can accept calculated
replacement texts.
So one can write stuff like
C-M-% \\bar %[0-9]+ RET \\bar %\,(+ 15 \#) RET
in order to replace the respective statements, with the first
replacement getting the number 15 then (assuming that you don't need to
replace anything before that).
The documentation mentions:
For computing replacement strings for ‘\,’, the ‘format’ function is
often useful (*note (elisp)Formatting Strings::). For example, to add
consecutively numbered strings like ‘ABC00042’ to columns 73 to 80
(unless they are already occupied), you can use
M-x replace-regexp ^.\{0,72\}$
\,(format "%-72sABC%05d" \& \#)
which is a bit tongue-in-cheek since it refers to conventions used for
mitigating the damage from dropping stacks of punch cards.
--
David Kastrup
___
auctex mailing list
auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex
bug#32345: 12.1.1; wrong preview position for four-byte utf-8 encoded character (xelatex)
jfbu writes: > Le 02/08/2018 à 15:06, jfbu a écrit : >> There is a problem here with xetex error logs. > > I opened an upstream ticket > > https://sourceforge.net/p/xetex/bugs/154/ I guess that's the best bet. preview-latex has special code to deal with 8-bit engines putting line breaks in the middle of multibyte characters or ^^-quoting only some of them. It would likely be possible to teach it to also deal with the XeTeX-specific current situation, but it would likely end up being a nightmare to maintain. -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
