GNU bug report logs - #76120
[PATCH] Expose the native sharing dialog (macOS)

Previous Next

Full log

Message #400 received at 76120 <at> debbugs.gnu.org (full text, mbox):

From: Alvaro Ramirez <alvaro <at> xenodium.com>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: Rudolf Adamkovič <rudolf <at> adamkovic.org>, rms <at> gnu.org,
 Juri Linkov <juri <at> linkov.net>, 76120 <at> debbugs.gnu.org, stefankangas <at> gmail.com,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#76120: This feature is not about "sharing", or a "native"
 anything.
Date: Sat, 15 Mar 2025 18:11:47 +0000

Visuwesh <visuweshm <at> gmail.com> writes:

> [சனி மார்ச் 15, 2025] Alvaro Ramirez wrote:

>>> I must sound like a parrot: but could you please consider 
>>> making
>>> filenames into file: URLs?  This would avoid the number of
>>> file-exists-p
>>> checks, which is a worthy goal IMO.  Remote files could be 
>>> checked
>>> with
>>> (file-remote-p default-directory).
>>
>> Could you share more details about file: please?
>
> The proposal for file: is mostly so that the backend doesn't 
> have to
> second-guess what the item type is.  It could similarly be a 
> cons cell
> such as (file . FILENAME).

Ah, right. I had a similar thought. From the previous comment 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76120#313:

    At a point, I was considering including type information per 
    item
    like:

    ((type . file)
    (value . "/path/to/hello.txt"))

    vs

    ((type . text)
    (value . "hello world"))

    My gut told me to go with the simpler string option initially 
    and
    consider including type information in a future iteration if 
    users
    do have concrete needs for it.

To me, it feels like an extension of how we describe what's being 
sent with a richer language. IMO, this richer language can come as 
a follow-up feature once we record enough concrete cases to guide 
its design.

>> Sending remote files isn't currently a goal. Neither macOS's
>> NSSharingServicePicker nor xdg-open (AFAIK) would be able to 
>> handle
>> remote files?
>
> With your current code for the open backend, I think xdg-open 
> will be
> executed in the remote machine.  OTOH, one could copy the remote 
> file
> using file-local-copy, and call local machine's xdg-open on the 
> local
> copy.

It sounds like a great feature to have and also one that come in 
as a follow-up feature. More on that below...

>   I routinely do the latter for opening log files in remote HPCs
> with molecular visualisers I have on my laptop:

The current proposal lends itself to experiment with such a thing 
via custom send-to-handlers.

If possible, I'd like to keep the current patch as an MVP of 
sorts, but customisable enough that we can play with suggestions 
like yours and add suggest another round of features in another 
iteration based on what we learned. Hope that makes sense.

>
>     (defun vz/dired-do-local-command (command &optional arg 
>     files)
>       "Run local shell command COMMAND on the marked FILES.
>     If ARG is non-nil, then consider run the shell command on 
>     the
>     next ARG files.  If the region is active, then run the shell
>     command on the files in the region.
>     FILES should a list of absolute remote filenames.
>     For format of COMMAND, refer `dired-do-shell-command'."
>       (interactive
>        (let ((files (dired-get-marked-files t current-prefix-arg 
>        nil nil t)))
>          (list (let ((default-directory "~/")) ; To make the 
>          completion work.
>                  (dired-read-shell-command "! on %s: " 
>                  current-prefix-arg files))
>                current-prefix-arg
>                (mapcar #'expand-file-name files)))
>        dired-mode)
>       (let ((default-directory "~/"))
>         (dired-do-shell-command command arg (mapcar (lambda (x) 
>         (or (file-local-copy x) x)) files))))

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.