Re: lisp/term/ns-win.el modification

[mituharu]

>> * File names in macOS may start or end with spaces. It's probably not a
>> good idea to trim spaces. (Again, it's hard to tell without a
>> description of the format.)
>
> Yes, but we're not talking about file names but file paths in a text file
> here.
> The problem with not trimming is that when a legit file is
> tripple-clicked, the whole line is selected, including trailing spaces.
> The way the service is currently implemented considers that spaces a
> belonging to the file name and since that file does not exist just opens a
> blank buffer.
>
> So I guess I could add a test to check wether the trimmed file exist and
> if not add the selected white space until I get an existing file (but then
> we'd hit cases where 2 files ending with different sorts of white space
> could be confused for each other).

For more consistent behavior with other apps on macOS, you can
let the system parse the selected text to get (possibly multiple)
filenames.  Just inspect the service pasteboard with
NSFilenamesPboardType instead of NSStringPboardType.
Alternatively, creating NSURL objects for pasteboard items would
also work.  (I'm not sure if this works on GNUstep.)

https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/PasteboardGuide106/Articles/pbReading.html#//apple_ref/doc/uid/TP40008123-SW5

                                     YAMAMOTO Mitsuharu
                                address@hidden