1:47 p.m.
Hi there
I would like to have the variable
`compilation-error-regexp-systems-list' buffer-local. I don't see much
of a point to drag all those error parsing regexps across my entire
XEmacs. However, in `compilation-mode' there is a nasty call to
kill-all-local-variables rendering my efforts useless.
Does anyone know why this is in there? Doesn't occur to
me. Unfortunately there are some loosely specified error regexps
that do a catch all, shadowing some of my own definitions.
Actually there is an interesting email, which might provide a clue, to
be found here http://osdir.com/ml/emacs.sources/2004-03/msg00031.html
Regards
-- Marcus
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:01 p.m.
>>>> "Marcus" == Marcus Harnisch
<marcus.harnisch(a)gmx.net> writes:
Marcus> Hi there
Marcus> I would like to have the variable
Marcus> `compilation-error-regexp-systems-list' buffer-local. I don't see
Marcus> much of a point to drag all those error parsing regexps across my
Marcus> entire XEmacs.
I'm not sure what you mean by "dragging," but it is just one symbol in a
global table referencing a single copy of the variable.
I local variables actually have a higher cost associated with them due to the
extra meta-data. Also, you will get an extra copy in any buffer that does set
it (depending on how it is set.) In any I would imagine that there is at
least a symbol table's worth a meta-data used by the buffer-local code.
Marcus> However, in `compilation-mode' there is a nasty
Marcus> call to kill-all-local-variables rendering my efforts useless.
Marcus> Does anyone know why this is in there? Doesn't occur to
Marcus> me.
I believe it is SOP for minor modes. Makes sure there's no goop left over
from the previous incarnation.
You can make the buffer-local survive `kill-all-local-variables' by making it
permanent, thus:
(put 'compilation-error-regexp-systems-list 'permanent-local t)
Marcus> Unfortunately there are some loosely specified error regexps
Marcus> that do a catch all, shadowing some of my own definitions.
I'd have to poke around in the code to see how the regexps are traversed.
Are you adding yours, w/append or cons? In either case, try the other.
Marcus> Actually there is an interesting email, which might provide a
Marcus> clue, to be found here
Marcus> http://osdir.com/ml/emacs.sources/2004-03/msg00031.html
Marcus> Regards
Marcus> -- Marcus
Marcus> _______________________________________________
Marcus> XEmacs-Beta mailing list
Marcus> XEmacs-Beta(a)xemacs.org
http> //calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
--
/ Turn the other cheek.
davep (|) -- Jesus Christ
/ Unless you're a NeoCon.
-- NT Signing statement by GWB
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:51 p.m.
David A. Panariti writes:
I'm not sure what you mean by "dragging," but it is
just one symbol in a
global table referencing a single copy of the variable.
I local variables actually have a higher cost associated with them due to the
extra meta-data. Also, you will get an extra copy in any buffer that does set
it (depending on how it is set.) In any I would imagine that there is at
least a symbol table's worth a meta-data used by the buffer-local code.
The problem is that with a global variable, I end up with lots of
cruft in c-e-r-a that I am not interested in for a given mode.
Let's assume I'd use a variety of languages at the same time. Because
of its global nature, c-e-r-s-l will have to contain entries for all
compilers. All this may end up in a larger number of error regexps
being applied than I need. Worse than the decrease in speed is the
fact that there is a potential that regexps earlier in c-e-r-a
(generated from c-e-r-s-l) would catch text in my output buffer
unintentionally, preventing the actual regexp from matching. The risk
of this happening is higher the more regexps there are, of course.
You can make the buffer-local survive `kill-all-local-variables'
by making it
permanent, thus:
(put 'compilation-error-regexp-systems-list 'permanent-local t)
I will try that as workaround, but don't regard that as a proper
solution to the problem. Next time things don't work for someone, we
will get a new flag `disable-permanent-local', followed by
`overwrite-disable-permanent-local',...
I am of course exaggerating but you get the idea.
Marcus> Unfortunately there are some loosely specified error
regexps
Marcus> that do a catch all, shadowing some of my own definitions.
I'd have to poke around in the code to see how the regexps are traversed.
Are you adding yours, w/append or cons? In either case, try the other.
They are traversed in order, so I could get away for now just putting
mine in front of something. But again, this is not a proper
solution. I'll now end up depending on the load order of libraries
adding their stuff.
Note that my request for a local variable is also not a perfect
solution, but by minimizing the list of active regexps it can help to
reduce the risk of regexp-shadowing.
Thanks for looking into this
-- Marcus
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:36 p.m.
Marcus Harnisch writes:
> You can make the buffer-local survive
`kill-all-local-variables'
> by making it permanent, thus:
> (put 'compilation-error-regexp-systems-list 'permanent-local t)
I will try that as workaround, but don't regard that as a proper
solution to the problem.
Well, if you don't consider that a proper solution, then there isn't
one at present. A "permanent-local" is intended be local to the
buffer. However, non-permanent locals are often used as an
approximation to "mode local" variables, and thus get killed by
`kill-all-local-variables' when modes are switched.
Note that my request for a local variable is also not a perfect
solution, but by minimizing the list of active regexps it can help to
reduce the risk of regexp-shadowing.
I've thought about adding a mode locale to the specifier
implementation. That might be the best way to handle this. I'm not
real happy with the idea of mode-local variables; GNU already has
frame-locals as well as buffer-locals, and this is altogether too
magic and uncontrollable for my taste. Specifiers are more explicitly
controllable.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:59 p.m.
Stephen J. Turnbull writes:
> > You can make the buffer-local survive
`kill-all-local-variables'
> > by making it permanent, thus:
> > (put 'compilation-error-regexp-systems-list 'permanent-local t)
>
> I will try that as workaround, but don't regard that as a proper
> solution to the problem.
Well, if you don't consider that a proper solution, then there isn't
one at present. A "permanent-local" is intended be local to the
buffer. However, non-permanent locals are often used as an
approximation to "mode local" variables, and thus get killed by
`kill-all-local-variables' when modes are switched.
I don't consider it a proper solution because it fixes the symptom,
not the cause. A different situation may require the buffer-local
variable to be killed when calling `kill-all-local-variables'. What
would you do to fix that?
I wonder if the call to `kill-all-local-variables' is a bit too
sledgehammerish and should be replaced by something less invasive.
Thanks
-- Marcus
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6115
days inactive
6119
days old
4 comments
3 participants
participants (3)
-
David A. Panariti -
Marcus Harnisch -
Stephen J. Turnbull