[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#4887: 23.1; list-load-path-shadows produces broken buffer
From: |
Mark Lillibridge |
Subject: |
bug#4887: 23.1; list-load-path-shadows produces broken buffer |
Date: |
Fri, 13 Nov 2009 13:57:10 -0800 |
> > Should linum use a different implementation method than
> > define-globalized-minor-mode? (does one exist?)
>
> You mean global-linum-mode? Yes, it could use a different method,
> e.g. setting global hooks instead, but that might prove tricky.
>
> > Should we instead fix define-globalized-minor-mode to work with all
> > buffers? Its documentation via ^h f claims it works in every buffer:
>
> That would be the best solution, yes.
I agree. Any fix that worked for global-linum-mode should
presumably be implemented as part of define-globalized-minor-mode so
that other global minor modes can benefit as well.
> Given the hooks we currently have, it's not very easy because buffers
> like *Shadows* get created without running any hook, so basically the
> first hook that would get triggered might be something like
> window-configuration-change-hook, but that hooks has no easy way to
> decide whether that buffer was just created recently or on the contrary
> has been around for a long while (in which case enabling linum-mode
> might be very wrong since the user may have turned it off there
> earlier).
I thought about using advice on get-buffer-create, but the manual
recommends creating a hook instead. Could we create a new-buffer hook?
That would certainly solve the problem and simplify
define-globalized-minor-mode. I wonder though, if this would call the
minor mode turn on function too early in some cases.
Alternatively, it doesn't look very hard to use
window-configuration-change-hook; we would have to add some storage to
remember which buffers we had already enabled any given minor mode in.
> An easier solution is to not change anything to
> define-globalized-minor-mode and to require Elisp code to explicitly set
> a major mode for any buffer that will be displayed. E.g. for *Shadows*
> the Elisp code should explicitly call fundamental-mode in it.
This would work as well; who makes the call on these sorts of things?
(This is a change of conventions more than a code patch.)
- Mark