Subject: Re: bug#76120: This feature is not about "sharing", or a "native" anything.

From: Visuwesh <[email-masked]>
Date: Thu, 20 Feb 2025 23:29:02 +0530

[வியாழன் பிப்ரவரி 20, 2025] Alvaro Ramirez wrote:

> Visuwesh <[email-masked]> writes:
> [...]
>> 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.

We could check if send-to-handler-function is non-nil and ensure we set
a non-nil default value iff the share/send-to feature is 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).

Sure.  It could be equally well be a defvar.  I just don't see why it
should be a defcustom.  But I won't insist on this.

>>>>> +(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? ;)

I confused this and send-to-context-items-function.  That said, it could
grow out of hand when we add support for other platforms/send-to
mechanisms.

>> 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).

I hope you will consider combining these two.  The default value could
check the existence of necessary conditions which would circumvent the
need for an extra supported-p.  If push comes to shove, the send
function could signal an error.  Provided that we have separate handler
function for each share-to mechanism.