GNU bug report logs -
#76120
[PATCH] Expose the native sharing dialog (macOS)
Previous Next
Full log
Message #316 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் பிப்ரவரி 20, 2025] Alvaro Ramirez wrote:
> Visuwesh <visuweshm <at> gmail.com> 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.
This bug report was last modified 20 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.