frame-resizing handles are no good (on Windows, at least)

frame-resizing handles are no good (on Windows, at least)

[Drew Adams]

On Windows, I find that the frame resizing handles are far too small. When I
try to grab a frame border, the double-headed arrow appears only when the
mouse pointer is very precisely on the border line - so precisely that the
double-headed pointer flickers on and off, without my even (seemingly)
moving the mouse at all. That is, it changes back to the normal, single
arrow of a standard buffer, which you see when the pointer is not over text.
The tolerance isn't large enough, I suppose.

And if I move the mouse to a border position where the double arrow appears,
and leave it at that position, the double arrow reverts to the standard
single arrow. IOW, the double arrow seems to be shown only when the mouse
(pointer) is moving. Sometimes you can thus actually grab the border even
though the double arrow is not showing at that position. This of course
makes it difficult to use, because you cannot tell when you are on a
sensitive spot. Frankly, trying to grab an Emacs 22 frame border reminds me
of those hoax dialog boxes where you cannot click the button because it
keeps moving out of the way - nice joke, but it gets old quickly.

By contrast, when I run Emacs 20 on the same platform I have absolutely no
such problem. I also have no such problem with other Windows applications
(e.g. the Outlook mail frame in which I am typing this).

Do others also experience this annoyance? If so, let's please fix it.
Wrestling with this is a waste of time, besides being very annoying. I'd be
surprised if this has not been reported before, if others see it too. I've
never gotten around to reporting it myself, because I've assumed that it was
a known problem that would be fixed in time - but now that the release is
nearly baked that assumption appears faulty.

Also, I don't think it's normal that as soon as you have actually grabbed
the border successfully the pointer changes back to the normal, single
arrow. It should stay as the double-headed arrow until you release the mouse
button.

I admit that I notice these problems more in my own setup, which uses
multiple frames, than I do with just emacs -q and a frame or two (I don't
notice the last problem mentioned with emacs -q, for instance). I doubt that
my setup is doing something special that causes these problems, however - my
code does nothing with the mouse pointer or the frame border. The same code
also does not show these problems with Emacs 20.

If no one else sees these problems, then I'll live with it, assuming that
something in my setup is responsible. I don't have the time to try to track
down the cause. If others see the same problems, then let's please fix them.
Thx.

Re: frame-resizing handles are no good (on Windows, at least)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 28 May 2006 19:36:03 -0700
> 
> On Windows, I find that the frame resizing handles are far too small. When I
> try to grab a frame border, the double-headed arrow appears only when the
> mouse pointer is very precisely on the border line - so precisely that the
> double-headed pointer flickers on and off, without my even (seemingly)
> moving the mouse at all. That is, it changes back to the normal, single
> arrow of a standard buffer, which you see when the pointer is not over text.
> The tolerance isn't large enough, I suppose.

I don't see this on my systems.  The resize arrow behaves exactly like
in other GUI applications, as far as the size of the region where it
appears is concerned, and it doesn't disappear, no matter how long I
leave it there, nor flickers while in that area.

> Also, I don't think it's normal that as soon as you have actually grabbed
> the border successfully the pointer changes back to the normal, single
> arrow. It should stay as the double-headed arrow until you release the mouse
> button.

It does for me.

> I admit that I notice these problems more in my own setup, which uses
> multiple frames, than I do with just emacs -q and a frame or two (I don't
> notice the last problem mentioned with emacs -q, for instance).

Well, in that case, please provide a minimal setup to reproduce the
problem.  My crystal ball is obviously not powerful enough to guess.

RE: frame-resizing handles are no good (on Windows, at least)

[Drew Adams]

    I don't see this on my systems.
    
    > I admit that I notice these problems more in my own setup, which uses
    > multiple frames, than I do with just emacs -q and a frame or 
    > two (I don't notice the last problem mentioned with emacs -q,
    > for instance).
    
    Well, in that case, please provide a minimal setup to reproduce the
    problem.  My crystal ball is obviously not powerful enough to guess.
    
I repeat:

  If no one else sees these problems, then I'll live with it, 
  assuming that something in my setup is responsible. I don't have
  the time to try to track down the cause. If others see the same
  problems, then let's please fix them. Thx.

Re: frame-resizing handles are no good (on Windows, at least)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 29 May 2006 06:11:14 -0700
> 
>     Well, in that case, please provide a minimal setup to reproduce the
>     problem.  My crystal ball is obviously not powerful enough to guess.
>     
> I repeat:

You don't need to repeat, I understood the first time.

>   If no one else sees these problems, then I'll live with it, 
>   assuming that something in my setup is responsible.

It's possible that I'll see it if I do something I don't normally do.

Re: frame-resizing handles are no good (on Windows, at least)

[Jason Rumney]

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

>   If no one else sees these problems, then I'll live with it, 
>   assuming that something in my setup is responsible. I don't have
>   the time to try to track down the cause.

A binary search of your config files doesn't take that long.

First step "emacs -Q", load all your config files (site-start.el,
.emacs, default.el) with load-file and confirm that you can reproduce
the bug - if so, then you can repeat the process, checking behaviour
after each load-library to find which file causes the problem, then
repeat the process as many times as necessary using eval-region to
narrow down where in the file the bug is triggered.