Re: mouse-drag-and-drop-region

[martin rudalics <rudalics@gmx.at>]

 > Thank you.  I think that by your revision, the problem was solved.  I
 > also revised code not to let user drop the text to minibuffer.

Thanks.  One issue I'm yet uncertain about: This part

               (if (and mouse-drag-and-drop-region-show-tooltip
                        (not drag-but-negligible)
                        (not point-to-paste-read-only)
                        cursor-in-text-area)
                   (tooltip-show text-tooltip)
                 (tooltip-hide))

means that the tooltip text does not appear as long as the mouse is
within the initial region (because there drag-but-negligible is non-nil,
I presume).  This comes somewhat unexpected - I'd expect the initial
feedback via a tooltip to appear right away as soon as I start dragging.

Personally, I'd even show the tooltip text when the mouse is temporarily
out of the frame and leave it to the cursor to indicate whether a drop
is possible at that position.  But this is a personal preference - I'll
check in whatever you prefer.

 > This
 > time, I attach a patch as a separated file.

Highly appreciated.  Applies without any problems now.

 >> Please consider also the following four bindings in `mouse-drag-track':
 >>
 >>           (echo-keystrokes 0)

I remember that occasionally during dragging some thing (I don't
remember whether it does happen with the region) I see in the echo area
text like down-mouse-1 or the like appear.  If you see that too, this
binding might be useful to suppress such feedback.

 >>
 >>           (make-cursor-line-fully-visible nil)
 >>
 >>           ;; Suppress automatic hscrolling, because that is a nuisance
 >>           ;; when setting point near the right fringe (but see below).
 >>           (auto-hscroll-mode-saved auto-hscroll-mode)

Both of theses might have impact when you move the cursor to a position
that is only partially visible at some border of the window.  You might
have to experiment, for example, by starting with a horizontally
scrolled window or a window with point near the bottom to see the
impact.

 >>           (old-track-mouse track-mouse)

This should handle the case where `mouse-drag-and-drop-region'
intercepts an already ongoing track operation.  I have no idea whether
such a thing can happen in practice.

 >> Maybe they are useful for you as well (a lot of experience went into the
 >> coding of that function).
 >
 > I wonder if this is beyond my skill.  Could you revise this part?

I indicated above whether and why these may be useful.  We probably
should just wait until real problems show up in this regard.

 > It is a good idea.  Now tooltip shows only substring.  I think
 > mouse-drag-and-drop-region-show-tooltip should be something like 256
 > by default.

OK.

 >> Finally, please think of how to embed your function into other packages:
 >> For example, how would a user drag file names from one dired buffer to
 >> another in order to copy or move the associated files from one directory
 >> to another?  Can we accomodate an exit function to do the pasting job?
 >
 > It is a good idea.  I suppose you mean dragging `file' when
 > event-start is with 'dired-filename.

Never using dired I have no idea.  But ISTR that most two-pane file
managers (aka Norton Commander clones) have some mouse support to do
that.  So it might be a good idea to think about how to incorporate such
support right now.

One issue with dired and customization buffers we probably have to
resolve is the following: When `inhibit-read-only' is non-nil, we should
allow cutting/pasting from/into read-only buffers or text.  I've never
looked into this matter.  Maybe you can find some code which does handle
that so we can steal it.

martin