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: Thu, 27 Apr 2017 23:53:09 +0900

> On Apr 27, 2017, at 20:30, Anders Lindgren <address@hidden> wrote:
> 
> 
>> Ok, but such a trimming function is trivial and I don't see how my rewriting 
>> it to make it different from that code would add to it. What should I do?

> Since it's small you could inline it and drop the comment. You could try to 
> rewrite the code into containing only one match and one replace.

Ok, I'll do.
 
>> Aha, I have't used Services that much. Can you give me a step-by-step 
>> description on how to use them, where the current system doesn't work. 
>> (Concretely, is this I do from within Emacs, from Finder, or from some other 
>> program?)

1) Select a path in any application where text can be selected
2) Go to the application menu and select Services > Open Selected File
3) The file should open in Emacs.app if it exists. If it doesn't, a buffer 
named after the name part of the path is opened.

Problem:

a) if the selected string is not trimmed (for ex you triple-clicked the line 
and it contained leading or trailing ws), the file won't open because the ws is 
considered integral part of the path

b) if the selection contains more than 1 line (for ex. a list of paths on 
multiple lines), no file will open since the whole string is considered the path

What I wrote solves a) and b) by splitting the selected string (except on 
spaces), by trimming the resulting paths, and by looping the original function 
on the thus created list of paths.
 
> 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.

> I don't want to modify the ns-spi-service-call block more than necessary.
> 
> If all you do is to place the call inside a dolist, you should be ok. 
> Introducing additional functions (only used in one location) isn't 100% clean 
> either.

Ok, that's something I'll try to do. Thank you.

> Trimming newline should obviously be done. How often does files contain 
> trailing whitespace? (I guess initial whitespace is more common.) Anyway, 
> once I have a concrete example to test, it will hopefully clear up for me.

Create an absolute path like /User/path/to/file or a relative path like 
~/path/to/file, select them and call the service on the selection.

The only issue that I see is when a file name *ends* with (normal) spaces, 
which is unlikely to happen, even if possible.

Jean-Christophe 


reply via email to

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