Jun 28, 2022, 12:50 by larsi@gnus.org:

> 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.
>
You would know more about how best to approach this.  Perhaps some form
of completion could help.  Have you reflected on categorising the modes,
organised in ways that makes the process of going through them quicker?

>> 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
>