bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15230: 24.3; Inconsistency in Tools menu


From: Stefan Kangas
Subject: bug#15230: 24.3; Inconsistency in Tools menu
Date: Thu, 23 Jan 2020 14:27:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> There is "Games" position in "Tools" menu.
>> I'm not sure if it should belong to this menu.
>
> I see your point, but I'm not sure where else to put it.
>
>> Another problem is that in "Tools" menu there are toggle type buttons
>> such as:
>
>> - Project Support (EDE)
>> - Source Code Parsers (Semantic)
>
>> These options are not "tools".  They do nothing functional.  They are
>> just turning some features on and off but have no immediate
>> functional meaning.
>
>> Another problem is that we have more similar options to add there and
>> this could turn into an extensible and almost unlimited list of
>> external features available to turn on and off.
>
> I guess we could move them to Options, but the toggles in Options tend
> to be of a different nature (basically UI preferences), whereas the EDE and
> Semantic are really toggles to turn on some tool, simply because those
> tools aren't quite tuned enough yet to always "just work", so turning
> them on unconditionally would lead to complaints.
>
>> We could add positions such as:
>> - Code Browser
>
> Not sure what package/function/feature that would refer to.
>
>> - Code Snippets
>
> These are usually enabled already.
>
>> - Syntax Checking
>
> You mean something like flymake?  This definitely falls in the same camp
> as EDE/Semantic, since it should also ideally be enabled by default, but
> there again, it's not polished/robust enough for that.
>
>> Then we will get a long and hard to navigate list of toggle buttons which
>> belong to "Options" menu rather than to "Tools".
>
> The Options menu is indeed problematic since Emacs has so many options:
> we can only keep in it a few options we consider to benefit from such
> a position (e.g. to make them easier to find for newcomers, or to make
> them easier to toggle at runtime).
>
>> Another solution is to move this list to submenu.
>> For example:
>> "Tools" -> "Features >> "
>
> That sounds like a good idea.  Tho it would have the downside that it
> would somewhat hide those features.

Having read the above 6 year old feature request, I don't see anything
actionable here.  Stefan M seems to have already answered all relevant
points, and there have been no further comments.

I'll give it a couple of weeks, so anyone interested will have a last
chance to chime in, and then I'm closing this bug.

Best regards,
Stefan Kangas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]