all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nick Helm <nick@tenpoint.co.nz>
To: Alan Third <alan@idiocy.org>
Cc: 30929@debbugs.gnu.org
Subject: bug#30929: 26.0.91; Text drag and drop does not work
Date: Mon, 09 Apr 2018 13:51:58 +1200	[thread overview]
Message-ID: <m2fu45jge9.fsf@tenpoint.co.nz> (raw)
In-Reply-To: <20180407150119.GA1190@breton.holly.idiocy.org> (Alan Third's message of "Sat, 7 Apr 2018 16:01:19 +0100")

On Sun, 08 Apr 2018 at 03:01:19 +1200, Alan Third wrote:

> On Wed, Mar 28, 2018 at 10:20:13PM +1300, Nick Helm wrote:
>> > It’s setting the actual modifier keys, so when a user changes those
>> > keys’ settings this breaks.
>> >
>> > You can also set these flags by using the actual modifier keys.
>> >
>> > This looks like it matches up with what Apple expect you to do, but it
>> > doesn’t seem to match up with Emacs’s event handling very well. 
>> 
>> That looks about right to me too, it least it matches the general
>> approach in the docs.
>> 
>> I had a go at mapping the hardware modifiers to Emacs events (and
>> existing bindings) for each drag type and DragOperation mask. Patch
>> attached. This doesn't support the ns-right-*-modifiers yet, but they
>> should be pretty easy to add if you want to go this way.

> 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.

> 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?

> This does mean that the modifier presses aren’t customisable, but they
> will always match the OS default at least.

Isn't that a good thing in this case? If dnd is considered an OS-level
event, then adding customisable modifier bindings was actually the wrong
thing to do.

> 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).


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 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?





  reply	other threads:[~2018-04-09  1:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-24 12:28 bug#30929: 26.0.91; Text drag and drop does not work Nick Helm
2018-03-25 11:57 ` Alan Third
2018-03-28  9:20   ` Nick Helm
2018-04-07 15:01     ` Alan Third
2018-04-09  1:51       ` Nick Helm [this message]
2018-04-10 19:38         ` Alan Third
2018-04-12  5:34           ` Nick Helm
2018-04-13 18:33             ` Alan Third
2018-04-24 12:42               ` Nick Helm
2018-04-24 18:19                 ` Alan Third
2018-04-25 23:16                   ` Nick Helm
2018-04-26 20:44                     ` Alan Third
2018-04-28  9:57                       ` Nick Helm
2019-01-05 10:27                         ` Alan Third
2019-01-05 13:05                           ` Nick Helm
2019-01-05 16:20                             ` Alan Third
2019-01-07 10:38                               ` Nick Helm
2019-01-10 19:23                                 ` Alan Third

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2fu45jge9.fsf@tenpoint.co.nz \
    --to=nick@tenpoint.co.nz \
    --cc=30929@debbugs.gnu.org \
    --cc=alan@idiocy.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.