bug#30929: 26.0.91; Text drag and drop does not work

[Alan Third]

On Mon, Apr 09, 2018 at 01:51:58PM +1200, Nick Helm wrote:
> On Sun, 08 Apr 2018 at 03:01:19 +1200, Alan Third wrote:
> 
> > I’ve been thinking about this and I’m not entirely sure it’s a good
> > idea to expose these modifier presses to Emacs. At least not by
> > default.
> 
> For what it's worth, I think this is a much better idea. It's a
> significant change from what we have now though.

Indeed. But given it doesn’t work without a reasonable amount of work
just now, I suspect it’s not going to affect too many people.

> > ns-drag-n-drop is perfectly capable of determining what action to take
> > by examining what it’s been passed in the event. 
> 
> Based solely on the received operation mask (which may include the
> user's OS-level modifers) and the data type sitting on the pb, right?

Well, that’s not quite what I was thinking of. At the moment, in C, we
build a list like:

    '(file "filename")
    '(url "http://url";)
    '(nil "plain text")

So I was thinking that using the operation mask and PB type we can
choose the correct type of list (like, it’s a file, but we only have
the link mask, so use the nil list). Then ns-drag-n-drop just looks at
that list and handles it.

But...

> > If there’s a good use case for allowing these modifiers to leak
> > through then I suggest we make it customisable. 
> 
> Personally, I don't see a need. I think it's better to just do what the
> user expects, which is what I think you're proposing. Experts can still
> intercept the event in Lisp (BTW, it's interesting to note that the
> mac-port doesn't expose incoming dnd events to Lisp at all and silently
> ignores all the modifiers).

This is probably a better idea, we pass the string, the type (from the
PB) and the mask to lisp, and then let ns-drag-n-drop sort it out.
Like you say, if an expert wants to do something different they can
then write their own function.

So in C we just construct something like:

    '(file
      (ns-drag-operation-copy
       ns-drag-operation-link)
      "filename")

Are you wanting to give this a go? I’m happy to work on it if not.

> If the dnd code gets a rewrite, it would be nice to add support for
> Emacs as the dragging source as well as a few nicities like mouse
> pointer overlays on copy operations etc.

I’m not sure what the deal is with drag‐n‐drop from Emacs on
GNU/Linux, but assuming it works under GNUstep as well as Cocoa we
could add Emacs as a drag source.

> I'm guessing the boat has well and truly sailed for such major tweaks in
> Emacs 26 though. Instead, would it make sense to change the default
> binding on macOS so at least basic (unmodified) text dnd works out of
> the box for the upcoming release?

That’s up to Eli. What would we have to do, just change the default
bindings in ns-win.el?

(global-set-key [drag-n-drop] 'ns-drag-n-drop)
(global-set-key [C-drag-n-drop] 'ns-drag-n-drop-other-frame)
(global-set-key [M-s-drag-n-drop] 'ns-drag-n-drop-as-text)
(global-set-key [C-M-s-drag-n-drop] 'ns-drag-n-drop-as-text-other-frame)

BTW, is it just me or does ‘ns-drag-n-drop-as-text-other-frame’ not
actually do anything different from ‘ns-drag-n-drop-as-text’?

...

OK. This is a disaster area. The current binding works if I drag and
drop text from iterm2, but fails if I drag from textedit. So I think
we need to bind every combination that includes meta to text dragging:

(global-set-key [M-drag-n-drop] 'ns-drag-n-drop-as-text)
(global-set-key [M-s-drag-n-drop] 'ns-drag-n-drop-as-text)
(global-set-key [C-M-s-drag-n-drop] 'ns-drag-n-drop-as-text)

And probably drop ns-drag-n-drop-as-text-other-frame, unless someone
can show that it does actually do what it’s supposed to.
-- 
Alan Third