[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#15230: 24.3; Inconsistency in Tools menu,
Stefan Kangas <=