>> The additional patch below seems to fix it.
> Thanks, I installed the patch under your name after Tassilo's change.
Thanks.
>> Stefan "who doesn't use AUCTeX's makefile to compile AUCTeX"
> How do you compile AUCTeX then, some `package' magic?
More or less: I use the "in place install
Arash Esbati wrote:
> Thanks, I did 'make clean' and applied your patch locally. Running make
> again gives:
>
> --8<---cut here---start->8---
> In toplevel form:
> bib-cite.el:591:11: Error: Recursive ‘require’ for feature ‘tex’
>
> In toplevel form:
> context
I suggest the patch below which renames `tex-site.el.in` to
`tex-site.el`. We lose the `AUCTEX-date` info, but IMO the
simplification is worth this minor downside (at least for GNU-devel
ELPA packages, the date is encoded in the `AUCTEX-version`).
[ We could keep `AUCTEX-version` in `tex-site.el`
> And I like the way the manual is formatted. Compare this:
> https://www.gnu.org/software/auctex/manual/auctex.html
> with this:
> https://elpa.gnu.org/devel/doc/auctex.html
Hmm... nice. FWIW, the elpa rendering is the same as that of
https://www.gnu.org/software/emacs/manual/html_
> And there it is! So it seems to work now; you can stop knocking. ;-)
Yay! That wood should is happy,
Stefan
> AFAIU, using `update-file-autoloads' again means keeping track of all
> AUCTeX files in the new GNUmakefile, or is there a better solution?
You should be able to use `update-directory-autoloads`.
It's a bit more cumbersome to use than `loaddefs-generate` but other
than that it should be OK.
> gitlog-to-auctexlog is based on gitlog-to-emacslog. Should the issue be
> reported there as well? gitlog-to-emacslog isn't different in this
> regard:
> https://git.savannah.gnu.org/cgit/emacs.git/tree/build-aux/gitlog-to-emacslog#n62
`gitlog-to-emacslog` is used only to build the release tarb
> But before investing time on Uwe's scenario: Stefan, do you know why
> no new devel release has been built so far?
You've presumably received copies (via auctex-devel) of the build
error notification. The original problem was that elpa.gnu.org did not
have TeX installed. After fixing it there
> +# If this is not a Git repository, just generate an empty ChangeLog.
> +test -d .git || {
> + >"$output"
> + exit
> +}
> +
> # Get the new value for gen_origin from the latest version in the repository.
> new_origin=`git log --pretty=format:%H 'HEAD^!'` || exit
I suspect it would be better
> Hence either
> 1) Uwe installs git
He does have Git installed. He's just working in a directory that's not
under Git's control.
> 2) AUCTeX implements fallback in build-aux/gitlog-to-auctexlog
> is necessary to have Changelog.
IMO `build-aux/gitlog-to-auctexlog` should gracefully fail
(e.g. g
>> I use it with `emacs -Q ...` when I want to try and isolate a problem.
>
> Thanks for the hint. My approach to that for package `foo' until now
> was:
>
> (progn
> (package-initialize t)
> (package-activate 'foo))
That works as well, indeed. There are many ways to skin this cat. 🙂
[ In m
> fatal: not a git repository (or any of the parent directories): .git
> fatal: not a git repository (or any of the parent directories): .git
> fatal: not a git repository (or any of the parent directories): .git
> fatal: not a git repository (or any of the parent directories): .git
> (cd doc; make
>> Side note: an AUCTeX installed with `package.el` behaves very similarly
>> except the autoloads file is called `auctex-autoloads.el` instead of
>> `loaddefs.el` and that this file takes care of the `add-to-list`, so
>> users just need to
>>
>> (load "~/Repos/el/auctex/auctex-autoloads")
>
>
> I think we need to adapt our instructions. To run straight from the
> clone, this seems to work fine:
>
> (add-to-list 'load-path "~/Repos/el/auctex")
> (load "~/Repos/el/auctex/loaddefs.el" nil t t)
Side note: an AUCTeX installed with `package.el` behaves very similarly
except the auto
> I was thinking about this too and my vote is to go with option 2 (i.e.,
> not your favorite ;-). I think it would make sense to have a sort of
> "staging area" where we can install code which might break or have other
> problems. Syncing it directly to ELPA-DEVEL and letting people install
> it
> Stefan, how would I make the switch on elpa? The package recipe I've
> tested is this
>
> (auctex :url "https://git.savannah.gnu.org/git/auctex.git";
> :branch "main"
> :news "NEWS.org"
> :make "elpa"
> :doc ("doc/auctex.texi" "doc/preview-latex.texi"))
>
> D
>> Duh: it's `:doc`, not `:manual`!
>> Sorry!
> Haha, and then it works just fine. ;-)
Yay!
Stefan
> Yes, it is. But I need the distinction if the current version got
> there just now (in HEAD) or previously.
So just a "yes/no" kind of information? I wonder what you use it for.
>> [ This assumes that the `:manual ...` thingy does
>> successfully&correctly build the docs. ]
>
> This is whe
>> Why do you need to look at diffs?
> In order to extract the version number.
I don't understand: it's right there in the file, you don't need
the diffs to extract it, no?
> Does :manual ("doc/auctex.texi" "doc/preview-latex.texi") tell elpa to
> build the docs again although the recipe's :make
>> The "%H" above makes it output the commit hash where `Version:` was
>> changed, so you can replace that with an appropriate % thingy to get
>> the date instead.
> Why would I need the date of the last release?
Don't know. I guess I misundersood what you meant by:
Instead of looking at spe
> Alright, I've had some time to do some fiddling. In the auctex
> repository, there's some new main branch (based on externals/auctex)
> where I've changed how AUCTEXVERSION and AUCTEXDATE are determined.
> Instead of looking at specially formatted lines in ChangeLog, it just
> looks at the git d
>> And nowhere in the elpa repository do I find some statement that for
>> auctex the externals/auctex branch in elpa.git is to be used instead
>> of the main or master branch of auctex.git.
> It's always built from `externals/`.
Well, not for `make auctex.tar` where it's built from whatever is HE
> So I could just replace packages/auctex with some other clone of
> auctex.git?
Yes.
>> So your first and third steps above can happen at some other time.
> Alright. But I currently don't understand how "make packages/auctex"
> knows which commit to check out.
The first `make packages/auctex`
> So just that I get it right, we'd do:
>
> - Make our former externals/elpa branch the new main branch
> - git checkout -b main externals/elpa && git push
> - Then clone elpa and setup the infrastructure as you said
> - Edit elpa-packages locally (but don't yet commit/push)
> - remov
g., info files.
>
> The reason is that at the time where we added AUCTeX to ELPA (and
> created the externals/elpa branch for that purpose), the ELPA machinery
> wasn't able to perform our normal build procedure. But Stefan Monnier
> chimed in and suggested that nowadays, those is
>> Hmm... this does look awful 🙁
> Exactly. 💀
How 'bout a hack more like:
(defvar auctex--extra-mode-parent
'((LaTeX-mode . latex-mode)
...))
(advice-add 'derived-mode-p :after-until #'auctex--compat-derived-mode-p)
(defun auctex--compat-derived-mode-p (&rest modes)
>>> (a-2) Now `TeX-add-local-master' adds entry of new mode names such as
>>> %%% Local Variables:
>>> %%% mode: LaTeX <-- not `latex'
>>> %%% End:
>
>> I don't like this very much: IMO the `mode:` cookie should really not specify
>> the "mode" to use but rather describe the file-type (Emacs c
>> We should fix this for Emacs-30.
>> [ And then add some backward compatibility hack (presumably using
>> an advice for when AUCTeX is used on Emacs<30). ]
> I attach my tentative proposal for Emacs<30, using an advice.
So, IIUC, you're counting on Someone™ to do the work on the Emacs side 🙂
> (a) The mode names change as follows:
> plain-tex-mode -> plain-TeX-mode
> latex-mode -> LaTeX-mode
> doctex-mode-> docTeX-mode
> context-mode -> ConTeXt-mode
> texinfo-mode -> Texinfo-mode
> ams-tex-mode -> AmSTeX-mode
> japanese-plain-tex-mode -> japane
> (defun semantic-symref-derive-find-filepatterns (&optional mode)
> ...(snip)...
> (let* ((mode (or mode major-mode)) <-- mode = LaTeX-mode
> ...(snip)...
> ;; No hit, try auto-mode-alist.
> (dolist (X auto-mode-alist) <-- Looking at `auto-mode-alist'
> (when (and (eq (cdr
>>> 2. ConTeXt modes
>> In the case of `ConTeXt-mode`, maybe the better option is to make the
>> submodes be minor modes?
> Hmm. Some difficulties for that idea come up to my mind:
Well, I did say "maybe" :-)
> 2. As they are minor mode, en-mode and nl-mode can be turned on at the
>same time.
>This is much unsatisfactory. I'm currently thinking to apply the
>attached patch to sort out the disorders of mode names. It works as
>follows:
>(a) It uses the names without `TeX-' prefix for LaTeX-mode,
>plain-TeX-mode and TeX-mode.
>(b) Those mode definitions are ove
> d. Directory local variables
>> Maybe the simplest option is to get used to the idea of setting
>> `derived-mode-parent` manually for those modes which are "morally"
>> a child mode, even though the implementation (and behavior) does not
>> inherit much if anything?
>
> Do you mean
> (put 'La
>> Not sure either, but we can arrange to re-instate the aliases (they're
>> not autoloads) upon unload, if so desired (actually, I think all it
>> takes (in Emacs-29) is to use `(defalias 'LaTeX-mode nil)` instead of
>> `(fset 'LaTeX-mode nil)`. Also, while I'm here, I think we should check
>> th
Hi, and thanks, it's great to see concrete movement towards trying to
fix this longstanding issue.
> 1. I'd like to push it to savannah server as a feature branch of AUCTeX
>repository (it isn't ready to merge into master branch yet.) Do you
>think it's OK?
Can't of any reason why not, bu
>> [ And in Emacs-30, you can use `major-mode-remap-alist` so that
>> `mode: latex` will not call `latex-mode` but some other function,
>> such as `LaTeX-mode`. ]
> Yes, `major-mode-remap-alist` provides a clean way. However AUCTeX still
> need to keep the current code for a certain period for
> 1. I first tried [A] because [B] wouldn't be easy to retain
> compatibility for users who have
>- a lot of files with "mode: latex" tag in the file local variables
> section.
The `mode:` specifies which function is called to enable the mode,
rather than which value of `major-mode` will
> Oh, I see where that happens (and why it doesn't happen if we redirect
> with `defalias`).
Hmm... no I still can't reproduce it, even with something else than
a defalias.
Stefan
Stefan Monnier [2022-09-25 10:01:40] wrote:
>> 1. Suppose that the file has %%% mode:latex as file variable. When emacs
>> opens this file, it runs `latex-mode' accordingly, which in turn runs
>> AUCTeX `LaTeX-mode' by redirectiton. Then it sets `major-mode' to
&g
> be a derived mode of `latex-mode'. However, defining `LaTeX-mode' by
> (define-derived-mode LaTeX-mode latex-mode ...) would cause infinite
> loop when redirection is enabled.
Yes, it's ugly. That's part of the reason for the weird way we define
`tex-mode` in `tex-mode.el` (and that was precede
> 1. Suppose that the file has %%% mode:latex as file variable. When emacs
> opens this file, it runs `latex-mode' accordingly, which in turn runs
> AUCTeX `LaTeX-mode' by redirectiton. Then it sets `major-mode' to
> `LaTeX-mode'. After that, `hack-local-variables' runs; it sees that
> `major mode
> Indeed. I learned people are often tempted to use `latex-' prefix to
> customize the behavior of AUCTeX. It means that, in addition to
> `latex-mode-hook', `latex-mode-map' and `latex-mode-syntax-table' (and
> their counterparts of plain-tex-mode, texinfo-mode and doctex-mode) are
> potential sou
> Maybe we could start by stating some goals:
>
> - AUCTeX should not set the `major-mode` to point to
> non-AUCTeX functions (even if/when it overrides those functions).
>
> - Cleanup the mode function names. Currently, AUCTeX's LaTeX mode is
> variously called:
>
> latex-mode
> TeX-l
Maybe we could start by stating some goals:
- AUCTeX should not set the `major-mode` to point to
non-AUCTeX functions (even if/when it overrides those functions).
- Cleanup the mode function names. Currently, AUCTeX's LaTeX mode is
variously called:
latex-mode
TeX-latex-mode
LaT
>>> I wonder why/if it's important that the AUCTeX modes identify as the
>>> builtin modes, i.e., what would be the issue with having (La)TeX-mode
>>> major-modes which have no relationship to (la)tex-mode at all plus a
>>> setup command users would call in their init file in order to modify
>>> `a
> 1. Why can't latex-mode not be removed/substituted by auctex?
For technical/administrative/historical reasons.
> 2. What's about reftex? Right now, since auctex provides a mayor
>mode, you can put it in a hook to startup reftex when you open a
>latex file with auctex ins
>> You may have seen an on-going discussion about the annoyance of the
>> mixups between latex-mode and LaTeX-mode and such.
> Could you tell us where that discussion takes place?
I think it's on gnu.emacs.help, aka help-gnu-emacs.
It started with someone complaining that rainbow-delimiters doesn
Tassilo Horn [2022-09-20 08:38:27] wrote:
> Stefan Monnier writes:
>> What I'm really asking here is if there's a willingness to introduce
>> the inevitable bit of breakage in exchange for a supposed longer term
>> benefit, and/or if someone can think of a better
David Kastrup [2022-09-19 23:20:27] wrote:
> Stefan Monnier writes:
>> I'm wondering if it would be possible to turn AUCTeX into a minor mode.
]...
> Doesn't really seem to fit the conventions for major and minor mode
> keybindings.
Not sure what you mean by that. A
You may have seen an on-going discussion about the annoyance of the
mixups between latex-mode and LaTeX-mode and such.
I do think it would be good to try and "integrate" the two modes, for
some definition of "integrate". The question being indeed what
"integration" is the best way forward.
I'm w
> That's this :help function in LaTeX-symbols-toolbar-switch-contents:
>
> --8<---cut here---start->8---
>:help ,(lambda (&rest _ignore)
> (concat "Turn "
> (if LaTeX-symbols-toolbar-visible-flag "off " "on ")
>
> I see `syntax-propertize-via-font-lock' is implemented using
> `font-lock-syntactic-keywords' as seen below. Is it planned that
> `syntax-propertize-via-font-lock' survives after
> `font-lock-syntactic-keywords' is removed in Emacs 29?
`syntax-propertize-via-font-lock' is not even declared obsol
> Thanks, Mr. Janitor! The patch looks good to me and its definitely fine
> for our ELPA releases. However, what about our standard tarball
> releases? There, Package-Requires has no meaning and we'd inevitable
> need to bump the emacs version requirement to 24.4. That's basically
> fine with m
The patch below removes the fallback code for when `nadvice` is not
available, replacing it with a dependency on `nadvice-0.3` (which could
be replaced by a dependency on Emacs-24.4).
Stefan
diff --git a/auctex.el b/auctex.el
index da5e667ba4..72d262dc33 100644
--- a/auctex.el
+++ b/auc
> Thanks. I've found one more occurrence of XEmacs compat code in
> reftex-vars.el. Can you please install the attached patch as well?
> TIA.
Thanks, pushed.
> Note to myself: We have to adjust RefTeX manual as well and mention the
> removal of XEmacs support.
I believe I just took care of tha
> I suggest to apply the following change to reftex-auc.el. The declared
> functions are defined in ext:latex and not ext:tex; and the name of
> arguments are also corrected. I don't have access to emacs repo, do you
> mind install the change?
Pushed, thanks,
Stefan
>> Many thanks for this. I ran `make' in tests directory and get the
>> following error (re-arranged for legibility):
> Thanks for the report. I don't experience such error, so I suppose that
> emacs 28 enhanced check for scope discrepancy between lexical and
> dynamic variables. (I'm using emacs
> Well, this is a piece of regresstion test suits and the variable in
> question is used only within this particular `ert-deftest'. So I
> presumed it's OK. Is this presumtion wrong?
Do you *need* the variable to be called "var"? If not, then renaming it
will save you the trouble of wondering und
>>> I'll try to mess up in a more challenging way next time, I promise.
>> Challenge accepted. :-)
> Well, it seems that we already have a challenge. :-)
> I'm now fixing regression tests, and found that preview.el(.in) still
> needs adaptation because it uses ad-{enable,disable}-advice explicitly.
>> Also, I had changes in the `README` which I had to throw out because
>> I couldn't find anything corresponding to it in the auctex.git code.
> The README file is generated from intro.texi and preview-readme.texi in
> auctex.git, so README itself isn't under control of git and is listed in
> .git
> Get your shits together, Stefan,
I'll try to mess up in a more challenging way next time, I promise.
> I've just merged master into externals/auctex. Could you please check
> if everything's right there, i.e., foremost that changes in *.el.in
> files on master are in the corresponding *.el fil
> At last I managed to figure out the origin and seem to recover the
> normal behavior. Sorry for your inconvinience.
Clearly I'm to blame, so thanks for the fix.
>> Thanks, I'd like to merge them into AUCTeX repository. If nobody
>> objects, I'll do it soon.
> Merged.
Great, thanks!
Stefan
> Oh, I wasn't aware of that! Thank you.
>
> By the way again, here are two very minor issues about your update to
> font-latex.el:
> 1. The doc string of `font-latex-keywords-1' was formerly
> "Subdued level highlighting for LaTeX modes."
> , but is now
> "High level highlighting for LaTeX modes."
BTW, I rebased my branch on top of your patch, and hence on top of
auctex.git's `master`.
Stefan
>> Duh! Thanks for the heads up!
>> Indeed, `defadvice` hides the code from the byte-compiler which is why
>> I didn't get a warning for the (boundp 'begin).
>
> I expect that the attached patch makes preview.el.in ready for lexical
> binding...oops, I just noticed that revised commit has been put
> Duh! Thanks for the heads up!
> Indeed, `defadvice` hides the code from the byte-compiler which is why
> I didn't get a warning for the (boundp 'begin).
> And I clearly forgot my usual scan of `(set `.
I (force) pushed an updated set of patches which should fix
those problems.
Stefan
> (defadvice TeX-region-create (around preview-counters)
> "Write out counter information to region."
> (let ((TeX-region-extra
> (concat
> (and (boundp 'begin)
> ^
>preview-buffer-has-counters
>(mapconcat
>
.
Please try it out and let me know if you find problems.
Also, feel free to merge any or all parts into AUCTeX's upstream, thanks.
Stefan
commit f8b4d2a9fede599eef619dfeabff7d716d71e250
Author: Stefan Monnier
Date: Mon Mar 22 22:56:59 2021 -0400
Use UTF-8 for all ELisp
I'd like to install the patch below but would like some confirmation
that my understanding is right.
AFAICT, `TeX-auto-add-type` is a macro that's run exclusively at the
top-level of some of AUCTeX's files (context.el, tex.el, and latex.el),
and it uses `add-hook` without a "local" argument in ord
branch: externals/auctex
commit 58701876d3c30dc54803696d93f430faca04b7a3
Author: Stefan Monnier
Commit: Stefan Monnier
multi-prompt.el, style/beamer*.el: Get copyright just right
---
multi-prompt.el| 3 +--
style/beamerarticle.el | 2 +-
style/beamerswitch.el | 2 +-
3 files
Is there a particular reason why AUCTeX doesn't make use of
next-error-function and remaps `next-error` via the keymap instead?
Stefan
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
> I was disabling some of the automatic setup. My original purpose of this
> was to try to reduce my emacs startup time.
In an ideal ELPA world, startup is fast because the automatic setup is
cheap (just a few autoloads and such). So if the automatic setup is too
slow, that can be for one of two
> Another problem seems to be that installing AUCTeX from ELPA via use-package
> does not work because that forcefully does (require ') under the
> hoods.
Actually (require 'auctex) does work with the ELPA package *if*
package-initialize was run before (and without a non-nil argument).
Calling pac
> I have around 30 packages that I install through ELPA. Since this is pretty
> unwieldy,
I must say that I find it far from obvious that it's unwieldy.
> I have these all configured using the "use-package" macro,
By that do you mean that you first go through the trouble of disabling
the normal
> Sorry, I don't quite understand the purpose of the patch. Is it
> intended for the ELPA version of AUCTeX or for the upstream package?
The ELPA version.
> The fact that the package is against tex-site.el in ELPA makes me
> think it's for the ELPA version of AUCTeX. In that case, I don't have
> Still, this workaround seem a little odd to me. First, It seems odd that I
> can't start AUCTeX "when I want", i.e., by using the line (load "auctex.el"
> nil t t), even though this worked for me in previous versions of auctex
> (11.89 and 11.88).
Packaging in ELPA aims to follow the way packag
> It just wants to ensure that when you kill the TeX wizard buffer, you
> also exit the recursive edit that it entered.
Then it sounds about right, yes.
Stefan
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/li
>>> Here's another one.
>> Does "another one" mean "another one within a few days"? Then I
>> probably have missed the first one(s).
No, the other one was a good while ago and the changes are in the
repository, so either you magically came up with the same fixes, or you
didn't miss it ;-)
>> Hm,
Here's another one. There's still lots of warnings, and some of the
warnings left in the files I touched below seem serious (e.g. use of
custom-buffer-done-function which seems to be a variable that doesn't
exist).
Stefan
diff --git a/context.el b/context.el
index b962e0d..25151e5 1006
> Could the ELPA scripts send a mail to the address in .el
> instead of (or in addition to) emacs-devel? Not everyone who has a
> package on ELPA follows emacs-devel too closely.
Good point,
Stefan
___
auctex-devel mailing list
auctex-devel@g
Stefan
commit ca06d68639f6f0d3305c697db8b66b99ac024df6
Author: Stefan Monnier
Date: Sat Nov 1 21:10:16 2014 -0400
Revert last commit, because it lacked metadata.
diff --git a/tex-jp.el b/tex-jp.el
--- a/tex-jp.el
+++ b/tex-jp.el
@@ -1,7 +1,7 @@
;;; tex-jp.el --- Support fo
Here's another patch which silences various compilation warnings, and
fixes a few commenting conventions (noticeable when using
outline-minor-mode).
Stefan
diff --git a/bib-cite.el b/bib-cite.el
index 9ecbc81..164385a 100644
--- a/bib-cite.el
+++ b/bib-cite.el
@@ -1002,6 +1002,16 @@ run
> I cherry-picked the commit from ELPA branch, good to see it works
> flawless! Thanks.
Good to know, thanks,
Stefan
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
monnier pushed a change to branch externals/auctex.
from 6ff4fca Add requires to fix separate compilation.
new 5211b5e Create a top level directory in the preview tarball.
new 19cb9af Add new TeX-file-line-error option
new c2d3585 Update MinionPro style.
branch: externals/auctex
commit 7909657676bab72663be6e12dc7e1c4f915b89ba
Author: Stefan Monnier
Date: Fri Nov 28 12:55:20 2014 -0500
Fix compilation and remove a few more warnings.
* tex.el (TeX-view-program-list-builtin): Fix up paren typo.
* preview.el: Cleanup compiler
monnier pushed a commit to branch externals/auctex
in repository elpa.
commit 6ff4fca5fc332789c8e295cc38a3334019ccfef1
Author: Stefan Monnier
Date: Wed Nov 26 15:07:23 2014 -0500
Add requires to fix separate compilation.
---
latex.el |1 +
preview.el |3 ++-
style
>> I'm not against this change, I'd only like to know if we can avoid to
>> move all files around. For ELPA, I understand the problem is that
>> preview.el isn't in the `load-path', we could add "preview/" (actually
>> (expand-file-name "preview" TeX-lisp-directory) ) to the `load-path'
>> in tex-
>> find-file-hooks has been obsolete since Emacs-22.1 and I expect to get
>> rid of it fairly soon.
> Feel free to do that. Now I've added a defvaralias for XEmacs.
Thanks,
Stefan
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lis
> Oh, I replied only to the list. Anyway, I've written a CL entry for you
> and committed (at least most parts of) the patch. A few things I
> couldn't use because XEmacs compatibility, like there's only
> find-file-hooks in XEmacs, no find-file-hook.
find-file-hooks has been obsolete since Emac
Here's a patch mostly based on byte-compiler warnings.
Stefan
diff --git a/bib-cite.el b/bib-cite.el
index 612641c..f1a113b 100644
--- a/bib-cite.el
+++ b/bib-cite.el
@@ -1,7 +1,7 @@
;;; bib-cite.el --- test
;; bib-cite.el - Display \cite, \ref or \label / Extract refs from BiBTeX fil
> Cc-ing emacs-devel: is there any problem with the package builder on
> ELPA?
It should work again tonight,
Stefan
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex-devel
> Cc-ing emacs-devel: is there any problem with the package builder on
> ELPA?
I'll check ASAP,
Stefan "back online for a couple of days, drowning in the backlog"
___
auctex-devel mailing list
auctex-devel@gnu.org
https://lists.gnu.org/mailman
>> Thanks. Then it makes more sense to keep both auctex and
>> preview-latex in the same package (more specifically to do the "mv
>> preview/* ./").
> As said, that's fine with me. But auctex/preview/ has its own autotools
> build setup that needs to be merged with auctex's. I've never used the
>> I'm not sure you're answering my question, so let me rephrase it: does
>> it work with tex-mode.el?
> The answer remains "No".
Thanks. Then it makes more sense to keep both auctex and preview-latex
in the same package (more specifically to do the "mv preview/* ./").
Stefan
_
It is not clear to me why the act of importing a runnable version of
AUCTeX into ELPA should be precluded from running a Makefile rule.
It is not like ELPA can directly access git repositories and extract
whatever it wants, so the import will always involve explicit steps.
>> Ye
>> It is not clear to me why the act of importing a runnable version of
>> AUCTeX into ELPA should be precluded from running a Makefile rule. It
>> is not like ELPA can directly access git repositories and extract
>> whatever it wants, so the import will always involve explicit steps.
Yes, GNU EL
> I've hoped that with the new Git ELPA, we could just checkout the
> savannah auctex repository as submodule, and then add some hacks to the
> makefiles to produce tarballs suitable for ELPA. Won't work, no?
No, because:
I'd very much prefer not having to run code from
the package itself.
The GNU ELPA package of AucTeX is ridiculously old.
As part of updating, I'd like to "streamline" the process, which mostly
involves reducing the difference between the code in the `elpa' branch
and the code in the official auctex repository.
The differences I can see are the following:
- the `pr
revno: 434
revision-id: monn...@iro.umontreal.ca-20130809215250-lqyfvls3iqfdbui9
parent: monn...@iro.umontreal.ca-20130809020004-wchassib8v7g6pcq
committer: Stefan Monnier
branch nick: elpa
timestamp: Fri 2013-08-09 17:52:50 -0400
1 - 100 of 117 matches
Mail list logo
