emacs-devel
[Top][All Lists]
Advanced

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

RE: New keybinding suggestion: C-x _ for `shrink-window'


From: Drew Adams
Subject: RE: New keybinding suggestion: C-x _ for `shrink-window'
Date: Sat, 17 Nov 2007 09:28:33 -0800

> > The highlighting of all mode lines doesn't change depending on
> > your input (aside from the highlighting of the selected
> > window's mode line). It is a constant, and just represents
> > noise - it doesn't indicate anything (except
> > that you are using `resize-windows').
>
> It indicates just that (that you are using `resize-windows' at the
> moment).

That's too heavy-handed a way to indicate that, IMO. Consider something
else - perhaps a mode-line indication. Users won't want to see neon mode
lines *everywhere*.

> You might for example leave the computer for a while and come
> back. Isn't it good then to know that you are using `resize-windows'?
> You may have forgotten, but Emacs knows - and behaves a bit
> differently ;-)

1. If the feedback is reasonable, then you will soon realize that you left
Emacs in such a "mode". Instead, this is like parking a meter-square PostIt
on your screen just to remind yourself.

2. And besides, you already have the selected window's changed background to
let you know. If that isn't enough, then highlighting all of the mode lines
won't help more. What would be next, play loud music? ;-)

> > Sorry, I don't understand, again. Changing the mode line of the selected
> > window is not needed to simply show that the window is selected - you
> > already change the window background to show that.
>
> Those two are alternatives that you can turn on/off with two defcustoms.

Oh, I see (I think). You are saying that the selected window can be
indicated by highlighting its mode line or highlightings its background or
both. Is that it? If so, then it would be clearer to combine that into a
single defcustom (`choice'). And the default behavior should *not* be to
highlight both. I have no problem with either alone, personally.

> > No, you said that you didn't know, and you thought that fringe was not
> > window-specific - but it is, AFAIK.
>
> You are right.
>
> > What is the impossibility you see?
>
> Changing the colors of one of the fringes in a window.

I don't see why that's impossible - just show only one of the fringes. You
don't necessarily need to change the color. You can use some mark in the
fringe if you can't change the color (but I think you can). Left and right
fringe are independent, AFAIK, and they can be almost anything, visually
(AFAIK). Again, I'm no expert on fringe (I turn it off, in fact), but I
think these things are possible.

And, again, any use of fringes for this should be temporary, for the
duration only. You should restore whatever fringe preference the user had
originally.

> >> You have more freedom with the mouse pointer.
> >
> > I don't know what freedom I have with it,
>
> You can position the mouse pointer wherever you want.

My impression is that you (Lennart) reposition it where you want; it doesn't
stay where I want (at the mouse position).

> > but the mouse pointer is a bad idea. It is either
> > unnoticeable (if you aren't currently using the mouse) or
> > it is plain wrong (if you are using the mouse).
>
> As I said in the portion you are replying to here I do not think that is
> wrong to use the mouse pointer to give feedback when you are working
> from the keyboard.

How do you know I am working from the keyboard? You might have an argument,
if you knew that I didn't care about the mouse pointer. Then, perhaps, you
could co-opt the pointer for another purpose. As it happens, I do care about
the pointer, and I do use the mouse - e.g. to select the window to operate
on. Touches pas a mon pointeur.

> That is the way the window manager in w32 sometimes
> does it. (It does exactly that when resizing a window from the keyboard.)

So what? Why is that relevant? And those "windows" are really frames anyway.
I don't see how this argues for taking over the mouse pointer here to
indicate the active border.

> Of course one can have different opinions wheter this is good or bad,
> but "plain wrong" is a bit to strong here in my taste.

It is plain wrong if you are using the mouse, because in that case you
depend on the pointer representing the mouse position. You yourself
introduced your defense of this by saying "when you are working from the
keyboard". It is unnoticeable if you are working from the keyboard (unless
you read the doc), and it is plain wrong if you are working with the mouse.
In the latter case, you expect the pointer to tell you where the mouse is.

> > Help in a separate frame does not tamper with the window layout.
>
> It is a good point and I have already said that if it is desireable I
> could add support for it. It is however not quite as simple as one might
> expect in this case.

(with-output-to-temp-buffer "*Help*"...) should take care of my objections.
Try it.

> >>> Please use (with-output-to-temp-buffer "*Help*"...) or
> >>> equivalent. It will solve the problem.
> >>
> >> You always do that with the normal help functions.
> >
> > I don't know what that means. The above problems (popup frame,
> > self-insert keys, `q' etc.) should be solved if you just use
> > that form. The *Help* buffer should then be in help-mode.
>
> I am afraid that you might be misunderstanding the problem here. What I
> have been trying to do is to temporary show the help and after this
> return to resizing for those people that do not normally use popup
> frames for help.

(with-output-to-temp-buffer "*Help*"...) should work regardless of the value
of pop-up-frames. If pop-up-frames is nil, then it uses a window, not the
whole frame, but if you want to use the whole frame in that case, then just
test pop-up-frames before doing what you do now, and, if non-nil, use
(with-output-to-temp-buffer "*Help*"...) instead.

> At the moment I have not taken care of popup help. I can do that if it
> is desireable, but it requires some careful thought about how to do it
> in this case. You are welcome with suggestions. (In fact I hoped that
> you would have some thoughts about this.) But please then try to answer
> the following questions:
>
> - When showing help in a popup frame the popup frame should of course
> not be in a resizing state. Should resizing be resumed when quitting help?

It doesn't matter to me. Resuming is no doubt doable, but why bother? Keep
it simple.

What is difficult for a user about issuing the command resize-windows again?
People won't be asking for help every four seconds. They won't mind hitting
the resize-windows key again after reading the help. And the benefit of
being able to see their window config while reading the help outweighs the
cost of needing to hit that key again.

> - If yes how should that be indicated to the user?
> - If no, when should resizing be resumed?

Save the configuration and exit. The user will hit the resize-windows key
again if s?he wants.

> >>    =   fit-window-to-buffer-works
> >>    -   shrink-window-if-larger-than-buffer
> >
> > I don't know. I'm unfamiliar with those commands. I only know that the
> > behavior I see doesn't correspond to anything I can make sense
> > of or find useful (in the cases I mentioned). If the functions
> > you use don't do what's right for this context, then you might
> > want to use something else.
>
> I decided to give the user the choice (= fit, - shrink).

Nothing wrong with choices. I described behavior that doesn't work (windows
disappearing unexpectedly), that's all.

