[patch] enhanced mac drag-n-drop

[patch] enhanced mac drag-n-drop

[Sean O'Rourke]

[-- Attachment #1: Type: text/plain, Size: 2837 bytes --]

The included patch to src/macterm.c extends Carbon Emacs' drag-n-drop
to handle directories, URLs, and text.  To use it, the included Lisp
code also needs to be added to the appropriate Lisp file, probably
lisp/term/mac-win.el.  This is my first foray into Emacs C-hackery, so
although it's been working for me for the last few days, I would
appreciate some Mac users' trying it out.

Thanks for your time,
/s

ps -- please Cc me on replies, as I'm not subscribed to emacs-devel.

(defun mac-primary-dnd-function (event)
  "Perform the most common action for each type of item dropped
onto Emacs on Mac OS X.  Currently, this means:
    * File or directory -- call `find-file'.
    * URL -- call `browse-url-browser-function'.
    * Text -- insert text at point."
  (interactive "e")
  ;; Make sure the drop target has positive co-ords before setting the
  ;; selected frame - otherwise it won't work.  <skx@tardis.ed.ac.uk>
  (let* ((window (posn-window (event-start event)))
         (coords (posn-x-y (event-start event)))
         (x (car coords))
         (y (cdr coords)))
    (if (and (> x 0) (> y 0))
        (set-frame-selected-window nil window))
    (mapcar
     (lambda (name)
       (case (car name)
         (text (insert (cdr name)))
         (url (funcall browse-url-browser-function (cdr name)))
         (file
          (setq name (cdr name))
          (if (and (file-exists-p name)
                   (not (string-match (image-file-name-regexp) name)))
              (find-file name)
              (insert name)))))
     (cadd event)))
  (raise-frame)
  (recenter))

(defun mac-secondary-dnd-function (event)
  "Perform a less common action for each type of item dropped
onto Emacs on Mac OS X.  Currently, this means:
    * File or directory -- insert pathname at point.
    * URL -- insert URL text at point.
    * Text -- if it is a file or directory name, edit that file;
      otherwise, insert text at point."
  (interactive "e")
  ;; Make sure the drop target has positive co-ords before setting the
  ;; selected frame - otherwise it won't work.  <skx@tardis.ed.ac.uk>
  (let* ((window (posn-window (event-start event)))
         (coords (posn-x-y (event-start event)))
         (x (car coords))
         (y (cdr coords)))
    (if (and (> x 0) (> y 0))
        (set-frame-selected-window nil window))
    (mapcar
     (lambda (name)
       (case (car name)
         (text (setq name (cdr name))
               (if (and (file-exists-p name)
                        (not (string-match (image-file-name-regexp) name)))
                   (find-file name)
                   (insert name)))
         ((url file) (insert (cdr name)))))
     (caddr event)))
    (raise-frame)
    (recenter))

(global-set-key [drag-n-drop] 'mac-primary-dnd-function)
(global-set-key [shift drag-n-drop] 'mac-secondary-dnd-function)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 8138 bytes --]

Index: macterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.106
diff -p -u -w -u -r1.106 macterm.c
--- macterm.c	16 Mar 2005 08:08:06 -0000	1.106
+++ macterm.c	5 Apr 2005 20:23:29 -0000
@@ -7155,7 +7159,8 @@ int current_mac_keyboard_text_encoding =
    drag and drop events.  */
 Lisp_Object Qmac_ready_for_drag_n_drop;
 
-Lisp_Object drag_and_drop_file_list;
+/* List of objects for a pending drag-n-drop event. */
+Lisp_Object drag_and_drop_list;
 
 Point saved_menu_event_location;
 
@@ -8078,10 +8083,10 @@ do_ae_open_documents(AppleEvent *message
 
   err = AEGetParamPtr (message, keyAEPosition, typeChar, &actual_type, &position, sizeof(SelectionRange), &actual_size);
   if (err == noErr)
-    drag_and_drop_file_list = Fcons (list3 (make_number (position.lineNum + 1),
+    drag_and_drop_list = Fcons (list3 (make_number (position.lineNum + 1),
 					    make_number (position.startRange + 1),
 					    make_number (position.endRange + 1)),
-				     drag_and_drop_file_list);
+                                drag_and_drop_list);
 
   /* Check to see that we got all of the required parameters from the
      event descriptor.  For an 'odoc' event this should just be the
@@ -8135,10 +8140,11 @@ do_ae_open_documents(AppleEvent *message
 					  sizeof (unix_path_name) - 1) == noErr)
 #endif
 	      /* x-dnd functions expect undecoded filenames.  */
-	      drag_and_drop_file_list =
-		Fcons (make_unibyte_string (unix_path_name,
-					    strlen (unix_path_name)),
-		       drag_and_drop_file_list);
+	      drag_and_drop_list =
+		Fcons (Fcons (intern("file"),
+                              make_unibyte_string (unix_path_name,
+                                                   strlen (unix_path_name))),
+                       drag_and_drop_list);
 	  }
       }
   }
@@ -8152,8 +8158,27 @@ descriptor_error_exit:
   return err;
 }
 
-
 #if TARGET_API_MAC_CARBON
+
+static FlavorType
+mac_favorite_flavor (DragReference theDrag, ItemReference theItem,
+                     FlavorFlags* theFlags)
+{
+    const FlavorType accepted_flavors[] = {
+        flavorTypeHFS,
+        flavorTypeDirectory,
+        'url ',
+        'utxt',
+        0
+    };
+    int j;
+    for (j = 0; accepted_flavors[j]; j++)
+        if (GetFlavorFlags (theDrag, theItem, accepted_flavors[j], &theFlags)
+            == noErr)
+            return accepted_flavors[j];
+    return 0;
+}
+
 static pascal OSErr
 mac_do_track_drag (DragTrackingMessage message, WindowPtr window,
 		   void *handlerRefCon, DragReference theDrag)
@@ -8176,8 +8201,7 @@ mac_do_track_drag (DragTrackingMessage m
       for (index = 1; index <= items; index++)
 	{
 	  GetDragItemReferenceNumber (theDrag, index, &theItem);
-	  result = GetFlavorFlags (theDrag, theItem, flavorTypeHFS, &theFlags);
-	  if (result == noErr)
+          if (mac_favorite_flavor (theDrag, theItem, &theFlags) != 0)
 	    {
 	      can_accept = 1;
 	      break;
@@ -8231,28 +8255,33 @@ mac_do_receive_drag (WindowPtr window, v
   Point mouse;
   OSErr result;
   ItemReference theItem;
-  HFSFlavor data;
-  Size size = sizeof (HFSFlavor);
 
   if (GetFrontWindowOfClass (kMovableModalWindowClass, false))
     return dragNotAcceptedErr;
 
-  drag_and_drop_file_list = Qnil;
+  drag_and_drop_list = Qnil;
   GetDragMouse (theDrag, &mouse, 0L);
   CountDragItems (theDrag, &items);
   for (index = 1; index <= items; index++)
     {
-      /* Only handle file references.  */
+      FlavorType flavor;
+
       GetDragItemReferenceNumber (theDrag, index, &theItem);
-      result = GetFlavorFlags (theDrag, theItem, flavorTypeHFS, &theFlags);
-      if (result == noErr)
+      flavor = mac_favorite_flavor (theDrag, theItem, &theFlags);
+      switch (flavor)
+        {
+        case flavorTypeHFS:
+        case flavorTypeDirectory:
+          /* Handle file/directory references.  */
 	{
+            HFSFlavor data;
+            Size size = sizeof (HFSFlavor);
 #ifdef MAC_OSX
 	  FSRef fref;
 #endif
 	  char unix_path_name[MAXPATHLEN];
 
-	  GetFlavorData (theDrag, theItem, flavorTypeHFS, &data, &size, 0L);
+            GetFlavorData (theDrag, theItem, flavor, &data, &size, 0L);
 #ifdef MAC_OSX
 	  /* Use Carbon routines, otherwise it converts the file name
 	     to /Macintosh HD/..., which is not correct. */
@@ -8262,16 +8291,52 @@ mac_do_receive_drag (WindowPtr window, v
 	  if (fsspec_to_posix_pathname (&data.fileSpec, unix_path_name,
 					sizeof (unix_path_name) - 1) == noErr)
 #endif
-	    /* x-dnd functions expect undecoded filenames.  */
-            drag_and_drop_file_list =
-	      Fcons (make_unibyte_string (unix_path_name,
+              /* x-dnd functions expect undecoded filenames, but we
+                 don't have to follow that. */
+              drag_and_drop_list =
+                Fcons (Fcons
+                       (intern ("file"),
+                        Fdecode_coding_string
+                        (make_unibyte_string (unix_path_name,
 					  strlen (unix_path_name)),
-		     drag_and_drop_file_list);
+                         NILP (Vfile_name_coding_system)
+                         ? Vdefault_file_name_coding_system
+                         : Vfile_name_coding_system,
+                         Qnil)),
+                       drag_and_drop_list);
+          }
+          break;
+
+        case 'url ':
+        case 'utxt':
+          {
+            Size size;
+            char * data;
+            if (GetFlavorDataSize (theDrag, theItem, flavor, &size) != noErr)
+              break;
+            data = xmalloc (size + 1);
+            GetFlavorData (theDrag, theItem, flavor, data, &size, 0L);
+            if (flavor == 'url ')
+                drag_and_drop_list =
+                    Fcons (Fcons (intern ("url"),
+                                  make_unibyte_string (data, size)),
+                           drag_and_drop_list);
+            else
+                drag_and_drop_list =
+                    Fcons (Fcons (intern ("text"),
+                                  Fdecode_coding_string
+                                  (make_unibyte_string (data, size),
+                                   intern ("utf-16"),
+                                   Qnil)),
+                           drag_and_drop_list);
+            free (data);
 	}
+          break;
+        };
     }
   /* If there are items in the list, construct an event and post it to
      the queue like an interrupt using kbd_buffer_store_event.  */
-  if (!NILP (drag_and_drop_file_list))
+  if (!NILP (drag_and_drop_list))
     {
       struct input_event event;
       Lisp_Object frame;
@@ -8288,7 +8353,7 @@ mac_do_receive_drag (WindowPtr window, v
       XSETINT (event.x, mouse.h);
       XSETINT (event.y, mouse.v);
       XSETFRAME (frame, f);
-      event.frame_or_window = Fcons (frame, drag_and_drop_file_list);
+      event.frame_or_window = Fcons (frame, drag_and_drop_list);
       event.arg = Qnil;
       /* Post to the interrupt queue */
       kbd_buffer_store_event (&event);
@@ -8298,12 +8363,13 @@ mac_do_receive_drag (WindowPtr window, v
 	GetCurrentProcess (&psn);
 	SetFrontProcess (&psn);
       }
-
       return noErr;
     }
   else
+    {
     return dragNotAcceptedErr;
 }
+}
 #endif
 
 
@@ -9091,13 +9157,13 @@ XTread_socket (sd, expected, hold_quit)
 	  break;
 
 	case kHighLevelEvent:
-	  drag_and_drop_file_list = Qnil;
+	  drag_and_drop_list = Qnil;
 
 	  AEProcessAppleEvent(&er);
 
 	  /* Build a DRAG_N_DROP_EVENT type event as is done in
 	     constuct_drag_n_drop in w32term.c.  */
-	  if (!NILP (drag_and_drop_file_list))
+	  if (!NILP (drag_and_drop_list))
 	    {
 	      struct frame *f = NULL;
 	      WindowPtr wp;
@@ -9129,7 +9195,7 @@ XTread_socket (sd, expected, hold_quit)
 	      XSETINT (inev.y, 0);
 
 	      XSETFRAME (frame, f);
-	      inev.frame_or_window = Fcons (frame, drag_and_drop_file_list);
+	      inev.frame_or_window = Fcons (frame, drag_and_drop_list);
 
 	      /* Regardless of whether Emacs was suspended or in the
 		 foreground, ask it to redraw its entire screen.

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [patch] enhanced mac drag-n-drop

[Stefan Monnier]

>   "Perform the most common action for each type of item dropped
> onto Emacs on Mac OS X.  Currently, this means:
>     * File or directory -- call `find-file'.
>     * URL -- call `browse-url-browser-function'.
>     * Text -- insert text at point."

I use my MacOSX system pretty much exclusively as an X11 server, so maybe
I don't understand enough of Mac OS X's GUI philosophy, but I believe that
the behavior by default for URL should be the same as for Text, except maybe
when the browse-url function is configured to use one of the Emacs based
webbrowsers (like W3, or emacs-w3m).
The idea is that if I want to open a URL in Safari or Firefox, I'll
drag&drop it there, whereas if I drop it onto Emacs I most likely *don't*
intend it to go to my external browser.
Of course, if I have url-handlers-mode enabled, maybe I intend URL-drops to
call find-file as well ;-)

>   (interactive "e")
>   ;; Make sure the drop target has positive co-ords before setting the
>   ;; selected frame - otherwise it won't work.  <skx@tardis.ed.ac.uk>
>   (let* ((window (posn-window (event-start event)))
>          (coords (posn-x-y (event-start event)))
>          (x (car coords))
>          (y (cdr coords)))
>     (if (and (> x 0) (> y 0))
>         (set-frame-selected-window nil window))

Under which circumstances can X and/or Y be negative?

>     (mapcar
>      (lambda (name)
>        (case (car name)

Please use dolist instead of mapcar here.

>          (text (insert (cdr name)))
>          (url (funcall browse-url-browser-function (cdr name)))

Why not (browse-url (cdr name)) ?

>          (file
>           (setq name (cdr name))
>           (if (and (file-exists-p name)
>                    (not (string-match (image-file-name-regexp) name)))
>               (find-file name)
>               (insert name)))))

What is the rationale for the (image-file-name-regexp) exception?

>      (cadd event)))
>   (raise-frame)
>   (recenter))

Why are raise-frame and recenter necessary?

> (defun mac-secondary-dnd-function (event)

Please factor out the commonality between the two functions into an
auxiliary function.

> (global-set-key [shift drag-n-drop] 'mac-secondary-dnd-function)

Does this work?  Shouldn't it be [(shift drag-n-drop)]?


        Stefan


PS: When I ask a question about a piece of code, the answer should typically
    be either to change the code, or to add a comment answering
    the question.

Re: [patch] enhanced mac drag-n-drop

[Jan D.]

> The included patch to src/macterm.c extends Carbon Emacs' drag-n-drop
> to handle directories, URLs, and text.  To use it, the included Lisp
> code also needs to be added to the appropriate Lisp file, probably
> lisp/term/mac-win.el.  This is my first foray into Emacs C-hackery, so
> although it's been working for me for the last few days, I would
> appreciate some Mac users' trying it out.
>


To make this more general, I think you should use or generalize the 
defcustom variables in x-dnd.el so that Emacs customizations in this 
area becomes available on several platforms.

	Jan D.

Re: [patch] enhanced mac drag-n-drop

[Sean O'Rourke]

"Jan D." <jan.h.d@swipnet.se> writes:
> To make this more general, I think you should use or generalize the
> defcustom variables in x-dnd.el so that Emacs customizations in this
> area becomes available on several platforms.

x-dnd-known-types, x-dnd-types-alist, and x-dnd-default-test-function
are useless, since they deal with xdnd protocol specifics, and I
handle character encodings at the C level.  But the rest of the file
looks like quite an improvement over my simple handler, so I'll look
at creating a mac analog to the x-specific parts.

/s

Re: [patch] enhanced mac drag-n-drop

[Jan D.]

> "Jan D." <jan.h.d@swipnet.se> writes:
>> To make this more general, I think you should use or generalize the
>> defcustom variables in x-dnd.el so that Emacs customizations in this
>> area becomes available on several platforms.
>
> x-dnd-known-types, x-dnd-types-alist, and x-dnd-default-test-function
> are useless, since they deal with xdnd protocol specifics, and I
> handle character encodings at the C level.  But the rest of the file
> looks like quite an improvement over my simple handler, so I'll look
> at creating a mac analog to the x-specific parts.


Not really xdnd protocol specifics, rather X11 DND specifics.  
x-dnd-types-alist is the only place a user can configure what to do 
with URL:s.  Some want to open them in a browser, some want to insert 
the URL text. I think it would be much more flexible if the mac C code 
generated x-dnd.el compatible events.  That must be easy.

And please don't do (raise-frame) (recenter).  I really dislike 
applications that raises windows and scrolls without being told to do 
so.  At least make it an option, default off.

	Jan D.

Re: [patch] enhanced mac drag-n-drop

[Jan D.]

> "Sean O'Rourke" <sorourke@cs.ucsd.edu> writes:
>
>> "Jan D." <jan.h.d@swipnet.se> writes:
>>> To make this more general, I think you should use or generalize the
>>> defcustom variables in x-dnd.el so that Emacs customizations in this
>>> area becomes available on several platforms.
>>
>> x-dnd-known-types, x-dnd-types-alist, and x-dnd-default-test-function
>> are useless, since they deal with xdnd protocol specifics, and I
>> handle character encodings at the C level.  But the rest of the file
>> looks like quite an improvement over my simple handler, so I'll look
>> at creating a mac analog to the x-specific parts.
>
> It might be useful to look at what the w32 code does. I recall finding
> it difficult to use much of x-dnd.el when I rewrote DND support on
> w32, but I did manage to use enough of it to give a reasonably
> consistent interface between w32 and X I think.

We should break out what you can use in a general dnd.el file.  The 
x-dnd.el currently contains both general DND handling and protocol 
specifics. I'll look at what the w32 code uses and try to generalize it 
more.

	Jan D.

Re: [patch] enhanced mac drag-n-drop

[Jason Rumney]

"Jan D." <jan.h.d@swipnet.se> writes:

> We should break out what you can use in a general dnd.el file.  The
> x-dnd.el currently contains both general DND handling and protocol
> specifics. I'll look at what the w32 code uses and try to generalize
> it more.

The code is in term/w32-win.el. I only used one function from
x-dnd.el, but I think I basically rewrote another function with minor
changes, so it may be possible to generalize that. Also a full dnd
implementation on w32 could probably use more from x-dnd.el if someone
were to contribute the necessary COM code to generate the more complex
events, so generalizing as much as you can would help in the long term.

Re: [patch] enhanced mac drag-n-drop

[Sean O'Rourke]

Jason Rumney <jasonr@gnu.org> writes:
>> We should break out what you can use in a general dnd.el file.

First, the XDND part (there are two other dnd protocols in there, but
I didn't look at them much) seems to contain code for enter, tracking,
leave, and drop handlers, which should probably be made into separate
hooks.  Carbon generates events for all of these, but currently we
only pass the drop up to the Lisp level, while the X version passes
all such events.  If this were cleaned up, it shouldn't be too hard to
extend the Mac version to pass the other events.

Second, the XDND version has message decoding mixed throughout the
Lisp code.  This is implementation-dependent, so IMHO it should be
done before Lisp gets ahold of the data, or at least before the
platform-independent part.  Examples include splitting URL-list
strings into separate URLs and matching on the XDND command names.

Third, there are the drop types, which have both different encodings
(platform-dependent) and different default actions (platform-
independent).  For the latter, it would be nice to agree on a set of
names (e.g. text, URL, file).

Finally, the "suggested action" in XDND will be very useful on Mac, so
I hope it stays around.

/s

Re: [patch] enhanced mac drag-n-drop

[Jan D.]

> Jason Rumney <jasonr@gnu.org> writes:
>>> We should break out what you can use in a general dnd.el file.
>
> Second, the XDND version has message decoding mixed throughout the
> Lisp code.  This is implementation-dependent, so IMHO it should be
> done before Lisp gets ahold of the data, or at least before the
> platform-independent part.  Examples include splitting URL-list
> strings into separate URLs and matching on the XDND command names.

This is one thing that I won't remove from Lisp.  For example, the 
format of URLs from Netscape/Mozilla has changed several times.  More 
and more new types are being added by Gnome and KDE file managers.  
Having the decoding of all that in Lisp is so much more flexible and 
much easier to modify, maintain and debug than having it in C.  If a 
general part is made, the decodings will be done in the platform 
specific parts, that's obvious.

>
> Third, there are the drop types, which have both different encodings
> (platform-dependent) and different default actions (platform-
> independent).  For the latter, it would be nice to agree on a set of
> names (e.g. text, URL, file).

I don't follow, what kind of action is text, URL, file?  An action 
would be more like insert-text, open-file or some such.

> Finally, the "suggested action" in XDND will be very useful on Mac, so
> I hope it stays around.

As it is part of the protocol in both XDND and Motif, it will not go 
anywhere.  I'll try to include some generalization of the concept.

	Jan D.

Re: [patch] enhanced mac drag-n-drop

[Jan D.]

Jason Rumney wrote:

>"Jan D." <jan.h.d@swipnet.se> writes:
>
>  
>
>>We should break out what you can use in a general dnd.el file.  The
>>x-dnd.el currently contains both general DND handling and protocol
>>specifics. I'll look at what the w32 code uses and try to generalize
>>it more.
>>    
>>
>
>The code is in term/w32-win.el. I only used one function from
>x-dnd.el, but I think I basically rewrote another function with minor
>changes, so it may be possible to generalize that. Also a full dnd
>implementation on w32 could probably use more from x-dnd.el if someone
>were to contribute the necessary COM code to generate the more complex
>events, so generalizing as much as you can would help in the long term.
>

I've done a small generalization, in the new file dnd.el.  The idea is 
that platform specific parts call functions in this file.  I've changed 
dired.el and w32-win.el (but not tested on w32).  I'm not sure how 
things work on w32, but I think dropping on a dired buffer will copy a 
file to the dired directory on w32 as well now.

The only thing a user can customize that is general on all platforms is 
the dnd-protocol-alist.  Now, I know that it is hard to cover all cases 
with such a simple selection mechanism,  For example, files may be image 
files, shall the image be created in Emacs?  What is the url of a sound 
clip that is dropped?

The X DND mechanism gives the types of items dropped, but I don't know 
what other platforms use for types, so it is hard for me to generalize 
this part.  And I don't want to add complexity until we need it.

    Jan D.

Re: [patch] enhanced mac drag-n-drop

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 05 Apr 2005 17:53:00 -0700, "Sean O'Rourke" <sorourke@cs.ucsd.edu> said:

> -	    /* x-dnd functions expect undecoded filenames.  */
> -            drag_and_drop_file_list =
> -	      Fcons (make_unibyte_string (unix_path_name,
> +              /* x-dnd functions expect undecoded filenames, but we
> +                 don't have to follow that. */
> +              drag_and_drop_list =
> +                Fcons (Fcons
> +                       (intern ("file"),
> +                        Fdecode_coding_string
> +                        (make_unibyte_string (unix_path_name,

I have a general question in relation to this part.  Is it safe
to (possibly indirectly) call Feval, which may cause GC, while
executing XTread_socket?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: [patch] enhanced mac drag-n-drop

[Jan D.]

>>>>>> On Tue, 05 Apr 2005 17:53:00 -0700, "Sean O'Rourke" 
>>>>>> <sorourke@cs.ucsd.edu> said:
>
>> -	    /* x-dnd functions expect undecoded filenames.  */
>> -            drag_and_drop_file_list =
>> -	      Fcons (make_unibyte_string (unix_path_name,
>> +              /* x-dnd functions expect undecoded filenames, but we
>> +                 don't have to follow that. */
>> +              drag_and_drop_list =
>> +                Fcons (Fcons
>> +                       (intern ("file"),
>> +                        Fdecode_coding_string
>> +                        (make_unibyte_string (unix_path_name,
>
> I have a general question in relation to this part.  Is it safe
> to (possibly indirectly) call Feval, which may cause GC, while
> executing XTread_socket?

It is not safe if the Mac OSX port runs XTread_socket in a signal 
handler.  That is one more argument for just creating simple events in 
C and pass them on to Lisp.

	Jan D.

Re: [patch] enhanced mac drag-n-drop

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 9 Apr 2005 15:46:10 +0200, "Jan D." <jan.h.d@swipnet.se> said:

>> Is it safe to (possibly indirectly) call Feval, which may cause GC,
>> while executing XTread_socket?

> It is not safe if the Mac OSX port runs XTread_socket in a signal
> handler.  That is one more argument for just creating simple events
> in C and pass them on to Lisp.

Thanks.  I've just encountered a situation that I'd like to use
code conversion, which may call Feval, inside XTread_socket.
That is related to a callback function for the clipboard, and it
should complete code conversion before it returns.  Thus passing
events to Lisp does not work here.

Is GC the only reason to avoid Feval inside XTread_socket?  If
so, is it possible to use code conversion together with
inhibit_garbage_collection?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: [patch] enhanced mac drag-n-drop

[Jan D.]

> Thanks.  I've just encountered a situation that I'd like to use
> code conversion, which may call Feval, inside XTread_socket.
> That is related to a callback function for the clipboard, and it
> should complete code conversion before it returns.  Thus passing
> events to Lisp does not work here.
>
> Is GC the only reason to avoid Feval inside XTread_socket?  If
> so, is it possible to use code conversion together with
> inhibit_garbage_collection?

The main reason AFAIK is that the Lisp interpreter is not reentrant.  
If some Lisp code is preempted by a signal and then XTread_socket calls 
Lisp code, you have two instances of the Lisp interpreter running in 
parallell, and it is not designed for that.  Much like not being thread 
safe.

	Jan D.

Re: [patch] enhanced mac drag-n-drop

[Stefan Monnier]

> Is GC the only reason to avoid Feval inside XTread_socket?
> If so, is it possible to use code conversion together with
> inhibit_garbage_collection?

Jan D. explained the problem, and I will just note that compiling
with -DSYNC_INPUT should lift that restriction (because it causes
XTread_socket to not be run from the signal handler any more).


        Stefan

Re: [patch] enhanced mac drag-n-drop

[Richard Stallman]

    Jan D. explained the problem, and I will just note that compiling
    with -DSYNC_INPUT should lift that restriction (because it causes
    XTread_socket to not be run from the signal handler any more).

Do you recall what the disadvantages of -DSYNC_INPUT were?
I think one disadvantage may have been that the Emacs window would
not refresh while something was busy.  But I am not sure if that
disadvantage is real.  Do you know?

Re: [patch] enhanced mac drag-n-drop

[Stefan Monnier]

>     Jan D. explained the problem, and I will just note that compiling
>     with -DSYNC_INPUT should lift that restriction (because it causes
>     XTread_socket to not be run from the signal handler any more).

> Do you recall what the disadvantages of -DSYNC_INPUT were?
> I think one disadvantage may have been that the Emacs window would
> not refresh while something was busy.  But I am not sure if that
> disadvantage is real.  Do you know?

Indeed, it makes signal handling synchronous, i.e. more like
cooperative multithreading: if you forget to use QUIT at some spot, it might
lead to an Emacs process completely unresponsive to C-g.
Note that we already have such occurrences current without
using -DSYNC_INPUT, so it wouldn't be a new class of bugs.

But the screen does get refreshed even while Emacs is busy since signals
processing can be done at any place where we do QUIT.

Other disadantages: it makes the QUIT macro bigger and maybe slower.
I haven't looked at the actual impact and neither have I tried to reduce
this impact.

OTOH, it makes several BLOCK_INPUT unnecessary, including all the
malloc_hook hacks.

For what it's worth I've been using Emacs with -DSYNC_INPUT since before
I installed the patch and haven't noticed any negative impact (except for
a few places where a QUIT was missing, but I haven't bumped into any such
thing for a while now).


        Stefan

Re: [patch] enhanced mac drag-n-drop

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 10 Apr 2005 23:35:55 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> For what it's worth I've been using Emacs with -DSYNC_INPUT since
> before I installed the patch and haven't noticed any negative impact
> (except for a few places where a QUIT was missing, but I haven't
> bumped into any such thing for a while now).

I've also been using Emacs on two SIGALRM systems, Mac OS X and
Solaris 8, with -DSYNC_INPUT and a small patch in
http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00094.html.
Both of them work without problems.

>>>>> On Sun, 10 Apr 2005 11:03:43 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I've just encountered a situation that I'd like to use code
> conversion, which may call Feval, inside XTread_socket.  That is
> related to a callback function for the clipboard, and it should
> complete code conversion before it returns.  Thus passing events to
> Lisp does not work here.

There seems to be some similar situations especially about
interapplication communication such as clipboard, drag-and-drop, and
service menu, on Mac.  Callback/handler functions are supposed to set
results on return there.  Some of them can be avoided by preparing all
the possible values that might be passed to other applications in
advance, and it seems to be acceptable in the case of the clipboard
mentioned above.  Because the next release is coming, I'll do so for
now, and leave the improved one to the Unicode version.

Thanks again for all the responses to my question.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: [patch] enhanced mac drag-n-drop

[Stefan Monnier]

> I've also been using Emacs on two SIGALRM systems, Mac OS X and
> Solaris 8, with -DSYNC_INPUT and a small patch in
> http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00094.html.
> Both of them work without problems.

Any reason why you haven't installed your small patch yet?
Since it only affects the SYNC_INPUT behavior (not used by default), it's
obviously safe to install.


        Stefan

Re: [patch] enhanced mac drag-n-drop

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 11 Apr 2005 12:39:40 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> Any reason why you haven't installed your small patch yet?  Since it
> only affects the SYNC_INPUT behavior (not used by default), it's
> obviously safe to install.

Well, I thought I needed kind of approval.  I've just checked it in.

>>>>> On Sun, 10 Apr 2005 23:35:55 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> OTOH, it makes several BLOCK_INPUT unnecessary, including all the
> malloc_hook hacks.

This reminded me of the recent topic on the hourglass cursor.  I think
show_hourglass is still called asynchronously even if SYNC_INPUT is
defined.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: [patch] enhanced mac drag-n-drop

[Richard Stallman]

    Indeed, it makes signal handling synchronous, i.e. more like
    cooperative multithreading: if you forget to use QUIT at some spot, it might
    lead to an Emacs process completely unresponsive to C-g.

Does this mean that immediate_quit stops working?

Re: [patch] enhanced mac drag-n-drop

[Stefan Monnier]

>     Indeed, it makes signal handling synchronous, i.e. more like
>     cooperative multithreading: if you forget to use QUIT at some spot, it
>     might lead to an Emacs process completely unresponsive to C-g.

> Does this mean that immediate_quit stops working?

Most likely.  Just like it currently doesn't work if you're inside
a BLOCK_INPUT section.


        Stefan

Re: [patch] enhanced mac drag-n-drop

[Richard Stallman]

    > Does this mean that immediate_quit stops working?

    Most likely.  Just like it currently doesn't work if you're inside
    a BLOCK_INPUT section.

immediate_quit isn't used inside BLOCK_INPUT sections, but it is used
in many places.  All those places would appear to become bugs
when -DSYNC_INPUT is used.

Surely most of them can be fixed to use QUIT instead and will work
well enough.  However, it is necessary to fix each and every one.

Re: [patch] enhanced mac drag-n-drop

[Richard Stallman]

    Thanks.  I've just encountered a situation that I'd like to use
    code conversion, which may call Feval, inside XTread_socket.

XTread_socket runs in a signal handler.  I don't think Emacs can
recover from a Lisp error occurrinmg in the signal handler.
I think there are many other potential causes of bugs
if eval were run from the signal handler.

Someone wrote code to move most of the real work of XTread_socket
outside the signal handler.  ISTR we did not install it because there
were some cases in which that would change the behavior for the worse.
But we didn't reach any final conclusion about it.