Re: [AUCTeX-devel] Plan for a new release? [Was: preview.sty included in GNU ELPA problematic]
Mosè Giordano writes: > Hi Ralf, > > 2014-09-02 20:00 GMT+02:00 Ralf Angeli : >> * Mosč Giordano (2014-09-02) writes: >> >>> for the release process we should follow the "Distributions" section >>> of the GNU Maintainer guide, right? I can build and sign all >>> tarballs, including XEmacs and Windows ones, but who will send the >>> packages to the FTP server? For what is worth, I haven't gone through >>> the process to automate FTP uploads yet. >> >> Up till the last release I've done the uploads for some time. So if you >> don't want to register at the moment, I can do the upload without much >> hassle. >> > > Ok, thank you. > >>> In the Makefile, the default shell is a generic /bin/sh, but in the >>> release-sign rule there is a "read -sp" command which is, AFAIK, >>> specific to "bash" and /bin/sh doesn't necessarily points to bash (in >>> Debian and derivates it doesn't). The "-p" option can be replaced by >>> a preceding "echo -n" message, the "-s" option doesn't have a generic >>> replacement. A solution could be to set the shell to /bin/bash, >>> another could be to replace the read "-p" option with the "echo" and >>> drop the "-s" option. >> >> Hm, I haven't had trouble with the command and I've been using Debian >> all along. But perhaps they changed the default shell since the last >> AUCTeX release? Did the command fail in your case? > > Yes, the release-sign rule fails for me unless I set the shell to > /bin/bash in the command line. The dash has been being the default > /bin/sh for Ubuntu since 2006 and for Debian since 2011. One can surround the read command with stty -echo read ... stty echo in order to switch off echoing. Of course, if things crash just there, people will get annoyed at the state of the terminal... -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Support for AnonymousPro.sty
Mosè Giordano writes: > 2014-11-03 8:39 GMT+01:00 Tassilo Horn : >> And please also add the new styles to STYLESRC in Makefile.in. > > From time to time I wonder why we don't use > STYLESRC = $(wildcard style/*.el) Because it is a total nuisance when you start developing something without checking it in and your repository becomes unworkable until you've finished. Also it is a total nuisance when you are compiling one version, have started editing on some file without saving (since you are compiling), and the compilation fails when it tries to compile your autosave file. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] change: documents with $$ to \begin{documents}
Uwe Brauer writes:
> Hi[1]
>
> Sometimes I receive documents with have basically only
> $$
> \int f =0
> $$
> constructions instead of say
> \begin{displaymath} or {equation*} etc.
>
> Anybody has a idea how to change the evil $$ to true latex constructs by
> using sophisticated regexp?
Not all that sophisticated.
M-% \$\$\(.*?\)\$\$ RET \\begin{equation*}\1\\end{equation*} RET
Note the use of .*? (non-greedy match) instead of .* here.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] change: documents with $$ to \begin{documents}
Uwe Brauer writes:
>>> "David" == David Kastrup writes:
>
>> Uwe Brauer writes:
>>> Hi[1]
>>>
>>> Sometimes I receive documents with have basically only
>>> $$
>>> \int f =0
>>> $$
>>> constructions instead of say
>>> \begin{displaymath} or {equation*} etc.
>>>
>>> Anybody has a idea how to change the evil $$ to true latex constructs by
>>> using sophisticated regexp?
>
>> Not all that sophisticated.
>
>> M-% \$\$\(.*?\)\$\$ RET \\begin{equation*}\1\\end{equation*} RET
>
> Thanks, but
>
>
> M-% is bound in Xemacs 21.5.33 and GNU emacs 24.1 to
> query-replace but it
> this should be query-replace-regexp, right?
Yes, C-M-%, sorry for that.
> Your code works for constructions like
>
> $$ \int $$
>
> But not for
> $$
> \int
> $$
Well, yes. Instead of . you need \(.\|^J\) or \SS (that's a bad cheat:
any character with a syntax class other than S which does not exist as
far as I know).
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] change: documents with $$ to \begin{documents}
Uwe Brauer writes: >> Uwe Brauer writes: > > Thanks for the rapid answer. > > >> Well, yes. Instead of . you need \(.\|^J\) or \SS (that's a bad cheat: >> any character with a syntax class other than S which does not exist as >> far as I know). > > Since I was not entirely sure about your answer I tried out the following > > > second \$\$\(\SS*?\)\$\$, works in GNU emacs but not in Xemacs > third \$\$\(.\|^J*?\)\$\$ does not work in both > forth \$\$\(\(.\|^J\)*?\)\$\$ does not work in both You have to enter ^J as C-q C-j -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] GNU emacs: 24.4.1 auctex 11.88: installation problem: style files
Uwe Brauer writes: > Hello > > I apologize if I miss here something elementary. > > Here is what I do: > > - I unpack auctex-11.88 in ~/emacs/site-lisp/packages/auctex-11.88/ > > - I run ./configure EMACS=/opt/emacs24/bin/emacs >(nothing more no pkg directory is specified) > > - I run make > > - I don't run make install I don't think that we have installation instructions telling you not to run "make install". Did you take a look at the installation instructions? They are in the manual and should also be available as a separate text file called INSTALL. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] GNU emacs: 24.4.1 auctex 11.88: installation problem: style files
Uwe Brauer writes: >> Uwe Brauer writes: > >> I don't think that we have installation instructions telling you not to >> run "make install". Did you take a look at the installation >> instructions? They are in the manual and should also be available as a >> separate text file called INSTALL. > > > The following configure option lead to a successful > make and > make install > ./configure --with-emacs=/opt/emacs24/bin/emacs > --prefix=/home/oub/ALLES/ > --with-lispdir=/home/oub/emacs/site-lisp/packages/auctex-11.88 > --without-texmf-dir > > The problem is I set in the init file > > (setq load-path (cons (expand-file-name > "~/emacs/site-lisp/packages/auctex-11.88") load-path)) > (setq load-path (cons (expand-file-name > "~/emacs/site-lisp/packages/auctex-11.88/auctex") load-path)) > > > But then again have the style file problem. All the files like beamer.el > are not found and the relevant commands of course neither. > > I am getting desperate. When all else fails, read the instructions. I quote from INSTALL: 6 Installation for non-privileged users *** Often people without system administration privileges want to install software for their private use. In that case you need to pass more options to the `configure' script. For XEmacs users, this is fairly easy, because the XEmacs package system has been designed to make this sort of thing practical: but GNU Emacs users (and XEmacs users for whom the package system is for some reason misbehaving) may need to do a little more work. The main expedient is using the `--prefix' option to the `configure' script, and let it point to the personal home directory. In that way, resulting binaries will be installed under the `bin' subdirectory of your home directory, manual pages under `man' and so on. It is reasonably easy to maintain a bunch of personal software, since the prefix argument is supported by most `configure' scripts. You'll have to add something like `/home/myself/share/emacs/site-lisp' to your `load-path' variable, if it isn't there already. XEmacs users can achieve the same end by pointing `configure' at an appropriate package directory (normally `--with-packagedir=~/.xemacs/xemacs-packages' will serve). The package directory stands a good chance at being detected automatically as long as it is in a subtree of the specified PREFIX. and: 4 Loading the package * You can detect the successful activation of AUCTeX and preview-latex in the menus after loading a LaTeX file like `preview/circ.tex': AUCTeX then gives you a `Command' menu, and preview-latex gives you a `Preview' menu. For XEmacs, if the installation occured into a valid package directory (which is the default), then this should work out of the box. What you did instead does not appear to match those instructions. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] GNU emacs: 24.4.1 auctex 11.88: installation problem: style files
Uwe Brauer writes: >> Uwe Brauer writes: > >> When all else fails, read the instructions. I quote from INSTALL: > >> 6 Installation for non-privileged users >> *** > > I have the following paths set > > (setq load-path (cons (expand-file-name "~/emacs/site-lisp") load-path)) > (setq load-path (cons (expand-file-name "~/emacs/site-lisp/packages") > load-path)) > (setq load-path (cons (expand-file-name > "~/emacs/site-lisp/packages/auctex-11.88") load-path)) > (setq load-path (cons (expand-file-name > "~/emacs/site-lisp/packages/auctex-11.88/auctex") load-path)) Let me just quote the XEmacs specific instructions _again_ (you cut them when replying): XEmacs users can achieve the same end by pointing `configure' at an appropriate package directory (normally `--with-packagedir=~/.xemacs/xemacs-packages' will serve). The package directory stands a good chance at being detected automatically as long as it is in a subtree of the specified PREFIX. You are meddling with your load-path as if you were using GNU Emacs. Please _either_ indeed use GNU Emacs, or follow the instructions specific to XEmacs. But creating some Frankenstein installation in between will not likely work. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] GNU emacs: 24.4.1 auctex 11.88: installation problem: style files
Uwe Brauer writes: >> Uwe Brauer writes: > >> I don't think that we have installation instructions telling you not to >> run "make install". Did you take a look at the installation >> instructions? They are in the manual and should also be available as a >> separate text file called INSTALL. > > Obviously not carefully enough, I also thought that I could do the same > as I do with gnus and org mode, compile the el files and then set the > relevant paths, however that does not work with auctex. > > However I am puzzled, since I do not really understand the different > between > > -with-packagelispdir=‘auctex’ (should that really be *literally* > auctex) > > And > > --with-lispdir=/dir So let's see what INSTALL has to say about them: `--with-lispdir=/DIR' This Emacs-only option specifies the location of the `site-lisp' directory within `load-path' under which the files will get installed (the bulk will get installed in a subdirectory). `./configure' should figure this out by itself. `--with-auctexstartfile=`auctex.el'' `--with-previewstartfile=`preview-latex.el'' This is the name of the respective startup files. If LISPDIR contains a subdirectory `site-start.d', the start files are placed there, and `site-start.el' should load them automatically. Please be aware that you must not move the start files after installation since other files are found _relative_ to them. `--with-packagelispdir=`auctex'' This is the directory where the bulk of the package gets located. The startfile adds this into LOAD-PATH. So you need to have lispdir in your load-path. *That's* *all*. The "start files" (which have sensible default names) will be put there. You *load* them in your .emacs file or similar, and *they* are responsible for putting up load paths and autoloads for the files that are, by and large, placed into packagelispdir which defaults to being the subdirectory "auctex" in your lispdir. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] progress
Uwe Brauer writes: >> Uwe Brauer writes: > >> No, unless you've configured `TeX-arg-input-file' to nil. And even >> then, the only difference will be that bidibeamer will be offered by >> `C-c C-e document RET'. The style file will be run regardless of that >> variable. > > Ok you meant to add this > > TeX-add-style-hook into the LaTeX-mode hook, right? > I misundertood this at first, but now it works, thanks. Hard to misunderstand things that have never been said. With your approach, you'll get completions even for documents that don't use beamer at all. Which is why Tassilo wrote: If bidibeamer is the same as beamer (at least from a user's POV), then a bidibeamer.el style file like (TeX-add-style-hook "bidibeamer" (lambda () (TeX-run-style-hooks "beamer")) LaTeX-dialect) should do the trick. I repeat: "a bidibeamer.el style file". You really should only start improvising things after you've exhausted the instructions and are quite sure there is nothing relevant left in them that you overlooked. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] progress
Uwe Brauer writes: >> Uwe Brauer writes: > >> Hard to misunderstand things that have never been said. With your >> approach, you'll get completions even for documents that don't use >> beamer at all. Which is why Tassilo wrote: > >> If bidibeamer is the same as beamer (at least from a user's POV), >> then a bidibeamer.el style file like > >> (TeX-add-style-hook >> "bidibeamer" >> (lambda () (TeX-run-style-hooks "beamer")) >> LaTeX-dialect) > >> should do the trick. > >> I repeat: "a bidibeamer.el style file". > > > Yes, I did that and it *did* not work. Have you enabled style file parsing? The AUCTeX manual has If you want to make AUCTeX aware of style files and multi-file documents right away, insert the following in your `.emacs' file. (setq TeX-auto-save t) (setq TeX-parse-self t) (setq-default TeX-master nil) right on the first page. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] TeX-command-buffer: generate buffer-file-name.dvi/pdf
Uwe Brauer writes:
>>> "Tassilo" == Tassilo Horn writes:
>
> Hi Tassilo
>
>
>> Because this way you can compile the "thing" you're currently working on
>> without overwriting your complete document, i.e., master.pdf/dvi.
>
>
> I don't understand, I have
>
> \documentclass[12pt]{article}
> \begin{document}
>
> \include{test1}
> \include{test2}
> \end{document}
>
>
> So
>
> - TeX-command-master main.tex gives main.pdf
>
> - TeX-command-master in say test1.tex gives again main.pdf
>
> - but when I run in test1.tex TeX-command-buffer, I don't get
> test1.pdf. I don't see what harm it could cause? I don't
> see what it could overwrite? what do I miss?
test1.aux for example.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] TeX-command-buffer: generate buffer-file-name.dvi/pdf
Uwe Brauer writes: >> Uwe Brauer writes: > >> test1.aux for example. > Hm, whats about a variable then?: > > TeX-command-buffer-name > > if t it compiles to buffer-file-name.pdf/dvi > > if nil the old behavior How do you expect that to work? TeX uses the same basic name for .pdf/.dvi as it does for its .tex file, and the .tex file of an included file cannot be run through LaTeX without change. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] TeX-command-buffer: generate buffer-file-name.dvi/pdf
Uwe Brauer writes: >> Uwe Brauer writes: > >> How do you expect that to work? TeX uses the same basic name for >> .pdf/.dvi as it does for its .tex file, and the .tex file of an included >> file cannot be run through LaTeX without change. > > Sigh! You are right. > > So the only solution would be to use the *standalone* or the *subfiles* > packages, the subfiles packages has the problem that auctex cannot scan > the master file to see what packages are loaded. So I opt for > standalone. What is the problem you are trying to solve here in the first place? -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] TeX-command-buffer: generate buffer-file-name.dvi/pdf
Uwe Brauer writes:
>> Uwe Brauer writes:
>
>> What is the problem you are trying to solve here in the first place?
>
> This is what I wrote yesterday:
>
> My problem concerns
>
> Tex master and the include command.
>
> I have for example a master file
> main.tex which looks like (leaving all the usepackages out)
> \documentclass[12pt]{article}
> \begin{document}
>
> \include{hoja1}
> \include{hoja2}
> \end{document}
>
>
>
> In the two slave files I have set the master to main.tex.
>
> In these slave files I can run TeX-command-buffer and only this
> file/buffer is compiled. However the resulting pdf/dvi is called
> _region_.pdf and this is a big restriction:
>
> - when I visit some time later the directory I have now idea
>to which file _region_.pdf corresponds.
>
> - when I want to send such pdf I have to rename it which is also
>cumbersome.
You shouldn't be sending such a file anyway since its labels and page
numbers will not correspond in any meaningful manner to that of the main
document. TeX-command-buffer is not supposed to produce a useful
document but something that is useful for working on a larger document
while not taking as long to produce.
There may be some LaTeX packages intended to do a more thorough job,
producing an actually valid approximation of a file extract.
> That is why I came up with using the latex style: subfiles, the
> corresponding files look
>
>
> \documentclass[12pt]{article}
> \usepackage{subfiles}
> \begin{document}
>
> \subfile{hoja1.tex}
> \subfile{hoja2.tex}
>
> \end{document}
>
> and the slave files for example
>
> \documentclass[main]{subfiles}
> \begin{document}
>
> text
>
> \end{document}
> %%% Local Variables:
> %%% mode: latex
> %%% TeX-master: t
> %%% End:
>
>
> Then I can run latex via TeX-command-master on the slave, the resulting
> pdf is called hoja1.pdf (I have a common header file), *but* auctex does
> not scan the headers of the master file and then I can not use parts of
> auctex functionality.
It might make sense adding better-working support for the subfiles
package. It's conceivable to let this reroute TeX-command-buffer etc as
the user interface, but I don't think that the code is reasonably
prepared to do this.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Support for expl3
Sean Allred writes: > Thanks for everything so far, guys. Simply being able to correctly > jump around by token is a great help :) > > Building off of what was provided here, I’ve taken the liberty of > adding some font-locking with the help of the awesome folks over at > Emacs.SE. I’ve attached an ‘updated’ expl3.el to this email (I can’t > get git-diff to cooperate, for some reason). Please keep in mind that we need copyright assignments from all authors of software, and to trace all copyrightable contributions. Mere advice is harmless, purely functional code (which could not sensibly be done in other ways) more or less as well, but we need to keep track of any actually copyrightable contributions even when they are smaller than the size we need for copyright assignments since the overall number of contribution counts towards when we need an assignment. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Hello and a question about missing AUCTeX features
Marcin Borkowski writes: > Oh. This probably settles the thing. I had some hope that AUCTeX is > outside the scope of this FSF-papers insanity. I don't have those > papers signed, and unless there is some serious change (either in FSF, > or in my ethical standpoint - either one is possible, but not very > likely), I'm afraid I cannot sign them. Shrug. If you call it "your ethical standpoint", you are saying that the FSF has behaved unethically regarding the copyrights they have been handed for safekeeping. Or that you expect them to do so in future. Or that you want to reserve to yourself the right to have second thoughts about contributing material to AUCTeX. Untangling the copyrighted material would be a mess if you or your direct or subsequent heirs (for 95 years after your death) change your mind about the contribution. The assignments have been ongoing for 30 years by now: I have yet to see behavior by the FSF in connection with them that I'd like to call unethical. On the other hand, I have seen a core contributor to XEmacs (which does not generally use copyright assignments) that he would rather retract all his work than have it relicensed under GPLv3 so that XEmacs would be able to continue merging code from Emacs. Presumably others managed to talk him out of it but exactly that kind of thing can happen with shared copyrights. And if you did not assign your copyright, the decision ultimately will rest with people who are not even born yet and whose only connection with your wishes is that they will likely share some genes with you. This idiocy of locking up persons' work far beyond their death is not the FSF's fault. And the FSF has contractual obligations in turn for my copyright assignment, obligations that my heirs would not have. So I rather take my bet with them. And I am definitely not betting that our legal systems get a clue by the time I die. Even if you consider the FSF evil incarnate, they are rather tied down with how they can abuse the copyrights they get assigned: they must only license under public licenses giving the general recipients the same rights they have. Take a look at the FSF parts of the assignment contracts if you have the opportunity. The easiest way to do that, of course, is to request the assignment papers. You will still be free to throw them away afterwards and not go through with your assignment/contribution. And you are pretty sure to make your decision based on the current version. > Another, technical question is: assuming that I develop some > AUCTeX-based utilities (=elisp functions), does it make sense to write > about them here? I do not want to give an impression that I'm somehow > hostile towards AUCTeX developers (I'm not), or that I want to compete > against them (I don't, and even if I did, I'm probably not competent > enough to do it successfully anyway). The problem is that I'm /very/ > critical towards the FSF (to the point that I do not want the FSF to > be in posession of any piece of paper with my personal signature). Shrug. Without such a piece of paper, ultimately people you don't even know and who have no contractual obligation to you will be in possession of your copyrights eventually. Once you are no longer there, they are free to take your work off the net and it will get scattered, redistributed by people who can no longer enforce the license you intended unless they add substantial amounts of code. And of course, you can confine your contributions at any time: a copyright assignment does not entitle the FSF to material you never intended to hand over. It only concerns material you wittingly contribute to the AUCTeX/Emacs repositories. So it may make sense to consider whether the consequences of making your point against the FSF are actually effective in promoting your ethics. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Hello and a question about missing AUCTeX features
Marcin Borkowski writes: > On 2015-04-12, at 20:04, David Kastrup wrote: > >> Marcin Borkowski writes: >> >>> Oh. This probably settles the thing. I had some hope that AUCTeX is >>> outside the scope of this FSF-papers insanity. I don't have those >>> papers signed, and unless there is some serious change (either in FSF, >>> or in my ethical standpoint - either one is possible, but not very >>> likely), I'm afraid I cannot sign them. >> >> Shrug. If you call it "your ethical standpoint", you are saying that >> the FSF has behaved unethically regarding the copyrights they have been >> handed for safekeeping. Or that you expect them to do so in future. >> >> [...] >> >> So it may make sense to consider whether the consequences of making your >> point against the FSF are actually effective in promoting your ethics. > > 0. TL;DR: I have serious doubts regarding FSF copyright papers and FSF > itself, and I'm generally disappointed by FSF's MLs. A list of > issues I have (in the form of four questions) closes this message. > > 1. I tried to find the actual text of the copyright agreement on the > Internet. I did not succeed, and from what I heard, I'm not alone. They are changed from time to time, and the copyright clerk might pick from several according to the exact circumstances. > I haven't seen any explanation for that phenomenon, either. A > situation when some organization has claims about freedom and openness > and at the same is so secretive about these documents is a red flag > for me. You won't likely find an employment contract on the Internet when applying for work there either. > (Maybe there is some explanation for that. I'd be happy to learn that > - I'm not a lawyer, there might be something I cannot see.) I don't really see the problem. You get the exact text applying to your case when requesting the assignment, and of course you are free not to accept it. > 2. There was a discussion some time ago about the possibility of > actually /withdrawing/ the FSF copyright agreement. (Not to things > that were contributed before, of course, just about termination so > that future work would be unaffected.) Also, about the precise scope > of the works I "give away" to the FSF. https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf>. The contract cannot possibly cover material that cannot be considered handed to the FSF. The FSF does not magically get to search your hard drives or web presences and gets to scoop up and claim ownership to anything related to the project. Any such notion is plainly silly. > This problem is actually a corollary to item 1: if the text of the > copyright agreement were freely available, it wouldn't be a concern. The agreement for your case will be made available to you upon request and you are free to ask whoever you want for it. Some people have published the text of theirs: there is no non-disclosure agreement involved either. It's just not canonical and thus may be misleading. > OTOH, the issue was raised by someone who /did/ sign those papers, so > these things might not be obvious. OYAH (=on yet another hand;-)), > that person was clearly a total jerk, so this might as well be FUD. It's not hard to find total jerks among highly skilled programmers, neither among skilled legal practitioners. And working on free software is not really something decreasing the quota since it favors people with strong beliefs and opinions. Most non-jerks don't even go to the bother of reading through what they are agreeing to. However, if it is just a single jerk, that's somewhat suspicious. Because, really, there is no shortage of them in the free software world. > But again: I have no way of knowing without actually requesting those > papers. Strange, isn't it? Not really. Try finding anybody else flaunting his individual contracts to the public. It's not anything like a public license. > (Even though you rightly point out that I could request them and then > throw them away. It's just that I think that they should be available > /on principle/, so that the whole process is more transparent.) But you don't get a guarantee that for a certain case a certain assignment form will get picked. There are also cases where the circumstances are such that a one-of-a-kind document needs to get drawn up. > 3. Some time ago, certain person wrote to one of the FSF-hosted > mailing lists about his software project, which was not "free" (as FSF > defines it) and closed-source. There were extremely hostile reactions > to that, and it was just plainly disgusting. While I understand that > the policy of F
Re: [AUCTeX-devel] Hello and a question about missing AUCTeX features
Marcin Borkowski writes: > So bascially this boils down to "subscribe to emacs-devel" anyway. > Well, I'll have to live with it, at least until I configure Gnus... The developer list is also available on news.gmane.org. While the volume is the same, at least it will not clog your mail box. If your user mail agent can work with NNTP, it will tend to be as simple as reading a mailing list only without touching your mail box. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] problems with Xemacs 21.4.22 Mule on Mac, xdvi
Uwe Brauer writes: >> Hi Uwe, >> 2015-06-10 8:41 GMT+02:00 Uwe Brauer : > >> Well, AUCTeX (actually *Emacs) expects a program to be in a PATH >> directory, not necessarily /usr/bin. If /usr/texbin is not in the >> PATH, AUCTeX cannot find xdvi, did you expect something else? > > Hm that is odd. > I thought that somewhere deep in the auctex code there are standards > path set like /usr/bin /usr/local/bin etc (however I could not find > such setting) so basically you say (X)Emacs wants the executables like > xdvi in any PATH whatsoever. > > I confess the laptop with MaC OS is not mine, but I suspect the tex > installation to be a MaC OS specific one and not texlive. > > But what I don't understand is the following. > If I do > > «which xdvi» in the terminal application of the Mac (which I think is a > bash shell) and it returns > > /usr/texbin/xdvi > > Isn't (X)Emacs supposed to find this executable? If you started (X)Emacs from the terminal application, yes. If you didn't, it depends on how the environments of (X)Emacs and the terminal application differ in their setup. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] latex-pretty-symbols.el and subscripts (x-symbol): don't display _ or ^
Uwe Brauer writes: >> Uwe Brauer writes: > >> Just for the record: I've just added `prettify-symbols-mode' support for >> (La)TeX to Emacs' built-in tex-mode.el. If you run a very, very recent >> emacs, you could activate that in AUCTeX using > > 21.4.1 is recent enough? I have my doubts that Tassilo would call an Emacs version from 12 years ago "very, very recent". -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] sub and superscripts: without «_» and «^»
Uwe Brauer writes:
> On 09/03/2015 11:49 AM, Tassilo Horn wrote:
>
>
> Uwe Brauer writes:
>
>> I strongly recommend to include the code in Auctex, maybe with a
>> additional variable, something like this
>
> It's far from perfect. For example, if you have some spurious ^ or _
> somewhere in your text (not in some math) you won't see it at all. And
> AUCTeX's font-latex does not raise/lower scripts on multiple levels,
> e.g., with x^y^z the y and the z have the same size and are equally
> raised.
Uh, correct? That's an error anyway. Are you talking about x^{y^z}
instead?
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] serious keybinding problem
Mosè Giordano writes: > Hi Uwe, > > 2015-09-15 12:34 GMT+02:00 Uwe Brauer : >> Hello >> >> >> I am currently facing two problems: >> >> >> - I always thought that local-key-binding via hook replaces the >> global-key-binding (at least so it is in Xemacs) now in GNU Emacs I >> have >> set (global-set-key "\C-cr" 'ispell-region) >> (setq reftex-extra-bindings t) >> which according to the documentation should bind >> \C-cr to reftex-reference etc. It dos not >> >> - But I also have set >> >> (add-hook 'LaTeX-mode-hook 'my-latex-mode-key) >> >> (defun my-latex-mode-key () >> "Setting of the following keys" >> (interactive) >> (local-set-key [(control right)] 'my-turn-bidi-on) >> (local-set-key [(control left)] 'my-turn-bidi-off) >> (local-set-key [(f31)] 'TeX-fold-buffer) >> (local-set-key [(f30)] 'TeX-fold-clearout-buffer) >> (local-set-key [(control f30)] 'preview-clearout-buffer)) >> >> However this binding is ignored, the global-key-binding is taken >> instead. >> >> I have to evaluate the function my-latex-mode-key and then switch latex >> mode off and on. Very annoying. > > I can't reproduce your problem in Emacs 24.5 (and I don't think this > bug, if exists, has anything to do with AUCTeX). It very much depends on what "But I also have set" is supposed to mean. If you add to LaTeX-mode-hook, of course this does not affect any buffers which are already in LaTeX-mode (for example by having loaded the desktop before setting up LaTeX-mode-hook). -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] \Bbb{Q} tex--prettify-symbols-alist
Uwe Brauer writes:
>>>> "Tassilo" == Tassilo Horn writes:
>
>> Uwe Brauer writes:
>> Hi Uwe,
>
>>> \Bbb{Q} is not included in tex--prettify-symbols-alist
>
>> Now it is. ;-)
>
>>> what is the corresponding UFT8 symbol?
>
>> 211A / ℚ
>
> I don't understand I have
>
> (dolist (el '(("\\setN" . ?\u2115)
> ("\\setP" . ?\u2119)
> ("\\setR" . ?\u211d)
> ("\\setQ" . ?\u211A)
> ("\\setC" . ?\u2102)
> ("\\quad" . ?␣)
> ("\\qquad" . ?\u29e2)
> ("\\varrho" . ?ϱ)
> ("\\setZ" . ?\u2124)))
> (add-to-list 'tex--prettify-symbols-alist el))
>
> But it does not work what do I miss?
_Where_ do you have that?
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] \Bbb{Q} tex--prettify-symbols-alist
Uwe Brauer writes:
>>>> "David" == David Kastrup writes:
>
>> Uwe Brauer writes:
>>>>>> "Tassilo" == Tassilo Horn writes:
>>>
>>> > Uwe Brauer writes:
>>> > Hi Uwe,
>>>
>>> >> \Bbb{Q} is not included in tex--prettify-symbols-alist
>>>
>>> > Now it is. ;-)
>>>
>>> >> what is the corresponding UFT8 symbol?
>>>
>>> > 211A / ℚ
>>>
>>> I don't understand I have
>>>
>>> (dolist (el '(("\\setN" . ?\u2115)
>>> ("\\setP" . ?\u2119)
>>> ("\\setR" . ?\u211d)
>>> ("\\setQ" . ?\u211A)
>>> ("\\setC" . ?\u2102)
>>> ("\\quad" . ?␣)
>>> ("\\qquad" . ?\u29e2)
>>> ("\\varrho" . ?ϱ)
>>> ("\\setZ" . ?\u2124)))
>>> (add-to-list 'tex--prettify-symbols-alist el))
>>>
>>> But it does not work what do I miss?
>
>> _Where_ do you have that?
>
> In a private file of mine.
That's nice but does not tell us in which context that private file of
yours gets loaded.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] \Bbb{Q} tex--prettify-symbols-alist
Uwe Brauer writes:
>> Uwe Brauer writes:
>
>> That's nice but does not tell us in which context that private file of
>> yours gets loaded.
>
> These are the lines in my init file
>
> ,
> | (load "auctex.el" nil t t)
> | (load "preview-latex.el" nil t t)
> |
> | (require 'tex-site)
> | ;(require 'change-prettify-list)
> | (require 'my-change-prettify-list)
> | (require 'my-fill-latex-sentence)
> | (require 'latex-keys)
> `
> and this is the file
> my-change-prettify-list:
> ,
> | (require 'tex-mode)
Uh, why? That's Emacs' built-in TeX mode. Why would you ever require
that in parallel with loading AUCTeX?
> | (dolist (el '(("\\setN" . ?\u2115)
> | ("\\setP" . ?\u2119)
> | ("\\setR" . ?\u211d)
> | ("\\setQ" . ?ℚ)
> | ("\\setC" . ?\u2102)
> | ("\\quad" . ?␣)
> | ("\\qquad" . ?\u29e2)
> | ("\\varrho" . ?ϱ)
> | ("\\setZ" . ?\u2124)))
> | (add-to-list 'tex--prettify-symbols-alist el))
> |
> |
> |
> | (provide 'my-change-prettify-list)
> `
> again: \setR works, \setQ does not.
First try not to use Emacs' built-in TeX mode at the same time as using
AUCTeX, or any further analysis is likely a waste of time.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] \Bbb{Q} tex--prettify-symbols-alist
Uwe Brauer writes: >>>> "Uwe" == Uwe Brauer writes: > > >> And I recall that some difficulties I encountered were solved by Tassilo >> however submitting patches to emacs not to auctex. In any case I do what >> you suggest. > > Good and bad news: > bad news: I delete (require 'tex-mode) byte compile my file restart > emacs and open a tex file \setQ is *not* displayed > > Good news. I restart emacs I load explicitly the elc version of my file > I open a tex file \setQ *is* displayed. > > I am puzzled since I think a > (require 'my-change-prettify-list) > would load the elc version. > > Any explanations? Using desktop.el? -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] amsmath, amsthm automatially insert thm, lemma etc
Arash Esbati writes: > Hi Mosè, > > Mosè Giordano writes: > >> Thanks for your contribution. I didn't have the time to actually test >> it, but it looks good. Just out of curiosity: isn't >> >> (format "%s" heading) >> >> the same as >> >> heading >> >> ? > > As always, thanks for your comments. You are right, of course, Only if (stringp heading) => t and possibly some other conditions. %s converts also non-strings. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] problems with git pull
Uwe Brauer writes: > Hi > > After a month of not updating I run today > > git pull > > I obtained: > error: refs/tags/auctex_5_6d does not point to a valid object! > error: refs/tags/auctex_6_1b does not point to a valid object! > error: refs/tags/auctex_6_1c does not point to a valid object! > error: refs/tags/auctex_release_7_0a does not point to a valid object! > error: refs/tags/rel-0-5 does not point to a valid object! > > 100 similar lines and then finally > >>From git://git.savannah.gnu.org/auctex > * [new tag] release_11_89 -> release_11_89 > Updating b072f9c..15ebec9 > error: Your local changes to '.gitignore' would be overwritten by > merge. Aborting. > Please, commit your changes or stash them before you can merge. > > I don't know which changes git is referring to. Try git diff to see the changes you made to .gitignore without committing. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] problems with git pull
Uwe Brauer writes: >> Uwe Brauer writes: > >> Try > >> git diff > >> to see the changes you made to .gitignore without committing. > > There is a long list of changes but I swore I did not do any of them, > strange. Some end-of-line translation at work? Are you using some sort of a network drive and some Windows/UNIX mixture making use of it? -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] git problem (again)
Uwe Brauer writes: > Hi > > I have a recent git clone > > git log | more > > Tells me > , > | commit e9ddab9c38927cedad9f059cd383c83f5e4b67ff > | Author: Mosè Giordano > | Date: Mon Jan 25 22:30:10 2016 +0100 > | > | Code cleaning > | > | * latex.el (TeX-arg-document): Remove useless (mapcar 'identity ...). > | Suggested by Marcin Borkowski. > | * style/biblatex.el (LaTeX-biblatex-package-options): Ditto. > ` > > Now I want to run git pull in order to get all the exciting new > features. But I receive git pull , | You are not currently on a > branch, so I cannot use any | 'branch..merge' in your > configuration file. | Please specify which remote branch you want to use > on the command | line and try again (e.g. 'git pull > '). | See git-pull(1) for details. ` > > Ok I can clone again, but I would love to know what is going on [1] Whatever you did (git reflog should give you a good idea), you probably can get back to normal using git checkout master -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [SOLVED]
Uwe Brauer writes:
> > Uwe Brauer writes:
>
> > Whatever you did (git reflog should give you a good idea),
>
> git reflog
> ,
> | e9ddab9 HEAD@{0}: checkout: moving from
> | 836ca430f8499a4c60ea3324810845aec6e032ee to e9ddab9c38927cedad9f059cd383c
> | 836ca43 HEAD@{1}: checkout: moving from master to
> | 836ca430f8499a4c60ea3324810845aec6e032ee
> | e9ddab9 HEAD@{2}: pull : Fast-forward
> | 08ab3c1 HEAD@{3}: clone: from http://git.savannah.gnu.org/r/auctex.git
> `
Well, you moved away from the master branch to an isolated commit rather
than a local branch head. And then to another isolated commit rather
than a local branch head.
Probably a bad use of "git checkout".
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Polish quotes - a simple patch
Marcin Borkowski writes:
> Hi all,
>
> how about this patch?
>
> diff -u --label /home/mbork/.emacs.d/elpa/auctex-11.89.1/style/polski.el
> --label \#\
> /home/mbork/.emacs.d/elpa/auctex-11.89.1/style/polski.el
> /tmp/buffer-content-18384jTP
> --- /home/mbork/.emacs.d/elpa/auctex-11.89.1/style/polski.el
> +++ #
> @@ -46,7 +46,7 @@
> "ppauza")
> ;; Quotation marks
> (unless (eq (car TeX-quote-language) 'override)
> - (setq TeX-quote-language '("polski" ",," "''" t)))
> + (setq TeX-quote-language '("polski" ",," "''")))
> ;; Fontification of quotation marks.
> (when (fboundp 'font-latex-add-quotes)
> (font-latex-add-quotes '(",," "''")))
>
> Diff finished. Thu Mar 3 05:54:48 2016
>
> I don't see any reason behind the "t" setting here; I've practically
> never wanted to insert a literal quote character in Polish TeX files.
So? In verbatim and/or code excerpts it's actually a rather likely
thing to insert.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] New error parsing
Tassilo Horn writes: > Mosè Giordano writes: > > Hi Mosè, > >> is there a particular reason why you used `memql' in >> `TeX-format-filter', file tex-buf.el line 1766 in current git HEAD? >> XEmacs doesn't have it and I think that both memq and member would >> work (with the former probably being a bit faster than the latter). > > I wasn't sure if two integers of the same value are always identical. Emacs: yes so far. Lisp: not necessarily. That's why eql exists in the first place. I prefer pretending that Emacs Lisp is like Lisp generally. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Further TikZ patches
Mosè Giordano writes: > Bug tracker isn't a good sample of our community, but sometimes I > think we're still supporting XEmacs for just one person. Well, I guess 1 in 10 users of Emacsens uses AUCTeX, so that seems plausible for XEmacs. By the same metric, there are at least 6 AUCTeX users all in all. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [AUCTeX] GNU AUCTeX 11.89.4 released to ELPA
Tassilo Horn writes: > Mosè Giordano writes: > > Hi Mosè, > >>> Thereby, I've also converted our ChangeLog.1 to UTF-8 and removed the >>> iconv pass from built-aux/gitlog-to-auctexlog because that apparently >>> failed for me. Seems like some recent commit had some non-ISO-8859-1 >>> encodable character in it (which is ok). >> >> XEmacs without MULE doesn't support UTF-8 encoding. > > Given the fact that XEmacs development has been discontinued, I think > we can stop supporting it actively. I don't think that it has officially been discontinued. Technically, it's likely more active than TeX (The Program) development, and we still support TeX. > It's probably too early to remove compatibility code, but I don't > think it's worth the trouble to consider XEmacs support for new code > at least. I agree with that assessment. The user base of XEmacs consists mainly of "traditional" users rather than newcomers, and so they will likely get along with "traditional" versions of TeX supported by their current AUCTeX installation, if any. > Well, and in the concrete case, if one character in the ChangeLog > shows up as \xxx or a box, I don't consider that a drama. :-) ChangeLog is strictly a developer resource. No XEmacs developer will be actively using XEmacs 21.4 no-mule. Trying to avoid utf-8 here is nonsensical in my book. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] A patch to fix auctex.texi
Arash Esbati writes:
> Mosè Giordano writes:
>
>> Thank for the report. I would use a conditional to test which command
>> is defined, see for example http://www.tex.ac.uk/FAQ-isdef.html
>
> I think this should do it:
>
> diff --git a/doc/macros.texi b/doc/macros.texi
> index fdf37a0..3f3a80f 100644
> --- a/doc/macros.texi
> +++ b/doc/macros.texi
> @@ -64,10 +64,17 @@ font-latex
>\def\TeX#1{TeX#1}%
>\def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
> \xdef\indexnofonts{\the\toks0}
> -\toks0\expandafter{\commondummies
> - \def\TeX#1{TeX#1}%
> - \def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
> -\xdef\commondummies{\the\toks0}
> +\ifx\commondummies\undefined
> + \toks0\expandafter{\definedummies
> +\def\TeX#1{TeX#1}%
> +\def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
> + \xdef\definedummies{\the\toks0}
> +\else
> + \toks0\expandafter{\commondummies
> +\def\TeX#1{TeX#1}%
> +\def\LaTeX#1{LaTeX#1}\def\previewlatex#1{preview-latex#1}}
> + \xdef\commondummies{\the\toks0}
> +\fi
I would not couple the tests in that manner. Just do
\ifx\commondummies\undefined \else
[Fix \commondummies]
\fi
\ifx\definedummies\undefined \else
[Fix \definedummies]
\fi
It keeps the tests connected to the actual code and has fewer implied
assumptions.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Spell checking of macros
Mosè Giordano writes:
> 2016-07-11 11:19 GMT+02:00 Arash Esbati :
>> Hi Mosè,
>>
>> Mosè Giordano writes:
>>
>>> 2016-07-08 19:11 GMT+02:00 Arash Esbati :
>>>> Hi Mosè,
>>>>
>>>> Mosè Giordano writes:
>>>>
>>>>> Thanks for your work! Some questions:
>>>>>
>>>>> * why all those `eval-when-compile'?
>>>>
>>>> The final regexp which goes into byte-compiled file is built with:
>>>>
>>>> --8<---cut here---start->8---
>>>> (defvar TeX-ispell-skip-cmds-one-arg-regexp
>>>> (eval-when-compile
>>>> (concat ""
>>>> (regexp-opt (TeX-ispell-sort-skip-cmds-list 1) t)))
>>>> "Regexp of LaTeX commands with one argument to be skipped.")
>>>> --8<---cut here---end--->8---
>>>
>>> Ok, then why this regexp is built with `eval-when-compile'?
>>
>> I wanted to implement a trick mentioned in regexp-opt.el:
>>
>> ;; Since this package was written to produce efficient regexps, not regexps
>> ;; efficiently, it is probably not a good idea to in-line too many calls in
>> ;; your code, unless you use the following trick with `eval-when-compile':
>> ;;
>> ;; (defvar definition-regexp
>> ;; (eval-when-compile
>> ;; (concat "^("
>> ;; (regexp-opt '("defun" "defsubst" "defmacro" "defalias"
>> ;; "defvar" "defconst") t)
>> ;; "\\>")))
>> ;;
>> ;; The `byte-compile' code will be as if you had defined the variable thus:
>> ;;
>> ;; (defvar definition-regexp
>> ;; "^(\\(def\\(alias\\|const\\|macro\\|subst\\|un\\|var\\)\\)\\>")
>
> Ok, fine.
>
>> Do you have any specific concern about using `eval-when-compile' here?
>
> I have the impression that currently AUCTeX doesn't require to be
> compiled. My understanding is that with this change compilation would
> become practically mandatory (at least in order to exploit this
> feature), is it correct?
No. It will interpret just fine, only slower. Which is basically the
expectation for loading uncompiled code anyway, though usually most of
the savings from compilation are expected more on run time than load
time.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Spell checking of macros
Mosè Giordano writes:
> Hi Arash,
>
> 2016-07-12 10:25 GMT+02:00 Arash Esbati :
>> Arash Esbati writes:
>>
>>> I'm thinking about writing a function like this to catch this kind of
>>> arguments:
>>>
>>> (defun TeX-ispell-tex-arg-end (&optional arg1 arg2)
>>> (condition-case nil
>>> (progn
>>> (while (looking-at "[ \t\n]*\\[") (forward-sexp))
>>> (forward-sexp (or arg1 1))
>>> (while (looking-at "[ \t\n]*\\[") (forward-sexp))
>>> (forward-sexp (or arg2 1)))
>>> (error
>>> (message "Error skipping s-expressions at point %d." (point))
>>> (beep)
>>> (sit-for 2
>>>
>>> and do ("tabular[*xy]" TeX-ispell-tex-arg-end).
>>
>> Following up myself again, I implemented a function
>> `TeX-ispell-tex-arg-end' to deal with constructs like:
>>
>> \raisebox{2em}[1em][1em]{text} or
>> \begin{tabularx}{300pt}{|p{3cm}|>{\raggedright}X|c|S|} etc.
>>
>> I'd like to apply the attached patch. I would appreciate any comments
>> before doing this.
>
> It looks overall good to me, but note that error messages *do not* end
> with a period (see `error`'s docstring) and you should replace the
> `message' function with `format' (and I don't think `beep' is needed).
Uh, no?
error is a compiled Lisp function in ‘subr.el’.
(error STRING &rest ARGS)
Signal an error, making a message by passing args to ‘format-message’.
In Emacs, the convention is that error messages start with a capital
letter but *do not* end with a period. Please follow this convention
for the sake of consistency.
Note: (error "%s" VALUE) makes the message VALUE without
interpreting format characters like ‘%’, ‘`’, and ‘'’.
You don't want to have format-message called twice. So just use
(error "Error skipping s-expressions at point %d." (point))
Do other errors actually output the value of point? Seems a bit strange
to me, but that's a different problem.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Spell checking of macros
Mosè Giordano writes: > 2016-07-17 19:28 GMT+02:00 David Kastrup : >> Mosè Giordano writes: >> >>> It looks overall good to me, but note that error messages *do not* end >>> with a period (see `error`'s docstring) and you should replace the >>> `message' function with `format' (and I don't think `beep' is needed). >> >> Uh, no? >> >> error is a compiled Lisp function in ‘subr.el’. >> >> (error STRING &rest ARGS) >> >> Signal an error, making a message by passing args to ‘format-message’. >> In Emacs, the convention is that error messages start with a capital >> letter but *do not* end with a period. Please follow this convention >> for the sake of consistency. >> >> Note: (error "%s" VALUE) makes the message VALUE without >> interpreting format characters like ‘%’, ‘`’, and ‘'’. >> >> You don't want to have format-message called twice. So just use >> >> (error "Error skipping s-expressions at point %d." (point)) > > Of course you're right, thanks. Well, apart from the "*do not* end with a period" bit of course. Copy&paste error. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] copyright question
Uwe Brauer writes: > Hi > > I just received the copyright papers. It seems that the clerk put in > only GNU auctex, which I interpret as just signing to contribute to > auctex only but not to Emacs or any other packages Emacs includes. That's not how I understand "AUCTeX/GNU Emacs". What is the exact project listed in your copy of the PDF? -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] copyright question
Uwe Brauer writes: >>>> "David" == David Kastrup writes: > >> Uwe Brauer writes: >>> Hi >>> >>> I just received the copyright papers. It seems that the clerk put in >>> only GNU auctex, which I interpret as just signing to contribute to >>> auctex only but not to Emacs or any other packages Emacs includes. > >> That's not how I understand "AUCTeX/GNU Emacs". > >> What is the exact project listed in your copy of the PDF? > > It says > > ASSIGNMENT -- GNU AUCTEX > > I interpret this as auctex only. The mail I received regarding your assignment request had "AUCTeX/GNU Emacs" in its subject line. Is it conceivable that there were two attachments in the mail? -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] my patch? Examn (bidi in preparation)
Mosè Giordano writes: > 2016-08-28 23:15 GMT+02:00 Uwe Brauer : >>>>> "Mosè" == Mosè Giordano writes: >> >> > Hi Uwe, >> > 2016-08-22 21:20 GMT+02:00 Uwe Brauer : >> >> Hi >> >> >> >> I presume the copyright issue is now solved. What is my patch >> >> for examn? >> >> > I check almost daily, but your name doesn't appear in the list of >> > people who assigned the copyright for Emacs or AUCTeX. >> >> Thanks, do I have access to this list also? > > No. Somewhat more explicit: this list contains contact and other personal details of all GNU contributors with copyright assignments. That list could be exploited for annoying purposes in the wrong hands. So it is not publicized but only available to GNU maintainers. This may seem like an inconvenience to you right now, but it also means that your own address, birth date and other information pertinent to the copyright assignment is not publicly available. Of course, the circle of GNU maintainers is not exactly small, but decidedly smaller than that of all GNU contributors, and many of those maintainers are so because of being in a position of trust by several others working on GNU. It's a reasonable compromise. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] my patch? Examn (bidi in preparation)
Uwe Brauer writes: >> On 28 Aug 2016, at 23:33, David Kastrup wrote: >> >> Of course, the circle of GNU maintainers is not exactly small, but >> decidedly smaller than that of all GNU contributors, and many of those >> maintainers are so because of being in a position of trust by several >> others working on GNU. It's a reasonable compromise. > > I agree. > > I find it only a pity that I discover after 10days that the > assignment did not arrive. I already wrote the clerk. Yes, it is a nuisance. As a rule, you (as well as the responsible maintainer) will receive a scan with the signature of an FSF representative on it: the copyright assignment is a contract with requirements for both parties. Sometimes stuff goes wrong or delays occur, not always readily explainable. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] my patch? Examn (bidi in preparation)
Uwe Brauer writes: >> Uwe Brauer writes: > >> Yes, it is a nuisance. As a rule, you (as well as the responsible >> maintainer) will receive a scan with the signature of an FSF >> representative on it: the copyright assignment is a contract with >> requirements for both parties. > >> Sometimes stuff goes wrong or delays occur, not always readily >> explainable. > > Sorry to nag, but you seem a person to be sufficiently high «placed» in the > GNU/FSF hierarchy either to judge or to give advice. Hm? I am not a member of the FSF at all. > Yesterday I wrote again the FSF clerk, Donald R. Robertson III, > complaining his missing reaction when I sent him the FSF copyright > papers, the 8th of August, however he still did not answer, do you > know how to proceed? Wait some more days. For one thing: if you wrote yesterday, yesterday was Sunday. Which is not a work day even in the U.S. (and Donald is an actual employee). And Monday is not half over in the U.S. since there is a timezone difference. And if he is not paid for mostly idling, he'll be working off a task queue. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] copyright assignment patches
Uwe Brauer writes: > Hi > > It seems that the process of the copyright assignment is finished. Could > somebody please confirm, I could then send 2 or 3 patches for styles and > documentation I prepared. I am afraid that at the current point of time, the accessible list ends with 2016-8-23 (about a week ago) so there might have been some work queue or vacation that has interfered with the updates to current date. Did you receive notice about the completion? If so, it usually takes half a day until the results carry into the official list. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] copyright assigment
Uwe Brauer writes: > Hi > > Any news with my copyright assignment? No. Have you received your copy signed by the FSF clerk? As long as that is not the case, the assignment has not been processed anyway. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] patch for the documentation concerning prettifying and friends
Uwe Brauer writes: [...] Uwe's assignment is finally registered for Emacs with date 2016-8-22. -- David Kastrup signature.asc Description: PGP signature ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] pretty patch
Uwe Brauer writes: > To be applied by > > git am --patch-format=hg pretty-new.patch > > I could not resist adding the following > > XEmacs user should either switch to GNU Emacs 25 or use the x-symbol > package which provides a similar feature. > > Although auctex is a GNU package it provides still some support for > Xemacs, so the documentation should reflect that at least with one > sentence. We document the XEmacs-specific support in AUCTeX (basically, how to use AUCTeX's scripts to create an XEmacs package and that XEmacs-distributed packages are usually activated automatically when installed via the package system). I don't think that AUCTeX documentation is the place to suggest switching to Emacs. Nor should we specifically recommend the use of unmaintained packages like X-Symbol. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Defaulting `TeX-parse-self' to t
Arash Esbati writes: > Hi all, > > is there a particular reason why AUCTeX sets `TeX-parse-self' to nil? > Does this reason still apply or can we default it to t? Yes, and yes. AUCTeX is intended to be useful as a system-wide installed TeX mode. If you are not actually interested in TeX, having AUCTeX rifle through whole remote directory hierarchies in the search for style files and what not is going to be a huge cost you did not ask for. > I have the impression that this decision is leading to a new standard > answer which is "customize latex-verbatim-environments or > latex-verbatim-environments-local" when somebody asks for "How do I add > my defined verbatim env to AUCTeX?" We have many style files and they > are in a good shape; I think we should move users in a direction that > they actually use them and get all the benefits. > > WDYT? I think that the AUCTeX manual should start right away with suggesting to _individually_ enable TeX-parse-self. Which it does as far as I remember. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Documentation of \PreviewMacro* in preview.dtx
Arash Esbati writes:
> Hi all,
>
> in preview.dtx, we have around line 304:
>
> % \DescribeMacro{\PreviewMacro} If ... you put a
> % declaration like
> % \begin{quote}
> % |\PreviewMacro[*[[!]{\includegraphics}|
> % \end{quote}
> % or, more readable,
> % \begin{quote}
> % |\PreviewMacro[{*[][]{}}]{\includegraphics}|
> % \end{quote}
>
> and around line 389, an example for \PreviewMacro* looking like this:
>
> % As an example for using this argument, you might want to specify
> % \begin{quote}
> % |\PreviewMacro*\footnote[{[]}][#1{}]|
> % \end{quote}
>
> I'm not a preview user, but I would have expected that \footnote comes
> last. Can someone confirms this?
>
> % \begin{quote}
> % |\PreviewMacro*[{[]}][#1{}]\footnote|
> % \end{quote}
The content of prfootnote.def appears to confirm your suspicion. This
seems like a documentation error.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [PATCH] When using SyncTeX with Evince, do not switch focus after syncing.
Mosè Giordano writes: > Dear Hong, > >> Do you all agree to make this an option? If so, I can update the patch >> to accommodate that. > > I'm not still convinced that the patch you propose is a good idea. > Why should people run "View" command to *not* view the document? If > you only want to sync the viewer, you should define a custom command > that does that, why hijacking a command that is supposed to do > something else? In addition, what's the point of syncing the viewer > without viewing it? "Viewing it" and "letting it take over focus" are two different things. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] [PATCH] When using SyncTeX with Evince, do not switch focus after syncing.
Colin Baxter writes: >>>>>> "Tassilo" == Tassilo Horn writes: > > Tassilo> Mosè Giordano writes: Hi! > > >>> Do you all agree to make this an option? If so, I can update the > >>> patch to accommodate that. > >> > >> I'm not still convinced that the patch you propose is a good > >> idea. Why should people run "View" command to *not* view the > >> document? > > Tassilo> I know what Hong's referring to. You want to view the > Tassilo> document in Evince but keep editing in emacs, thus the > Tassilo> input focus should stick there. > > To me, and assuming I have not totally misunderstood the proposal, > there seems to be a philosophical issue here. If you were to write a > program, you wouldn't expect to view the output of the compilation as > you enter the code. You might look at an initial output but then you > would concentrate on the code before compiling again - you surely > wouldn't do both simultaneously. TeX/LaTeX is also code, so why would > not the same expectation apply? I apologise if I have misunderstood. Well, your philosophy did not manage to prevent preview-latex. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
[AUCTeX-commit] GNU AUCTeX branch, master, updated. 837d590008c1dd4e92ffbce15008efb761d11f7c
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 837d590008c1dd4e92ffbce15008efb761d11f7c (commit) from b20eea0e238d4283ea168feec1ad54a841bce186 (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 837d590008c1dd4e92ffbce15008efb761d11f7c Author: David Kastrup Date: Mon Nov 6 23:58:23 2017 +0100 Remove use of .runandhide operator Ghostscript bug 698680 <https://bugs.ghostscript.com/show_bug.cgi?id=698680> has been caused by the removal of the .runandhide operator in Ghostscript 9.22 upstream. Since .runandhide has no longer been used in a security-critical manner, its operation can be emulated by storing the respective information in a .preview-ST variable. Potentially malicious code would not be able to retrieve a non-safe "save" object from here. --- Summary of changes: preview.el.in | 8 1 file changed, 4 insertions(+), 4 deletions(-) hooks/post-receive -- GNU AUCTeX ___ auctex-commit mailing list auctex-com...@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-commit
[AUCTeX-diffs] GNU AUCTeX branch, master, updated. 837d590008c1dd4e92ffbce15008efb761d11f7c
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 837d590008c1dd4e92ffbce15008efb761d11f7c (commit)
from b20eea0e238d4283ea168feec1ad54a841bce186 (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 837d590008c1dd4e92ffbce15008efb761d11f7c
Author: David Kastrup
Date: Mon Nov 6 23:58:23 2017 +0100
Remove use of .runandhide operator
Ghostscript bug 698680
<https://bugs.ghostscript.com/show_bug.cgi?id=698680> has been caused
by the removal of the .runandhide operator in Ghostscript 9.22
upstream. Since .runandhide has no longer been used in a
security-critical manner, its operation can be emulated by storing the
respective information in a .preview-ST variable. Potentially
malicious code would not be able to retrieve a non-safe "save" object
from here.
diff --git a/preview.el.in b/preview.el.in
index d113721..6685341 100644
--- a/preview.el.in
+++ b/preview.el.in
@@ -738,10 +738,10 @@ SETUP may contain a parser setup function."
null eq{pop{pop}bind}if def\
<>setpagedevice\
-/preview-do{[count 3 roll save]3 1 roll dup length 0 eq\
-{pop}{setpagedevice}{ifelse .runandhide}\
+/preview-do{/.preview-ST[count 4 roll save]def dup length 0 eq\
+{pop}{setpagedevice}{ifelse exec}\
stopped{handleerror quit}if \
-aload pop restore}bind def "
+.preview-ST aload pop restore}bind def "
(preview-gs-color-string preview-colors)))
(preview-gs-queue-empty)
(preview-parse-messages (or setup #'preview-gs-dvips-process-setup
@@ -1090,7 +1090,7 @@ NONREL is not NIL."
.locksafe} stopped pop "
(mapconcat 'preview-ps-quote-filename all-files ""))
preview-gs-init-string
- (format "[%s(r)file]aload exch %s .runandhide aload pop "
+ (format " %s(r)file /.preview-ST 1 index def %s exec
.preview-ST "
(preview-ps-quote-filename file)
(preview-gs-dsc-cvx 0 preview-gs-dsc))
---
Summary of changes:
preview.el.in | 8
1 file changed, 4 insertions(+), 4 deletions(-)
hooks/post-receive
--
GNU AUCTeX
___
auctex-diffs mailing list
auctex-di...@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-diffs
Re: [AUCTeX-devel] Call for patches for last release on 11.x series
Uwe Brauer writes: >>>> "Mosè" == Mosè Giordano writes: > >> Dear all, > >> now that the Ghostscript issue has been fixed I think it's a good >> time to release a new version of AUCTeX, that will be the last in >> the 11.x series concerning new features. At the same time we'll >> release AUCTeX 12.01, (almost?) identical to 11.92, but it'll >> support only GNU Emacs >>> = 24 and the development will continue only here. > > Ok, what's about styles? Could those go in the future in both branches, > in master in the 11.92-old or whatever the name of the branch will be?? The point of stopping development for XEmacs is not to increase the workload. I'd recommend not making a branch but a _tag_ for the last version known to work with XEmacs to make unambiguously clear that the AUCTeX developers are not responsible for working on an XEmacs version any more. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Call for patches for last release on 11.x series
Arash Esbati writes: > Mosè Giordano writes: > >> 2017-11-10 18:42 GMT+01:00 David Kastrup : >>> Uwe Brauer writes: >>> >>>> Ok, what's about styles? Could those go in the future in both branches, >>>> in master in the 11.92-old or whatever the name of the branch will be?? >>> >>> The point of stopping development for XEmacs is not to increase the >>> workload. >> >> Yes, we don't want to port any new feature --- including style files >> --- to the then frozen 11.x series. > > +1. > >>> I'd recommend not making a branch but a _tag_ for the last >>> version known to work with XEmacs to make unambiguously clear that the >>> AUCTeX developers are not responsible for working on an XEmacs version >>> any more. >> >> For sure we'll just tag release_11_92 for the time being. I think >> that we reserve the possibility to create a branch if it'll be >> necessary to port important bug fixes to 11.x series, but this can be >> decided later. > > I'm also in favor of this version. We have a situation right now that > the current master is not really compatible with XEmacs and older > Emacsen because of the `delete-dups' usage here and there. I think we > should create a new branch and add a compatibility function there. Can > we use the one from Emacs 25.3 and just rename it to `TeX-delete-dups'? > > (defun delete-dups (list) > "Destructively remove `equal' duplicates from LIST. > Store the result in LIST and return it. LIST must be a proper list. > Of several `equal' occurrences of an element in LIST, the first > one is kept." > (let ((l (length list))) > (if (> l 100) > (let ((hash (make-hash-table :test #'equal :size l)) > (tail list) retail) > (puthash (car list) t hash) > (while (setq retail (cdr tail)) > (let ((elt (car retail))) > (if (gethash elt hash) > (setcdr tail (cdr retail)) > (puthash elt t hash) > (setq tail retail) > (let ((tail list)) > (while tail > (setcdr tail (delete (car tail) (cdr tail))) > (setq tail (cdr tail)) > list) I'm pretty sure I created an efficient version of delete-dups (didn't use a hash table but rather some algorithm based on sorting) for RefTeX at one point of time. Can we use that? Have I committed it? -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Call for patches for last release on 11.x series
David Kastrup writes: >> (defun delete-dups (list) >> "Destructively remove `equal' duplicates from LIST. >> Store the result in LIST and return it. LIST must be a proper list. >> Of several `equal' occurrences of an element in LIST, the first >> one is kept." >> (let ((l (length list))) >> (if (> l 100) >> (let ((hash (make-hash-table :test #'equal :size l)) >> (tail list) retail) >> (puthash (car list) t hash) >> (while (setq retail (cdr tail)) >> (let ((elt (car retail))) >> (if (gethash elt hash) >> (setcdr tail (cdr retail)) >> (puthash elt t hash) >> (setq tail retail) >> (let ((tail list)) >> (while tail >> (setcdr tail (delete (car tail) (cdr tail))) >> (setq tail (cdr tail)) >> list) > > I'm pretty sure I created an efficient version of delete-dups (didn't > use a hash table but rather some algorithm based on sorting) for RefTeX > at one point of time. Can we use that? > > Have I committed it? Ok, so RefTeX is now in the Emacs repo and it neither defines nor uses anything called akin to delete-dups. This is serious "Huh?" domain. Pretty sure I am not dreaming this up. At any rate: not sure whether XEmacs has the same make-hash-table/gethash/puthash calls. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Call for patches for last release on 11.x series
David Kastrup writes: > David Kastrup writes: > >>> (defun delete-dups (list) >>> "Destructively remove `equal' duplicates from LIST. >>> Store the result in LIST and return it. LIST must be a proper list. >>> Of several `equal' occurrences of an element in LIST, the first >>> one is kept." >>> (let ((l (length list))) >>> (if (> l 100) >>> (let ((hash (make-hash-table :test #'equal :size l)) >>> (tail list) retail) >>> (puthash (car list) t hash) >>> (while (setq retail (cdr tail)) >>> (let ((elt (car retail))) >>> (if (gethash elt hash) >>> (setcdr tail (cdr retail)) >>> (puthash elt t hash) >>> (setq tail retail) >>> (let ((tail list)) >>> (while tail >>> (setcdr tail (delete (car tail) (cdr tail))) >>> (setq tail (cdr tail)) >>> list) >> >> I'm pretty sure I created an efficient version of delete-dups (didn't >> use a hash table but rather some algorithm based on sorting) for RefTeX >> at one point of time. Can we use that? >> >> Have I committed it? > > Ok, so RefTeX is now in the Emacs repo and it neither defines nor uses > anything called akin to delete-dups. This is serious "Huh?" domain. > Pretty sure I am not dreaming this up. > > At any rate: not sure whether XEmacs has the same > make-hash-table/gethash/puthash calls. Ah, it's there, in reftex.el after all. (defun reftex-uniquify (list &optional sort) ;; Return a list of all strings in LIST, but each only once, keeping order ;; unless SORT is set (faster!). (setq list (copy-sequence list)) (if sort (progn (setq list (sort list 'string<)) (let ((p list)) (while (cdr p) (if (string= (car p) (car (cdr p))) (setcdr p (cdr (cdr p))) (setq p (cdr p) list) (let ((p list) lst elt) ;; push all sublists into lst in reverse(!) order (while p (push p lst) (setq p (cdr p))) ;; sort all sublists (setq lst (sort lst (lambda (x1 x2) (string< (car x1) (car x2) (while (cdr lst) (setq elt (car (car lst))) ;; for equal elements in the sorted sublist, replace the ;; last(!) original list member with nil (when (string= elt (car (cadr lst))) (setcar (pop lst) nil) (while (and (cdr lst) (string= elt (car (cadr lst (setcar (pop lst) nil))) (pop lst))) ;; weed out all nils and return. (delq nil list))) But that's specialized on strings, and a different package anyway. -- 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. 9fdfe2c3d466d0a37b2d46b94052516e16d2c0c5
"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 9fdfe2c3d466d0a37b2d46b94052516e16d2c0c5 (commit) > from b2571b6048928882903204553716b9ec19d3e15b (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 9fdfe2c3d466d0a37b2d46b94052516e16d2c0c5 > Author: Ikumi Keita > Date: Thu Nov 30 00:32:49 2017 +0900 > > Re-implement auto-detect of path separator from kpsewhich output > > * tex.el (TeX-kpathsea-path-delimiter): Accept t for Autodetect again > and make it default on w32 platform. > (TeX-tree-expand): Use heuristics as much as possible to determine the > path separator, paying attention to the case that it cannot be > determined. > > +;; It seems that kpsewhich accepts semicolon as > +;; path delimiter even on non-w32 platform and > +;; converts it to colon if necessary. > +;; Quote from texmf.cnf of TeXLive 2017: > +;; "In this file, either ; or : can be used to > +;; separate path components." > +,(mapconcat #'identity vars ";"))) You know, it is not prohibited to actually test out such things. dak@lola:/usr/local/tmp/lilypond$ kpsewhich --progname=latex --expand-path "/home/dak/tex/india/:/tmp" /home/dak/tex/india:/tmp dak@lola:/usr/local/tmp/lilypond$ kpsewhich --progname=latex --expand-path "/home/dak/tex/india/;/tmp" dak@lola:/usr/local/tmp/lilypond$ kpsewhich --version kpathsea version 6.2.3 Copyright 2017 Karl Berry & Olaf Weber. License LGPLv2.1+: GNU Lesser GPL version 2.1 or later <http://gnu.org/licenses/lgpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. What are you trying to fix here? The code you replaced was not an accident. -- 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. 9fdfe2c3d466d0a37b2d46b94052516e16d2c0c5
David Kastrup writes: > "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 9fdfe2c3d466d0a37b2d46b94052516e16d2c0c5 (commit) >> from b2571b6048928882903204553716b9ec19d3e15b (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 9fdfe2c3d466d0a37b2d46b94052516e16d2c0c5 >> Author: Ikumi Keita >> Date: Thu Nov 30 00:32:49 2017 +0900 >> >> Re-implement auto-detect of path separator from kpsewhich output >> >> * tex.el (TeX-kpathsea-path-delimiter): Accept t for Autodetect again >> and make it default on w32 platform. >> (TeX-tree-expand): Use heuristics as much as possible to determine the >> path separator, paying attention to the case that it cannot be >> determined. >> > >> + ;; It seems that kpsewhich accepts semicolon as >> + ;; path delimiter even on non-w32 platform and >> + ;; converts it to colon if necessary. >> + ;; Quote from texmf.cnf of TeXLive 2017: >> + ;; "In this file, either ; or : can be used to >> + ;; separate path components." >> + ,(mapconcat #'identity vars ";"))) > > You know, it is not prohibited to actually test out such things. > > dak@lola:/usr/local/tmp/lilypond$ kpsewhich --progname=latex > --expand-path "/home/dak/tex/india/:/tmp" > /home/dak/tex/india:/tmp > dak@lola:/usr/local/tmp/lilypond$ kpsewhich --progname=latex > --expand-path "/home/dak/tex/india/;/tmp" > In other words: texmf.cnf has different rules than the kpsewhich command line. The previous code was the result of a lot of testing and discussion. Replacing it without doing either is not a recipe for success. -- 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. 9fdfe2c3d466d0a37b2d46b94052516e16d2c0c5
Ikumi Keita writes: >>>>>> David Kastrup writes: > >> You know, it is not prohibited to actually test out such things. > >> dak@lola:/usr/local/tmp/lilypond$ kpsewhich --progname=latex --expand-path >> "/home/dak/tex/india/:/tmp" >> /home/dak/tex/india:/tmp >> dak@lola:/usr/local/tmp/lilypond$ kpsewhich --progname=latex --expand-path >> "/home/dak/tex/india/;/tmp" > >> dak@lola:/usr/local/tmp/lilypond$ kpsewhich --version >> kpathsea version 6.2.3 >> Copyright 2017 Karl Berry & Olaf Weber. >> License LGPLv2.1+: GNU Lesser GPL version 2.1 or later >> <http://gnu.org/licenses/lgpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. > > Oops, I'm so sorry! I did test > kpsewhich --progname latex --expand-path '$SYSTEXMF;$TEXMFLOCAL' > and see that it output > /usr/local/texlive/2017/texmf-var:/usr/local/texlive/texmf-local > . This observation led me to think that kpsewhich accepts semicolon as > the delimiter. Sigh. Interesting: $ kpsewhich --progname latex --expand-path '$SYSTEXMF;$TEXMFLOCAL' /var/lib/texmf:/usr/local/share/texmf:/usr/share/texlive/texmf-dist $ kpsewhich --progname latex --expand-path '$SYSTEXMF' /var/lib/texmf:/usr/local/share/texmf:/usr/share/texlive/texmf-dist:/usr/share/texmf $ kpsewhich --progname latex --expand-path '$TEXMFLOCAL' /usr/local/share/texmf I have no idea what this signifies, to be honest. The ; being part of the variable name? -- 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. 9fdfe2c3d466d0a37b2d46b94052516e16d2c0c5
Mosè Giordano writes: > Hi Keita, > > 2017-11-29 18:38 GMT+01:00 Ikumi Keita : >> My current idea is to fix the relavant code with the attached patch. >> Could you please take a look and see whether it is reasonable? > > Are the braces necessary? Otherwise comma will not be special and could be part of a directory name. -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Fix about usage of kpsewhich
Mosè Giordano writes: > Hi Keita, > > sorry for the late reply, these days I'm getting all @gnu.org emails > with huge delay. > > 2017-12-01 15:05 GMT+01:00 Ikumi Keita : >> Hi all, >> >> First I apologize my repeated mistakes in recent commits with regard to >> the usage of kpsewhich. The function `TeX-tree-expand' in the latest >> git repository is broken badly. >> >> Since the new release is planned to be soon, it's better to clean up >> the things without much delay, I think. There are three ways that we >> can take. >> >> (1) Commit my pending patch proposed in >> https://lists.gnu.org/archive/html/auctex-devel/2017-11/msg00030.html > > Braces + comma should be fine. Unless there are directories containing comma itself in the PATH. Is that an allowed character in Windows file systems? -- David Kastrup ___ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Fix about usage of kpsewhich
Ikumi Keita writes:
> Hi Mosè and all,
>
>>>>>> Mosè Giordano writes:
>> sorry for the late reply, these days I'm getting all @gnu.org emails
>> with huge delay.
>
> It seems that the delivery system of GNU mail list suffers severe
> trouble these days. No mails since Nov 30 are listed on
> https://lists.gnu.org/archive/html/auctex/
> https://lists.gnu.org/archive/html/auctex-devel/
> https://lists.gnu.org/archive/html/bug-auctex/
> at the time of writing this message.
>
>> 2017-12-01 23:34 GMT+01:00 David Kastrup :
>>>> Braces + comma should be fine.
>>>
>>> Unless there are directories containing comma itself in the PATH. Is
>>> that an allowed character in Windows file systems?
>
>> It's allowed in NTFS, according to Wikipedia[1]:
>
>> In Win32 namespace: any UTF-16 code unit (case-insensitive) except
>> /\:*"?<>| as well as NUL
>
> Actually, the code in question is used regardless of the platform, so
> the file systems involved are not limited to NTFS.
>
> I just thought of another approach using brace expansion. We can obtain
> the right path delimiter by just taking the second character of the
> output of "kpsewhich --expand-path {.,..}".
Presumably
kpsewhich --expand-path "{.,..}"
That's really clever. Yes, it should do the trick, assuming the Windows
executable doesn't try to be helpful by inserting the current directory,
and "foreign" implementations of kpsewhich (like the MikTeX one) behave
accordingly.
> It would be robust since it would work on any platform and not be
> interfered with directory names with literal comma.
Indeed.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
Re: [AUCTeX-devel] Fix about usage of kpsewhich
David Kastrup writes:
> Ikumi Keita writes:
>
>> Hi Mosè and all,
>>
>>>>>>> Mosè Giordano writes:
>>> sorry for the late reply, these days I'm getting all @gnu.org emails
>>> with huge delay.
>>
>> It seems that the delivery system of GNU mail list suffers severe
>> trouble these days. No mails since Nov 30 are listed on
>> https://lists.gnu.org/archive/html/auctex/
>> https://lists.gnu.org/archive/html/auctex-devel/
>> https://lists.gnu.org/archive/html/bug-auctex/
>> at the time of writing this message.
>>
>>> 2017-12-01 23:34 GMT+01:00 David Kastrup :
>>>>> Braces + comma should be fine.
>>>>
>>>> Unless there are directories containing comma itself in the PATH. Is
>>>> that an allowed character in Windows file systems?
>>
>>> It's allowed in NTFS, according to Wikipedia[1]:
>>
>>> In Win32 namespace: any UTF-16 code unit (case-insensitive) except
>>> /\:*"?<>| as well as NUL
>>
>> Actually, the code in question is used regardless of the platform, so
>> the file systems involved are not limited to NTFS.
>>
>> I just thought of another approach using brace expansion. We can obtain
>> the right path delimiter by just taking the second character of the
>> output of "kpsewhich --expand-path {.,..}".
>
> Presumably
>
> kpsewhich --expand-path "{.,..}"
>
> That's really clever. Yes, it should do the trick, assuming the Windows
> executable doesn't try to be helpful by inserting the current directory,
> and "foreign" implementations of kpsewhich (like the MikTeX one) behave
> accordingly.
Ok, here is how I suggest to use that trick: if the expanded string
contains ; use ; as delimiter, otherwise :. That should work even if
some executable considers it sane to insert drive letters or directory
separators or whatever else. But a ; in there should never be
accidental.
--
David Kastrup
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
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-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-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] 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] 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
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
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: >> 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] 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] 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: > [ 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] [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
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
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:
>>>>>> 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:
>>>>>> 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:
>>>>>> 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] 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: 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: 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: 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: 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: 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: 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
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: 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: 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
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: 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
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
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
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: 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: 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
