Phil Sainty <psainty@orcon.net.nz> writes:
Major modes would need to be identifiable as such in order to
provide the menu you propose, and I don't believe there's a reliable
way to do that at present for all major modes.
We can identify major modes defined with `define-derived-mode'
however, as all such modes have a `derived-mode-parent' property;
and that does cover the majority.
Yes, it should be possible to provide a command to allow you to choose
between modes. But I think having something like that callable from the
mode line would be of limited value, but perhaps not? The reason is
that we just have So Many Modes -- over 500, at least, so discovering
modes via a menu would be cumbersome.
p.s. Tangentially, I think it would be good if all symbols for both
major and minor modes had (or rather, were expected to have) symbol
properties to explicitly identify which type of mode they are,
including differentiation between the various minor mode types
(buffer-local, global, and 'globalized' pairings), as I think there
would be other uses for being able to query the available modes.
Yes, that might be nice if you want to explore "what are the major
modes I can possibly use here?".
We almost kinda sorta have that. All minor modes should be defined via
define-minor-mode now, and that updates the global-minor-modes and
local-minor-mode variables. So all mode functions that aren't there are
major modes, so we could use heuristics to get us pretty far (along with
`derived-mode-parent').
However, we do have functions that end with -mode that aren't modes.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no