Re: [External] : Re: Info-mode patch

[Arthur Miller <arthur.miller@live.com>]

Drew Adams <drew.adams@oracle.com> writes:

>> For me it is because I would prefer having less code if
>> I don't have to. I assumed you will do something like
>> that; and my personal opinion is that I would definitely
>> prefer not having foo, and foo-other-window, along with
>> foo-mode-map and foo-mode-other-window-map, because I
>> see it as a necessary duplication in an environment
>> already full with numerous commands and symbols.
>
> 1. Sincere apologies: I'm not following this thread.
> Just a comment on this bit I quoted out of context.
>
> 2. There are lots of "I" occurrences there.  That's
> fine, if the result is that something gets changed
> in Emacs only for some "I"s who might want to opt
> into that change.
>
> 3. There's an inherent trade-off in benefits, which
> means that different users and different code uses
> (libraries) can prefer different positions on the
> trade-off spectrum.
>
> I'm referring to this:
>
> If there is some semi-automatic way of predefining
> keys for other-window, other-frame, etc. behavior
> for "base" commands, then that might mean some
> simplification of some implementation code.  And it
> could perhaps result in fewer commands.
>
> But fewer commands and predefining some systematic
> scheme for key-binding the window/frame variants is
> also _constraining_.
>
> Users also need to be able to easily bind different
> individual commands to whatever keys they like, in
> whatever keymaps they like.
>
> And users can also prefer to have separate commands,
> discoverable by name matches etc.  I might want to
> find an `-other-window' or `-other-frame' version
> of a command - both to read its doc and to invoke
> it - specifically.	
>
> Tying things up in a tight knot might be useful for
> implementers or for some users.  But it could tie
> the hands of other users and implementers of other
> code.
>
> Having multiple `foo', `foo-other-window', and/or
> `foo-other-frame' really bothers some people.  Me,
> I prefer that - greatly.  I don't want to have to
> carve out some such behavior from an iron block,
> or, in effect, have to define my own variants.
> This applies to my use of commands interactively
> and in code.
>
> Again, I'm ignorant of what's being proposed.  So
> maybe this is just a knee-jerk, alarmist response.
> But if it rings a bell, then please make any such
> changes 100% optional for users - and opt-in, not
> opt-out.

I can just suggest you to try the patch. You should be able to use it as-is,
as you always did, at least it is my intention, otherwise it is a bug; even with
your multiple help buffers. 

But you can also bind all commands to any keymap you wish, and there is no need
to "-other-window" commands at all; with other words, you don't need to neither
discover nor search anything.

> Emacs is very different things for different users
> and use cases.  Sweeping changes can break things
> for others, without any bad intentions.

Of course Drew, we are all aware of the fact. I tried for that explicit reason
to be completely backwards compatible. If I have failed in some case, than it is
a bug.

I am al for automation myself, dispute is that I would pefer future commands
in Emacs to be written with some assumptions, so we don't need double set of
commands. For that I have already mentioned that we could automate that with
something like define-minor-mode, and I do have a small framework idea in mind,
but I haven't had time to code it yet.

Juris approach is good for the old code so it don't have to be reworked, and 
if you want some occasional function to run on other window. I think it would be
good to have it in Emacs as an option for people to use occaionally with older
code.

But I don't think it is very good as the only alternative, for all the
future use, because I am sure we can avoid the duplication of commands,
i.e. "-other-window" commands, and maps as the wrapper approach does. We only
need to take care how we write a command, and they would work from everywhere,
there is nothing to opt in/out. 

I have also suggested that we abstract boring details in some macro, something like
define-command, that take care of prompting user, choosing a window, dealing
with universal prefix etc. As Eli said, the point was to just make Info and help
mode commands callable from other widows, which this patch does, so I haven't
coded anything general, but I am quite confident it would be relatively simple to do.