> But it is very common that one loads and evals one and the same file
> over and over. We don't want to keep a history of that.
I had not considered that. Does loading the same file more than once
really happen often? On purpose? For what reason?
To load a file multiple times
So the "provide" merely sets a flag, and this flag causes the
encompassing load not to throw the collected previous autoload data
away at the end of the load sequence, but use it for marking the
changed functions with the old autoloads in their properties.
Clearer now?
Why mak
Lute Kamstra <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
> If files do get reloaded often (for good reasons), then recording
> old values of functions and variables should probably be done only
> if require loads a file. That wouldn't happen twice.
Well, I still thin
David Kastrup <[EMAIL PROTECTED]> writes:
> Lute Kamstra <[EMAIL PROTECTED]> writes:
>
>> David Kastrup <[EMAIL PROTECTED]> writes:
>>
>>> Lute Kamstra <[EMAIL PROTECTED]> writes:
>>>
Consider the following situation:
function 'a is autoloaded: (autoload "blabla" ...).
function
Lute Kamstra <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> Lute Kamstra <[EMAIL PROTECTED]> writes:
>>
>>> Consider the following situation:
>>>
>>> function 'a is autoloaded: (autoload "blabla" ...).
>>> function 'b is autoloaded: (autoload "other" ...).
>>> functio
David Kastrup <[EMAIL PROTECTED]> writes:
> Lute Kamstra <[EMAIL PROTECTED]> writes:
>
>> Consider the following situation:
>>
>> function 'a is autoloaded: (autoload "blabla" ...).
>> function 'b is autoloaded: (autoload "other" ...).
>> function 'c is defined.
>> function 'd is unbound.
>>
>> "b
David Kastrup <[EMAIL PROTECTED]> writes:
> Lute Kamstra <[EMAIL PROTECTED]> writes:
>
>> David Kastrup <[EMAIL PROTECTED]> writes:
>>
>> [...]
>>
>>> Well, the idea explored a bit later later was that "load" will
>>> record autoloads, but not do anything with them by itself, instead
>>> letting "
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Consider the following situation:
>
> function 'a is autoloaded: (autoload "blabla" ...).
> function 'b is autoloaded: (autoload "other" ...).
> function 'c is defined.
> function 'd is unbound.
>
> "blabla" defines 'a, 'b, 'c, and 'd as functions.
>
> Do
Lute Kamstra <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
> [...]
>
>> Well, the idea explored a bit later later was that "load" will
>> record autoloads, but not do anything with them by itself, instead
>> letting "provide" handle it.
>
> Ah, now I understand your pos
Stefan Monnier <[EMAIL PROTECTED]> writes:
[...]
> if I have function FOO autoloaded and (require 'blabla) replaces
> that with some other definition, than an immediately following
> (unload-feature 'blabla) should restore the autoload, no matter
> whether the autoload was pointing to blabla.el o
David Kastrup <[EMAIL PROTECTED]> writes:
[...]
> Well, the idea explored a bit later later was that "load" will record
> autoloads, but not do anything with them by itself, instead letting
> "provide" handle it.
Ah, now I understand your post. I think letting provide record
autoloads is a bad
So a better expedient would be to have
(provide 'xxx)
turn on the necessary action at the end of the current load file in
case that the feature is provided the first time.
I am not sure if this really solves any part of the question of
how we might try to implement better unloadin
Lute Kamstra <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> The function that _clearly_ should trigger/use the recorded
>> information, however, is "require".
>
> Agreed.
>
>> I don't think we need to make (load "filename") (unload-feature
>>'filename) do anything sen
David Kastrup <[EMAIL PROTECTED]> writes:
> Lute Kamstra <[EMAIL PROTECTED]> writes:
>
>> Richard Stallman <[EMAIL PROTECTED]> writes:
>>
>>> Is there a reason why Fload can't do like do_autoload and use the
>>> information recorded in Vautoload_queue to set the autoload property
>>> o
I am at the moment just
concerned with creating a setup where Emacs packagers would have no
qualms enabling AUCTeX as the default mode by preloading "auctex.el"
(to be created). And this goal can be achieved if (unload-feature
'auctex) or something similar will remove it agai
I wrote:
Again: do you have knowledge of even a single instance where this
alias has been used, promoted, or found convenient for or by as much
as a single person?
If these names are not really used by users, maybe we could these
names in both AUCTeX and tex-mode.e
If I can get a _definite_ promise that tex-mode's aliases on TeX-mode
and LaTeX-mode will stay in place (as long as the AUCTeX maintainer of
the day is throwing a tantrum when necessary to remind people), then I
would be fine with letting AUCTeX merely overload tex-mode, latex-mode
Richard Stallman <[EMAIL PROTECTED]> writes:
> If I can get a _definite_ promise that tex-mode's aliases on
> TeX-mode and LaTeX-mode will stay in place (as long as the
> AUCTeX maintainer of the day is throwing a tantrum when
> necessary to remind people), then I would be fine wit
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Richard Stallman <[EMAIL PROTECTED]> writes:
>
>> Is there a reason why Fload can't do like do_autoload and use the
>> information recorded in Vautoload_queue to set the autoload property
>> of function symbols?
>>
>> Maybe it could work.
>>
>
Richard Stallman <[EMAIL PROTECTED]> writes:
> Why do we desperately need a special alias just in exactly that
> case where it really is likely to cause problems?
>
> The idea that it "causes problems" is based on a mistaken idea of
> how things ought to work. ALL the usual ways of invoki
Why do we desperately need a special alias just in exactly that case
where it really is likely to cause problems?
The idea that it "causes problems" is based on a mistaken idea of
how things ought to work. ALL the usual ways of invoking a mode
for TeX should be defined by both AUCTeX and
Richard Stallman <[EMAIL PROTECTED]> writes:
> So they SHOULD be invoked by the same names.
>
> I explained already why nothing else makes sense. AUCTeX makes
> extensive use of mode cookies in local variables, and those are only
> obeyed in the lowercase version. The choice of AUCTe
Richard Stallman <[EMAIL PROTECTED]> writes:
> Is there a reason why Fload can't do like do_autoload and use the
> information recorded in Vautoload_queue to set the autoload property
> of function symbols?
>
> Maybe it could work.
>
> I think it would be better not to try changing thi
The only conceivable way they could be called unwittingly by a user is
if a TeX file from somebody else contained a "mode: TeX" or "mode:
LaTeX" specification.
The reason they would be used if some users types M-x TeX mode.
It seemed plausible to me that some users would do that.
It co
Is there a reason why Fload can't do like do_autoload and use the
information recorded in Vautoload_queue to set the autoload property
of function symbols?
Maybe it could work.
I think it would be better not to try changing this now.
___
E
You wrote in an earlier mail:
> Ok, so it was "eric". At that time AUCTeX started to be sort of a
> contender, and AUCTeX used TeX-mode and LaTeX-mode, quite likely with
> the intent not to conflict. And maybe "eric" switched between
> computers and was surprised that TeX-mode worked on one syst
Andreas Schwab <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
> I didn't blame anyone, it's just that both tex-mode and TeX-mode are
> natural ways to name the mode for processing TeX input files, independent
> of who is implementing it.
AFAIK, no mode command uses capita
Andreas Schwab <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> I didn't claim any such thing. I just pointed out that the only
>> conceivable effect of the aliases in our times is to cause trouble
>> and confusion. If people need a historic excuse for blaming the
>>
David Kastrup <[EMAIL PROTECTED]> writes:
> I didn't claim any such thing. I just pointed out that the only
> conceivable effect of the aliases in our times is to cause trouble and
> confusion. If people need a historic excuse for blaming the bad
> effects of their current decisions on somebody
Andreas Schwab <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> Even if at one time before 1990 it might have been the case that
>> the mode was not merely aliased, I doubt that pre-1990
>> compatibility is a major concern nowadays.
>
> But you can't claim that AUCTeX i
David Kastrup <[EMAIL PROTECTED]> writes:
> "Is using" is an exaggeration. I checked out version 1.1 (from 1990),
> and the only "uses" for it are the aliases. I doubt that this has ever
> been different (in spite of the following changelog entries), but if
> somebody has older versions around,
Stefan Monnier <[EMAIL PROTECTED]> writes:
>>> I of course understand why it would override them, but not why it
>>> would set major-mode to `latex-mode' rather than to `LaTeX-mode'.
>>>
>>> In my opinion, LaTeX-mode is the AUCTeX major mode, while
>>> latex-mode can be either, depending on the u
>> I of course understand why it would override them, but not why it
>> would set major-mode to `latex-mode' rather than to `LaTeX-mode'.
>>
>> In my opinion, LaTeX-mode is the AUCTeX major mode, while latex-mode
>> can be either, depending on the user's preference.
> You are confusing the value
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> Forget it, Bub. TeX-mode and LaTeX-mode are already taken as
>> aliases. Who was the smart guy responsible for that? The
>> annotations show:
>
>> 1.3 (jimb 13-May-91): ;;;###autoload
>> 1.17 (eric 23-Apr-93): (defalias 'TeX
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> I explained already why nothing else makes sense. AUCTeX makes
>> extensive use of mode cookies in local variables, and those are only
>> obeyed in the lowercase version. The choice of AUCTeX vs tex-mode is
>> a user preference and should not be embe
> I explained already why nothing else makes sense. AUCTeX makes
> extensive use of mode cookies in local variables, and those are only
> obeyed in the lowercase version. The choice of AUCTeX vs tex-mode is
> a user preference and should not be embedded into files.
I of course understand why it
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> The whole separation has been maintained rather meticulously. For
>
> Actually, it seems to still use lowercase for the "main" major mode
> functions (like latex-mode, ...), which I think is wrong.
I explained already why nothing else makes sense. A
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> So auctex.el without auctex-override.el would be a waste of time.
>
> I can't see any auctex.el in auctex's CVS repository, so I'll assume
> it's autogenerated file and I guess what I called auctex-override.el
> could be called auctex.el.
It will be a
Andreas Schwab <[EMAIL PROTECTED]> writes:
> Stefan Monnier <[EMAIL PROTECTED]> writes:
>
>> I think the above is a good reason why "TeX-mode" and "LaTeX-mode"
>> belong to AUCTeX rather than to tex-mode.el.
>
> tex-mode.el is using TeX-mode since the beginning, and LaTeX-mode since
> 1986.
"Is u
Stefan Monnier <[EMAIL PROTECTED]> writes:
>>> Don't you mean auctex-unload-hook?
>
> No. I was talking about a new file auctex-override.el which
> provides the feature auctex-override and whose unloading runs thus
> the auctex-override-unload-hook.
Whoops, my mistake.
Lute.
_
David Kastrup <[EMAIL PROTECTED]> writes:
[...]
>>> Won't work. Autoloads corresponding to a different file than the
>>> loaded one don't get restored.
>>
>> That's a bug which we should fix.
>
> I am not sure it is a bug. If I load several packages redefining one
> symbol, and then unload _one
> So auctex.el without auctex-override.el would be a waste of time.
I can't see any auctex.el in auctex's CVS repository, so I'll assume it's
autogenerated file and I guess what I called auctex-override.el could be
called auctex.el. I used a different name specifically because I have no
idea what
Stefan Monnier <[EMAIL PROTECTED]> writes:
In the mean time, you can use an auctex-override-unload-hook to
re-install the autoloads.
>>> Don't you mean auctex-unload-hook?
>> Probably.
>
> No. I was talking about a new file auctex-override.el which
> provides the feature auctex-override
>>> Won't work. Autoloads corresponding to a different file than the
>>> loaded one don't get restored.
>> That's a bug which we should fix.
> I am not sure it is a bug.
Maybe not the problem described in the text I quoted, but if I have function
FOO autoloaded and (require 'blabla) replaces that
>>> In the mean time, you can use an auctex-override-unload-hook to
>>> re-install the autoloads.
>> Don't you mean auctex-unload-hook?
> Probably.
No. I was talking about a new file auctex-override.el which provides the
feature auctex-override and whose unloading runs thus the
auctex-override-un
> The whole separation has been maintained rather meticulously. For
Actually, it seems to still use lowercase for the "main" major mode
functions (like latex-mode, ...), which I think is wrong.
If you followed my auctex-override approach (where all of auctex, except
for this auctex-override file,
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Stefan Monnier <[EMAIL PROTECTED]> writes:
>
> [...]
>
>>> Won't work. Autoloads corresponding to a different file than the
>>> loaded one don't get restored.
>>
>> That's a bug which we should fix.
>
> unload-feature restores the (autoload ...) form tha
Andreas Schwab <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> Forget it, Bub. TeX-mode and LaTeX-mode are already taken as aliases.
>> Who was the smart guy responsible for that? The annotations show:
>>
>> 1.3 (jimb 13-May-91): ;;;###autoload
>> 1.17
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> Any objection to removing those aliases?
>> These names belong to AUCTeX and are just wrong in tex-mode.el.
>
>> I don't see any reason to consider them "wrong", or to think they
>> "belong" to anything other than tex-mode.el.
>
> - tex-mode.el
Richard Stallman <[EMAIL PROTECTED]> writes:
> Any objection to removing those aliases?
> These names belong to AUCTeX and are just wrong in tex-mode.el.
>
> I don't see any reason to consider them "wrong", or to think they
> "belong" to anything other than tex-mode.el.
To put a bit more
Stefan Monnier <[EMAIL PROTECTED]> writes:
> I think the above is a good reason why "TeX-mode" and "LaTeX-mode" belong to
> AUCTeX rather than to tex-mode.el.
tex-mode.el is using TeX-mode since the beginning, and LaTeX-mode since
1986.
1985-09-29 Richard M. Stallman ([EMAIL PROTECTED])
Richard Stallman <[EMAIL PROTECTED]> writes:
> Maybe we can shift recording the old autoload definition from
> do_autoload to Fload?
>
> Fload has no information about this.
> It would have to be done in Fdefun, etc.
>From what I understand, the way it works now is that Ffset records the
> Any objection to removing those aliases?
> These names belong to AUCTeX and are just wrong in tex-mode.el.
> I don't see any reason to consider them "wrong", or to think they
> "belong" to anything other than tex-mode.el.
- tex-mode.el uses the "tex-" and "latex-" prefix for all its fun
I guess it can't hurt to leave a function on a hook or in
auto-mode-alist if it is replaced by a restored autoload. (Even if
feature x actually put it there.) See patch below. Erring on the
other side seems more damaging: removing a function from a hook when
that function was
Any objection to removing those aliases?
These names belong to AUCTeX and are just wrong in tex-mode.el.
I don't see any reason to consider them "wrong", or to think they
"belong" to anything other than tex-mode.el.
___
Emacs-devel mailing list
Maybe we can shift recording the old autoload definition from
do_autoload to Fload?
Fload has no information about this.
It would have to be done in Fdefun, etc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/list
David Kastrup <[EMAIL PROTECTED]> writes:
> Forget it, Bub. TeX-mode and LaTeX-mode are already taken as aliases.
> Who was the smart guy responsible for that? The annotations show:
>
> 1.3 (jimb 13-May-91): ;;;###autoload
> 1.17 (eric 23-Apr-93): (defalias 'TeX-mode 'te
Stefan Monnier <[EMAIL PROTECTED]> writes:
[...]
>> Won't work. Autoloads corresponding to a different file than the
>> loaded one don't get restored.
>
> That's a bug which we should fix.
unload-feature restores the (autoload ...) form that is present in the
autoload property of the symbol. A
>(add-hook 'auctex-override-unload-hook
> (lambda ()
>(dolist (x TeX-saved-other-tex-autoloads)
> (fset (car x) (cdr x)
Hmm... that won't work because the unload-hook is run before unload-feature
calls fmakunbound on the functions.
I guess in t
David Kastrup <[EMAIL PROTECTED]> writes:
[...]
> Won't work. Autoloads corresponding to a different file than the
> loaded one don't get restored. I have not found the exact place that
> causes this, but only the "right" definitions cause the autoload to be
> saved in the autoload property of
> Forget it, Bub. TeX-mode and LaTeX-mode are already taken as aliases.
> Who was the smart guy responsible for that? The annotations show:
> 1.3 (jimb 13-May-91): ;;;###autoload
> 1.17 (eric 23-Apr-93): (defalias 'TeX-mode 'tex-mode)
> 1.3 (jimb 13-May-91):
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> Does anybody see any problems with that approach apart from the fact
>> that it is crazy as anything?
>
> Well, for one thing, it's crazy as anything.
>
> What about the following:
>
> - make all auctex thingies use the TeX- and LaTeX- prefix (i.e. no
David Kastrup <[EMAIL PROTECTED]> writes:
> Lute Kamstra <[EMAIL PROTECTED]> writes:
>
>> unload-feature removes functions it is unloading from hooks. What
>> about removing these functions from auto-mode-alist as well?
[...]
> Actually, _both_ sound like a spectacularly bad idea if the unloade
> Does anybody see any problems with that approach apart from the fact
> that it is crazy as anything?
Well, for one thing, it's crazy as anything.
What about the following:
- make all auctex thingies use the TeX- and LaTeX- prefix (i.e. no conflict
at all with the other tex-mode), with autolo
Lute Kamstra <[EMAIL PROTECTED]> writes:
> unload-feature removes functions it is unloading from hooks. What
> about removing these functions from auto-mode-alist as well?
>
> Index: lisp/loadhist.el
> ===
> RCS file: /cvsroot/emacs/
unload-feature removes functions it is unloading from hooks. What
about removing these functions from auto-mode-alist as well?
Lute.
Index: lisp/loadhist.el
===
RCS file: /cvsroot/emacs/emacs/lisp/loadhist.el,v
retrieving revision
66 matches
Mail list logo
