emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jean-Christophe Helary
Subject: Re: lisp/term/ns-win.el modification
Date: Fri, 28 Apr 2017 00:31:34 +0900

> On Apr 28, 2017, at 0:09, Davis Herring <address@hidden> 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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]