GNU bug report logs - #30929
26.0.91; [macOS] Text drag and drop does not work

Previous Next

Package: emacs;

Reported by: Nick Helm <nick <at> tenpoint.co.nz>

Date: Sat, 24 Mar 2018 20:00:02 UTC

Severity: normal

Found in version 26.0.91

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


Message #37 received at 30929 <at> debbugs.gnu.org (full text, mbox):

From: Nick Helm <nick <at> tenpoint.co.nz>
To: Alan Third <alan <at> idiocy.org>
Cc: 30929 <at> debbugs.gnu.org
Subject: Re: bug#30929: 26.0.91; Text drag and drop does not work
Date: Thu, 26 Apr 2018 11:16:32 +1200
On Wed, 25 Apr 2018 at 06:19:33 +1200, Alan Third wrote:

> What do you mean by too many permutations? Is it because of the number
> of NSDragOperation options?

No, the NSDragOperation and mask stuff is relatively straightforward,
although we have to work out which one to apply and a lot of that
depends on the context in Lisp.

My main problem is the bewildering number of different data types that
have be to handled, in particular casting every possibility from 
ObjC -> C -> Lisp and interpreting them at the end.

But there are other complications. When the source adds a dragging image
to the pasteboard, I thought it was a single type. It's not, each one
(NSStringPboardType, NSFilenamesPboardType, etc) is an array of
conforming types, and different sources can use different conforming
types to represent the same image. We have to work out which one to use.
This gets harder when we're dealing with more than one image on the
pasteboard, each with it's own types. Some sources also place the same
image on the pasteboard twice (or more) to represent it using different
types, so we need to know about those too.

Then there's backwards compatibility, as not all these things work the
same way on older versions of macOS. It all gets pretty convoluted. 

Other related stuff doesn't work the way I expect either. I'd planned to
highlight the target Emacs window with a border to give the user better
feedback about the drop location. That's a pretty basic thing to do. But
there's something odd about Emacs's NSView implementation, which means
any code using drawRect is either ignored or affects all the objects in
the view at once, as if everything is drawn onto one flat canvas.

I also wanted to use draggingUpdate to update point during the dragging
session, in order to give the user better control over the insertion
point. Again, pretty rudimentary stuff. But I'm embarrassed to admit, I
can't even work out how to move point from C, much less from ObjC, and
much much less make it follow the mouse mid-dragging session.

As far as I can tell, Emacs on free platforms doesn't support being the
dragging source (either to other apps or within Emacs itself), so
I didn't look at that option at all.









This bug report was last modified 6 years and 129 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.