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

From: Visuwesh <[email-masked]>
Date: Thu, 20 Feb 2025 21:56:53 +0530

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

> Visuwesh <[email-masked]> writes:
>
>> [வியாழன் பிப்ரவரி 20, 2025] Alvaro Ramirez wrote:
>>
>> In interest of adapting my personal KDE Connect code as a plug-in
>> for
>> the new library, I have some comments below.
>
> Thanks for the comments Visuwesh!
>
> KDE Connect sounds like a great option for KDE users! Would you be
> interested in submitting your code as a follow-up patch to include it
> amongst the known mechanisms?

If there's enough interest, and time permitting, I can give it a shot.

>>> +(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?  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.

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

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

>>> +  :type '(function :tag "Function")
>>> +  :group 'send-to
>>> +  :version "31.1")
>>> +
>>> +(defcustom send-to-context-items-function
>>> #'send-to--default-context-items
>>> +  "A function to collect the items to be sent by `send-to'.
>>> +
>>> +Defaults to `send-to--default-context-items'.
>>> +
>>> +The function returns a list of items, where each item can be a
>>> either
>>> +a filename or plain text."
>>> +  :type '(function :tag "Function")
>>> +  :group 'send-to
>>> +  :version "31.1")
>>
>> We should document how a filename is distinguished from plain text
>> item
>> here again.
>
> Yep. Good point. Will do.
>
>> 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.