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

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.

Except we have no way of identifying whether the left or right
modifier has been pressed.

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.

I have two reasons for avoiding this:

  1. They’re not always modifier presses. Applications set these flags
     themselves and it seems strange to me that it can look like a modifier
     has been pressed when the user has done no such thing.

  2. It’s so very easy to break the bindings by rebinding the
     modifiers, which is often recommended for people using non‐US
     keyboards.

ns-drag-n-drop is perfectly capable of determining what action to take
by examining what it’s been passed in the event. So I think that if we
receive, for example, a filename and only NSDragOperationLink is set
then we should mark the filename as a string and then send the event
to lisp where it is inserted as plain text. But if NSDragOperationCopy
or NSDragOperationGeneric is set we mark it as a file and lisp will
open the file.

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

If there’s a good use case for allowing these modifiers to leak
through then I suggest we make it customisable. That way new users
aren’t going to completely break drag‐n‐drop accidentally, and people
who know what they’re doing can break it as much as they want and live
with the consequences.

-- 
Alan Third





  reply	other threads:[~2018-04-07 15:01 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 [this message]
2018-04-09  1:51       ` Nick Helm
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=20180407150119.GA1190@breton.holly.idiocy.org \
    --to=alan@idiocy.org \
    --cc=30929@debbugs.gnu.org \
    --cc=nick@tenpoint.co.nz \
    /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.