Re: Feature request: ls --hyperlink

[Pádraig Brady]

On 21/08/17 04:28, Pádraig Brady wrote:
> On 05/05/17 14:05, Pádraig Brady wrote:
>> On 04/05/17 13:14, Egmont Koblinger wrote:
>>> Hi,
>>>
>>> Recently two popular terminal emulators, GNOME Terminal and iTerm2
>>> have implemented a brand new feature: explicit hyperlinks.
>>>
>>> Unlike the existing functionality of most terminal emulators of
>>> automatically detecting URLs that appear on the screen, this time it's
>>> like hyperlinks on web pages: the link target is specified by the OSC
>>> 8 escape sequence and the visible text can be an arbitrary piece of
>>> text.
>>>
>>> As I've played with this feature, I found a really compelling use
>>> case: listing files in a way that all of them are hyperlinks to
>>> "file://...". It makes it as easy and convenient as a Ctrl+click to
>>> open them in their preferred graphical application.
>>>
>>> (For even more fun, there's a pending demo patch to GNOME Terminal to
>>> display a preview of certain local files on mouseover. We're uncertain
>>> yet if we'll finalize and ship it or not.)
>>>
>>> I've created a quick proof of concept patch for a new cmdline option
>>> "ls --hyperlink=always/auto/never", have set it up in my "ls" alias,
>>> and been using that happily for a few weeks now. Please find it at
>>> https://bugzilla.gnome.org/show_bug.cgi?id=779734#c126. Note that it
>>> contains a couple of issues, e.g. I forgot to free some data, and it
>>> does stupid things around symlinks. As said, it's a demo, not a fully
>>> polished patch.
>>>
>>> I'd be curious to hear if you like this idea, and would be happy to
>>> see this option appearing in mainstream coreutils.
>>>
>>> Please see 
>>> https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
>>> for details about the feature.
>>>
>>> Let me know if you have any questions, concerns etc. (cc me, I'm not
>>> subscribed).
>>
>> Interesting.
>> This could apply to any util really that displays file names,
>> though ls would be the most useful.
>> Generally it also seems useful to the case where a file has a non 
>> representable name
>> (well not cleanly at least without $'shell quoting').
> 
> I've attached an implementation for ls --hyperlink.
> 
> Some notes:
> 
> I used canonicalize_filename_mode for consistency with other tools,
> and to relax the canonicalization with CAN_MISSING.
> I did this because access may be possible outside current shell context,
> and also we don't want to diagnose perm issues that would
> either not otherwise need diagnosing, or would be diagnosed
> independently by stat() etc.
> 
> --dired is handled appropriately, since the terminal codes
> are similar to non displayed color codes and can be skipped similarly.
> 
> I used more stringent escaping as per rfc3986
> because I think there are security issues with the more lax
> encoding described at 
> https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
> and I don't see any advantage of using that more lax encoding.
> If terminals provided a copy link functionality, or
> the links otherwise got outside the terminal context
> then there could be problematic handling of non encoded items.
> For example if you didn't encode '?' and the link was passed
> to a browser, then anything after that would be ignored.
> Also '%' needs to be encoded for the same reasons where
> files other than intended could be resolved.
> 
> This should work on windows where c: is separated from the
> hostname appropriately and '\' are converted to '/',
> though I haven't tested there.
> 
> I've tested with valgrind with multiple specified dirs
> and there are no leaks.
> 
> I was tempted to add --hyperlink to realpath, though I'm not sure it's needed.
> 
> I was tempted to add a --hyperlink=raw option to output just the file://...
> portion without the terminal codes, as older terminals highlight/process
> those fine and they might be otherwise usefule.  Though again I wasn't sure.
> 

Version 2 attached which fixes a small mem leak,
ensures that URLs are aligned in padded output,
and disables --dired with --hyperlink since it didn't work in testing
and precluded the URL alignment method used (which excludes quotes from the 
URL).
It might be useful to support //DIRED-OPTIONS// --hyperlink to identify
the URI portion to emacs, but we can do that separately if useful.

cheers,
Pádraig.

ls--hyperlink.patch
Description: Text Data