Tassilo Horn t...@gnu.org writes:
Wrapping with (eval-when (compile load eval) ...) seems to work, but I'm
not sure if that's a good idea.
Or you could turn them into macros.
Indeed, that looks like a typical use-case for macros, but I'm rather
sure that there's a good reason that the auto
David Kastrup d...@gnu.org writes:
Or you could turn them into macros.
Indeed, that looks like a typical use-case for macros, but I'm rather
sure that there's a good reason that the auto parser stuff is like it
is. David?
[...]
At any rate, the base of the style code has probably not
That's ok. But if the style files were compiled, adding the requires
into the style files would make the compilation take minutes, because
each style file compilation would need to load the core files first.
Yup. I personally don't see much need to add the `require's in those
style files.
I guess I should wrap those TeX-auto-add-type calls with a
`eval-when-compile', right?
You could.
No, I get a compile error in tex.el when compiling
Of course, eval-when-compile and eval-and-compile come with their own
set of problems. My you could wasn't really meant as an encouragement.
Stefan Monnier monn...@iro.umontreal.ca writes:
Or you could turn them into macros.
Indeed, that looks like a typical use-case for macros, but I'm rather
sure that there's a good reason that the auto parser stuff is like it
is. David?
Whatever the reason, looking at the code of
Stefan Monnier monn...@iro.umontreal.ca writes:
That's ok. But if the style files were compiled, adding the requires
into the style files would make the compilation take minutes, because
each style file compilation would need to load the core files first.
Yup. I personally don't see much
Glenn Morris r...@gnu.org writes:
Hi Glenn,
;; Local Variables:
;; byte-compile-warnings: (free-vars unresolved)
;; End:
That does indeed stop the unresolved function warnings but not the
free-vars warnings. Why not?
Personally I think this is bad practice.
Why? As said, all those
Tassilo Horn wrote:
Personally I think this is bad practice.
Why?
Well, what if you make a typo and use a function that is really undefined?
As said, all those style files use LaTeX-* and TeX-* vars and
functions defined by AUCTeX's core. However, the style files can't be
required
Glenn Morris r...@gnu.org writes:
Personally I think this is bad practice.
Why?
Well, what if you make a typo and use a function that is really
undefined?
It'll throw at runtime, but hopefully it does so before shipping a
release.
As said, all those style files use LaTeX-* and TeX-*
2014-01-30 Tassilo Horn t...@gnu.org:
And possibly adding requires would slow down the compilation process
quite a bit. There are currently 144 style files. As said, most of
them are rather short, but the tex, latex, and font-latex they'd need to
require are large (~14000 LOC in total).
Is
Tassilo Horn t...@gnu.org writes:
Why can't the style files require whatever AUCTeX files they need?
They could, I guess.
I was wrong. I've just added the needed requires to all style files,
but I get exactly as many warnings as before. This is because of these
reasons.
1. Many TeX-* and
Mosè Giordano giordano.m...@libero.it writes:
And possibly adding requires would slow down the compilation process
quite a bit. There are currently 144 style files. As said, most of
them are rather short, but the tex, latex, and font-latex they'd need
to require are large (~14000 LOC in
And with the ELPA builds, I think it's the same thing.
IIRC there are different cases.
When installing an ELPA package, indeed all the .el files are compiled
within the running Emacs. There aren't many guarantees of ordering tho,
so it could potentially happen that the style files get compiled
1. Many TeX-* and LaTeX-* functions and variables are not generated
before tex.el and latex.el are loaded. AUCTeX has an auto parser
[...]
The byte-compiler doesn't seem to execute top-level funcalls, so all
those functions/vars are unknown at compile-time.
Indeed, the byte-compiler
Admittedly I haven't spent much time dealing with compatibility with
older Emacsen lately, but in the past I've never found warnings useful
for that work. So I only ever used warnings to help debug improve my
code on my main Emacs version, and completely ignored warnings when
porting to
Thierry Volpiatto thierry.volpia...@gmail.com writes:
Hi Thierry,
While you are at it, I had often complaints about some completing-read's
working badly with helm.
This is because they are not written correctly in Auctex.
I have submitted a bug long time ago but never had an answer.
Oh,
Tassilo Horn wrote:
;; Local Variables:
;; byte-compile-warnings: (free-vars unresolved)
;; End:
That does indeed stop the unresolved function warnings but not the
free-vars warnings. Why not?
Personally I think this is bad practice.
Anyway, aren't you missing a not:
Tassilo Horn t...@gnu.org writes:
Thierry Volpiatto thierry.volpia...@gmail.com writes:
Hi Thierry,
While you are at it, I had often complaints about some completing-read's
working badly with helm.
This is because they are not written correctly in Auctex.
I have submitted a bug long time
Tassilo Horn writes:
Any good idea to fix those? I could add requires, but that would
possibly slow down the compilation and is not neccessary as explained
above. I could add defvars (but no declare-functions cause that's not
available on older emacsen/xemacs) for the free variables, but
Glenn Morris r...@gnu.org writes:
Tassilo Horn wrote:
(but no declare-functions cause that's not available on older
emacsen/xemacs)
It's available since Emacs 22.2, ie 6 years, or the past 9 Emacs releases.
If XEmacs has not added even a compat stub in that time, which would
take about a
Tassilo Horn wrote:
(but no declare-functions cause that's not available on older
emacsen/xemacs)
It's available since Emacs 22.2, ie 6 years, or the past 9 Emacs releases.
If XEmacs has not added even a compat stub in that time, which would
take about a minute, that seems telling.
Glenn Morris r...@gnu.org writes:
(but no declare-functions cause that's not available on older
emacsen/xemacs)
It's available since Emacs 22.2, ie 6 years, or the past 9 Emacs releases.
If XEmacs has not added even a compat stub in that time, which would
take about a minute, that seems
(eval-and-compile
(unless (fboundp 'declare-function)
(defmacro declare-function (fn file optional arglist fileonly)
`(autoload ',fn ,file
Yuck! This is an ugly trick trying to silence warnings.
Better macroexpand it to nil: you'll get warnings in older Emacsen, but
at least
Stefan Monnier writes:
(eval-and-compile
(unless (fboundp 'declare-function)
(defmacro declare-function (fn file optional arglist fileonly)
`(autoload ',fn ,file
Yuck! This is an ugly trick trying to silence warnings.
Not much uglier than declare-function itself. These
That's certainly not recommended for everyone and everything, but since
declare-function must used in situations were the function to be
declared is known to be already defined at runtime, the autoload will
never do anything anyway;
It does do something:
- it does something during
Stefan Monnier writes:
That's certainly not recommended for everyone and everything, but since
declare-function must used in situations were the function to be
declared is known to be already defined at runtime, the autoload will
never do anything anyway;
It does do something:
- it does
On updating to latest Auctex from the Package Manager, there were
hundreds of warnings during compilation.
Indeed.
Expected behaviour:
Packages in Elpa compile without warnings.
ELPA packages are not magical that way, no. It completely depends on
the package's maintainers to try and make
27 matches
Mail list logo
