Re: Some developement questions

[hw]

Phil Sainty <address@hidden> writes:

> On 08/09/18 02:15, hw wrote:
>> Phil Sainty <address@hidden> writes:
>>> Whatever you feel you're gaining from hiding the menus surely
>>> can't be of greater benefit to you than all the knowledge and
>>> functionality that you're missing as a consequence?
>>
>> Well, I'm not missing anything.  What would I be searching for in
>> the menues, and why would I bother to look?
>
> In the snippets I quoted before, as well as in other earlier emails,
> you have explained how there are numerous Emacs features and modes
> that you don't really know how to use because you don't know what the
> key bindings are;

That must have been a misunderstanding.

Of course there are many features and key bindings I don't how to use or
I don't know about at all.  I will probably never know all there is to
know.

And that's fine because I do not need all the available features and key
bindings.  I only need to know those I use, and there is a difference
between things I use frequently and things I rarely use.  Info is one of
the things I rarely use.

The last time I used info was probably 4 or 5 years ago.  I simply
didn't need to use it in between because I was using Emacs just fine all
the time.

That is why I'm saying that it would be nice if the menu was
automatically enabled with modes I rarely use and disabled with those I
frequently use.  It might have occured to me to look into the menu to
find out how to go back if the menu had been enabled --- that the menu
would have enabled itself automatically for the info buffer would have
told me that I'll probably need it.

Is that so difficult to understand?

> and also that you have hidden the feature which would most trivially
> let you find out what they did and how to use them.  With the menus
> visible I am *imagining* that it would occur to you to look at them
> the next time you were wondering what sorts of commands a particular
> mode provided, and that in the process you may even discover some
> useful key bindings as well.

I would try to ignore it if it was permanently enabled.  It wastes
screen space, it is inefficient and I rather learn the key bindings than
having to use a menu.  I wouldn't use it *because* it's permanently
enabled and thus permanently annoys me.

>> Do you have an example?
>
> Sure.  You said just before:
>
>> Emacs can work with CVS systems like git.  I haven't found yet out
>> how to make use of this feature, yet I'm sure there are lots of key
>> bindings that make editing source code much more efficient when you
>> are using CVS systems.
>
> Sitting there waiting in the Tools -> Version Control menu we find
> all of the following:

I wouldn't enable the menu if I wanted to use this mode.  I would read
the documentation and learn how to use it.


> [...]
>
> I have to admit that I'm genuinely perplexed.  On the one hand you
> profess to having some difficulty finding out how to do things -- or
> even what things there might be available to do -- all of which sounds
> to me a lot like "I'm missing things"; and on the other hand you say
> "I'm not missing anything" and that you see no reasons to look in the
> menus, despite those menus existing for the purposes of showing people
> the things they can do, and making it easy to do them even when they
> don't know the key bindings.

I think that's probably because you misunderstood.

When I was stuck in the info help, I wanted to read documentation about
tramp, not about anything else.  I followed a reference and didn't know
how to get back, so I looked into the help.  Then I just wanted to get
out of the stupid help page because even that page didn't tell me how I
could get back.  Quitting the info buffer doesn't help for some reason
because when you call info again, you get to the same place where you
left --- that is a very annoying feature not only with info buffers.  So
finally I killed the buffer and started over.

It didn't occur to me to turn on the menu.  Why would it?  It had
nothing to do with I wanted.


So guess what keys especially a new user might try to go back.  Chances
are pretty good he would try Alt-left rather than an ideosyncratic key
only Emacs knows about.  But that doesn't work, and the user remains
stuck.  The user quits the info buffer and calls info again to start
over --- just to find out that he is still stuck at the same place.  The
new user may not be familiar with this weird behaviour and not know that
he needs to kill the buffer.

Seriously?  Do you call that good design?  Do you call that helpfull?

I'm merely saying this is something to improve upon.  You're pushing it
back by saying I should have the menu enabled.  The new user might still
have it enabled, but he might also have found out that it can be
disabled.  He might have disabled it because he wants to learn the key
bindings, and disabling the menu supports that because when something is
harder to look up, there is more incentive to remember it.  It might not
occur to him to enable it when he's stuck in the help of info, or
somewhere else, while trying to read documentation about something.

That someone has trouble finding out something can happen to everyone.
So why not make it easier for everyone?

> If the menus are not one of the *best* answers to your issue, then
> I've completely and utterly misunderstood.

Apparently it happens to me all the time that people don't understand
what I'm saying :/

I think I've found a better answer to the problem with the idea of the
menues enabling and disabling themselves automatically.  The answer to
that was that I can have that by using mode hooks.  That probably means
it will never be considered to perhaps become a default behaviour.

I think it would be an improvement, especially for new users who do not
know about mode hooks.  I don't know how to do it, either, but I'm sure
I can find out when I want to.