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

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

> On May 1, 2017, at 15:33, Eli Zaretskii <eliz@gnu.org> wrote:
>> It looks like Anders found that in some cases a a non breakable space could be added to a string in Gmail:
>> 
>> "I did test your patch from within gmail in Chrome. One this that I realized was that when typing a space, it sometimes came out as a plain space, sometimes as a non-breakable space. I'm not sure this is specific to the edit field in gmail, but I think it would ba good idea to trim both kind of spaces."

> What about other whitespace characters? can they also be added in
> these scenarios?

The only scenario that we have is the user who types and selects a string, or selects an already existing string and calls that NS function on it.

>> But as I pointed out earlier, it would also be nice to have a clear definition of what "trimming" a string means. It is means remove the ws at the beginning and end of the string then the Unicode characters for ws should be used.
> 
> But if these characters can appear in the string you want to have,
> after "trimming", then trimming them wouldn't be correct, would it?
> That's why I'm asking these questions.  We shouldn't remove anything
> that could be legitimately part of the payload, we should only remove
> stuff that might be prepended/appended to the payload by the software
> involved in the transaction.

I understand, and that was part of the discussion we had with Anders at the beginning of the thread.

The function only understand paths that start from / or from ~, so the path can't start with ws. As for paths ending with ws, that's a very marginal case. Currently, in a triple-click all the ws ending the string is selected and the function will thus fail to open the selected path. It should be possible to test incrementally whether the trimmed path points to a file, or if the path ending with the first ws does, etc until the end of the trailing ws list, but that's not practical.

Jean-Christophe