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

Previous Next

Full log

View this message in rfc822 format

From: Alvaro Ramirez <alvaro <at> xenodium.com>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 76120 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com, shipmints <at> gmail.com, rms <at> gnu.org
Subject: bug#76120: This feature is not about "sharing", or a "native" anything.
Date: Thu, 20 Feb 2025 17:30:04 +0000

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

>>>> +(defcustom send-to-support-checker-function
>>>> #'send-to--default-support-checker-p
>>>> +  "A function returning non-nil when sending is supported by
>>>> current platform."
>>>> +  :type '(function :tag "Function")
>>>> +  :group 'send-to
>>>> +  :version "31.1")
>>>
>>> Does this need to be a defcustom?  This seems like an internal
>>> feature,
>>> and I wonder if a defvar/defcustom is necessary even.
>>
>> If we want the feature to support configurable alternatives, we 
>> need
>> to be able to check for required dependencies. This is just the
>> customization point for such a check.
>
> Thinking about this a bit more, I wonder if this and
> send-to-handler-function should be unified?

Ah, right. That was my initial approach. Splitting into two 
functions came later when I needed the context menu to be a little 
smarter and only show the "Send to..." menu if the required 
infrastructure is truly available.

> If s-t-h-f doesn't have
> xdg-open in GNU/Linux, it could signal an error.  I don't see 
> why this
> should be a defcustom, this isn't something the user should be
> configuring IMO.  At least, as a user, I don't want to configure 
> a test
> function such as this.

I'm typically grateful for the variety of defcustom's available 
across packages. Most of them, I don't have to change as I'm happy 
with the defaults chosen by the author. My thinking here was to 
offer an appealing default, but offer optional customizations, 
should users chose to bring their own "Send to..." 
implementation. The KDE Connect integration you mentioned is a 
good example (if we don't end up bundling by default).

>>>> +(defcustom send-to-handler-function 
>>>> #'send-to--default-handler
>>>> +  "A function handling `send-to' external routing.
>>>> +
>>>> +The function receives a list of items to send.
>>>> +
>>>> +Each item can be a either a filename or plain text."
>
> ...which leads me to: should we rather have separate handler 
> functions
> instead of grouping everything together in a single big one?

24 lines of code is a big function? ;)

> The default value could depend on system-type and availability 
> of the
> required binaries.  This would be easier for package developers 
> and
> users (e.g., a user could more easily choose between KDE Connect 
> or
> xdg-open).

We can maybe consolidate configuration into a single variable (a 
list of handlers), but each handler would likely still need to 
implement at least two operations (supported-p + send).

>>> What about other URLs such as https:?  IMO, these should be
>>> accounted
>>> for since it is quite common to send URLs (to other devices in 
>>> my
>>> case).
>>
>> Yup. I do this frequently too. The current implementation 
>> (using
>> file-exists-p) should handle sending URLs (ie. https://gnu.org) 
>> as
>> text.
>
> I think this test might fail if someone uses url-handler-mode.
>

Oh my, TIL about url-handler-mode. Thanks! Will need to tweak the 
logic.

>>> Also should this be buffer-local so different major-mode
>>> can provide different providers?
>>
>> Ah. Sure. Will do.
>
> Thinking about it a bit more, the job of providing a "items" 
> function is
> really the package/major-mode author's job.  Perhaps, it would 
> be better
> to have an abnormal hook or somesuch where the first non-nil 
> item
> returned would be sent.
>
> Having separate functions would make it easier for 
> package/major-mode
> authors to provide glue code rather than having a single big 
> function
> that does everything.

The buffer-local suggestion seems to strike a good balance 
here. Send-to.el can offer an appealing default to pick files and 
package/major-modes can choose to override locally if needed.

Previous Next

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