emacs-devel
[Top][All Lists]
Advanced

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

RE: mouse.el patch to flash yank position and highlight line


From: Drew Adams
Subject: RE: mouse.el patch to flash yank position and highlight line
Date: Sat, 14 Jul 2007 12:30:11 -0700

>     * A fix to `mouse-yank-secondary', so you get a reasonable
>       error message if the secondary selection is not yet defined
>       (instead of "Wrong type argument: char-or-string-p, nil").
>
> That fix should be installed.  Could you please send a patch
> for just that fix?

-----8<----------------
*** mouse-CVS-2007-07-13.el     Fri Jul 13 14:49:54 2007
--- mouse-CVS-patched-2007-07-14a.el    Sat Jul 14 12:12:34 2007
***************
*** 1631,1637 ****
    ;; Give temporary modes such as isearch a chance to turn off.
    (run-hooks 'mouse-leave-buffer-hook)
    (or mouse-yank-at-point (mouse-set-point click))
!   (insert (x-get-selection 'SECONDARY)))

  (defun mouse-kill-secondary ()
    "Kill the text in the secondary selection.
--- 1631,1640 ----
    ;; Give temporary modes such as isearch a chance to turn off.
    (run-hooks 'mouse-leave-buffer-hook)
    (or mouse-yank-at-point (mouse-set-point click))
!   (let ((secondary (x-get-selection 'SECONDARY)))
!     (if secondary
!         (insert (x-get-selection 'SECONDARY))
!       (error "No secondary selection"))))

  (defun mouse-kill-secondary ()
    "Kill the text in the secondary selection.
-----8<----------------

>     * `mouse-tear-off-window' does not try to delete the window
>       if it is the only one in its frame. Instead, it clones the
>       frame and window. That is, it does a "tear-off" at the frame
>       level, instead of the window level.
>
> That seems like a good idea, but the implementation is wrong.  It
> should try to do delete-window, and if that fails, then clone the
> frame.

I don't see why. If `one-window-p' is true, why would you try to delete the
window? The deletion will never succeed, will it? What's the point? This is
the code:

(save-window-excursion (select-window window)
                       (unless (one-window-p) (delete-window window)))

This was the previous code: (delete-window window)

The new frame was already being created in the old code, in any case; I made
no change in that regard. No explicit frame cloning is done. The window
being deleted is in the old frame; it is deleted because the buffer is now
displayed in a new frame. If the original frame is `one-window-p', then
there is no need to delete the original window, and it is impossible to do
so, in any case.

Please elaborate, if you think I'm misunderstanding you.

> As for the bulk of the change, I just don't understand the point.

Please try again.

> Your message explains the details from the bottom up,

Not at all. At the very beginning I describe the new commands, which is all
there is. I propose that commands `mouse-flash-position-or-M-x' and
`mouse-scan-lines-or-M-:' be bound to `down-mouse-2' and `S-down-mouse-2',
respectively.

Do you not understand the descriptions of those commands? I will try to
explain better, if you let me know what part you don't understand.

Does the following information help?

- `mouse-flash-position-or-M-x' helps with the problem that some people
sometimes have of not being able to tell exactly where the mouse pointer is
pointing. They sometimes accidentally paste a character to the left or right
of what they intended. Some people reported on Emacs Wiki even setting
'mouse-yank-at-point' to 't' just because of this annoyance. With
`mouse-flash-position-or-M-x', you see the yank position highlighted while
the mouse button is depressed. This helps you guide your paste.

- `mouse-scan-lines-or-M-:' highlights the entire line under the pointer as
long as the mouse button is depressed. Use this for whatever you want. I use
it for reading and for visually aligning text that is in the same line.

Both of these track mouse movement. That is, the highlight follows the
pointer during a drag. This means, for example, that you can correct the
yank position before releasing the mouse button to yank. Or you can use
`C-g' before releasing the button, to cancel yanking altogether.

Each of these commands has an alternative functionality for use in the echo
area, where yanking is not possible and there is no need for line
highlighting. This functionality is totally unrelated to the highlighting
features, but I see no reason not to provide it. Just as `C-mouse-1' acts
differently whether you click the mode-line or within a buffer, so clicking
`mouse-2' can act differently whether you click in the echo area or not.

If the echo area were available as a pseudo key like the mode-line is, then
these unrelated features could be implemented by binding different commands,
one for use in the echo area, and one for use elsewhere. Instead, a single
command tests whether the click is in the echo area and acts appropriately.

> and these things sound like facilities for doing something else.  What is
the
> something else?

There is nothing else.







reply via email to

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