Opened 10 years ago

Last modified 10 years ago

#462 new defect

dragging a folder proxy icon to an IDE listener inserts a file pathname, not a directory pathname

Reported by: james.anderson Owned by: rme
Priority: normal Milestone:
Component: IDE Version: 1.3
Keywords: Cc:

Description

This applies to both list icons and proxy icons. In the IDE, one must add a slash to the end. In the terminal, the inserted text comprises the pathname + a succeeding space.

Change History (7)

comment:1 Changed 10 years ago by mikel

  • Owner set to mikel
  • Status changed from new to assigned

comment:2 Changed 10 years ago by mikel

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed; we were using the default drop-handling for NSTextView, which handles dropped files in the way described in the bug report. The fix adds to cocoa-editor.lisp an implementation of #/performDragOperation: that tries to find NSFilenamesPboardType in the pasteboard, and, if successful, canonicalizes the pathnames so that directory pathnames end in a "/"

comment:3 Changed 10 years ago by rme

  • Resolution fixed deleted
  • Status changed from closed to reopened

We go to a lot of trouble to support multiple dragged-in filenames, but I wonder if this is just wasted effort?

It seems to me that the typical scenario would be that the user drags in a single file which he means to use as an argument to some function (like probe-file or whatever). If that's true, then maybe what we want is to insert is something like "/path/to/file", quotation marks included, (if not #p"/path/to/file") instead of an unquoted string.

We could refuse the drop if there's more than one filename on the pasteboard.

comment:4 Changed 10 years ago by mikel

If we go to the trouble to get the dragged items at all, we're getting multiple items, because the DragInfo? gives us an array, regardless of how many are dropped. The remaining effort is in service of finding out whether the dropped pathnames are directories and, if so, making sure that the pasted string(s) end with a slash, which is what the ticket is asking for.

It does seem reasonable to paste them as strings rather than hunks of text, or even to convert them to (the printed representation of) pathnames. As long as I'm doing that, though, I could always paste a (list #P"foo" #P"bar"...) expression when there are several of them.

comment:5 Changed 10 years ago by mikel

The implementation I wrote of performDragOperation caused more problems than it solved. Using hi::insert-string on the listener's buffer-point caused hemlock to become confused in a way that confuses me (something is getting an integer argument instead of an expected vector after the paste, and I was unable to identify the culprit in the debugger.)

Until I have time to devise an implementation that actually works, I'm backing this change out and leaving the bug open.

comment:6 Changed 10 years ago by rme

From a quick glance, it looks like current-open-line-p is providing the wrong answer when an icon is dropped into an open line.

(The chars slot of a line will be a negative fixnum when the line is open.)

This is probably because hi::*current-buffer* isn't bound when the performDragOperation method is called. See r12370 for a possible solution.

comment:7 Changed 10 years ago by mikel

  • Owner changed from mikel to rme
  • Status changed from reopened to new
Note: See TracTickets for help on using tickets.