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

[Jean-Christophe Helary <jean.christophe.helary@gmail.com>]

> On Apr 28, 2017, at 0:09, Davis Herring <herring@lanl.gov> wrote:
> 
>>> I mean what the string contains. Your code splits it on certain characters: "[\f\t\n\r\v]+". It is always good to be able to go to some documentation, to verify that these really are the characters that delimiter file names. However, if the content is an arbitrary text file, then that should be mentioned.
>> 
>> The content is an arbitrary string selected in any application that supports services. I've removed \s from the delimiters *because* spaces can be part of a path on Mac.
> 
> All those characters could appear as well: macOS is Unix

They probably could, but how realistic do you think it is to have a file path that *includes* a page break, a carriage return, a tabulation, a new line, or a vertical tab?

> , after all, and so supports anything except NUL (and reserves / as a directory separator, although in some interfaces / and : are interchanged).  That said, of course spaces are much more common in names, but it's good to remember that this is a human factors decision, not a technical one based on OS rules.

I understand.

The current use case is the following:

The user selects lines that all include 1 path on each line, and depending on the way the lines are selected (triple-clicking or selection with the keyboard) some leading and trailing white spaces can be included.

So we are not really talking about a very general case of any possible path that's possible under Unix. I think it is reasonable to make assumptions about what the user *sees* and what the user considers a path to be selected and opened with that service.

Jean-Christophe