> > emacs -Q
> > (setq pop-up-frames t)
> > M-x resize-windows
> > 3 2 3 2
> > C-g
> >
> > Bam!
> >
> > I used the last version you had posted before my reply: 0.94.
>
> Please try the latest version instead.

Where is it?

> > That responds to what you just wrote. Why not have a standard
> > way to exit and stick to it?
>
> No problem. I actually wanted some feedback on this. The current way try
> to mimick how isearch exits, but that might be a bad choice in this case.

I think it is. resize-windows is a mix of functionalities (split, resize,
etc.). Isearch is the wrong model here, IMO.

BTW, an argument could be made that Isearch too should be exited in a
uniform way (only a few keys, such as C-g and RET). But RMS, in particular,
wants control keys to do their thing immediately. This has come up nearly
every time someone wants to bind a control-key sequence in the isearch map.
Little by little, some control keys (e.g. C-y, C-w) have been added to the
map, but it's requires a "discussion" each time.

>From the user's point of view, the exiting rule is therefore complex. Here
is what the manual says:

 "<RET> is necessary only if the next command you want
  to type is a printing character, <DEL>, <RET>, or
  another character that is special within searches
  (`C-q', `C-w', `C-r', `C-s', `C-y', `M-y', `M-r',
  `M-c', `M-e', and some other meta-characters)."

IOW, you need to be aware of each key that is special within searches, in
order to know which keys (all the others) exit Isearch. Not friendly to
newbies, and, IMO, not all that useful to non-newbies. C'est la vie.

> > See Bastien's code. There is no mixing. There are two possible
> > modes. The default mode is border movement. The alternate mode
> > is window resizing. It should be the other way around: simple
> > as default, complex as alternate;
> > gross tuning as default, fine-tuning as alternate.
>
> Unfortunately I think it is (or rather was) utterly confusing for more
> complex window layouts even though the intention to simply was nice.
> (For simple layouts it was fine.)

Resizing is a simple operation. Most of the time, it suffices for what users
need, IMO. If they need more complex maneuvering, then they can have
recourse to the heavy lifting of border movement. You should not plunge them
immediately into something that is more complex and requires more thought.
If the aim is simply to increase or decrease a window's horizontal or
vertical dimension (which it is 80% of the time), then one shouldn't need to
think in terms of selecting a border to move and a direction to move it.

> > My main suggestions are (1) simplify the UI, and (2) find a good way to
> > indicate which border is active (for border movement).
>
> (1) can't be done without (2) here.

I don't understand that statement. I offered some suggestions for
simplification, from highlighting to help display to default behavior
(resize vs move border).

> The problem is really that it is
> hard to find a good way to do (2). That was what I tried to explain from
> the beginning. Coloring the relevant vertical border or fringe would IMO
> opinion be the best solution.

We agree on that last part. And highlight the mode line, for a horizontal
border (except top).

BTW, for a top window top border, you might temporarily add a header line as
the selected-border indicator.

> (An additional possibility is to change
> the mouse pointer shape, but that is a lot of work.)

My advice is to stay away from the mouse pointer for things that have
nothing to do with the mouse.

HTH.





reply via email to

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