GNU bug report logs -
#76120
[PATCH] Expose the native sharing dialog (macOS)
Previous Next
To reply to this bug, email your comments to 76120 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Fri, 07 Feb 2025 15:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Álvaro Ramírez <alvaro <at> xenodium.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 07 Feb 2025 15:00:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi folks,
Similar to the existing ns-do-show-character-palette command, this
patch exposes a native macOS context dialog.
The new addition enables users to share (send) text or files to
other apps.
Examples:
- Send current buffer file.
- Send a list of dired files.
- Send region text.
I'm keen to polish the patch a bit more, but wanted to pre-fly
things before investing further.
Overall it's a nice/convenient addition. I use it frequently to
quickly send things to my phone over local network/Bluetooth.
I'm attaching a couple of screenshots showcasing a couple of uses:
share-dired-files.jpg (send files from dired)
share-region-text.jpg (send region text)
Hope you like it.
Álvaro
In GNU Emacs 31.0.50 (build 44, aarch64-apple-darwin24.0.0, NS
appkit-2566.00 Version 15.0.1 (Build 24A348)) of 2025-02-07 built
on
MacBookPro
Repository revision: 811d575336942b1cd1e1c6fb50620babdf9cc82c
Repository branch: macos-share
Windowing system distributor 'Apple', version 10.3.2566
System Description: macOS 15.0.1
Configured using:
'configure --with-ns
--prefix=/Users/alvaro/stuff/active/code/third_party/emacs/nextstep/Emacs.app/Contents/MacOS
--enable-locallisppath=/Users/alvaro/stuff/active/code/third_party/emacs/nextstep/Emacs.app/Contents/MacOS'
[0001-Expose-the-native-sharing-dialog-macOS.patch (text/patch, attachment)]
[share-dired-files.jpg (image/jpeg, attachment)]
[share-region-text.jpg (image/jpeg, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Fri, 07 Feb 2025 22:21:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Simplifying patch
(0002-Expose-the-native-sharing-dialog-macOS.patch)
help-debbugs <at> gnu.org (GNU bug Tracking System) writes:
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your
> message
> has been received.
>
> Your message is being forwarded to the package maintainers and
> other
> interested parties for their attention; they will reply in due
> course.
>
> Your message has been sent to the package maintainer(s):
> bug-gnu-emacs <at> gnu.org
>
> If you wish to submit further information on this problem,
> please
> send it to 76120 <at> debbugs.gnu.org.
>
> Please do not send mail to help-debbugs <at> gnu.org unless you wish
> to report a problem with the Bug-tracking system.
[0002-Expose-the-native-sharing-dialog-macOS.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 08 Feb 2025 00:17:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Álvaro Ramírez <alvaro <at> xenodium.com> writes:
> Hi folks,
>
> Similar to the existing ns-do-show-character-palette command, this
> patch exposes a native macOS context dialog.
>
> The new addition enables users to share (send) text or files to
> other apps.
>
> Examples:
>
> - Send current buffer file.
> - Send a list of dired files.
> - Send region text.
>
> I'm keen to polish the patch a bit more, but wanted to pre-fly
> things before investing further.
Thanks. Does this functionality exist on free operating systems (most
importantly on GNU/Linux)?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sun, 09 Feb 2025 13:36:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 76120 <at> debbugs.gnu.org (full text, mbox):
+76120 <at> debbugs.gnu.org (sorry, missed adding earlier)
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>>
>>> Thanks. Does this functionality exist on free operating
>>> systems (most
>>> importantly on GNU/Linux)?
>>>
>>> Yup. Lots of options there. Here are a handful.
>>>
>>> - GSConnect:
>>> https://github.com/GSConnect/gnome-shell-extension-gsconnect
>>> - KDE Connect: https://kdeconnect.kde.org
>>> - Desktop integration portal:
>>> https://flatpak.github.io/xdg-desktop-portal
>>> - Teleport: https://gitlab.gnome.org/jsparber/teleport
>>
>> Another resource
>> https://flatpak.github.io/xdg-desktop-portal/docs/convenience-libraries.html
>
> Do they work with Emacs, or do we need to do more work first?
There’s one already
https://github.com/carldotac/kdeconnect.el. There may be more.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sun, 09 Feb 2025 15:13:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> +76120 <at> debbugs.gnu.org (sorry, missed adding earlier)
>
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>>
>>> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>>>
>>>> Thanks. Does this functionality exist on free operating
>>>> systems (most
>>>> importantly on GNU/Linux)?
>>>>
>>>> Yup. Lots of options there. Here are a handful.
>>>>
>>>> - GSConnect:
>>>> https://github.com/GSConnect/gnome-shell-extension-gsconnect
>>>> - KDE Connect: https://kdeconnect.kde.org
>>>> - Desktop integration portal:
>>>> https://flatpak.github.io/xdg-desktop-portal
>>>> - Teleport: https://gitlab.gnome.org/jsparber/teleport
>>>
>>> Another resource
>>> https://flatpak.github.io/xdg-desktop-portal/docs/convenience-libraries.html
>>
>> Do they work with Emacs, or do we need to do more work first?
>
> There’s one already
> https://github.com/carldotac/kdeconnect.el. There may be more.
According to our guidelines, we must have the same functionality on
GNU/Linux before we can install it for a non-free system.[1] This is
also documented in nextstep/README.
In other words, the feature you have proposed sounds useful, and we are
grateful for your contribution. However, we really would need it
working on GNU/Linux, as a part of core, before we can install such a
feature on macOS. The reasons for this are detailed in the link below,
but comes down to us not wanting to make Emacs better on non-free
operating systems than it is on free ones.
Would you or anyone else be interested in implementing this for
GNU/Linux as well? I don't think we need perfect coverage of all
desktop environments, but it would be useful to support it on one or more
popular ones (for example Gnome or KDE).
This would also be a good opportunity to generalize the feature, so that
instead of having `ns-share`, we would have a command named `share-file`
or something like that.
Footnotes:
[1] https://www.gnu.org/prep/maintain/maintain.html#Non_002dGNU_002donly-Features
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sun, 09 Feb 2025 18:11:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Thanks for the details Stefan
Stefan Kangas <stefankangas <at> gmail.com> writes:
> According to our guidelines, we must have the same functionality
> on
> GNU/Linux before we can install it for a non-free system.[1]
> This is
> also documented in nextstep/README.
If that's the official guideline, I suppose there isn't much room
for guideline discussion, unless you think it's worth revisiting
the current stance in 2025.
> In other words, the feature you have proposed sounds useful, and
> we are
> grateful for your contribution. However, we really would need
> it
> working on GNU/Linux, as a part of core, before we can install
> such a
> feature on macOS. The reasons for this are detailed in the link
> below,
> but comes down to us not wanting to make Emacs better on
> non-free
> operating systems than it is on free ones.
I've been gradually dipping my toes into upstream contributions
(not just macOS-related) in the hope I can maybe become a more
active contributor in the future.
While I understand the spirit of the guideline, I can't help but
feel a bit discouraged to contribute my other packages and/or
other patches which are typically platform-agnostic.
Somehow, feels like a net loss.
>
> Would you or anyone else be interested in implementing this for
> GNU/Linux as well? I don't think we need perfect coverage of
> all
> desktop environments, but it would be useful to support it on
> one or more
> popular ones (for example Gnome or KDE).
Skills-wise, I wouldn't be the best candidate to make the
Linux-related changes. I could try reaching out to Carl Lieberman,
author of https://github.com/carldotac/kdeconnect.el, to see if
they'd be inclined to contribute their package upstream.
> This would also be a good opportunity to generalize the feature,
> so that
> instead of having `ns-share`, we would have a command named
> `share-file`
> or something like that.
Without a Linux partner to help with the counter changes, I'm less
likely to take on the additional scope.
I could also reach out to emacs-devel if you reckon it's
appropriate to scout Linux support.
>
> Footnotes:
> [1]
> https://www.gnu.org/prep/maintain/maintain.html#Non_002dGNU_002donly-Features
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sun, 09 Feb 2025 19:44:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 9 Feb 2025 07:12:34 -0800
>
> According to our guidelines, we must have the same functionality on
> GNU/Linux before we can install it for a non-free system.[1] This is
> also documented in nextstep/README.
What is the functionality in question? Toolkit dialogs are available
on all platforms, including GNU/Linux. Are you talking about special
features of those dialogs, or something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sun, 09 Feb 2025 20:45:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Sun, 9 Feb 2025 07:12:34 -0800
>>
>> According to our guidelines, we must have the same functionality on
>> GNU/Linux before we can install it for a non-free system.[1] This is
>> also documented in nextstep/README.
>
> What is the functionality in question? Toolkit dialogs are available
> on all platforms, including GNU/Linux. Are you talking about special
> features of those dialogs, or something else?
I'm talking about the feature of "sharing" a file using such dialogs, as
seen in the screenshots attached here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76120#5
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sun, 09 Feb 2025 20:56:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>> According to our guidelines, we must have the same functionality
>> on
>> GNU/Linux before we can install it for a non-free system.[1]
>> This is
>> also documented in nextstep/README.
>
> If that's the official guideline, I suppose there isn't much room
> for guideline discussion, unless you think it's worth revisiting
> the current stance in 2025.
It's above my pay grade, since this policy is project-wide in GNU.
Keep in mind that the goal of the GNU project is to replace all non-free
software with free software. This includes replacing macOS with
GNU/Linux. Thus, we don't want to help make it more attractive to keep
using non-free systems than it is to use free ones.
I suggest reading this link for more background:
https://www.gnu.org/prep/maintain/maintain.html#Non_002dGNU_002donly-Features
>> In other words, the feature you have proposed sounds useful, and
>> we are
>> grateful for your contribution. However, we really would need
>> it
>> working on GNU/Linux, as a part of core, before we can install
>> such a
>> feature on macOS. The reasons for this are detailed in the link
>> below,
>> but comes down to us not wanting to make Emacs better on
>> non-free
>> operating systems than it is on free ones.
>
> I've been gradually dipping my toes into upstream contributions
> (not just macOS-related) in the hope I can maybe become a more
> active contributor in the future.
That's great! Thank you in advance, and welcome to the project.
> While I understand the spirit of the guideline, I can't help but
> feel a bit discouraged to contribute my other packages and/or
> other patches which are typically platform-agnostic.
>
> Somehow, feels like a net loss.
I can only hope that you will understand the reasoning provided above.
Note that it's quite rare that we have run into this, because Emacs for
the most part works almost exactly the same across all platforms.
>> Would you or anyone else be interested in implementing this for
>> GNU/Linux as well? I don't think we need perfect coverage of
>> all
>> desktop environments, but it would be useful to support it on
>> one or more
>> popular ones (for example Gnome or KDE).
>
> Skills-wise, I wouldn't be the best candidate to make the
> Linux-related changes. I could try reaching out to Carl Lieberman,
> author of https://github.com/carldotac/kdeconnect.el, to see if
> they'd be inclined to contribute their package upstream.
>
>> This would also be a good opportunity to generalize the feature,
>> so that
>> instead of having `ns-share`, we would have a command named
>> `share-file`
>> or something like that.
>
> Without a Linux partner to help with the counter changes, I'm less
> likely to take on the additional scope.
>
> I could also reach out to emacs-devel if you reckon it's
> appropriate to scout Linux support.
Asking Carl Lieberman might be a useful step. Asking on emacs-devel
would also be useful, to see if other people have any comments.
It's quite possible that I misunderstood, and that we do have
first-class support for this feature on GNU/Linux, for example.
(Emacs is very large, and it wouldn't be the first time I wasn't even
aware of some feature, so I wouldn't be surprised.)
Thanks again for your contribution and patience here!
>>
>> Footnotes:
>> [1]
>> https://www.gnu.org/prep/maintain/maintain.html#Non_002dGNU_002donly-Features
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sun, 09 Feb 2025 22:51:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Thanks for all the context Stefan.
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Asking Carl Lieberman might be a useful step.
Sounds good. Reached out to Carl.
> Asking on emacs-devel would also be useful, to see if other
> people
> have any comments. It's quite possible that I misunderstood, and
> that we do have
> first-class support for this feature on GNU/Linux, for example.
> (Emacs is very large, and it wouldn't be the first time I wasn't
> even
> aware of some feature, so I wouldn't be surprised.)
I've reached out to emacs-devel also.
>
> Thanks again for your contribution and patience here!
Thanks for your help!
>>>
>>> Footnotes:
>>> [1]
>>> https://www.gnu.org/prep/maintain/maintain.html#Non_002dGNU_002donly-Features
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 00:18:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
>>> Would you or anyone else be interested in implementing this for
>>> GNU/Linux as well? I don't think we need perfect coverage of
>>> all
>>> desktop environments, but it would be useful to support it on
>>> one or more
>>> popular ones (for example Gnome or KDE).
>>
>> Skills-wise, I wouldn't be the best candidate to make the
>> Linux-related changes. I could try reaching out to Carl Lieberman,
>> author of https://github.com/carldotac/kdeconnect.el, to see if
>> they'd be inclined to contribute their package upstream.
>>
>>> This would also be a good opportunity to generalize the feature,
>>> so that
>>> instead of having `ns-share`, we would have a command named
>>> `share-file`
>>> or something like that.
>>
>> Without a Linux partner to help with the counter changes, I'm less
>> likely to take on the additional scope.
>>
>> I could also reach out to emacs-devel if you reckon it's
>> appropriate to scout Linux support.
>
> Asking Carl Lieberman might be a useful step. Asking on emacs-devel
> would also be useful, to see if other people have any comments.
kdeconnect.el doesn't implement any dialog to "share" a file but only
invokes KDEconnect CLI to share a file.
From what I know there's no direct share "Linux" (Linux in quotes
because the definition what Linux is isn't exact) or XDG API for sharing.
KDE has the Purpose API[1] as a generic API for interacting with
applications to e.g. provide a share API or open something in an
application. For example KDE Connect has a provider for this API which
allows to share with it similarly to it's CLI application.
How sharing is done in KDE can been here.[2]
GNOME doesn't have a Sharing API but there's an issue open about this
topic.[3]
Links:
[1] https://api.kde.org/frameworks/purpose/html/dir_b0f0133c8c657e97aec4f8e0dece5ee9.html
[2] https://userbase.kde.org/Tips/Transfer_files_between_phone_and_PC_using_Wi-Fi
[3] https://gitlab.gnome.org/Teams/Design/whiteboards/-/issues/118
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 01:59:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[திங்கள் பிப்ரவரி 10, 2025] Björn Bidar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>>>> Would you or anyone else be interested in implementing this for
>>>> GNU/Linux as well? I don't think we need perfect coverage of
>>>> all
>>>> desktop environments, but it would be useful to support it on
>>>> one or more
>>>> popular ones (for example Gnome or KDE).
>>>
>>> Skills-wise, I wouldn't be the best candidate to make the
>>> Linux-related changes. I could try reaching out to Carl Lieberman,
>>> author of https://github.com/carldotac/kdeconnect.el, to see if
>>> they'd be inclined to contribute their package upstream.
>>>
>>>> This would also be a good opportunity to generalize the feature,
>>>> so that
>>>> instead of having `ns-share`, we would have a command named
>>>> `share-file`
>>>> or something like that.
>>>
>>> Without a Linux partner to help with the counter changes, I'm less
>>> likely to take on the additional scope.
>>>
>>> I could also reach out to emacs-devel if you reckon it's
>>> appropriate to scout Linux support.
>>
>> Asking Carl Lieberman might be a useful step. Asking on emacs-devel
>> would also be useful, to see if other people have any comments.
>
> kdeconnect.el doesn't implement any dialog to "share" a file but only
> invokes KDEconnect CLI to share a file.
Personally, I think we might be better served by using the dbus
interface directly. I have the attached in my init file which could be
a reference. Of course, as you point out, there's no share to other
applications; only to devices.
[Message part 2 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 02:03:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[திங்கள் பிப்ரவரி 10, 2025] Björn Bidar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>>>> Would you or anyone else be interested in implementing this for
>>>> GNU/Linux as well? I don't think we need perfect coverage of
>>>> all
>>>> desktop environments, but it would be useful to support it on
>>>> one or more
>>>> popular ones (for example Gnome or KDE).
>>>
>>> Skills-wise, I wouldn't be the best candidate to make the
>>> Linux-related changes. I could try reaching out to Carl Lieberman,
>>> author of https://github.com/carldotac/kdeconnect.el, to see if
>>> they'd be inclined to contribute their package upstream.
>>>
>>>> This would also be a good opportunity to generalize the feature,
>>>> so that
>>>> instead of having `ns-share`, we would have a command named
>>>> `share-file`
>>>> or something like that.
>>>
>>> Without a Linux partner to help with the counter changes, I'm less
>>> likely to take on the additional scope.
>>>
>>> I could also reach out to emacs-devel if you reckon it's
>>> appropriate to scout Linux support.
>>
>> Asking Carl Lieberman might be a useful step. Asking on emacs-devel
>> would also be useful, to see if other people have any comments.
>
> kdeconnect.el doesn't implement any dialog to "share" a file but only
> invokes KDEconnect CLI to share a file.
Personally, I think we might be better served by using the dbus
interface directly. I have the attached in my init file which could be
a reference. Of course, as you point out, there's no share to other
applications; only to devices.
[Message part 2 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 04:28:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Álvaro Ramírez <alvaro <at> xenodium.com> writes:
> Hi folks,
>
> Similar to the existing ns-do-show-character-palette command, this
> patch exposes a native macOS context dialog.
>
> The new addition enables users to share (send) text or files to other
> apps.
>
> Examples:
>
> - Send current buffer file.
> - Send a list of dired files.
> - Send region text.
>
> I'm keen to polish the patch a bit more, but wanted to pre-fly things
> before investing further.
>
> Overall it's a nice/convenient addition. I use it frequently to
> quickly send things to my phone over local network/Bluetooth.
>
> I'm attaching a couple of screenshots showcasing a couple of uses:
>
> share-dired-files.jpg (send files from dired)
> share-region-text.jpg (send region text)
>
> Hope you like it.
Thanks. No such functionality exists on Free operating systems, and
consequently we cannot accept such features, until such time as similar
file sharing facilities appear and become widely available in GNU/Linux.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 09:11:01 GMT)
Full text and
rfc822 format available.
Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):
Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:
> Álvaro Ramírez <alvaro <at> xenodium.com> writes:
>
>> Hi folks,
>>
>> Similar to the existing ns-do-show-character-palette command, this
>> patch exposes a native macOS context dialog.
>>
>> The new addition enables users to share (send) text or files to other
>> apps.
>>
>> Examples:
>>
>> - Send current buffer file.
>> - Send a list of dired files.
>> - Send region text.
>>
>> I'm keen to polish the patch a bit more, but wanted to pre-fly things
>> before investing further.
>>
>> Overall it's a nice/convenient addition. I use it frequently to
>> quickly send things to my phone over local network/Bluetooth.
>>
>> I'm attaching a couple of screenshots showcasing a couple of uses:
>>
>> share-dired-files.jpg (send files from dired)
>> share-region-text.jpg (send region text)
>>
>> Hope you like it.
>
> Thanks. No such functionality exists on Free operating systems, and
> consequently we cannot accept such features, until such time as similar
> file sharing facilities appear and become widely available in GNU/Linux.
Hmm, doesn't Android have this feature? I'm looking at
https://developer.android.com/training/sharing/send and it seems very
similar. Maybe Emacs should support this on Android?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 10:45:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
Hi,
> Personally, I think we might be better served by using the dbus
> interface directly. I have the attached in my init file which could be
> a reference. Of course, as you point out, there's no share to other
> applications; only to devices.
Yes, that's for KDE. Unfortunately, there doesn't seem to exist an
equivalent for Gnome.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 11:01:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 10 Feb 2025, at 10:44, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Visuwesh <visuweshm <at> gmail.com> writes:
>
> Hi,
>
>> Personally, I think we might be better served by using the dbus
>> interface directly. I have the attached in my init file which could be
>> a reference. Of course, as you point out, there's no share to other
>> applications; only to devices.
>
> Yes, that's for KDE. Unfortunately, there doesn't seem to exist an
> equivalent for Gnome.
Would something like this help? https://github.com/GSConnect/gnome-shell-extension-gsconnect
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 11:13:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[திங்கள் பிப்ரவரி 10, 2025] Michael Albinus wrote:
> Visuwesh <visuweshm <at> gmail.com> writes:
>
> Hi,
>
>> Personally, I think we might be better served by using the dbus
>> interface directly. I have the attached in my init file which could be
>> a reference. Of course, as you point out, there's no share to other
>> applications; only to devices.
>
> Yes, that's for KDE. Unfortunately, there doesn't seem to exist an
> equivalent for Gnome.
My memory is a bit vague but GSConnect (GNOME's equivalent of KDE
Connect) still talks to the kdeconnect server over DBus.
But maybe you meant something GNOME-specific (and not KDE Connect)?
> Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 12:52:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 9 Feb 2025 12:44:06 -0800
> Cc: alvaro <at> xenodium.com, 76120 <at> debbugs.gnu.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Stefan Kangas <stefankangas <at> gmail.com>
> >> Date: Sun, 9 Feb 2025 07:12:34 -0800
> >>
> >> According to our guidelines, we must have the same functionality on
> >> GNU/Linux before we can install it for a non-free system.[1] This is
> >> also documented in nextstep/README.
> >
> > What is the functionality in question? Toolkit dialogs are available
> > on all platforms, including GNU/Linux. Are you talking about special
> > features of those dialogs, or something else?
>
> I'm talking about the feature of "sharing" a file using such dialogs, as
> seen in the screenshots attached here:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76120#5
Isn't this what shell-command-do-open ("Open" in a context menu) does,
in conjunction with shell-command-guess-open? We also have
dired-context-menu, with similar functionality. E.g., the w32
implementation calls w32-shell-execute, which AFAIU is the equivalent
of the proposed functionality, but just for a single action "share".
All we need is to have this as part of the above functionalities, not
as a separate NS-specific idiosyncratic feature.
IOW, the way to implement this is to add the "share" (or maybe we
should call it "send to" or something similar) action to the context
menus we already have, and then each platform can implement that as it
sees fit. For example, on GNU/Linux desktops I'd expect xdg-open to
have that capability.
If the above doesn't make sense, then let me turn the table and ask:
how is this proposed functionality different from what the above
infrastructure already provides?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 13:15:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> Cc: 76120 <at> debbugs.gnu.org, Alvaro Ramirez <alvaro <at> xenodium.com>
> Date: Mon, 10 Feb 2025 02:17:42 +0200
> From: Björn Bidar via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
> >>> Would you or anyone else be interested in implementing this for
> >>> GNU/Linux as well? I don't think we need perfect coverage of
> >>> all
> >>> desktop environments, but it would be useful to support it on
> >>> one or more
> >>> popular ones (for example Gnome or KDE).
> >>
> >> Skills-wise, I wouldn't be the best candidate to make the
> >> Linux-related changes. I could try reaching out to Carl Lieberman,
> >> author of https://github.com/carldotac/kdeconnect.el, to see if
> >> they'd be inclined to contribute their package upstream.
> >>
> >>> This would also be a good opportunity to generalize the feature,
> >>> so that
> >>> instead of having `ns-share`, we would have a command named
> >>> `share-file`
> >>> or something like that.
> >>
> >> Without a Linux partner to help with the counter changes, I'm less
> >> likely to take on the additional scope.
> >>
> >> I could also reach out to emacs-devel if you reckon it's
> >> appropriate to scout Linux support.
> >
> > Asking Carl Lieberman might be a useful step. Asking on emacs-devel
> > would also be useful, to see if other people have any comments.
>
> kdeconnect.el doesn't implement any dialog to "share" a file but only
> invokes KDEconnect CLI to share a file.
>
> >From what I know there's no direct share "Linux" (Linux in quotes
> because the definition what Linux is isn't exact) or XDG API for sharing.
>
> KDE has the Purpose API[1] as a generic API for interacting with
> applications to e.g. provide a share API or open something in an
> application. For example KDE Connect has a provider for this API which
> allows to share with it similarly to it's CLI application.
>
> How sharing is done in KDE can been here.[2]
>
> GNOME doesn't have a Sharing API but there's an issue open about this
> topic.[3]
I think we should get our terminology right, because the "share"
business is replete with hype which muddies the waters. In
particular, quite a few "sharing" options are another word with "open
with", and we already have that (see my other message up-thread).
Examples:
. "sharing" with a printer means printing, which is the same as
"opening" by a printer
. "sharing" with an email program means sending as an email message,
which is the same as "opening" by a MUA
. "sharing" a selection of text is the same a drag-n-drop the text
onto an application
etc., etc. So what exactly is the "sharing" we are talking about
here? I very much hope that it doesn't just mean show a menu whose
caption says "Share with" (which would mean it's another hype)...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 13:23:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Sun, 9 Feb 2025 12:44:06 -0800
>> Cc: alvaro <at> xenodium.com, 76120 <at> debbugs.gnu.org
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Stefan Kangas <stefankangas <at> gmail.com>
>> >> Date: Sun, 9 Feb 2025 07:12:34 -0800
>> >>
>> >> According to our guidelines, we must have the same functionality on
>> >> GNU/Linux before we can install it for a non-free system.[1] This is
>> >> also documented in nextstep/README.
>> >
>> > What is the functionality in question? Toolkit dialogs are available
>> > on all platforms, including GNU/Linux. Are you talking about special
>> > features of those dialogs, or something else?
>>
>> I'm talking about the feature of "sharing" a file using such dialogs, as
>> seen in the screenshots attached here:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76120#5
>
> Isn't this what shell-command-do-open ("Open" in a context menu) does,
> in conjunction with shell-command-guess-open? We also have
> dired-context-menu, with similar functionality. E.g., the w32
> implementation calls w32-shell-execute, which AFAIU is the equivalent
> of the proposed functionality, but just for a single action "share".
> All we need is to have this as part of the above functionalities, not
> as a separate NS-specific idiosyncratic feature.
>
> IOW, the way to implement this is to add the "share" (or maybe we
> should call it "send to" or something similar) action to the context
> menus we already have, and then each platform can implement that as it
> sees fit. For example, on GNU/Linux desktops I'd expect xdg-open to
> have that capability.
That makes sense to me, thanks. So maybe we should just add the
proposed functionality to our already-existing context menus on NS?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 14:10:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I think we should get our terminology right, because the "share"
> business is replete with hype which muddies the waters. In
> particular, quite a few "sharing" options are another word with
> "open
> with", and we already have that (see my other message
> up-thread).
> Examples:
>
> . "sharing" with a printer means printing, which is the same
> as
> "opening" by a printer
> . "sharing" with an email program means sending as an email
> message,
> which is the same as "opening" by a MUA
> . "sharing" a selection of text is the same a drag-n-drop the
> text
> onto an application
>
> etc., etc. So what exactly is the "sharing" we are talking
> about
> here? I very much hope that it doesn't just mean show a menu
> whose
> caption says "Share with" (which would mean it's another
> hype)...
Thanks for highlighting this Eli. "Sharing" is indeed an
overloaded term and can invite unrelated discussion.
What's available in this macOS dialog is a context menu of
sorts. It more or less aggregates "open with", "send to", or "drag
and drop" for external (non-Emacs) applications.
My initial integration approached things by enumerating available
context actions from the system and pipe through existing Emacs
infrastructure (context-menu-mode or completing-read). However,
this route is a dead end on macOS as the API is now deprecated
https://developer.apple.com/documentation/appkit/nssharingservice/sharingservices(foritems:)?language=objc
in favor of using the picker dialog
https://developer.apple.com/documentation/appkit/nssharingservicepicker?language=objc
which is included in the current proposal.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 14:18:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>
>> Isn't this what shell-command-do-open ("Open" in a context
>> menu) does,
>> in conjunction with shell-command-guess-open? We also have
>> dired-context-menu, with similar functionality. E.g., the w32
>> implementation calls w32-shell-execute, which AFAIU is the
>> equivalent
>> of the proposed functionality, but just for a single action
>> "share".
>> All we need is to have this as part of the above
>> functionalities, not
>> as a separate NS-specific idiosyncratic feature.
>>
>> IOW, the way to implement this is to add the "share" (or maybe
>> we
>> should call it "send to" or something similar) action to the
>> context
>> menus we already have, and then each platform can implement
>> that as it
>> sees fit. For example, on GNU/Linux desktops I'd expect
>> xdg-open to
>> have that capability.
>
> That makes sense to me, thanks. So maybe we should just add the
> proposed functionality to our already-existing context menus on
> NS?
Happy to modify the proposed patch to include an entry point in
the existing context menu if we reckon that's acceptable.
Keep in mind it would be just that: an entry point to open the
same dialog (ie. invoke ns-share somehow). I'm fine with it if you
are.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 14:20:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 10 Feb 2025 07:22:17 -0600
> Cc: alvaro <at> xenodium.com, 76120 <at> debbugs.gnu.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Stefan Kangas <stefankangas <at> gmail.com>
> >> Date: Sun, 9 Feb 2025 12:44:06 -0800
> >> Cc: alvaro <at> xenodium.com, 76120 <at> debbugs.gnu.org
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> >> From: Stefan Kangas <stefankangas <at> gmail.com>
> >> >> Date: Sun, 9 Feb 2025 07:12:34 -0800
> >> >>
> >> >> According to our guidelines, we must have the same functionality on
> >> >> GNU/Linux before we can install it for a non-free system.[1] This is
> >> >> also documented in nextstep/README.
> >> >
> >> > What is the functionality in question? Toolkit dialogs are available
> >> > on all platforms, including GNU/Linux. Are you talking about special
> >> > features of those dialogs, or something else?
> >>
> >> I'm talking about the feature of "sharing" a file using such dialogs, as
> >> seen in the screenshots attached here:
> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76120#5
> >
> > Isn't this what shell-command-do-open ("Open" in a context menu) does,
> > in conjunction with shell-command-guess-open? We also have
> > dired-context-menu, with similar functionality. E.g., the w32
> > implementation calls w32-shell-execute, which AFAIU is the equivalent
> > of the proposed functionality, but just for a single action "share".
> > All we need is to have this as part of the above functionalities, not
> > as a separate NS-specific idiosyncratic feature.
> >
> > IOW, the way to implement this is to add the "share" (or maybe we
> > should call it "send to" or something similar) action to the context
> > menus we already have, and then each platform can implement that as it
> > sees fit. For example, on GNU/Linux desktops I'd expect xdg-open to
> > have that capability.
>
> That makes sense to me, thanks. So maybe we should just add the
> proposed functionality to our already-existing context menus on NS?
That'd be my suggestion, yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 14:32:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
> stefankangas <at> gmail.com,
> 76120 <at> debbugs.gnu.org
> Date: Mon, 10 Feb 2025 14:09:35 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I think we should get our terminology right, because the "share"
> > business is replete with hype which muddies the waters. In
> > particular, quite a few "sharing" options are another word with
> > "open
> > with", and we already have that (see my other message
> > up-thread).
> > Examples:
> >
> > . "sharing" with a printer means printing, which is the same
> > as
> > "opening" by a printer
> > . "sharing" with an email program means sending as an email
> > message,
> > which is the same as "opening" by a MUA
> > . "sharing" a selection of text is the same a drag-n-drop the
> > text
> > onto an application
> >
> > etc., etc. So what exactly is the "sharing" we are talking
> > about
> > here? I very much hope that it doesn't just mean show a menu
> > whose
> > caption says "Share with" (which would mean it's another
> > hype)...
>
> Thanks for highlighting this Eli. "Sharing" is indeed an
> overloaded term and can invite unrelated discussion.
>
> What's available in this macOS dialog is a context menu of
> sorts. It more or less aggregates "open with", "send to", or "drag
> and drop" for external (non-Emacs) applications.
>
> My initial integration approached things by enumerating available
> context actions from the system and pipe through existing Emacs
> infrastructure (context-menu-mode or completing-read). However,
> this route is a dead end on macOS as the API is now deprecated
> https://developer.apple.com/documentation/appkit/nssharingservice/sharingservices(foritems:)?language=objc
> in favor of using the picker dialog
> https://developer.apple.com/documentation/appkit/nssharingservicepicker?language=objc
> which is included in the current proposal.
Does an application have any control which contacts are shown in this
dialog? If so, then I think you could make this dialog pop up as one
(system-specific) selections in the existing Emacs context menu, and
remove from the list the contacts that are already available in the
existing context menu. If the application cannot control that list, I
think it's very bad, because it would mean the same contact will
appear more than once under different names.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 14:48:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Mon, 10 Feb 2025 07:22:17 -0600
>> Cc: alvaro <at> xenodium.com, 76120 <at> debbugs.gnu.org
>>
>> That makes sense to me, thanks. So maybe we should just add the
>> proposed functionality to our already-existing context menus on NS?
>
> That'd be my suggestion, yes.
Álvaro, could you please rework your patch along these lines?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 15:15:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Does an application have any control which contacts are shown in
> this
> dialog?
Yep. There is some degree of configurability/filtering available
for this dialog, but we won't need it. Read on...
> If so, then I think you could make this dialog pop up as one
> (system-specific) selections in the existing Emacs context menu,
> and
> remove from the list the contacts that are already available in
> the
> existing context menu. If the application cannot control that
> list, I
> think it's very bad, because it would mean the same contact will
> appear more than once under different names.
I agree, this duplication would be bad, but it won't happen unless
someone submits a similar patch like mine introducing/exposing the
same macOS "sharing" actions elsewhere.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 15:30:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Stefan Kangas <stefankangas <at> gmail.com>
>>> Date: Mon, 10 Feb 2025 07:22:17 -0600
>>> Cc: alvaro <at> xenodium.com, 76120 <at> debbugs.gnu.org
>>>
>>> That makes sense to me, thanks. So maybe we should just add
>>> the
>>> proposed functionality to our already-existing context menus
>>> on NS?
>>
>> That'd be my suggestion, yes.
>
> Álvaro, could you please rework your patch along these lines?
Certainly! How about the following scope...
1. Add a "Share..." context menu item via context-menu-mode.
2. Make the "Share..." entry configurable (custom set to a
function).
3. The default function invokes xdg-open on GNU/Linux and ns-share
on macOS.
Sound OK?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 20:10:03 GMT)
Full text and
rfc822 format available.
Message #89 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Visuwesh <visuweshm <at> gmail.com> writes:
>
> Hi,
>
>> Personally, I think we might be better served by using the dbus
>> interface directly. I have the attached in my init file which could be
>> a reference. Of course, as you point out, there's no share to other
>> applications; only to devices.
>
> Yes, that's for KDE. Unfortunately, there doesn't seem to exist an
> equivalent for Gnome.
The kdeconnect server is the equivalent for all desktops. With GSConnect
you can use KDE Connect with GTK frontend.
Recreating kdeconnectd with GTK would only reinvent the wheel out of
NIH.
This entirely offtopic but is to highlight that the DBUS API is the
mostly neutral way of implementing the support.
The only downside is that it requires more legwork initially.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 20:25:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 76120 <at> debbugs.gnu.org (full text, mbox):
First of all Alvaro's explanation explains it quite well but I want to
add to it.
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: 76120 <at> debbugs.gnu.org, Alvaro Ramirez <alvaro <at> xenodium.com>
>> Date: Mon, 10 Feb 2025 02:17:42 +0200
>> From: Björn Bidar via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Stefan Kangas <stefankangas <at> gmail.com> writes:
>>
>> >>> Would you or anyone else be interested in implementing this for
>> >>> GNU/Linux as well? I don't think we need perfect coverage of
>> >>> all
>> >>> desktop environments, but it would be useful to support it on
>> >>> one or more
>> >>> popular ones (for example Gnome or KDE).
>> >>
>> >> Skills-wise, I wouldn't be the best candidate to make the
>> >> Linux-related changes. I could try reaching out to Carl Lieberman,
>> >> author of https://github.com/carldotac/kdeconnect.el, to see if
>> >> they'd be inclined to contribute their package upstream.
>> >>
>> >>> This would also be a good opportunity to generalize the feature,
>> >>> so that
>> >>> instead of having `ns-share`, we would have a command named
>> >>> `share-file`
>> >>> or something like that.
>> >>
>> >> Without a Linux partner to help with the counter changes, I'm less
>> >> likely to take on the additional scope.
>> >>
>> >> I could also reach out to emacs-devel if you reckon it's
>> >> appropriate to scout Linux support.
>> >
>> > Asking Carl Lieberman might be a useful step. Asking on emacs-devel
>> > would also be useful, to see if other people have any comments.
>>
>> kdeconnect.el doesn't implement any dialog to "share" a file but only
>> invokes KDEconnect CLI to share a file.
>>
>> >From what I know there's no direct share "Linux" (Linux in quotes
>> because the definition what Linux is isn't exact) or XDG API for sharing.
>>
>> KDE has the Purpose API[1] as a generic API for interacting with
>> applications to e.g. provide a share API or open something in an
>> application. For example KDE Connect has a provider for this API which
>> allows to share with it similarly to it's CLI application.
>>
>> How sharing is done in KDE can been here.[2]
>>
>> GNOME doesn't have a Sharing API but there's an issue open about this
>> topic.[3]
>
> I think we should get our terminology right, because the "share"
> business is replete with hype which muddies the waters. In
> particular, quite a few "sharing" options are another word with "open
> with", and we already have that (see my other message up-thread).
> Examples:
>
> . "sharing" with a printer means printing, which is the same as
> "opening" by a printer
> . "sharing" with an email program means sending as an email message,
> which is the same as "opening" by a MUA
In this context the MUA would be opened with the to be shared file
in a new message window, removing the step in between opening and
attaching the file.
More like a mailto: link rather than manually "opening".
> . "sharing" a selection of text is the same a drag-n-drop the text
> onto an application
It's the same but the program which is the direction would receive the
input prepared by the sending program e.g. any kind of content not just
text.
> etc., etc. So what exactly is the "sharing" we are talking about
> here? I very much hope that it doesn't just mean show a menu whose
> caption says "Share with" (which would mean it's another hype)...
Well it's certainly not another hype since a feature like it or similar
has been implemented across all major operating systems.
The point is that there's a direct interaction from the user in the
current program they use to programs offering methods of interaction so
kinda like open with but with a specific action in mind.
E.g. instead of print menu there's a menu to show various actions
such as printing or forwarding the file. The purpose is that such action
are in central location instead of a button for every specific action
specific to each program.
Kinda like you can invoke org-capture anywhere in Emacs and go from
there but explicitly support by a program.
Since program is in control about what is shared to the action it can
also assemble the file in any preferred the user wants.
For example if the user wants to share an image it could cut and
downscale the image.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 20:57:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> From: Stefan Kangas <stefankangas <at> gmail.com>
>>>> Date: Mon, 10 Feb 2025 07:22:17 -0600
>>>> Cc: alvaro <at> xenodium.com, 76120 <at> debbugs.gnu.org
>>>>
>>>> That makes sense to me, thanks. So maybe we should just add
>>>> the
>>>> proposed functionality to our already-existing context menus
>>>> on NS?
>>>
>>> That'd be my suggestion, yes.
>>
>> Álvaro, could you please rework your patch along these lines?
>
> Certainly! How about the following scope...
>
> 1. Add a "Share..." context menu item via context-menu-mode.
> 2. Make the "Share..." entry configurable (custom set to a
> function).
> 3. The default function invokes xdg-open on GNU/Linux and ns-share
> on macOS.
>
> Sound OK?
Can we make the "Share..." context menu item a submenu of the first one
on supported systems?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 22:09:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>> Certainly! How about the following scope...
>>
>> 1. Add a "Share..." context menu item via context-menu-mode.
>> 2. Make the "Share..." entry configurable (custom set to a
>> function).
>> 3. The default function invokes xdg-open on GNU/Linux and
>> ns-share
>> on macOS.
>>
>> Sound OK?
>
> Can we make the "Share..." context menu item a submenu of the
> first one
> on supported systems?
I think so, but to make sure I'm understanding correctly, it would
look something like either of the following options.
Btw, the other menu items I'm showing seem major-mode-dependent. I
just happen to include what I have for elisp-mode.
Option 1)
Root >
----------
| Paste
| Select and Paste >
| Select >
----------
| Go Back
| Go Forward
----------
| Go Back
| Go Forward
----------
| Share...
----------
Option 2)
Root >
----------
| Paste
| Select and Paste >
| Select >
----------
| Go Back
| Go Forward
----------
| Go Back
| Go Forward
----------
| Something new (not sure what to call yet)
---------- |
----------
| Share...
----------
If we mean 2), what do we call the new top level category? ;)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 10 Feb 2025 22:15:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> From: Stefan Kangas <stefankangas <at> gmail.com>
>>>> Date: Mon, 10 Feb 2025 07:22:17 -0600
>>>> Cc: alvaro <at> xenodium.com, 76120 <at> debbugs.gnu.org
>>>>
>>>> That makes sense to me, thanks. So maybe we should just add the
>>>> proposed functionality to our already-existing context menus on
>>>> NS?
>>>
>>> That'd be my suggestion, yes.
>>
>> Álvaro, could you please rework your patch along these lines?
>
> Certainly! How about the following scope...
>
> 1. Add a "Share..." context menu item via context-menu-mode.
> 2. Make the "Share..." entry configurable (custom set to a function).
> 3. The default function invokes xdg-open on GNU/Linux and ns-share on
> macOS.
>
> Sound OK?
Since xdg-open isn't the same as "sharing" doesn't that only circumvent
the policy to not add functionality that is only supported on non-free
platforms?
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Tue, 11 Feb 2025 07:13:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 08:04:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Björn Bidar <bjorn.bidar <at> thaodan.de> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> Stefan Kangas <stefankangas <at> gmail.com> writes:
>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>>>> From: Stefan Kangas <stefankangas <at> gmail.com>
>>>>> Date: Mon, 10 Feb 2025 07:22:17 -0600
>>>>> Cc: alvaro <at> xenodium.com, 76120 <at> debbugs.gnu.org
>>>>>
>>>>> That makes sense to me, thanks. So maybe we should just add
>>>>> the
>>>>> proposed functionality to our already-existing context menus
>>>>> on
>>>>> NS?
>>>>
>>>> That'd be my suggestion, yes.
>>>
>>> Álvaro, could you please rework your patch along these lines?
>>
>> Certainly! How about the following scope...
>>
>> 1. Add a "Share..." context menu item via context-menu-mode.
>> 2. Make the "Share..." entry configurable (custom set to a
>> function).
>> 3. The default function invokes xdg-open on GNU/Linux and
>> ns-share on
>> macOS.
>>
>> Sound OK?
>
> Since xdg-open isn't the same as "sharing" doesn't that only
> circumvent
> the policy to not add functionality that is only supported on
> non-free
> platforms?
Ah, not in a position to answer questions about policy.
As the person submitting the contribution, I based the proposal on
Stefan and Eli's feedback. I'm seeking confirmation to ensure I'm
interpreting their suggestion correctly.
That said, please check the latest proposal (there was one more
iteration) https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76120#98
after Stefan requested a tweak.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 12:19:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com
> Date: Mon, 10 Feb 2025 22:23:51 +0200
>
> > . "sharing" with a printer means printing, which is the same as
> > "opening" by a printer
> > . "sharing" with an email program means sending as an email message,
> > which is the same as "opening" by a MUA
>
> In this context the MUA would be opened with the to be shared file
> in a new message window, removing the step in between opening and
> attaching the file.
> More like a mailto: link rather than manually "opening".
I think you interpret "open" too literally. In this case it is just a
verb; in particular, it does NOT mean just starting the program. It
means telling the program to do its thing with the stuff that Emacs
submits to it.
> > . "sharing" a selection of text is the same a drag-n-drop the text
> > onto an application
>
> It's the same but the program which is the direction would receive the
> input prepared by the sending program e.g. any kind of content not just
> text.
I was responding to the images posted, where the selection was plain
text. I realize that it's an example, but so are my examples.
> > etc., etc. So what exactly is the "sharing" we are talking about
> > here? I very much hope that it doesn't just mean show a menu whose
> > caption says "Share with" (which would mean it's another hype)...
>
> Well it's certainly not another hype since a feature like it or similar
> has been implemented across all major operating systems.
(We just saw that GNU/Linux doesn't really implement it yet...)
> The point is that there's a direct interaction from the user in the
> current program they use to programs offering methods of interaction so
> kinda like open with but with a specific action in mind.
That's the same idea that is behind shell-command-do-open.
> E.g. instead of print menu there's a menu to show various actions
> such as printing or forwarding the file. The purpose is that such action
> are in central location instead of a button for every specific action
> specific to each program.
I didn't say anything about separate buttons. We also have this in a
central location: the context menu.
So I still don't see the difference, except in terminology.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 12:45:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76120 <at> debbugs.gnu.org, Eli
> Zaretskii <eliz <at> gnu.org>
> Date: Tue, 11 Feb 2025 00:14:22 +0200
>
> Since xdg-open isn't the same as "sharing" doesn't that only circumvent
> the policy to not add functionality that is only supported on non-free
> platforms?
After all the discussions we had about the meaning of "sharing" in
this case, what exactly makes you say xdg-open etc. are not equivalent
to this "sharing"? just the fact that xdg-open doesn't have an option
called literally "share", or something else?
IOW, would you please describe the general functionality that the
proposed "sharing" offers and xdg-open doesn't?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 13:29:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: 76120 <at> debbugs.gnu.org
> Date: Tue, 11 Feb 2025 08:03:18 +0000
>
> Björn Bidar <bjorn.bidar <at> thaodan.de> writes:
>
> > Since xdg-open isn't the same as "sharing" doesn't that only
> > circumvent
> > the policy to not add functionality that is only supported on
> > non-free
> > platforms?
>
> Ah, not in a position to answer questions about policy.
>
> As the person submitting the contribution, I based the proposal on
> Stefan and Eli's feedback. I'm seeking confirmation to ensure I'm
> interpreting their suggestion correctly.
You are.
One thing you can be certain of: we are not going to circumvent our
own policies!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 14:56:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[செவ்வாய் பிப்ரவரி 11, 2025] Eli Zaretskii wrote:
>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76120 <at> debbugs.gnu.org, Eli
>> Zaretskii <eliz <at> gnu.org>
>> Date: Tue, 11 Feb 2025 00:14:22 +0200
>>
>> Since xdg-open isn't the same as "sharing" doesn't that only circumvent
>> the policy to not add functionality that is only supported on non-free
>> platforms?
>
> After all the discussions we had about the meaning of "sharing" in
> this case, what exactly makes you say xdg-open etc. are not equivalent
> to this "sharing"? just the fact that xdg-open doesn't have an option
> called literally "share", or something else?
>
> IOW, would you please describe the general functionality that the
> proposed "sharing" offers and xdg-open doesn't?
xdg-open simply opens the given file in the most suitable application
(if you ask me how it is determined, I can only tell it is dark arts).
So, `xdg-open ~/somepdf.pdf' will open the file in a PDF reader,
`xdg-open ~/img.png' will open it in an image viewer, etc. However, I
see an "Airdrop" option in the MacOS's share menu which AFAIK/U is akin
to "Share to device" which xdg-open cannot do. For this, we need to
rely on KDE Connect or something similar for which Emacs does not have
support for OOTB.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 15:31:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
> 76120 <at> debbugs.gnu.org,
> alvaro <at> xenodium.com, stefankangas <at> gmail.com
> Date: Tue, 11 Feb 2025 20:25:35 +0530
>
> [செவ்வாய் பிப்ரவரி 11, 2025] Eli Zaretskii wrote:
>
> >> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> >> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76120 <at> debbugs.gnu.org, Eli
> >> Zaretskii <eliz <at> gnu.org>
> >> Date: Tue, 11 Feb 2025 00:14:22 +0200
> >>
> >> Since xdg-open isn't the same as "sharing" doesn't that only circumvent
> >> the policy to not add functionality that is only supported on non-free
> >> platforms?
> >
> > After all the discussions we had about the meaning of "sharing" in
> > this case, what exactly makes you say xdg-open etc. are not equivalent
> > to this "sharing"? just the fact that xdg-open doesn't have an option
> > called literally "share", or something else?
> >
> > IOW, would you please describe the general functionality that the
> > proposed "sharing" offers and xdg-open doesn't?
>
> xdg-open simply opens the given file in the most suitable application
> (if you ask me how it is determined, I can only tell it is dark arts).
> So, `xdg-open ~/somepdf.pdf' will open the file in a PDF reader,
That's "sharing" the file with that program.
> `xdg-open ~/img.png' will open it in an image viewer, etc.
That'd be "sharing" the image with the viewer.
> However, I
> see an "Airdrop" option in the MacOS's share menu which AFAIK/U is akin
> to "Share to device" which xdg-open cannot do. For this, we need to
> rely on KDE Connect or something similar for which Emacs does not have
> support for OOTB.
Every platform has specialized "sharing target" that other platforms
don't. That doesn't mean there's some functionality here that is
specific to macOS.
Moreover, our shell-command-do-open and other similar features,
especially when accessed from a context menu, provide more
possibilities than just xdg-open, see the "Guess shell command"
portion of dired-aux.el. They are also extensible.
So I see absolutely no problem with adding a "share" menu to these
existing capabilities.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 15:46:01 GMT)
Full text and
rfc822 format available.
Message #124 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Can we make the "Share..." context menu item a submenu of the
>> first one
>> on supported systems?
>
> I think so, but to make sure I'm understanding correctly, it would
> look something like either of the following options.
>
> Btw, the other menu items I'm showing seem major-mode-dependent. I
> just happen to include what I have for elisp-mode.
>
> Option 1)
>
> Root >
> ----------
> | Paste
> | Select and Paste >
> | Select >
> ----------
> | Go Back
> | Go Forward
> ----------
> | Go Back
> | Go Forward
> ----------
> | Share...
> ----------
>
> Option 2)
>
> Root >
> ----------
> | Paste
> | Select and Paste >
> | Select >
> ----------
> | Go Back
> | Go Forward
> ----------
> | Go Back
> | Go Forward
> ----------
> | Something new (not sure what to call yet)
> ---------- |
> ----------
> | Share...
> ----------
>
> If we mean 2), what do we call the new top level category? ;)
I was thinking something along these lines instead:
Option 3)
Root >
----------
| Paste
| Select and Paste >
| Select >
----------
| Go Back
| Go Forward
----------
| Go Back
| Go Forward
----------
| Share...
----------|
----------
| Mail
| AirDrop
| etc.
----------
If that's not possible, I think option 1 is probably best.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 15:47:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[செவ்வாய் பிப்ரவரி 11, 2025] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
>> 76120 <at> debbugs.gnu.org,
>> alvaro <at> xenodium.com, stefankangas <at> gmail.com
>> Date: Tue, 11 Feb 2025 20:25:35 +0530
>>
>> [செவ்வாய் பிப்ரவரி 11, 2025] Eli Zaretskii wrote:
>>
>> >> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> >> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76120 <at> debbugs.gnu.org, Eli
>> >> Zaretskii <eliz <at> gnu.org>
>> >> Date: Tue, 11 Feb 2025 00:14:22 +0200
>> >>
>> >> Since xdg-open isn't the same as "sharing" doesn't that only circumvent
>> >> the policy to not add functionality that is only supported on non-free
>> >> platforms?
>> >
>> > After all the discussions we had about the meaning of "sharing" in
>> > this case, what exactly makes you say xdg-open etc. are not equivalent
>> > to this "sharing"? just the fact that xdg-open doesn't have an option
>> > called literally "share", or something else?
>> >
>> > IOW, would you please describe the general functionality that the
>> > proposed "sharing" offers and xdg-open doesn't?
>>
>> xdg-open simply opens the given file in the most suitable application
>> (if you ask me how it is determined, I can only tell it is dark arts).
>> So, `xdg-open ~/somepdf.pdf' will open the file in a PDF reader,
>
> That's "sharing" the file with that program.
>
>> `xdg-open ~/img.png' will open it in an image viewer, etc.
>
> That'd be "sharing" the image with the viewer.
>
>> However, I
>> see an "Airdrop" option in the MacOS's share menu which AFAIK/U is akin
>> to "Share to device" which xdg-open cannot do. For this, we need to
>> rely on KDE Connect or something similar for which Emacs does not have
>> support for OOTB.
>
> Every platform has specialized "sharing target" that other platforms
> don't. That doesn't mean there's some functionality here that is
> specific to macOS.
So what you're getting at is "share" is an overloaded term that has no
specific meaning, right?
> Moreover, our shell-command-do-open and other similar features,
> especially when accessed from a context menu, provide more
> possibilities than just xdg-open, see the "Guess shell command"
> portion of dired-aux.el. They are also extensible.
>
> So I see absolutely no problem with adding a "share" menu to these
> existing capabilities.
I have no strong opinions here so I will agree with your decision
regardless.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 15:54:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: bjorn.bidar <at> thaodan.de, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com,
> stefankangas <at> gmail.com
> Date: Tue, 11 Feb 2025 21:16:45 +0530
>
> [செவ்வாய் பிப்ரவரி 11, 2025] Eli Zaretskii wrote:
>
> >> xdg-open simply opens the given file in the most suitable application
> >> (if you ask me how it is determined, I can only tell it is dark arts).
> >> So, `xdg-open ~/somepdf.pdf' will open the file in a PDF reader,
> >
> > That's "sharing" the file with that program.
> >
> >> `xdg-open ~/img.png' will open it in an image viewer, etc.
> >
> > That'd be "sharing" the image with the viewer.
> >
> >> However, I
> >> see an "Airdrop" option in the MacOS's share menu which AFAIK/U is akin
> >> to "Share to device" which xdg-open cannot do. For this, we need to
> >> rely on KDE Connect or something similar for which Emacs does not have
> >> support for OOTB.
> >
> > Every platform has specialized "sharing target" that other platforms
> > don't. That doesn't mean there's some functionality here that is
> > specific to macOS.
>
> So what you're getting at is "share" is an overloaded term that has no
> specific meaning, right?
Yes. It basically means submitting a file or a text selection
or... to the relevant applications and services, and asking them "to
do their thing". Which is what our features already do, using the
capabilities provided by the target platforms. This is just an
addition to the menu, which happens to be specific to macOS, but
nothing more special as these features go.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 16:35:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com
>> Date: Mon, 10 Feb 2025 22:23:51 +0200
>>
>> > . "sharing" with a printer means printing, which is the same as
>> > "opening" by a printer
>> > . "sharing" with an email program means sending as an email message,
>> > which is the same as "opening" by a MUA
>>
>> In this context the MUA would be opened with the to be shared file
>> in a new message window, removing the step in between opening and
>> attaching the file.
>> More like a mailto: link rather than manually "opening".
>
> I think you interpret "open" too literally. In this case it is just a
> verb; in particular, it does NOT mean just starting the program. It
> means telling the program to do its thing with the stuff that Emacs
> submits to it.
You seam to misunderstand me: If the program is started or doesn't
matter the point is that the interaction with the program to pass an
item to the program is curated between the programs. The programs in the
share menu offer predefined dialogues and actions which can be selected
by the user to interact with the file.
>> > . "sharing" a selection of text is the same a drag-n-drop the text
>> > onto an application
>>
>> It's the same but the program which is the direction would receive the
>> input prepared by the sending program e.g. any kind of content not just
>> text.
>
> I was responding to the images posted, where the selection was plain
> text. I realize that it's an example, but so are my examples.
>
>> > etc., etc. So what exactly is the "sharing" we are talking about
>> > here? I very much hope that it doesn't just mean show a menu whose
>> > caption says "Share with" (which would mean it's another hype)...
>>
>> Well it's certainly not another hype since a feature like it or similar
>> has been implemented across all major operating systems.
>
> (We just saw that GNU/Linux doesn't really implement it yet...)
I should have written desktop operating system but none the less Linux
isn't one unified platform. KDE has implemented the feature so KDE based
Linux distributions or those hat offer KDE could fit into that category.
>> The point is that there's a direct interaction from the user in the
>> current program they use to programs offering methods of interaction so
>> kinda like open with but with a specific action in mind.
>
> That's the same idea that is behind shell-command-do-open.
>> E.g. instead of print menu there's a menu to show various actions
>> such as printing or forwarding the file. The purpose is that such action
>> are in central location instead of a button for every specific action
>> specific to each program.
>
> I didn't say anything about separate buttons. We also have this in a
> central location: the context menu.
>
> So I still don't see the difference, except in terminology.
Please look at the link I posted a few mails eariler but KDE's Purpose
framework.
It contains a link with a few example screenshots, I added the link to
this mail too.
You can see that in the third screenshot from the top that in the
context menu there is an item called "Share".
The items are not static, each item in the list is populated by the
underlying framework, in this case KDE's Purpose, to fit the current
context.
Each share option has to accept the file or uri type of the current
context, the URI type matters for link sharing.
A share option could be open file in a program with a specific dialog or
an action such as upload file, paste to clipboard or send to device via
technology such as Bluetooth or app.
For the latter case a dialog to select the target device would open.
In contrast the regular context menu is mostly static and specific to
each application. E.g. to achieve the same feature using a context menu
without a share framework each item in the menu would have to be added
explicitly by Emacs for each platform.
[1] https://userbase.kde.org/Tips/Transfer_files_between_phone_and_PC_using_Wi-Fi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 17:15:01 GMT)
Full text and
rfc822 format available.
Message #136 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76120 <at> debbugs.gnu.org, Eli
>> Zaretskii <eliz <at> gnu.org>
>> Date: Tue, 11 Feb 2025 00:14:22 +0200
>>
>> Since xdg-open isn't the same as "sharing" doesn't that only circumvent
>> the policy to not add functionality that is only supported on non-free
>> platforms?
>
> After all the discussions we had about the meaning of "sharing" in
> this case, what exactly makes you say xdg-open etc. are not equivalent
> to this "sharing"? just the fact that xdg-open doesn't have an option
> called literally "share", or something else?
xdg-open doesn't provide a list but opens the file in the default
program associated by the active desktop environment or a fallback if
existing.
xdg-open is like using Emacs's mailcap support.
> IOW, would you please describe the general functionality that the
> proposed "sharing" offers and xdg-open doesn't?
Sharing offers a list of specific action available to all program
using the framework e.g.
- Share using app, opens a dialog of the app to select the target
where the file is supposed to go and in case the user confirms the
target the file is send of, the dialog is closed.
The specific application isn't opened at all or only exist as this
sharing dialog or other desktop widgets with an application window in
the classical sense.
- Send file using Bluetooth. Very similar to the example above except
that the platforms or desktop environments Bluetooth Ui's file share
dialog opens.
These two are not possible in xdg-open at all even if it would contain a
list of specific applications to choose from.
The reason is that these dialogues are not regular applications which
accept specific types but either only available over a context-menu
using the platform API (i.e. gtk) or can called using a desktop file but
the file is hidden unless explicitly invoked.
For Bluetooth it should be possible to invoke the specific send-file
dialogues if they are available as separate applications.
For example for Bluedevul what would be 'bluedevil-sendfile'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 17:23:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for clarifying Stefan
Stefan Kangas <stefankangas <at> gmail.com>writes:
> I was thinking something along these lines instead:
>
> Option 3)
>
> Root >
> ----------
> | Paste
> | Select and Paste >
> | Select >
> ----------
> | Go Back
> | Go Forward
> ----------
> | Go Back
> | Go Forward
> ----------
> | Share...
> ----------|
> ----------
> | Mail
> | AirDrop
> | etc.
> ----------
>
> If that's not possible, I think option 1 is probably best.
Sounds good.
The sharing submenu would have to be the native dialog itself
unless we use a deprecated macOS API to populate the context menu
ourselves. If possible, I'd like to avoid using the deprecated
API. See the attached sharing.png screenshot for what the
experience would look like in practice.
If this approach is acceptable, I'll go ahead and rework the patch
to achieve this experience. Lemme know.
[sharing.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 17:28:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
>> 76120 <at> debbugs.gnu.org,
>> alvaro <at> xenodium.com, stefankangas <at> gmail.com
>> Date: Tue, 11 Feb 2025 20:25:35 +0530
>>
>> [செவ்வாய் பிப்ரவரி 11, 2025] Eli Zaretskii wrote:
>>
>> >> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> >> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76120 <at> debbugs.gnu.org, Eli
>> >> Zaretskii <eliz <at> gnu.org>
>> >> Date: Tue, 11 Feb 2025 00:14:22 +0200
>> >>
>> >> Since xdg-open isn't the same as "sharing" doesn't that only circumvent
>> >> the policy to not add functionality that is only supported on non-free
>> >> platforms?
>> >
>> > After all the discussions we had about the meaning of "sharing" in
>> > this case, what exactly makes you say xdg-open etc. are not equivalent
>> > to this "sharing"? just the fact that xdg-open doesn't have an option
>> > called literally "share", or something else?
>> >
>> > IOW, would you please describe the general functionality that the
>> > proposed "sharing" offers and xdg-open doesn't?
>>
>> xdg-open simply opens the given file in the most suitable application
>> (if you ask me how it is determined, I can only tell it is dark arts).
>> So, `xdg-open ~/somepdf.pdf' will open the file in a PDF reader,
>
> That's "sharing" the file with that program.
>
>> `xdg-open ~/img.png' will open it in an image viewer, etc.
>
> That'd be "sharing" the image with the viewer.
No that's not the same that's opening it. Sharing in this context would
mean to send the file or specific parts of the current thing that the
user does such as an exerb of the current conversation that the user
has.
The Android developer documentation explains this quite well[1]:
> Android uses intents and their associated extras to let users share information quickly and easily using their favorite apps.
> Android provides two ways for users to share data between apps:
> The Android Sharesheet is primarily designed for sending content outside
> your app and/or directly to another user.
> For example, sharing a URL with a friend. The Android intent resolver is
> best suited for passing data to the next stage of a well-defined task.
> For example, opening a PDF from your app and letting users pick their
> preferred viewer.
The latter example is actually very similar to the open-with dialogues
in most desktop environments however the other examples are still
different.
The Android developer documentation is Android specific but explains the
general purpose of this kind of feature as all platforms follow the same
paradigm.
The Apple documentation goes deeper into the UX part of the topic but
the intention is the same. [2]
Please read some of the documentation (I linked now and earlier) to understand this type of feature
better, it is not the same open-with it can do much more.
>
>> However, I
>> see an "Airdrop" option in the MacOS's share menu which AFAIK/U is akin
>> to "Share to device" which xdg-open cannot do. For this, we need to
>> rely on KDE Connect or something similar for which Emacs does not have
>> support for OOTB.
>
> Every platform has specialized "sharing target" that other platforms
> don't. That doesn't mean there's some functionality here that is
> specific to macOS.
>
> Moreover, our shell-command-do-open and other similar features,
> especially when accessed from a context menu, provide more
> possibilities than just xdg-open, see the "Guess shell command"
> portion of dired-aux.el. They are also extensible.
The difference is that the point of this patch is to invoke the platform
specific sharing dialog and not relay on Emacs to decide how to interact
with the file
And also as said now multiple times, the sharing dialogues do more than
just open the file but to somehow send it using a program, using
bluetooth, upload or whatever this not what any of the examples you have
do.
[1] https://developer.android.com/training/sharing/send
[2] https://developer.apple.com/design/human-interface-guidelines/collaboration-and-sharing
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 18:03:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com
> Date: Tue, 11 Feb 2025 18:34:13 +0200
>
> > So I still don't see the difference, except in terminology.
>
> Please look at the link I posted a few mails eariler but KDE's Purpose
> framework.
> It contains a link with a few example screenshots, I added the link to
> this mail too.
>
> You can see that in the third screenshot from the top that in the
> context menu there is an item called "Share".
>
> The items are not static, each item in the list is populated by the
> underlying framework, in this case KDE's Purpose, to fit the current
> context.
> Each share option has to accept the file or uri type of the current
> context, the URI type matters for link sharing.
>
> A share option could be open file in a program with a specific dialog or
> an action such as upload file, paste to clipboard or send to device via
> technology such as Bluetooth or app.
> For the latter case a dialog to select the target device would open.
>
> In contrast the regular context menu is mostly static and specific to
> each application. E.g. to achieve the same feature using a context menu
> without a share framework each item in the menu would have to be added
> explicitly by Emacs for each platform.
No, the context menu is not static. For example, in the case of
Dired, it depends on the type of the file on which the user clicks.
So we have this functionality, we just didn't call it "share".
And if you still disagree, then let's agree to disagree, because we
already repeat ourselves.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 18:14:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: alvaro <at> xenodium.com, stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org
> Date: Tue, 11 Feb 2025 19:14:30 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > IOW, would you please describe the general functionality that the
> > proposed "sharing" offers and xdg-open doesn't?
>
> Sharing offers a list of specific action available to all program
> using the framework e.g.
>
> - Share using app, opens a dialog of the app to select the target
> where the file is supposed to go and in case the user confirms the
> target the file is send of, the dialog is closed.
> The specific application isn't opened at all or only exist as this
> sharing dialog or other desktop widgets with an application window in
> the classical sense.
>
> - Send file using Bluetooth. Very similar to the example above except
> that the platforms or desktop environments Bluetooth Ui's file share
> dialog opens.
>
> These two are not possible in xdg-open at all even if it would contain a
> list of specific applications to choose from.
Sending a file via a communication channel can be done in Emacs
without xdg-open. Our context menu already includes items that are
not necessarily xdg-open (and users can extend that).
And what an application does when some object is "shared" with it
depends on the application and the object; opening a dialog is not
necessary, and in many cases there's no dialog at all.
More importantly, these capabilities are not special in any way, they
are just brought together under the umbrella of "sharing", but each
capability is simple and most of them are already available in Emacs.
Which application or communications channel is used is immaterial for
the purposes of this particular discussion.
So this argument that adding "share" somehow adds something on macOS
features that are not available elsewhere is simply wrong.
Again, if you disagree, let's leave it at that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 18:35:01 GMT)
Full text and
rfc822 format available.
Message #151 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> The sharing submenu would have to be the native dialog itself
> unless we use a deprecated macOS API to populate the context menu
> ourselves. If possible, I'd like to avoid using the deprecated
> API. See the attached sharing.png screenshot for what the
> experience would look like in practice.
>
> If this approach is acceptable, I'll go ahead and rework the patch
> to achieve this experience. Lemme know.
Your approach sounds good, and I agree that we should better avoid using
the deprecated API.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 19:46:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: alvaro <at> xenodium.com, stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org
>> Date: Tue, 11 Feb 2025 19:14:30 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > IOW, would you please describe the general functionality that the
>> > proposed "sharing" offers and xdg-open doesn't?
>>
>> Sharing offers a list of specific action available to all program
>> using the framework e.g.
>>
>> - Share using app, opens a dialog of the app to select the target
>> where the file is supposed to go and in case the user confirms the
>> target the file is send of, the dialog is closed.
>> The specific application isn't opened at all or only exist as this
>> sharing dialog or other desktop widgets with an application window in
>> the classical sense.
>>
>> - Send file using Bluetooth. Very similar to the example above except
>> that the platforms or desktop environments Bluetooth Ui's file share
>> dialog opens.
>>
>> These two are not possible in xdg-open at all even if it would contain a
>> list of specific applications to choose from.
>
> Sending a file via a communication channel can be done in Emacs
> without xdg-open. Our context menu already includes items that are
> not necessarily xdg-open (and users can extend that).
> And what an application does when some object is "shared" with it
> depends on the application and the object; opening a dialog is not
> necessary, and in many cases there's no dialog at all.
>
> More importantly, these capabilities are not special in any way, they
> are just brought together under the umbrella of "sharing", but each
> capability is simple and most of them are already available in Emacs.
> Which application or communications channel is used is immaterial for
> the purposes of this particular discussion.
Sure but the functionaity provided by Apple share API talks to the
operating system to pupulate the menu which isn't possible right now
on Linux outside of using the KDE Purpose API. The point is the
operating system integration which only would be available for macOS.
> So this argument that adding "share" somehow adds something on macOS
> features that are not available elsewhere is simply wrong.
If only want to add equivalent features why not add a menu entry which
uses xdg-open on Linux and open(1) on macOS? The open shell command on
macOS is the 100% equivalent to xdg-open on Linux.
https://ss64.com/mac/open.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 20:09:01 GMT)
Full text and
rfc822 format available.
Message #157 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: alvaro <at> xenodium.com, stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org
> Date: Tue, 11 Feb 2025 21:45:04 +0200
>
> If only want to add equivalent features why not add a menu entry which
> uses xdg-open on Linux and open(1) on macOS? The open shell command on
> macOS is the 100% equivalent to xdg-open on Linux.
We could do both. But please don't interpret "equivalent" too
literally.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 21:06:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> The sharing submenu would have to be the native dialog itself
>> unless we use a deprecated macOS API to populate the context
>> menu
>> ourselves. If possible, I'd like to avoid using the deprecated
>> API. See the attached sharing.png screenshot for what the
>> experience would look like in practice.
>>
>> If this approach is acceptable, I'll go ahead and rework the
>> patch
>> to achieve this experience. Lemme know.
>
> Your approach sounds good, and I agree that we should better
> avoid using
> the deprecated API.
Thanks for your patience and guidance here Stefan. Will go reshape
the patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 21:06:03 GMT)
Full text and
rfc822 format available.
Message #163 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: alvaro <at> xenodium.com, stefankangas <at> gmail.com,
>> 76120 <at> debbugs.gnu.org
>> Date: Tue, 11 Feb 2025 21:45:04 +0200
>>
>> If only want to add equivalent features why not add a menu
>> entry which
>> uses xdg-open on Linux and open(1) on macOS? The open shell
>> command on
>> macOS is the 100% equivalent to xdg-open on Linux.
>
> We could do both. But please don't interpret "equivalent" too
> literally.
Happy to help enable both. I shall cater for flexibility in the
patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 11 Feb 2025 21:49:02 GMT)
Full text and
rfc822 format available.
Message #166 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: alvaro <at> xenodium.com, stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org
>> Date: Tue, 11 Feb 2025 21:45:04 +0200
>>
>> If only want to add equivalent features why not add a menu entry which
>> uses xdg-open on Linux and open(1) on macOS? The open shell command on
>> macOS is the 100% equivalent to xdg-open on Linux.
>
> We could do both. But please don't interpret "equivalent" too
> literally.
I'm only interpreting it literally to the point that using the NS API
directly is an improvement over using xdg-open/open.
An improvement for a non-free platform.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 12 Feb 2025 13:16:02 GMT)
Full text and
rfc822 format available.
Message #169 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: alvaro <at> xenodium.com, stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org
> Date: Tue, 11 Feb 2025 23:48:42 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> >> Cc: alvaro <at> xenodium.com, stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org
> >> Date: Tue, 11 Feb 2025 21:45:04 +0200
> >>
> >> If only want to add equivalent features why not add a menu entry which
> >> uses xdg-open on Linux and open(1) on macOS? The open shell command on
> >> macOS is the 100% equivalent to xdg-open on Linux.
> >
> > We could do both. But please don't interpret "equivalent" too
> > literally.
>
> I'm only interpreting it literally to the point that using the NS API
> directly is an improvement over using xdg-open/open.
>
> An improvement for a non-free platform.
We do improve Emacs on non-free platforms, and this one is not an
improvement over free platforms (xdg-open/open is just part of the
feature).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 01:09:02 GMT)
Full text and
rfc822 format available.
Message #172 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76120 <at> debbugs.gnu.org, Eli
>> Zaretskii <eliz <at> gnu.org>
>> Date: Tue, 11 Feb 2025 00:14:22 +0200
>>
>> Since xdg-open isn't the same as "sharing" doesn't that only circumvent
>> the policy to not add functionality that is only supported on non-free
>> platforms?
>
> After all the discussions we had about the meaning of "sharing" in
> this case, what exactly makes you say xdg-open etc. are not equivalent
> to this "sharing"? just the fact that xdg-open doesn't have an option
> called literally "share", or something else?
>
> IOW, would you please describe the general functionality that the
> proposed "sharing" offers and xdg-open doesn't?
I won't object to implementing Bluetooth "sharing", since a file can
easily be sent through e.g. blueman-sendto, but I will object to the
dialog proposed by the OP. Contrasting the facilities exposed by this
dialog with their GNU/Linux equivalents is beside the point of our
policy against features which place proprietary systems at an advantage,
because our object in doing so is to prevent the creation of any
material incentive in Emacs that might motivate users to install Mac OS,
not simply to guarantee that Emacs on Mac OS holds no advantage in raw
capabilities over Emacs on free systems. I say this dialog is certainly
such an incentive, as attested by the existence of this patch rather
than a patch adding aliases from xdg-open and blueman to AppleScript
workalikes. You and I may not be vain enough for such features to
influence our preferences as regards operating systems, but you cannot
deny that people exist whom they do influence.
What is more, half of the dialog is devoted to Apple's proprietary file
sharing protocol, AirDrop. Any person can see the folly in providing a
direct interface to a proprietary file sharing system in Emacs, never
mind such a file sharing system as is only available on one brand of
computer. And it breaks the GNUstep build, though that is the least of
our concerns.
Just my two cents.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 03:31:01 GMT)
Full text and
rfc822 format available.
Message #175 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> I won't object to implementing Bluetooth "sharing", since a file can
> easily be sent through e.g. blueman-sendto, but I will object to the
> dialog proposed by the OP. Contrasting the facilities exposed by this
> dialog with their GNU/Linux equivalents is beside the point of our
> policy against features which place proprietary systems at an advantage,
> because our object in doing so is to prevent the creation of any
> material incentive in Emacs that might motivate users to install Mac OS,
> not simply to guarantee that Emacs on Mac OS holds no advantage in raw
> capabilities over Emacs on free systems. I say this dialog is certainly
> such an incentive, as attested by the existence of this patch rather
> than a patch adding aliases from xdg-open and blueman to AppleScript
> workalikes. You and I may not be vain enough for such features to
> influence our preferences as regards operating systems, but you cannot
> deny that people exist whom they do influence.
>
> What is more, half of the dialog is devoted to Apple's proprietary file
> sharing protocol, AirDrop. Any person can see the folly in providing a
> direct interface to a proprietary file sharing system in Emacs, never
> mind such a file sharing system as is only available on one brand of
> computer. And it breaks the GNUstep build, though that is the least of
> our concerns.
>
> Just my two cents.
It also requires compiler extensions (lambdas) only implemented by
Clang.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 06:31:02 GMT)
Full text and
rfc822 format available.
Message #178 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>>> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76120 <at> debbugs.gnu.org, Eli
>>> Zaretskii <eliz <at> gnu.org>
>>> Date: Tue, 11 Feb 2025 00:14:22 +0200
>>>
>>> Since xdg-open isn't the same as "sharing" doesn't that only circumvent
>>> the policy to not add functionality that is only supported on non-free
>>> platforms?
>>
>> After all the discussions we had about the meaning of "sharing" in
>> this case, what exactly makes you say xdg-open etc. are not equivalent
>> to this "sharing"? just the fact that xdg-open doesn't have an option
>> called literally "share", or something else?
>>
>> IOW, would you please describe the general functionality that the
>> proposed "sharing" offers and xdg-open doesn't?
>
> I won't object to implementing Bluetooth "sharing", since a file can
> easily be sent through e.g. blueman-sendto, but I will object to the
> dialog proposed by the OP. Contrasting the facilities exposed by this
> dialog with their GNU/Linux equivalents is beside the point of our
> policy against features which place proprietary systems at an advantage,
> because our object in doing so is to prevent the creation of any
> material incentive in Emacs that might motivate users to install Mac OS,
> not simply to guarantee that Emacs on Mac OS holds no advantage in raw
> capabilities over Emacs on free systems. I say this dialog is certainly
> such an incentive, as attested by the existence of this patch rather
> than a patch adding aliases from xdg-open and blueman to AppleScript
> workalikes. You and I may not be vain enough for such features to
> influence our preferences as regards operating systems, but you cannot
> deny that people exist whom they do influence.
Thank you for putting so direct. You might have worded it much better
than me. Point being is also that all the sharing options prepulated by
the OS without the user having to do anything in all apps and Emacs,
including those offending of the proprietary entries, which isn't
possible anywhere. E.g. I couldn't just reuse all the option provided by
KDE in that dialog without some direct integration here.
> What is more, half of the dialog is devoted to Apple's proprietary file
> sharing protocol, AirDrop. Any person can see the folly in providing a
> direct interface to a proprietary file sharing system in Emacs, never
> mind such a file sharing system as is only available on one brand of
> computer.
Would it possible to disable AirDrop in this dialog?
> And it breaks the GNUstep build, though that is the least of
> our concerns.
Assuming till GNUStep would implement the API?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 07:46:02 GMT)
Full text and
rfc822 format available.
Message #181 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
> 76120 <at> debbugs.gnu.org,
> alvaro <at> xenodium.com, stefankangas <at> gmail.com
> Date: Thu, 13 Feb 2025 09:07:49 +0800
>
> I won't object to implementing Bluetooth "sharing", since a file can
> easily be sent through e.g. blueman-sendto, but I will object to the
> dialog proposed by the OP. Contrasting the facilities exposed by this
> dialog with their GNU/Linux equivalents is beside the point of our
> policy against features which place proprietary systems at an advantage,
> because our object in doing so is to prevent the creation of any
> material incentive in Emacs that might motivate users to install Mac OS,
> not simply to guarantee that Emacs on Mac OS holds no advantage in raw
> capabilities over Emacs on free systems. I say this dialog is certainly
> such an incentive, as attested by the existence of this patch rather
> than a patch adding aliases from xdg-open and blueman to AppleScript
> workalikes. You and I may not be vain enough for such features to
> influence our preferences as regards operating systems, but you cannot
> deny that people exist whom they do influence.
>
> What is more, half of the dialog is devoted to Apple's proprietary file
> sharing protocol, AirDrop. Any person can see the folly in providing a
> direct interface to a proprietary file sharing system in Emacs, never
> mind such a file sharing system as is only available on one brand of
> computer. And it breaks the GNUstep build, though that is the least of
> our concerns.
>
> Just my two cents.
Thanks, noted. I stand by my opinion that there's nothing here that's
against our policies.
The issues you mention are very minor and insignificant; if we start
judging changes by these intimate details, we will eventually conclude
that many features we use on non-Posix platforms should be thrown
away, and perhaps that Emacs cannot be reasonably usable on those
platforms at all. E.g., isn't using the system messages in a separate
thread to implement the input subsystem on MS-Windows also "direct
interface to proprietary mechanisms"? Or using SuspendThread and
ResumeThread to emulate Posix signal handling on Windows? Or even
interfacing with DPMI to allow Emacs run as a 32-bit process with
memory protection on top of 16-bit DOS that has no memory protection
at all?
Emacs's architecture and expectations from the underlying platform are
so Posix-centric that emulating them without resorting to proprietary
system-specific mechanisms is practically impossible. Anyone who
demands us to avoid such interfaces and mechanisms basically tells us
to stop supporting those systems in a way that makes Emacs useful and
its features reasonably portable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 08:00:02 GMT)
Full text and
rfc822 format available.
Message #184 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Contrasting the facilities exposed by this
> dialog with their GNU/Linux equivalents is beside the point of
> our
> policy against features which place proprietary systems at an
> advantage,
> because our object in doing so is to prevent the creation of any
> material incentive in Emacs that might motivate users to install
> Mac OS,
> not simply to guarantee that Emacs on Mac OS holds no advantage
> in raw
> capabilities over Emacs on free systems.
While I haven't tried it myself, there's OpenDrop
(https://github.com/seemoo-lab/opendrop) for anyone who may be
keen to use on GNU/Linux.
> And it breaks the GNUstep build, though that is the least of
> our concerns.
Ah, sorry. Fairly new to upstream contributions. I hadn't
considered GNUstep. Taking a closer look, it seems this can be
addressed by guarding under NS_IMPL_COCOA. Please correct me if
otherwise.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 08:01:04 GMT)
Full text and
rfc822 format available.
Message #187 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
> alvaro <at> xenodium.com,
> stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org
> Date: Thu, 13 Feb 2025 11:30:39 +0800
>
> Po Lu <luangruo <at> yahoo.com> writes:
>
> > I won't object to implementing Bluetooth "sharing", since a file can
> > easily be sent through e.g. blueman-sendto, but I will object to the
> > dialog proposed by the OP. Contrasting the facilities exposed by this
> > dialog with their GNU/Linux equivalents is beside the point of our
> > policy against features which place proprietary systems at an advantage,
> > because our object in doing so is to prevent the creation of any
> > material incentive in Emacs that might motivate users to install Mac OS,
> > not simply to guarantee that Emacs on Mac OS holds no advantage in raw
> > capabilities over Emacs on free systems. I say this dialog is certainly
> > such an incentive, as attested by the existence of this patch rather
> > than a patch adding aliases from xdg-open and blueman to AppleScript
> > workalikes. You and I may not be vain enough for such features to
> > influence our preferences as regards operating systems, but you cannot
> > deny that people exist whom they do influence.
> >
> > What is more, half of the dialog is devoted to Apple's proprietary file
> > sharing protocol, AirDrop. Any person can see the folly in providing a
> > direct interface to a proprietary file sharing system in Emacs, never
> > mind such a file sharing system as is only available on one brand of
> > computer. And it breaks the GNUstep build, though that is the least of
> > our concerns.
> >
> > Just my two cents.
>
> It also requires compiler extensions (lambdas) only implemented by
> Clang.
Last time I looked, the work to make the NS port to compile with GCC
was never finished, so we pretty much rely on Clang on that platform,
AFAIU.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 08:06:02 GMT)
Full text and
rfc822 format available.
Message #190 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> It also requires compiler extensions (lambdas) only implemented
> by
> Clang.
Seems like NS_IMPL_COCOA would also help here as it would imply
lambda availability. Having said that, this is just syntactic
sugar and not required for achieving the same result. I'm happy to
remove lambda usage from the patch if needed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 08:10:03 GMT)
Full text and
rfc822 format available.
Message #193 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76120 <at> debbugs.gnu.org,
> alvaro <at> xenodium.com, stefankangas <at> gmail.com
> Date: Thu, 13 Feb 2025 08:30:45 +0200
>
> Would it possible to disable AirDrop in this dialog?
It's possible, but I see no need to do it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 08:14:02 GMT)
Full text and
rfc822 format available.
Message #196 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> The issues you mention are very minor and insignificant; if we start
> judging changes by these intimate details, we will eventually conclude
> that many features we use on non-Posix platforms should be thrown
> away, and perhaps that Emacs cannot be reasonably usable on those
> platforms at all. E.g., isn't using the system messages in a separate
> thread to implement the input subsystem on MS-Windows also "direct
> interface to proprietary mechanisms"? Or using SuspendThread and
> ResumeThread to emulate Posix signal handling on Windows? Or even
> interfacing with DPMI to allow Emacs run as a 32-bit process with
> memory protection on top of 16-bit DOS that has no memory protection
> at all?
But we're not judging features by intimate details, and we won't have to
remove the MS-Windows or DJGPP ports, because they create no incentive
for users to migrate to MS-Windows or MS-DOS, in contrast to user-facing
amenities provided by the operating system's GUI. (In fact I've lately
discovered that it is FreeDOS where the Emacs port is most useful, and
that operating system is 100% Free Software.) We decide whether to
reject features by the probability that they will induce users to
another, proprietary, operating system. The fact that Emacs's GUI
backend executes in threads created by proprietary C runtime alone is
clearly not applicable to this criterion, but GUI file sharing
capabilities are. The rather when they amount to an endorsement of a
proprietary file sharing service.
> Emacs's architecture and expectations from the underlying platform are
> so Posix-centric that emulating them without resorting to proprietary
> system-specific mechanisms is practically impossible. Anyone who
> demands us to avoid such interfaces and mechanisms basically tells us
> to stop supporting those systems in a way that makes Emacs useful and
> its features reasonably portable.
Mac OS is a POSIX system, just as much as GNU/Linux, if not more. We
are speaking of user-visible productivity features provided by the GUI,
not internal porting details, and I find it difficult to accept that a
one-click interface to "cloud" file storage and to the iPhone Simulator
is fundamental to Emacs's architecture or way of life, as it were.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 08:16:01 GMT)
Full text and
rfc822 format available.
Message #199 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Po Lu <luangruo <at> yahoo.com> writes:
>
>> It also requires compiler extensions (lambdas) only implemented
>> by
>> Clang.
>
> Seems like NS_IMPL_COCOA would also help here as it would imply
> lambda availability. Having said that, this is just syntactic
> sugar and not required for achieving the same result. I'm happy to
> remove lambda usage from the patch if needed.
Let's stick to things we know to work also on GCC, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 08:17:02 GMT)
Full text and
rfc822 format available.
Message #202 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Ah, sorry. Fairly new to upstream contributions. I hadn't
> considered GNUstep. Taking a closer look, it seems this can be
> addressed by guarding under NS_IMPL_COCOA. Please correct me if
> otherwise.
No need to apologize. No one can know everything.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 08:20:02 GMT)
Full text and
rfc822 format available.
Message #205 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Last time I looked, the work to make the NS port to compile with GCC
> was never finished, so we pretty much rely on Clang on that platform,
> AFAIU.
As far as I'm aware (which I confess is not very substantial), the
default compiler on Mac OS X 10.6 is GCC. We continue to support this
system, and crucially GNUstep as well.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 08:25:02 GMT)
Full text and
rfc822 format available.
Message #208 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> While I haven't tried it myself, there's OpenDrop
> (https://github.com/seemoo-lab/opendrop) for anyone who may be keen to
> use on GNU/Linux.
Its README declares it to be a research project that is not fully
functional without certificates extracted from a running Apple system.
I don't think any one could argue with propriety that a partially
compatible and unmaintained research project is sufficient cause to
declare AirDrop a free protocol.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 08:50:01 GMT)
Full text and
rfc822 format available.
Message #211 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> Po Lu <luangruo <at> yahoo.com> writes:
>>
>>> It also requires compiler extensions (lambdas) only
>>> implemented
>>> by
>>> Clang.
>>
>> Seems like NS_IMPL_COCOA would also help here as it would imply
>> lambda availability. Having said that, this is just syntactic
>> sugar and not required for achieving the same result. I'm happy
>> to
>> remove lambda usage from the patch if needed.
>
> Let's stick to things we know to work also on GCC, thanks.
SGTM. Will remove lambda.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 09:01:01 GMT)
Full text and
rfc822 format available.
Message #214 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: bjorn.bidar <at> thaodan.de, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com,
> stefankangas <at> gmail.com
> Date: Thu, 13 Feb 2025 16:12:54 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> But we're not judging features by intimate details, and we won't have to
> remove the MS-Windows or DJGPP ports, because they create no incentive
> for users to migrate to MS-Windows or MS-DOS, in contrast to user-facing
> amenities provided by the operating system's GUI.
That's your opinion, and you are entitled to it. But it doesn't mean
it is universally true: how can we know what does and doesn't give
users incentives?
I'm having hard time to believe that seeing "Share" is such an
incentive.
> (In fact I've lately
> discovered that it is FreeDOS where the Emacs port is most useful, and
> that operating system is 100% Free Software.)
Try to count how many users of DJGPP Emacs actually do that on
FreeDOS.
> We decide whether to
> reject features by the probability that they will induce users to
> another, proprietary, operating system. The fact that Emacs's GUI
> backend executes in threads created by proprietary C runtime alone is
> clearly not applicable to this criterion, but GUI file sharing
> capabilities are. The rather when they amount to an endorsement of a
> proprietary file sharing service.
You are being subjective here because you want to make a point.
> > Emacs's architecture and expectations from the underlying platform are
> > so Posix-centric that emulating them without resorting to proprietary
> > system-specific mechanisms is practically impossible. Anyone who
> > demands us to avoid such interfaces and mechanisms basically tells us
> > to stop supporting those systems in a way that makes Emacs useful and
> > its features reasonably portable.
>
> Mac OS is a POSIX system, just as much as GNU/Linux, if not more.
Not in its GUI system.
> We are speaking of user-visible productivity features provided by
> the GUI, not internal porting details, and I find it difficult to
> accept that a one-click interface to "cloud" file storage and to the
> iPhone Simulator is fundamental to Emacs's architecture or way of
> life, as it were.
It is neither fundamental nor an incentive to migrate.
So let's drop this futile argument, okay? We have gobs of real work
on our hands.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 09:48:02 GMT)
Full text and
rfc822 format available.
Message #217 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: bjorn.bidar <at> thaodan.de, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com,
>> stefankangas <at> gmail.com
>> Date: Thu, 13 Feb 2025 16:12:54 +0800
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> But we're not judging features by intimate details, and we won't have to
>> remove the MS-Windows or DJGPP ports, because they create no incentive
>> for users to migrate to MS-Windows or MS-DOS, in contrast to user-facing
>> amenities provided by the operating system's GUI.
>
> That's your opinion, and you are entitled to it. But it doesn't mean
> it is universally true: how can we know what does and doesn't give
> users incentives?
>
> I'm having hard time to believe that seeing "Share" is such an
> incentive.
I'm sure you'll agree that it is much more plausible for this to be an
incentive than for a choice of thread library or DOS extender, which
makes not a whit of a difference in actually running Emacs. At any
rate, this sentiment is everywhere to be found in on-line Emacs forums
and chatrooms, and you need look no further than the popularity of the
Carbon Emacs port, which is integrated with the Mac OS dictionary, share
dialog, and animation framework. Minor frivolities such as this do play
an active role in enticing users to proprietary operating systems, and
we cannot be consistent without categorically refusing to endorse them.
And no, personally, I would not be moved by a Share dialog.
>> (In fact I've lately discovered that it is FreeDOS where the Emacs
>> port is most useful, and that operating system is 100% Free
>> Software.)
>
> Try to count how many users of DJGPP Emacs actually do that on
> FreeDOS.
[...]
>> We decide whether to reject features by the probability that they
>> will induce users to another, proprietary, operating system. The
>> fact that Emacs's GUI backend executes in threads created by
>> proprietary C runtime alone is clearly not applicable to this
>> criterion, but GUI file sharing capabilities are. The rather when
>> they amount to an endorsement of a proprietary file sharing service.
>
> You are being subjective here because you want to make a point.
Then, in the spirit of your question above, I ask, how many people will
agree that being able to link Emacs against a particular C runtime and
threading library will prepossesses users towards a new operating
system?
>> > Emacs's architecture and expectations from the underlying platform are
>> > so Posix-centric that emulating them without resorting to proprietary
>> > system-specific mechanisms is practically impossible. Anyone who
>> > demands us to avoid such interfaces and mechanisms basically tells us
>> > to stop supporting those systems in a way that makes Emacs useful and
>> > its features reasonably portable.
>>
>> Mac OS is a POSIX system, just as much as GNU/Linux, if not more.
>
> Not in its GUI system.
If so, how is POSIX relevant at all? POSIX standardizes no windowing
system, and those POSIX-portable windowing systems which Emacs does
support on GNU/Linux systems are equally functional on Mac OS, not to
mention such non-POSIX systems as OpenVMS, and even MS-DOS.
>> We are speaking of user-visible productivity features provided by
>> the GUI, not internal porting details, and I find it difficult to
>> accept that a one-click interface to "cloud" file storage and to the
>> iPhone Simulator is fundamental to Emacs's architecture or way of
>> life, as it were.
>
> It is neither fundamental nor an incentive to migrate.
The implication I was addressing was that a Share dialog could be
equally fundamental to Emacs as the POSIX `open' or `fstat' system
calls. Moreover, it _is_ capable of being such an incentive, or this
patch would not exist.
> So let's drop this futile argument, okay? We have gobs of real work
> on our hands.
The easiest means of doing this would be to shelve this proposal till a
comparable file-sharing system appears on the X desktop.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 10:19:02 GMT)
Full text and
rfc822 format available.
Message #220 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: bjorn.bidar <at> thaodan.de, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com,
> stefankangas <at> gmail.com
> Date: Thu, 13 Feb 2025 17:47:03 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Po Lu <luangruo <at> yahoo.com>
> >> Cc: bjorn.bidar <at> thaodan.de, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com,
> >> stefankangas <at> gmail.com
> >> Date: Thu, 13 Feb 2025 16:12:54 +0800
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> But we're not judging features by intimate details, and we won't have to
> >> remove the MS-Windows or DJGPP ports, because they create no incentive
> >> for users to migrate to MS-Windows or MS-DOS, in contrast to user-facing
> >> amenities provided by the operating system's GUI.
> >
> > That's your opinion, and you are entitled to it. But it doesn't mean
> > it is universally true: how can we know what does and doesn't give
> > users incentives?
> >
> > I'm having hard time to believe that seeing "Share" is such an
> > incentive.
>
> I'm sure you'll agree that it is much more plausible for this to be an
> incentive than for a choice of thread library or DOS extender
No, I don't agree. They are of the same plausibility.
> And no, personally, I would not be moved by a Share dialog.
Then why assume others will be?
> >> We decide whether to reject features by the probability that they
> >> will induce users to another, proprietary, operating system. The
> >> fact that Emacs's GUI backend executes in threads created by
> >> proprietary C runtime alone is clearly not applicable to this
> >> criterion, but GUI file sharing capabilities are. The rather when
> >> they amount to an endorsement of a proprietary file sharing service.
> >
> > You are being subjective here because you want to make a point.
>
> Then, in the spirit of your question above, I ask, how many people will
> agree that being able to link Emacs against a particular C runtime and
> threading library will prepossesses users towards a new operating
> system?
I don't see the relevance, sorry.
> >> > Emacs's architecture and expectations from the underlying platform are
> >> > so Posix-centric that emulating them without resorting to proprietary
> >> > system-specific mechanisms is practically impossible. Anyone who
> >> > demands us to avoid such interfaces and mechanisms basically tells us
> >> > to stop supporting those systems in a way that makes Emacs useful and
> >> > its features reasonably portable.
> >>
> >> Mac OS is a POSIX system, just as much as GNU/Linux, if not more.
> >
> > Not in its GUI system.
>
> If so, how is POSIX relevant at all?
The assumptions made by Emacs about the GUI system basics are
relevant.
> > It is neither fundamental nor an incentive to migrate.
>
> The implication I was addressing was that a Share dialog could be
> equally fundamental to Emacs as the POSIX `open' or `fstat' system
> calls. Moreover, it _is_ capable of being such an incentive, or this
> patch would not exist.
This patch adds to Emacs platform-specific means to "open" stuff,
that's all.
> > So let's drop this futile argument, okay? We have gobs of real work
> > on our hands.
>
> The easiest means of doing this would be to shelve this proposal till a
> comparable file-sharing system appears on the X desktop.
I'm not willing to shelve it because I see no reason for that. As
already explained in this too-long dispute. Please accept that, even
if you disagree.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 15:00:02 GMT)
Full text and
rfc822 format available.
Message #223 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I'm sure you'll agree that it is much more plausible for this to be an
>> incentive than for a choice of thread library or DOS extender
>
> No, I don't agree. They are of the same plausibility.
After what I have seen among Macintosh users, I cannot agree. How
otherwise do you account for the popularity of the Carbon Emacs port
which does already provide such OS interfaces and is frequently
recommended on the strength of this "added value" alone?
> Then why assume others will be?
Because there is abundant evidence of this in this thread, and
elsewhere?
>> >> We decide whether to reject features by the probability that they
>> >> will induce users to another, proprietary, operating system. The
>> >> fact that Emacs's GUI backend executes in threads created by
>> >> proprietary C runtime alone is clearly not applicable to this
>> >> criterion, but GUI file sharing capabilities are. The rather when
>> >> they amount to an endorsement of a proprietary file sharing service.
>> >
>> > You are being subjective here because you want to make a point.
>>
>> Then, in the spirit of your question above, I ask, how many people will
>> agree that being able to link Emacs against a particular C runtime and
>> threading library will prepossesses users towards a new operating
>> system?
>
> I don't see the relevance, sorry.
I simply restated the postulate which you used to equate this dialog box
with the MS-DOS and MS-Windows ports, which scarcely provide any
material advantage over Emacs on free desktop systems. Windows NT's
threads or DPMI are implementation details, not advantages, and the only
program from which users could be enticed to the DJGPP port is EDIT.COM.
>> >> > Emacs's architecture and expectations from the underlying platform are
>> >> > so Posix-centric that emulating them without resorting to proprietary
>> >> > system-specific mechanisms is practically impossible. Anyone who
>> >> > demands us to avoid such interfaces and mechanisms basically tells us
>> >> > to stop supporting those systems in a way that makes Emacs useful and
>> >> > its features reasonably portable.
>> >>
>> >> Mac OS is a POSIX system, just as much as GNU/Linux, if not more.
>> >
>> > Not in its GUI system.
>>
>> If so, how is POSIX relevant at all?
>
> The assumptions made by Emacs about the GUI system basics are
> relevant.
A Share dialog without which Emacs has fared satisfactorily on Mac OS
for upwards of a decade cannot properly be said to be part of its
"basics", I should think.
>> > It is neither fundamental nor an incentive to migrate.
>>
>> The implication I was addressing was that a Share dialog could be
>> equally fundamental to Emacs as the POSIX `open' or `fstat' system
>> calls. Moreover, it _is_ capable of being such an incentive, or this
>> patch would not exist.
>
> This patch adds to Emacs platform-specific means to "open" stuff,
> that's all.
In such a convenient manner as is not yet possible in GNU/Linux systems.
Mac OS users are _already_ able to open files as on free systems by
executing the `open' command in a subprocess, which is functionally
identical to `xdg-open'. There are no grounds on which to go any
further.
>> > So let's drop this futile argument, okay? We have gobs of real work
>> > on our hands.
>>
>> The easiest means of doing this would be to shelve this proposal till a
>> comparable file-sharing system appears on the X desktop.
>
> I'm not willing to shelve it because I see no reason for that. As
> already explained in this too-long dispute. Please accept that, even
> if you disagree.
I cannot accept this--it amounts to overt if well-intentioned sabotage
of the GNU project's raison d'etre. It is widely known that AirDrop is
as thoroughly restrictive as the rest of Apple's computer services, and
it is additionally an engine of grotesque censorship, with which every
move towards reconciliation renders it more difficult to improve and
promote Emacs in good conscience, and by putting across the reasoning
behind my protests, I hope to enable others to explain why this is so
more effectively than I can.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 16:03:02 GMT)
Full text and
rfc822 format available.
Message #226 received at 76120 <at> debbugs.gnu.org (full text, mbox):
An update from the patch's perspective... I'm reworking things a
little to make the feature adjustable on different platforms out
of the box.
In the first submission of the new context menu, I'd like to
include the generic bits along with the agreed scope of GNU/Linux
support (via xdg-open) and macOS (via share dialog). Either will
be configurable/overridable by users.
On a related note, Rudolf kindly shared Android's equivalent API
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76120#47 which
sounds like a lovely addition to the family. It'd be great to work
with a keen counterpart who'd like to help me raise the tide and
lifts all boats.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 16:34:02 GMT)
Full text and
rfc822 format available.
Message #229 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> I cannot accept this--it amounts to overt if well-intentioned sabotage
> of the GNU project's raison d'etre. It is widely known that AirDrop is
> as thoroughly restrictive as the rest of Apple's computer services, and
> it is additionally an engine of grotesque censorship, with which every
> move towards reconciliation renders it more difficult to improve and
> promote Emacs in good conscience, and by putting across the reasoning
> behind my protests, I hope to enable others to explain why this is so
> more effectively than I can.
Despite finding the tone here rather exaggerated, things like these
actually makes me appreciate the implacability:
https://www.schneier.com/blog/archives/2025/02/uk-is-ordering-apple-to-break-its-own-encryption.html
While I fully appreciate Eli's argument that the word "Share" is mostly
hype, a problem that is harder to avoid is that the content of the
"Share" menu is not necessarily customizable or controlled by users.
OTOH, nothing on a macOS machine is ultimately controlled by the user,
so Eli is right that we either have to draw the line somewhere, or
desupport the platform completely. The latter would not help our cause.
In this context, a minor convenience feature that is mostly equivalent
to "Open with" doesn't strike me as the best place to put our heels in
the ground. I wouldn't say that it's unproblematic, because nothing is
as far as proprietary systems go. However, it's also not clear that
anything principled is at stake, given that modulo packaging we can
provide equivalent functionality on GNU/Linux, let alone that this is a
decision that GNU will live or die by.
The question of where to draw the line is not easy, and it's up to the
maintainers to decide. Our decision has been made clear, as has the
counter-arguments, and only Richard is in a position to overrule that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 16:52:02 GMT)
Full text and
rfc822 format available.
Message #232 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: bjorn.bidar <at> thaodan.de, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com,
> stefankangas <at> gmail.com
> Date: Thu, 13 Feb 2025 22:59:18 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I'm not willing to shelve it because I see no reason for that. As
> > already explained in this too-long dispute. Please accept that, even
> > if you disagree.
>
> I cannot accept this--it amounts to overt if well-intentioned sabotage
> of the GNU project's raison d'etre.
You are out of line.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 16:59:01 GMT)
Full text and
rfc822 format available.
Message #235 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> An update from the patch's perspective... I'm reworking things a
> little to make the feature adjustable on different platforms out
> of the box.
>
> In the first submission of the new context menu, I'd like to
> include the generic bits along with the agreed scope of GNU/Linux
> support (via xdg-open) and macOS (via share dialog). Either will
> be configurable/overridable by users.
>
> On a related note, Rudolf kindly shared Android's equivalent API
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76120#47 which
> sounds like a lovely addition to the family. It'd be great to work
> with a keen counterpart who'd like to help me raise the tide and
> lifts all boats.
Sounds good to me, and thanks for working on this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 17:40:02 GMT)
Full text and
rfc822 format available.
Message #238 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76120 <at> debbugs.gnu.org,
>> alvaro <at> xenodium.com, stefankangas <at> gmail.com
>> Date: Thu, 13 Feb 2025 08:30:45 +0200
>>
>> Would it possible to disable AirDrop in this dialog?
>
> It's possible, but I see no need to do it.
The reasons that Po Lo (sorry please correct me on using your name
without last name) are not enough?
AirDrop is an entirely non-free protocol made by a computer which
produces their devices in a state sponsored labor camps.
There is no way to use this protocol without Apple's control without
going into, at least outside of Europe, legally gray areas.
This isn't just something like SMB/CIFS which can be used without any
non-free platforms involved.
Even if this could be enabled in theory it shouldn't be enabled by
default IMHO. From my point of view implementing such a modern feature
for macOS first and not even disabling these proprietary to one platform
tied protocols looks bad at best.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 17:54:02 GMT)
Full text and
rfc822 format available.
Message #241 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Po Lu <luangruo <at> yahoo.com>
>>> Cc: bjorn.bidar <at> thaodan.de, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com,
>>> stefankangas <at> gmail.com
>>> Date: Thu, 13 Feb 2025 16:12:54 +0800
>>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>> But we're not judging features by intimate details, and we won't have to
>>> remove the MS-Windows or DJGPP ports, because they create no incentive
>>> for users to migrate to MS-Windows or MS-DOS, in contrast to user-facing
>>> amenities provided by the operating system's GUI.
>>
>> That's your opinion, and you are entitled to it. But it doesn't mean
>> it is universally true: how can we know what does and doesn't give
>> users incentives?
>>
>> I'm having hard time to believe that seeing "Share" is such an
>> incentive.
>
> I'm sure you'll agree that it is much more plausible for this to be an
> incentive than for a choice of thread library or DOS extender, which
> makes not a whit of a difference in actually running Emacs. At any
> rate, this sentiment is everywhere to be found in on-line Emacs forums
> and chatrooms, and you need look no further than the popularity of the
> Carbon Emacs port, which is integrated with the Mac OS dictionary, share
> dialog, and animation framework. Minor frivolities such as this do play
> an active role in enticing users to proprietary operating systems, and
> we cannot be consistent without categorically refusing to endorse them.
>
> And no, personally, I would not be moved by a Share dialog.
>
>>> (In fact I've lately discovered that it is FreeDOS where the Emacs
>>> port is most useful, and that operating system is 100% Free
>>> Software.)
>>
>> Try to count how many users of DJGPP Emacs actually do that on
>> FreeDOS.
>
> [...]
>
>>> We decide whether to reject features by the probability that they
>>> will induce users to another, proprietary, operating system. The
>>> fact that Emacs's GUI backend executes in threads created by
>>> proprietary C runtime alone is clearly not applicable to this
>>> criterion, but GUI file sharing capabilities are. The rather when
>>> they amount to an endorsement of a proprietary file sharing service.
>>
>> You are being subjective here because you want to make a point.
>
> Then, in the spirit of your question above, I ask, how many people will
> agree that being able to link Emacs against a particular C runtime and
> threading library will prepossesses users towards a new operating
> system?
>
>>> > Emacs's architecture and expectations from the underlying platform are
>>> > so Posix-centric that emulating them without resorting to proprietary
>>> > system-specific mechanisms is practically impossible. Anyone who
>>> > demands us to avoid such interfaces and mechanisms basically tells us
>>> > to stop supporting those systems in a way that makes Emacs useful and
>>> > its features reasonably portable.
>>>
>>> Mac OS is a POSIX system, just as much as GNU/Linux, if not more.
>>
>> Not in its GUI system.
>
> If so, how is POSIX relevant at all? POSIX standardizes no windowing
> system, and those POSIX-portable windowing systems which Emacs does
> support on GNU/Linux systems are equally functional on Mac OS, not to
> mention such non-POSIX systems as OpenVMS, and even MS-DOS.
>>> We are speaking of user-visible productivity features provided by
>>> the GUI, not internal porting details, and I find it difficult to
>>> accept that a one-click interface to "cloud" file storage and to the
>>> iPhone Simulator is fundamental to Emacs's architecture or way of
>>> life, as it were.
>>
>> It is neither fundamental nor an incentive to migrate.
>
> The implication I was addressing was that a Share dialog could be
> equally fundamental to Emacs as the POSIX `open' or `fstat' system
> calls. Moreover, it _is_ capable of being such an incentive, or this
> patch would not exist.
I think the difficulty to come to a conscious could be related to that
this is one of the features coming from mobile platform which has
different UX implications which my be not apparent without trying them
by oneself first or putting themselves in the POV of a user who might
want to use these. The documentation that is available shows the
differences also.
As mobile developer I know that these are essential for modern messaging
apps for example to forward content to others. Without them you have
safe the thing you want to share if you can, some mobile platforms such
as iOS make that hard, and then open the app you want to send the thing
with. That the feature in the case of macOS originates from iOS should
tell enough that this isn't just open, file access between apps on iOS
with the open command isn't possible as they can't reach out of their
sandbox.
Even for a desktop use case this can be quite useful although much less
required.
From this patch a user could for example write a document or share a
piece of code with another user on iMessage.
But lets turn this around: Would it be ok to implement this for the
Android port and lets say enable deeper integration with Google Drive
this way?
>> So let's drop this futile argument, okay? We have gobs of real work
>> on our hands.
>
> The easiest means of doing this would be to shelve this proposal till a
> comparable file-sharing system appears on the X desktop.
I agree this would relay on clarifying the semantics here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Feb 2025 20:10:02 GMT)
Full text and
rfc822 format available.
Message #244 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 13 Feb 2025 08:33:14 -0800
> Cc: bjorn.bidar <at> thaodan.de, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com
>
> Po Lu <luangruo <at> yahoo.com> writes:
>
> > I cannot accept this--it amounts to overt if well-intentioned sabotage
> > of the GNU project's raison d'etre. It is widely known that AirDrop is
> > as thoroughly restrictive as the rest of Apple's computer services, and
> > it is additionally an engine of grotesque censorship, with which every
> > move towards reconciliation renders it more difficult to improve and
> > promote Emacs in good conscience, and by putting across the reasoning
> > behind my protests, I hope to enable others to explain why this is so
> > more effectively than I can.
>
> Despite finding the tone here rather exaggerated, things like these
> actually makes me appreciate the implacability:
> https://www.schneier.com/blog/archives/2025/02/uk-is-ordering-apple-to-break-its-own-encryption.html
>
> While I fully appreciate Eli's argument that the word "Share" is mostly
> hype, a problem that is harder to avoid is that the content of the
> "Share" menu is not necessarily customizable or controlled by users.
>
> OTOH, nothing on a macOS machine is ultimately controlled by the user,
> so Eli is right that we either have to draw the line somewhere, or
> desupport the platform completely. The latter would not help our cause.
>
> In this context, a minor convenience feature that is mostly equivalent
> to "Open with" doesn't strike me as the best place to put our heels in
> the ground. I wouldn't say that it's unproblematic, because nothing is
> as far as proprietary systems go. However, it's also not clear that
> anything principled is at stake, given that modulo packaging we can
> provide equivalent functionality on GNU/Linux, let alone that this is a
> decision that GNU will live or die by.
>
> The question of where to draw the line is not easy, and it's up to the
> maintainers to decide. Our decision has been made clear, as has the
> counter-arguments, and only Richard is in a position to overrule that.
It should be clear to everyone that if Richard upholds the view that
I'm committing sabotage of the GNU project, either overt or covert, I
will step down that very moment.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Fri, 14 Feb 2025 10:34:02 GMT)
Full text and
rfc822 format available.
Message #247 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> It should be clear to everyone that if Richard upholds the view that
> I'm committing sabotage of the GNU project, either overt or covert, I
> will step down that very moment.
I'm not sure how that view point came up exactly but I want to add that
I didn't mean to sound like I think you sabotage the GNU project.
So yeah I don't think a disagreement should escalate like this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Fri, 14 Feb 2025 14:19:01 GMT)
Full text and
rfc822 format available.
Message #250 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Björn Bidar <bjorn.bidar <at> thaodan.de> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> It should be clear to everyone that if Richard upholds the view that
>> I'm committing sabotage of the GNU project, either overt or covert, I
>> will step down that very moment.
The claim is completely frivolous, IMNSHO.
> I'm not sure how that view point came up exactly
Please see up-thread:
"[This] amounts to overt if well-intentioned sabotage of the GNU
project's raison d'etre."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Fri, 14 Feb 2025 16:14:02 GMT)
Full text and
rfc822 format available.
Message #253 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Björn Bidar <bjorn.bidar <at> thaodan.de> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>> It should be clear to everyone that if Richard upholds the view that
>>> I'm committing sabotage of the GNU project, either overt or covert, I
>>> will step down that very moment.
>
> The claim is completely frivolous, IMNSHO.
>
>> I'm not sure how that view point came up exactly
>
> Please see up-thread:
>
> "[This] amounts to overt if well-intentioned sabotage of the GNU
> project's raison d'etre."
Ah thank you for citing the referenced point here.
Point is still IMHO that (actively) sabotaging and unintentionally
doing something which sabotages something are two different things IMHO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Fri, 14 Feb 2025 22:07:01 GMT)
Full text and
rfc822 format available.
Message #256 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Could someone please explain briefly what the "native sharing dialog"
of MacOS does? What does it try to share, and when?
When this discussion started, I did not know what sort of feature it
was asking to enable on MacOS. I am trying to guess but I am still
not sure.
Is it a facility to copy files between one MacOS machine and another,
that does not communicate with any other system? I am starting to
guess so, because a facility that is "native" to MacOS would work only
on MacOS.
Or is it a facility to invoke "the right applcation" to oerate
on a file?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Feb 2025 00:35:01 GMT)
Full text and
rfc822 format available.
Message #259 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Richard Stallman <rms <at> gnu.org> writes:
Hi Richard,
I proposed the feature/patch.
I happen to use macOS for my work and of course Emacs (big fan)
for a bunch of things.
> Could someone please explain briefly what the "native sharing
> dialog"
> of MacOS does?
May be simpler to visualize. I've attached two screenshots with
the agreed flow implemented for both GNU/Linux (linux.jpg) and
macOS (macos.jpg).
> What does it try to share, and when?
Current buffer file, a selection of files from dired, or region
text, after the user chooses to share with external apps
(non-Emacs) via the mouse context menu "Share...".
> When this discussion started, I did not know what sort of
> feature it
> was asking to enable on MacOS. I am trying to guess but I am
> still
> not sure.
I hope the screenshots help here.
> Is it a facility to copy files between one MacOS machine and
> another,
> that does not communicate with any other system? I am starting
> to
> guess so, because a facility that is "native" to MacOS would
> work only
> on MacOS.
While my initial proposal was for macOS only, I agreed with Stefan
and Eli in this thread to bring the "Share..." context menu option
to both GNU/Linux and macOS.
[linux.jpg (image/jpeg, inline)]
[macos.jpg (image/jpeg, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Feb 2025 01:17:01 GMT)
Full text and
rfc822 format available.
Message #262 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> Could someone please explain briefly what the "native sharing dialog"
> of MacOS does? What does it try to share, and when?
>
> When this discussion started, I did not know what sort of feature it
> was asking to enable on MacOS. I am trying to guess but I am still
> not sure.
>
> Is it a facility to copy files between one MacOS machine and another,
> that does not communicate with any other system? I am starting to
> guess so, because a facility that is "native" to MacOS would work only
> on MacOS.
>
> Or is it a facility to invoke "the right applcation" to oerate
> on a file?
The "Share" function in macOS, usually shown as a button or menu option,
allows you to share content using applications (e.g., Mail) and system
services (e.g., AirDrop). Invoking it opens a menu with options like
AirDrop, Mail, Messages, and other installed programs.
This feature works through a macOS/iOS-specific API called "Share
Extensions", which lets programs specify what types of content they can
handle, such as files, text, links, images, or videos. The receiving
process is informed of the content type through the API, and the
recommendation is that the program should then treat it as something
intended for sharing or posting.
Examples:
1. Files. The file name and relevant metadata (such as type, size, and
preview data) are sent to the chosen program or service, which
handles it in context-specific ways. For example, AirDrop sends the
file to nearby Apple devices, Mail attaches it to a new email, and
Notes saves an image file as a note. The receiving program can also
provide additional options based on the file type, e.g. sharing a
photo to a social media program may offer editing or captioning
options before posting, but again, that would be up to that program.
2. Text. The selected text is handed off to the chosen program, where
it is embedded accordingly. For example, sharing text through Notes
creates a new note, preserving formatting when possible, while with
something like Messages, you can select a recipient to send the
shared text as a message to that person.
3. Links. The context menu shows options like "Add to Reading List",
which saves the link for offline reading, or "Add Bookmark", which
adds it to some list of bookmarks. There is also "Add Website to
Shared Links", but I don't know the specific behavior of that option.
I hope this clarifies some of the key aspects of the "Share" feature.
If anyone has anything to add or correct, please do.
Footnotes:
[1] This is the one I was able to find.
https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/Share.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Feb 2025 05:32:02 GMT)
Full text and
rfc822 format available.
Message #265 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> Cc: 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com
> From: Richard Stallman <rms <at> gnu.org>
> Date: Fri, 14 Feb 2025 17:06:09 -0500
>
> Could someone please explain briefly what the "native sharing dialog"
> of MacOS does? What does it try to share, and when?
It allows to send a file or a region of text to another application or
a service. It's an addition to a feature we already have in Dired and
other places whereby a file can be "opened" by some external means,
like a program (e.g., to show it or do other actions with it) or a
printing service (e.g., to print the text).
> Is it a facility to copy files between one MacOS machine and another,
> that does not communicate with any other system? I am starting to
> guess so, because a facility that is "native" to MacOS would work only
> on MacOS.
>
> Or is it a facility to invoke "the right applcation" to oerate
> on a file?
It allows to do both.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Mon, 17 Feb 2025 19:51:02 GMT)
Full text and
rfc822 format available.
Message #268 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Eli and Stefan,
Attaching the latest iteration of the patch (renamed
0003-Add-context-menu-share-to-mouse.el.patch) incorporating your
feedback.
New in patch:
- Sharing/opening file externally is now generic and available via
context menu (needs context-menu-mode enabled) on multiple
platforms.
- Added file opening/sharing support for GNU/Linux via (xdg-open)
and any other platform which support it.
- Region/text opening/sharing is now supported by xdg-open too.
- Sharing/opening routing behavior is now configurable and can
override the context menu implementation.
- Removes lambda usage from Objective-C/native code.
- Guards macOS addition via NS_IMPL_COCOA (avoid breaking
GNUstep).
While routing logic is now configurable, it'be great to extend the
default behavior for other platforms. Android sounds like a great
candidate as per Rudolf's suggested API
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76120#47. Any
Android folks keen on extending the feature?
Also attaching screenshots as per current patch for both GNU/Linux
and macOS.
Álvaro
[0003-Add-context-menu-share-to-mouse.el.patch (text/x-patch, attachment)]
[macos.jpg (image/jpeg, attachment)]
[linux.jpg (image/jpeg, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 19 Feb 2025 00:59:02 GMT)
Full text and
rfc822 format available.
Message #271 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> It allows to send a file or a region of text to another application or
> a service.
The term "sharing" is very misleading for this; we use the word
"share" for comething that people do with other people. So we should
not adopt Apple's terminology.
I think "system invocation dialog" is a better name for us to use.
Is there any reason that would be misleading?
It's an addition to a feature we already have in Dired and
> other places whereby a file can be "opened" by some external means,
> like a program (e.g., to show it or do other actions with it) or a
> printing service (e.g., to print the text).
Does that mean it is comparable to the ! command in Dired?
Do shell commands exist on MacOS? Can users do with ! on MacOS the
same things they can do with the system invocation dialog?
Perhaps the system invocation dialog has some conveniences -- for
instance, not needing to remember shell commands or their syntax.
Is that the case?
If so, would those conveniences be convenient on GNU/Linux if they
existed?
Should we aim to implement that system invocation dialog on GNU/Linux?
Then it would be a feature that isn't MacOS-specific.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 19 Feb 2025 01:00:02 GMT)
Full text and
rfc822 format available.
Message #274 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Thanks for the concrete explanation. I think I basically understand
it now. (Of course, I have never seen it in use.)
> Examples:
> 1. Files. The file name and relevant metadata (such as type, size, and
> preview data) are sent to the chosen program or service, which
> handles it in context-specific ways....
> 2. Text. The selected text is handed off to the chosen program, where
> it is embedded accordingly....
> 3. Links. The context menu shows options like "Add to Reading List",
> which saves the link for offline reading, or "Add Bookmark", which
> adds it to some list of bookmarks...
Would it be useful to implement this feature in Emacs in a
system-independent way? Or perhaps implement our own version for use
n GNU/Linux and similar systems, and use the SmacOS version when on
SmacOS?
Another alternative would be to implement this as a separate program
that Emacs could invoke, and other GUI programs could also invoke.
Because a useful feature should not be supported solely on a nonfree system!
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 19 Feb 2025 01:00:04 GMT)
Full text and
rfc822 format available.
Message #277 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Thanks for the screen shots. One drawback of screenshots is that they
don't show the inputs, only what the screen looks like. After
screenshot 2, I think you gave a commend (perhaps with the mouse),
but what command was it?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 19 Feb 2025 09:44:01 GMT)
Full text and
rfc822 format available.
Message #280 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> +(defgroup context-share nil
> + "Share files and text with external applications."
Please do not use the wrd "share" in this file.
This feature is not about sharing, not at all.
It invokes an external command on some text or file.
Whatever term we choose will probably remain in place for decades. We
should choose it with careful thought, not rush.
We should not use a term that does not fit the actions
and we should not get our terminology from a company that
makes nonfree operating systems.
Let's replace "share" with "manipulate" now, with the idea that we can
change the word a few weeks from now -- after discussing about the
best word to use.
"Manipulate" fits what the feature does, and it is clearly better than
"share". If we find a better word, we can change to that.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 19 Feb 2025 12:03:02 GMT)
Full text and
rfc822 format available.
Message #283 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> Let's replace "share" with "manipulate" now, with the idea that
> we can
> change the word a few weeks from now -- after discussing about
> the
> best word to use.
>
> "Manipulate" fits what the feature does, and it is clearly
> better than
> "share". If we find a better word, we can change to that.
How about "send-to" as package prefix instead of "share"? The
context menu would also be "Send to...".
"Send to" feels like a great candidate, as it would apply
generally across different platforms.
Eli, Stefan, WDYT?
ps. Credit to Stephane for proposing "send-to" as an alternative.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 19 Feb 2025 13:25:02 GMT)
Full text and
rfc822 format available.
Message #286 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> Or perhaps implement our own version for use
> n GNU/Linux and similar systems, and use the SmacOS version when
> on
> SmacOS?
The proposal in the latest patch includes both of these: An
implementation for GNU/Linux (and similar systems) and another for
macOS.
Maybe also worth mentioning, the patch offers additional
customization points in case users want different implementations
altogether.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 19 Feb 2025 13:33:02 GMT)
Full text and
rfc822 format available.
Message #289 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> Thanks for the screen shots. One drawback of screenshots is
> that they
> don't show the inputs, only what the screen looks like. After
> screenshot 2, I think you gave a commend (perhaps with the
> mouse),
> but what command was it?
The flow is as follows:
1. Mark 3 dired files (via M-x dired-mark): ChangeLog.1,
ChangeLog.2, and ChangeLog.3.
2. Mouse right-click in buffer to open context menu (needs
context-menu-mode enabled) and select "Share...".
3. Display the new feature dialog.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 19 Feb 2025 15:13:02 GMT)
Full text and
rfc822 format available.
Message #292 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Richard Stallman <rms <at> gnu.org>
> Cc: 76120 <at> debbugs.gnu.org
> Date: Tue, 18 Feb 2025 19:58:00 -0500
>
> > It allows to send a file or a region of text to another application or
> > a service.
>
> The term "sharing" is very misleading for this; we use the word
> "share" for comething that people do with other people. So we should
> not adopt Apple's terminology.
I agree that it's misleading terminology, but it isn't Apple's
terminology. It is widely used today, primarily in smartphones, but
also on modern laptop and desktop operating systems.
> I think "system invocation dialog" is a better name for us to use.
> Is there any reason that would be misleading?
I think you have in mind invocation of programs. However, "sharing"
does not necessarily invoke a program, it could also send stuff to
some service or communication channel.
> It's an addition to a feature we already have in Dired and
> > other places whereby a file can be "opened" by some external means,
> > like a program (e.g., to show it or do other actions with it) or a
> > printing service (e.g., to print the text).
>
> Does that mean it is comparable to the ! command in Dired?
For some of the actions and some types of material to "share", it is.
For others, no. It is also system-dependent: for example, printing a
document or a buffer on GNU/Linux will usually mean invoking a program
like lpr, but on Windows Emacs just submits the text directly to the
system's printer spooling service.
> Do shell commands exist on MacOS? Can users do with ! on MacOS the
> same things they can do with the system invocation dialog?
Yes and yes. But some of the actions don't invoke shell commands, as
I tried to explain above.
> Perhaps the system invocation dialog has some conveniences -- for
> instance, not needing to remember shell commands or their syntax.
> Is that the case?
Yes. Basically, when I'm asking the system to "open" some document, I
don't need to know which program is pertinent for that. This is so
also on GNU/Linux, where at least some of these actions invoke
xdg-open, which is a shell command used to open a file or a URL with
the "preferred application" (which users can customize).
> If so, would those conveniences be convenient on GNU/Linux if they
> existed?
They already exist. However, some of these conveniences might not
(yet) be available on all systems.
> Should we aim to implement that system invocation dialog on GNU/Linux?
We already did, see shell-command-guess-functions and the features
built around that. We want to add the ability to invoke this platform
specific "sharing" as part of those features.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 19 Feb 2025 16:29:01 GMT)
Full text and
rfc822 format available.
Message #295 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> Cc: 76120 <at> debbugs.gnu.org
> From: Richard Stallman <rms <at> gnu.org>
> Date: Wed, 19 Feb 2025 04:43:03 -0500
>
> > +(defgroup context-share nil
> > + "Share files and text with external applications."
>
> Please do not use the wrd "share" in this file.
> This feature is not about sharing, not at all.
> It invokes an external command on some text or file.
How about "Send files or text to external application or service."?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 19 Feb 2025 16:35:02 GMT)
Full text and
rfc822 format available.
Message #298 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: 76120 <at> debbugs.gnu.org
> Date: Wed, 19 Feb 2025 12:02:39 +0000
>
> Richard Stallman <rms <at> gnu.org> writes:
>
> > Let's replace "share" with "manipulate" now, with the idea that
> > we can
> > change the word a few weeks from now -- after discussing about
> > the
> > best word to use.
> >
> > "Manipulate" fits what the feature does, and it is clearly
> > better than
> > "share". If we find a better word, we can change to that.
>
> How about "send-to" as package prefix instead of "share"? The
> context menu would also be "Send to...".
>
> "Send to" feels like a great candidate, as it would apply
> generally across different platforms.
Yes, I think it's better (just sand the same proposal, before even
reading this).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 11:59:02 GMT)
Full text and
rfc822 format available.
Message #301 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Alvaro Ramirez <alvaro <at> xenodium.com>
>> Cc: 76120 <at> debbugs.gnu.org
>> Date: Wed, 19 Feb 2025 12:02:39 +0000
>>
>> Richard Stallman <rms <at> gnu.org> writes:
>>
>> > Let's replace "share" with "manipulate" now, with the idea
>> > that
>> > we can
>> > change the word a few weeks from now -- after discussing
>> > about
>> > the
>> > best word to use.
>> >
>> > "Manipulate" fits what the feature does, and it is clearly
>> > better than
>> > "share". If we find a better word, we can change to that.
>>
>> How about "send-to" as package prefix instead of "share"? The
>> context menu would also be "Send to...".
>>
>> "Send to" feels like a great candidate, as it would apply
>> generally across different platforms.
>
> Yes, I think it's better (just sand the same proposal, before
> even
> reading this).
Sounds good. Thank you.
Attaching the latest iteration of the patch (renamed
0004-Add-Send-to-context-menu-item-to-mouse-el.patch)..
New since 0003-Add-context-menu-share-to-mouse.el.patch:
- Replacing the word "share" throughout patch and using
"send"/"send to" instead.
[0004-Add-Send-to-context-menu-item-to-mouse-el.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 12:03:04 GMT)
Full text and
rfc822 format available.
Message #304 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
What is the reason for the word "context" in this feature's name?
I suppose somehow its operation depends on some sort of context,
but how so? And is that so crucially significant that the feature
should be named after it?
Skimming the code I don't see anything that would make the word
"context" central to explaining its purpose.
If I missed something, could you please explain what I missed?
Maybe that will suggest a word that is more a propos.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 12:25:02 GMT)
Full text and
rfc822 format available.
Message #307 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் பிப்ரவரி 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.
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Alvaro Ramirez <alvaro <at> xenodium.com>
>>> Cc: 76120 <at> debbugs.gnu.org
>>> Date: Wed, 19 Feb 2025 12:02:39 +0000
>>>
>>> Richard Stallman <rms <at> gnu.org> writes:
>>>
>>> > Let's replace "share" with "manipulate" now, with the idea >
>>> that
>>> > we can
>>> > change the word a few weeks from now -- after discussing > about
>>> > the
>>> > best word to use.
>>> >
>>> > "Manipulate" fits what the feature does, and it is clearly
>>> > better than
>>> > "share". If we find a better word, we can change to that.
>>>
>>> How about "send-to" as package prefix instead of "share"? The
>>> context menu would also be "Send to...".
>>>
>>> "Send to" feels like a great candidate, as it would apply
>>> generally across different platforms.
>>
>> Yes, I think it's better (just sand the same proposal, before even
>> reading this).
>
> Sounds good. Thank you.
>
> Attaching the latest iteration of the patch (renamed
> 0004-Add-Send-to-context-menu-item-to-mouse-el.patch)..
>
> New since 0003-Add-context-menu-share-to-mouse.el.patch:
>
> - Replacing the word "share" throughout patch and using "send"/"send
> to" instead.
>
> From 7e1f671568fde6e5f3f3381a634f6ba6077105bd Mon Sep 17 00:00:00 2001
> From: xenodium <8107219+xenodium <at> users.noreply.github.com>
> Date: Thu, 13 Feb 2025 17:30:01 +0000
> Subject: [PATCH] Add "Send to..." context menu item to mouse.el
>
> * lisp/send-to.el: New package implements sending to apps or services.
>
> * lisp/mouse.el (context-menu-send-to): Add "Send to..." context menu.
>
> * lisp/term/ns-win.el (ns-send-items): Expose native macOS send API.
>
> * src/nsfns.m (ns-send-items): Implement native macOS sending.
>
> * etc/NEWS: Announce the new feature.
> ---
> etc/NEWS | 7 ++
> lisp/mouse.el | 17 +++-
> lisp/send-to.el | 216 ++++++++++++++++++++++++++++++++++++++++++++
> lisp/term/ns-win.el | 1 +
> src/nsfns.m | 62 +++++++++++++
> 5 files changed, 302 insertions(+), 1 deletion(-)
> create mode 100644 lisp/send-to.el
>
> diff --git a/etc/NEWS b/etc/NEWS
> index dea24adb3c9..a1798322ad6 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -280,6 +280,13 @@ customize help text for tabs displayed on the tab-bar. Help text is
> normally shown in the echo area or via tooltips. See the variable's
> docstring for arguments passed to a help-text function.
>
> +** Mouse
> +
> +---
> +*** context-menu-mode now includes a "Send to..." menu item.
> +The menu item enables sending current file(s) or region text to external
> +(non-Emacs) apps or services. See send-to.el for customisations.
> +
> ** Project
>
> ---
> diff --git a/lisp/mouse.el b/lisp/mouse.el
> index 1f0ca6a51b6..4076097c90c 100644
> --- a/lisp/mouse.el
> +++ b/lisp/mouse.el
> @@ -30,6 +30,7 @@
> ;;; Code:
>
> (eval-when-compile (require 'rect))
> +(eval-when-compile (require 'send-to))
>
> ;; Indent track-mouse like progn.
> (put 'track-mouse 'lisp-indent-function 0)
> @@ -393,7 +394,8 @@ context-menu-functions
> context-menu-region
> context-menu-middle-separator
> context-menu-local
> - context-menu-minor)
> + context-menu-minor
> + context-menu-send-to)
> "List of functions that produce the contents of the context menu.
> Each function receives the menu and the mouse click event as its arguments
> and should return the same menu with changes such as added new menu items."
> @@ -536,6 +538,19 @@ context-menu-minor
> (cdr mode))))
> menu)
>
> +(defun context-menu-send-to (menu _click)
> + "Add a \"Send to...\" context MENU entry on supported platforms."
> + (run-hooks 'activate-menubar-hook 'menu-bar-update-hook)
> + (when (send-to-supported-p)
> + (define-key-after menu [separator-send] menu-bar-separator)
> + (define-key-after menu [send]
> + '(menu-item "Send to..." (lambda ()
> + (interactive)
> + (send-to))
> + :help
> + "Send item (region, buffer file, or dired files) to app or service")))
> + menu)
> +
> (defun context-menu-buffers (menu _click)
> "Populate MENU with the buffer submenus to buffer switching."
> (run-hooks 'activate-menubar-hook 'menu-bar-update-hook)
> diff --git a/lisp/send-to.el b/lisp/send-to.el
> new file mode 100644
> index 00000000000..78fd1b03ec3
> --- /dev/null
> +++ b/lisp/send-to.el
> @@ -0,0 +1,216 @@
> +;;; send-to.el --- send files to apps or services -*- lexical-binding: t -*-
> +
> +;; Copyright (C) 1993-2025 Free Software Foundation, Inc.
> +
> +;; Maintainer: emacs-devel <at> gnu.org
> +;; Keywords: send, apps
> +;; Package: emacs
> +
> +;; This file is part of GNU Emacs.
> +
> +;; GNU Emacs is free software: you can redistribute it and/or modify
> +;; it under the terms of the GNU General Public License as published by
> +;; the Free Software Foundation, either version 3 of the License, or
> +;; (at your option) any later version.
> +
> +;; GNU Emacs is distributed in the hope that it will be useful,
> +;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +;; GNU General Public License for more details.
> +
> +;; You should have received a copy of the GNU General Public License
> +;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
> +
> +;;; Commentary:
> +
> +;; This package provides commands to facilitate sending files to
> +;; external apps or services.
> +;;
> +;; Enable `context-menu-mode' to get a "Send to..." context menu item.
> +;;
> +;; `send-to' uses `send-to-context-items-function' to
> +;; pick which file(s) to send and `send-to-handler-function' to
> +;; route handling to external (non-Emacs) app or service.
> +
> +;;; Code:
> +
> +(require 'seq)
This isn't required since seq is preloaded nowadays IIRC.
> +(declare-function dired-between-files "dired")
> +(declare-function dired-get-filename "dired")
> +(declare-function dired-get-marked-files "dired")
> +(declare-function dired-move-to-filename "dired")
> +
> +(defgroup send-to nil
> + "Send files or text to external applications or services."
> + :group 'external
> + :version "31.1")
> +
> +(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.
> +(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."
I see that the way to distinguish between a filename and "plain text" is
`file-exists-p'. Why not make filenames be a file: URL?
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).
> + :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. Also should this be buffer-local so different major-mode
can provide different providers? The current approach is a bit
difficult for major-mode authors to provide support for this feature.
> +;;;###autoload
> +(defun send-to-supported-p ()
> + "Return non-nil for platforms where `send-to' is supported."
> + (unless send-to-support-checker-function
> + (error "`send-to-support-checker-function' must be set"))
> + (funcall send-to-support-checker-function))
> +
> +;;;###autoload
> +(defun send-to (&optional items)
> + "Send file(s) or region text to external (non-Emacs) apps or services.
> +
> +Sending implementation is handled by `send-to-handler-function'.
> +
> +ITEMS list is automatically populated based on context.
> +See `send-to-context-items-function' for details.
> +
> +ITEMS can be overridden to send a specific list of items."
> + (interactive)
> + (unless send-to-handler-function
> + (error "`send-to-handler-function' must be set"))
> + (unless send-to-context-items-function
> + (error "`send-to-context-items-function' must be set"))
> + (dolist (item items)
> + (unless (stringp item)
> + (error "Item must be a string: %s" item)))
> + (funcall send-to-handler-function
> + (or items
> + (funcall send-to-context-items-function)
> + (user-error "Nothing to send"))))
> +
> +(defun send-to--format-items (items)
> + "Format ITEMS into a user-presentable message string."
> + (truncate-string-to-width
> + (string-join
> + (seq-map (lambda (item)
> + (if (and (stringp item)
> + (file-exists-p item))
> + (format "\"%s\"" (file-name-nondirectory item))
> + (format "\"%s\"" (truncate-string-to-width item 35 nil nil "…"))))
> + items) " ") 70 nil nil "…"))
> +
> +(defun send-to--dired-filenames-in-region ()
> + "If in `dired' buffer, return region files. nil otherwise."
> + (when (and (derived-mode-p 'dired-mode)
> + (use-region-p))
> + (let* ((start (region-beginning))
> + (end (region-end))
> + (marked-files (dired-get-marked-files nil nil nil t))
> + (active-marks-p (if (= (length marked-files) 1)
> + nil ;; File found at point (not marked)
> + (not (seq-empty-p marked-files))))
> + (filenames))
> + (when active-marks-p
> + (user-error "Either mark `dired' files or select a region, but not both"))
> + (save-excursion
> + (save-restriction
> + (goto-char start)
> + (while (< (point) end)
> + ;; Skip non-file lines.
> + (while (and (< (point) end) (dired-between-files))
> + (forward-line 1))
> + (when (and (dired-get-filename nil t)
> + ;; Filename must be in region.
> + (< (save-excursion
> + (forward-line 0)
> + (dired-move-to-filename))
> + end))
> + (setq filenames (append filenames (list (dired-get-filename nil t)))))
> + (forward-line 1))))
> + filenames)))
> +
> +(defun send-to--default-support-checker-p ()
> + "Return non-nil for platforms supporting send capability."
> + (or (and (featurep 'ns) (fboundp 'ns-send-items))
> + (executable-find "xdg-open")))
> +
> +(defun send-to--default-handler (items)
> + "Send ITEMS to external (non-Emacs) apps or services.
> +
> +ITEMS can be filenames or any text to send.
> +
> +Text is written to a temporary file before sending."
> + (unless items
> + (error "Nothing to send"))
> + (cond ((and (featurep 'ns) (fboundp 'ns-send-items))
> + (ns-send-items
> + (seq-map #'send-to--convert-item-to-filename items)))
> + ((executable-find "xdg-open")
> + (when (y-or-n-p (format "Open externally: %s ?"
> + (send-to--format-items items)))
> + (dolist (item items)
> + (with-temp-buffer
> + (unless (zerop (call-process
> + "xdg-open" nil (current-buffer) t
> + (send-to--convert-item-to-filename
> + item)))
> + (error "%s" (string-trim (buffer-string))))))))
> + (t
> + (error "Don't know how to sende %s (adjust `send-to-handler-function')"
^^^^^ Typo here!
> + (send-to--format-items items)))))
> +
> +(defun send-to--convert-item-to-filename (item)
> + "Convert ITEM to a filename.
> +
> +Unless ITEM is a verifiable filename, save its content to a file and
> +return its new timestamped filename."
> + (if (file-exists-p item)
> + item
> + (let ((filename (concat temporary-file-directory
> + (format-time-string "%F_%H.%M.%S") ".txt")))
> + (with-temp-file filename
> + (insert item))
> + filename)))
> +
> +(defun send-to--default-context-items ()
> + "Build a list of items to send based on default context.
> +
> +From a `dired' buffer, chosen items are based on either of these being active:
> +
> + - Marked files
> + - Files in region.
> + - File at point.
> +
> +From any other buffer, either of these two, in order of preference:
> +
> + - Active region text.
> + - Buffer file."
> + (cond ((derived-mode-p 'dired-mode)
> + (or
> + (send-to--dired-filenames-in-region)
> + (dired-get-marked-files)))
> + ((use-region-p)
> + (list (buffer-substring-no-properties
> + (region-beginning)
> + (region-end))))
> + ((buffer-file-name)
> + (list (buffer-file-name)))))
Why not add (thing-at-point 'existing-filename)? Addition of this will
also provide rudimentary support for other major-modes via
thing-at-point-provider-alist.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 12:33:01 GMT)
Full text and
rfc822 format available.
Message #310 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> What is the reason for the word "context" in this feature's
> name?
Couple of reasons:
1. The "Send to..." feature is accessible via the context menu,
displayed when right clicking on a buffer (this needs the existing
context-menu-mode minor mode turned on).
2. What is offered to send by the "Send to..." feature depends on
context. Either of the following can be sent, depending on which
is active:
- Current buffer filename.
- Region text.
- A selection of marked dired files.
- A selection of dired files in region.
- File at dired point.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 13:12:02 GMT)
Full text and
rfc822 format available.
Message #313 received at 76120 <at> debbugs.gnu.org (full text, mbox):
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?
>> +(require 'seq)
>
> This isn't required since seq is preloaded nowadays IIRC.
Great! Will remove.
>> +(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.
>> +(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."
>
> I see that the way to distinguish between a filename and "plain
> text" is
> `file-exists-p'. Why not make filenames be a file: URL?
Ah sure. This is an option. file: didn't occur to me.
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.
> 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.
>> + :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.
>> + (error "Don't know how to sende %s (adjust
>> `send-to-handler-function')"
> ^^^^^ Typo here!
>
Oops. Thanks!
>> + (cond ((derived-mode-p 'dired-mode)
>> + (or
>> + (send-to--dired-filenames-in-region)
>> + (dired-get-marked-files)))
>> + ((use-region-p)
>> + (list (buffer-substring-no-properties
>> + (region-beginning)
>> + (region-end))))
>> + ((buffer-file-name)
>> + (list (buffer-file-name)))))
>
> Why not add (thing-at-point 'existing-filename)?
No reason other than I didn't know ;) I can use thing-at-point.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 16:28:02 GMT)
Full text and
rfc822 format available.
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 17:21:01 GMT)
Full text and
rfc822 format available.
Message #319 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> +(defun send-to--default-support-checker-p ()
> + "Return non-nil for platforms supporting send capability."
> + (or (and (featurep 'ns) (fboundp 'ns-send-items))
> + (executable-find "xdg-open")))
> [...]
> + ((executable-find "xdg-open")
> + (when (y-or-n-p (format "Open externally: %s ?"
> + (send-to--format-items items)))
> + (dolist (item items)
> + (with-temp-buffer
> + (unless (zerop (call-process
> + "xdg-open" nil (current-buffer) t
> + (send-to--convert-item-to-filename
> + item)))
No need to duplicate (executable-find "xdg-open")
since it already exists in shell-command-guess-open
used by shell-command-do-open.
All the code with the name prefix shell-command-*
should be moved from dired-aux.el to a new file.
Then your code can be added to the same file.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 17:31:02 GMT)
Full text and
rfc822 format available.
Message #322 received at 76120 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 17:38:02 GMT)
Full text and
rfc822 format available.
Message #325 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> +(defun send-to--default-support-checker-p ()
>> + "Return non-nil for platforms supporting send capability."
>> + (or (and (featurep 'ns) (fboundp 'ns-send-items))
>> + (executable-find "xdg-open")))
>> [...]
>> + ((executable-find "xdg-open")
>> + (when (y-or-n-p (format "Open externally: %s ?"
>> + (send-to--format-items
>> items)))
>> + (dolist (item items)
>> + (with-temp-buffer
>> + (unless (zerop (call-process
>> + "xdg-open" nil (current-buffer)
>> t
>> +
>> (send-to--convert-item-to-filename
>> + item)))
>
> No need to duplicate (executable-find "xdg-open")
> since it already exists in shell-command-guess-open
> used by shell-command-do-open.
Ah, thanks. Sure I can use that.
>
> All the code with the name prefix shell-command-*
> should be moved from dired-aux.el to a new file.
>
> Then your code can be added to the same file.
Can we defer reorganizing dired-aux.el to a separate patch,
please?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 17:52:01 GMT)
Full text and
rfc822 format available.
Message #328 received at 76120 <at> debbugs.gnu.org (full text, mbox):
>> All the code with the name prefix shell-command-*
>> should be moved from dired-aux.el to a new file.
>>
>> Then your code can be added to the same file.
>
> Can we defer reorganizing dired-aux.el to a separate patch, please?
Indeed, this would be a separate task.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 18:00:03 GMT)
Full text and
rfc822 format available.
Message #331 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் பிப்ரவரி 20, 2025] Alvaro Ramirez wrote:
> Visuwesh <visuweshm <at> gmail.com> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 20 Feb 2025 22:16:02 GMT)
Full text and
rfc822 format available.
Message #334 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Thanks for this Visuwesh.
Visuwesh <visuweshm <at> gmail.com> writes:
> [வியாழன் பிப்ரவரி 20, 2025] Alvaro Ramirez wrote:
>
>> Visuwesh <visuweshm <at> gmail.com> 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.
This may sort itself out with a list of handlers. I'll have a play
with it, though will wait a bit for other's feedback before the
next patch iteration.
>>> 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.
Ah yes. I was thinking of defvar and defcustom as somewhat
equivalent customization points. Defvar SGTM.
>>>>>> +(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.
Maybe. If it's not growing here, it'll grow somewhere else. Let's
see how it pans out with the handler list. There may be
suggestions from others. Let's see.
>
>>> 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.
If possible, I'd prefer hiding the "Send to..." menu item if the
feature isn't supported on the platform. Signaling errors out of
the box may not be a great first experience.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Fri, 21 Feb 2025 00:56:04 GMT)
Full text and
rfc822 format available.
Message #337 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > It allows to send a file or a region of text to another application or
> > a service.
>
> The term "sharing" is very misleading for this; we use the word
> "share" for comething that people do with other people. So we should
> not adopt Apple's terminology.
As Eli already explained the term "share" in that context is an industry
term now days. Redefining would be good UX.
> I think "system invocation dialog" is a better name for us to use.
> Is there any reason that would be misleading?
>
> It's an addition to a feature we already have in Dired and
> > other places whereby a file can be "opened" by some external means,
> > like a program (e.g., to show it or do other actions with it) or a
> > printing service (e.g., to print the text).
>
> Does that mean it is comparable to the ! command in Dired?
No as the platform share dialog doesn't execute arbitrary programs but
a list of programs or actions. The term action is vague but largely
describes invoking programs specific to the dialogue to e.g. send a file
over Bluetooth, a service such as KDE connect or upload it to
some like Nextcloud. Some programs offer dialogues to only send a file
to a user without opening the program this way.
It's like the print dialogue but with other programs be able to hook
themselves into that dialog.
Because of that nature most of these API's to access these require the
use of libraries instead of some kind of IPC mechanism.
If this stays this way one way to add this feature to Emacs would be to
adopt either the window-system's implementation in the form of GNOME for
GTK builds or use some glib based implementation if there's a way to do
this without involvement of the window system toolkit. The latter would
work like freedesktop.org XDG-Desktop portals if that's possible. I
didn't design any of this I just investigated what is out there.
> Do shell commands exist on MacOS? Can users do with ! on MacOS the
> same things they can do with the system invocation dialog?
There's the open(1) command on macOS which is akin to xdg-open, but that
is not the same as the "share" dialog. open largely exactly like
xdg-open, the program is opened in the default application nothing else
happens.
> Perhaps the system invocation dialog has some conveniences -- for
> instance, not needing to remember shell commands or their syntax.
> Is that the case?
Yes exactly. It's just a list of programs to share the file with like a
Matrix messenger, common actions such as share over Bluetooth etc.
The point the benefit for this dialog is that all programs on the OS can
use this dialog giving the user consistent UX when e.g. sending files.
> If so, would those conveniences be convenient on GNU/Linux if they
> existed?
There would but at this moment there's no shared standard definition for
a standard for this. KDE has a implement for this which is support by
most of their applications. GNOME doesn't have a working implementation
by there are plans. It's largely a GNU/Freedesktop.org XDG/Linux thing.
> Should we aim to implement that system invocation dialog on GNU/Linux?
> Then it would be a feature that isn't MacOS-specific.
I'm not sure who is we in this context. GNU wouldn't be the best driver
of such efforts as Linux desktop standardization largely happened
around Freedesktop.org XDG.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Fri, 21 Feb 2025 02:49:02 GMT)
Full text and
rfc822 format available.
Message #340 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் பிப்ரவரி 20, 2025] Alvaro Ramirez wrote:
> If possible, I'd prefer hiding the "Send to..." menu item if the
> feature isn't supported on the platform. Signaling errors out of the
> box may not be a great first experience.
Never mind my suggestion about unifying -supported-p and -handler.
After a night's sleep, I realise it is not really possible to separate
them.
Like you say, I don't see how I could hide the "Send to..." menu if no
devices are currently via KDE Connect (which is different from running
the daemon).
[ Although I believe nowadays that you can send links still and they
would sent to the device all at once whenever it connects. ]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Fri, 21 Feb 2025 10:25:03 GMT)
Full text and
rfc822 format available.
Message #343 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
> [வியாழன் பிப்ரவரி 20, 2025] Alvaro Ramirez wrote:
>
>> If possible, I'd prefer hiding the "Send to..." menu item if
>> the
>> feature isn't supported on the platform. Signaling errors out
>> of the
>> box may not be a great first experience.
>
> Never mind my suggestion about unifying -supported-p and
> -handler.
Sounds good. Thanks for getting back.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 22 Feb 2025 00:35:02 GMT)
Full text and
rfc822 format available.
Message #346 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
What job does KDE Connect do? What aspects of KDE does it require the
user to use?
Is there a solution for that job which functions on a wider range of
GNU/Linux systems?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 22 Feb 2025 16:01:06 GMT)
Full text and
rfc822 format available.
Message #349 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> What job does KDE Connect do? What aspects of KDE does it
> require the
> user to use?
Not familiar with KDE Connect myself, but from their website
https://kdeconnect.kde.org :
"Enabling communication between all your devices. Made for people
like you.
Files and links. Shared between devices."
> Is there a solution for that job which functions on a wider
> range of
> GNU/Linux systems?
For the patch, we agreed to use xdg-open (widely available) as
GNU/Linux's default.
The patch also includes customisation points, should users prefer
to override the default. They could swap to KDE Connect (or
something else), if that's their preference.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sun, 23 Feb 2025 10:03:01 GMT)
Full text and
rfc822 format available.
Message #352 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> In interest of adapting my personal KDE Connect code as a plug-in for
> the new library, I have some comments below.
Is the idea that this feature will invoke some platform-specific
feature on each platform, and KDE Connect will be one of those
platform-specific features?
It looks that way, and it mekses sense, but could someone please confirm?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sun, 23 Feb 2025 10:03:02 GMT)
Full text and
rfc822 format available.
Message #355 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> How about "send-to" as package prefix instead of "share"? The
> context menu would also be "Send to...".
> "Send to" feels like a great candidate, as it would apply
> generally across different platforms.
It's good enough to use, and I don't have a better suggestion. If we
come across better choice, we can switch to that.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sun, 23 Feb 2025 10:09:02 GMT)
Full text and
rfc822 format available.
Message #358 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Richard Stallman <rms <at> gnu.org>
> Cc: alvaro <at> xenodium.com, eliz <at> gnu.org, stefankangas <at> gmail.com,
> 76120 <at> debbugs.gnu.org, shipmints <at> gmail.com
> Date: Sun, 23 Feb 2025 05:01:50 -0500
>
> > In interest of adapting my personal KDE Connect code as a plug-in for
> > the new library, I have some comments below.
>
> Is the idea that this feature will invoke some platform-specific
> feature on each platform, and KDE Connect will be one of those
> platform-specific features?
>
> It looks that way, and it mekses sense, but could someone please confirm?
Yes, that's the intent.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 25 Feb 2025 23:48:01 GMT)
Full text and
rfc822 format available.
Message #361 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> "Enabling communication between all your devices. Made for people
> like you.
Evidently not for people like me, because I can't understand what that
means.
> Files and links. Shared between devices."
I can't understand that either. What does it mean to "share links
between devices"?
There must be a less terse descri[topm pf oy -- can you find it and
send it?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 26 Feb 2025 00:24:01 GMT)
Full text and
rfc822 format available.
Message #364 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> > "Enabling communication between all your devices. Made for
> > people
> > like you.
>
> Evidently not for people like me, because I can't understand
> what that
> means.
Ah sure. They're quotes I found from
https://kdeconnect.kde.org. I'm not familiar with the project
myself.
> > Files and links. Shared between devices."
>
> I can't understand that either. What does it mean to "share
> links
> between devices"?
>
> There must be a less terse descri[topm pf oy -- can you find it
> and
> send it?
I found the following from https://userbase.kde.org/KDEConnect
"What is KDE Connect?"
"KDE Connect is a project that enables all your devices to
communicate with each other. Here's a few things KDE Connect can
do:""
"- Receive your phone notifications on your desktop computer and
reply to messages
- Control music playing on your desktop from your phone
- Use your phone as a remote control for your desktop
- Run predefined commands on your PC from connected devices. See
the list of example commands for more details.
- Check your phone's battery level from the desktop
- Ring your phone to help find it
- Share files and links between devices
- Browse your phone from your desktop
- Control the desktop's volume using your phone
- Send SMS from your desktop"
Probably best to take a looks at https://kdeconnect.kde.org and
https://userbase.kde.org/KDEConnect for details.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 26 Feb 2025 10:39:02 GMT)
Full text and
rfc822 format available.
Message #367 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Attaching the latest iteration of the patch (renamed
> 0004-Add-Send-to-context-menu-item-to-mouse-el.patch)..
Below are a couple of comments, if you are interested in feedback.
> * lisp/send-to.el: New package implements sending to apps or services.
The verb sending needs an object, i.e. sending what?
> +(non-Emacs) apps or services. See send-to.el for customisations.
Two spaces should separate sentences.
> + "Send item (region, buffer file, or dired files) to app or service")))
Dired is a proper noun and so should be capitalized.
> +(defgroup send-to nil
> + "Send files or text to external applications or services."
> + :group 'external
> + :version "31.1")
Inconsistent terminology: the patch says "apps" everywhere else.
(Personally, I am for saying "applications" everywhere.)
> + (error "Don't know how to sende %s (adjust `send-to-handler-function')"
A typo in the word send.
Thank you for your work on the patch!
Rudy
--
"One can begin to reason only when a clear picture has been formed in
the imagination."
--- Walter Warwick Sawyer, Mathematician's Delight, 1943
Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 26 Feb 2025 10:52:02 GMT)
Full text and
rfc822 format available.
Message #370 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> Attaching the latest iteration of the patch (renamed
>> 0004-Add-Send-to-context-menu-item-to-mouse-el.patch)..
>
> Below are a couple of comments, if you are interested in
> feedback.
Thank you Rudolf! I shall apply these in the next patch iteration.
>
>> * lisp/send-to.el: New package implements sending to apps or
>> services.
>
> The verb sending needs an object, i.e. sending what?
>
>> +(non-Emacs) apps or services. See send-to.el for
>> customisations.
>
> Two spaces should separate sentences.
>
>> + "Send item (region, buffer file, or dired files) to app or
>> service")))
>
> Dired is a proper noun and so should be capitalized.
>
>> +(defgroup send-to nil
>> + "Send files or text to external applications or services."
>> + :group 'external
>> + :version "31.1")
>
> Inconsistent terminology: the patch says "apps" everywhere else.
>
> (Personally, I am for saying "applications" everywhere.)
>
>> + (error "Don't know how to sende %s (adjust
>> `send-to-handler-function')"
>
> A typo in the word send.
>
> Thank you for your work on the patch!
>
> Rudy
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 04 Mar 2025 13:10:01 GMT)
Full text and
rfc822 format available.
Message #373 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi folks,
Thanks for all the feedback. Attaching the latest iteration of the
patch (0005-Add-Send-to-context-menu-item-to-mouse-el.patch),
applying your
suggestions.
Patch highlights:
- Introduces buffer-local `send-to-handlers' list var to break out
concrete handler functionality per platform (also makes it more
modular/pluggable).
- The list also enables changing platform handler priority.
- Now using shell-command-guess-open instead of xdg-open.
- I'm deferring changes to direx-aux as discussed with Juri.
- Fixes a bug in ns--share-items (native macOS menu displayed in
the wrong location, in multi-window layouts).
- Other tweaks as per feedback (Thank you Juri, Rudy, and
Visuwesh).
Re-attaching screenshots although there have been no UX changes
applied in this patch.
Please read on for relevant discussion of changes or refer to the
patch itself.
Alvaro
>> +(require 'seq)
> Visuwesh: This isn't required since seq is preloaded nowadays
> IIRC.
Removed.
>> +(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")
>
> Visuwesh: We should document how a filename is distinguished
> from plain text
> item here again.
Now documented in send-to-handlers.
>> +(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")
>
> Visuwesh: Also should this be buffer-local so different
> major-mode
> can provide different providers?
send-to-handlers is now buffer local.
>> + (error "Don't know how to sende %s (adjust
>> `send-to-handler-function')"
>
> Visuwesh: ^^^^^ Typo here!
Fixed.
>> + (cond ((derived-mode-p 'dired-mode)
>> + (or
>> + (send-to--dired-filenames-in-region)
>> + (dired-get-marked-files)))
>> + ((use-region-p)
>> + (list (buffer-substring-no-properties
>> + (region-beginning)
>> + (region-end))))
>> + ((buffer-file-name)
>> + (list (buffer-file-name)))))
>
> Visuwesh: Why not add (thing-at-point 'existing-filename)?
Added.
>> Yup. I do this frequently too. The current implementation
>> (using
>> file-exists-p) should handle sending URLs (ie. https://gnu.org)
>> as
>> text.
>
> Visuwesh: I think this test might fail if someone uses
> url-handler-mode.
Check now for local files only.
> Visuwesh: 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.
I've added send-to-handlers buffer-local var, which makes things
more modular/pluggable.
>> +(defun send-to--default-support-checker-p ()
>> + "Return non-nil for platforms supporting send capability."
>> + (or (and (featurep 'ns) (fboundp 'ns-send-items))
>> + (executable-find "xdg-open")))
>> [...]
>> + ((executable-find "xdg-open")
>> + (when (y-or-n-p (format "Open externally: %s ?"
>> + (send-to--format-items
>> items)))
>> + (dolist (item items)
>> + (with-temp-buffer
>> + (unless (zerop (call-process
>> + "xdg-open" nil (current-buffer)
>> t
>> +
>> (send-to--convert-item-to-filename
>> + item)))
>
> Juri: No need to duplicate (executable-find "xdg-open")
> since it already exists in shell-command-guess-open
> used by shell-command-do-open.
Now using shell-command-guess-open, but conditionally loading via:
(unless (boundp 'shell-command-guess-open)
(require 'dired-aux))
>> Can we defer reorganizing dired-aux.el to a separate patch,
>> please?
>
> Juri: Indeed, this would be a separate task.
Until dired-aux bits are moved, I'm requiring conditionally (see
above) as it caused issues (happy to take an alternate approach):
alvaro <at> linux $ make
...
Error: error ("Eager macro-expansion failure: (void-function
easy-menu-define)")
signal(error ("Eager macro-expansion failure: (void-function
easy-menu-define)"))
error("Eager macro-expansion failure: %S" (void-function
easy-menu-define))
(condition-case err (let ((macroexp--pending-eager-loads (cons
load-file-name macroexp--pending-eager-loads))) (if full-p
(macroexpand--all-toplevel form) (macroexpand form))) ((debug
error) (error "Eager macro-expansion failure: %S" err) form))
(cond ((eq 'skip (car macroexp--pending-eager-loads)) form)
((and load-file-name (member load-file-name
macroexp--pending-eager-loads)) (let* ((bt (delq nil (mapcar
#'macroexp--trim-backtrace-frame (macroexp--backtrace)))) (elem
(list 'load (file-name-nondirectory load-file-name))) (tail
(member elem (cdr (member elem bt))))) (if tail (setcdr tail
(list '…))) (if (eq (car-safe (car bt)) 'macroexpand-all) (setq
bt (cdr bt))) (if macroexp--debug-eager (debug
'eager-macroexp-cycle) (error "Eager macro-expansion skipped due
to cycle:\n %s" (mapconcat #'prin1-to-string (nreverse bt) " =>
"))) (setq macroexp--pending-eager-loads (cons 'skip
macroexp--pending-eager-loads)) form)) (t (condition-case err
(let ((macroexp--pending-eager-loads (cons load-file-name
macroexp--pending-eager-loads))) (if full-p
(macroexpand--all-toplevel form) (macroexpand form))) ((debug
error) (error "Eager macro-expansion failure: %S" err) form))))
internal-macroexpand-for-load((eval-when-compile (require
'send-to)) nil)
eval-buffer(#<buffer *load*> nil
"/home/alvaro/Downloads/emacs/lisp/mouse.el" nil t)
...
> Visuwesh: Sure. It could be equally well be a defvar.
Switched to defvar-local.
> Richard: It's good enough to use, and I don't have a better
> suggestion. If we
> come across better choice, we can switch to that.
Sounds good. Using "send" as agreed.
>> * lisp/send-to.el: New package implements sending to apps or
>> services.
> Rudy: The verb sending needs an object, i.e. sending what?
Now says: "New package implements sending files/region."
>> +(non-Emacs) apps or services. See send-to.el for
>> customisations.
>
> Rudy: Two spaces should separate sentences.
Done
>> + "Send item (region, buffer file, or dired files) to app or
>> service")))
> Rudy: Dired is a proper noun and so should be capitalized.
Done
>> +(defgroup send-to nil
>> + "Send files or text to external applications or services."
>> + :group 'external
>> + :version "31.1")
>
> Rudy: Inconsistent terminology: the patch says "apps" everywhere
> else.
>
> (Personally, I am for saying "applications" everywhere.)
Switched to "applications" everywhere.
>> + (error "Don't know how to sende %s (adjust
>> `send-to-handler-function')"
> Rudy: A typo in the word send.
Fixed
[0005-Add-Send-to-context-menu-item-to-mouse-el.patch (text/x-patch, attachment)]
[macos.jpg (image/jpeg, attachment)]
[linux.jpg (image/jpeg, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 04 Mar 2025 13:44:02 GMT)
Full text and
rfc822 format available.
Message #376 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Hi folks,
>
> Thanks for all the feedback. Attaching the latest iteration of
> the
> patch (0005-Add-Send-to-context-menu-item-to-mouse-el.patch),
> applying
> your
> suggestions.
>
> Patch highlights:
>
> - Introduces buffer-local `send-to-handlers' list var to break
> out
> concrete handler functionality per platform (also makes it
> more
> modular/pluggable).
> - The list also enables changing platform handler priority.
> - Now using shell-command-guess-open instead of xdg-open.
> - I'm deferring changes to direx-aux as discussed with Juri.
> - Fixes a bug in ns--share-items (native macOS menu displayed in
> the
> wrong location, in multi-window layouts).
> - Other tweaks as per feedback (Thank you Juri, Rudy, and
> Visuwesh).
>
> Re-attaching screenshots although there have been no UX changes
> applied in this patch.
Sorry. Wrong screenshots before. Please ignore.
Attaching send-gnu-linux.jpg and send-macos.jpg, which show the
use of "Send to..." instead of "Share..." terminology.
>
> Please read on for relevant discussion of changes or refer to
> the
> patch itself.
>
> Alvaro
>
>>> +(require 'seq)
>> Visuwesh: This isn't required since seq is preloaded nowadays
>> IIRC.
>
> Removed.
>
>>> +(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")
>>
>> Visuwesh: We should document how a filename is distinguished
>> from
>> plain text
>> item here again.
>
> Now documented in send-to-handlers.
>
>>> +(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")
>>
>> Visuwesh: Also should this be buffer-local so different
>> major-mode
>> can provide different providers?
>
> send-to-handlers is now buffer local.
>
>>> + (error "Don't know how to sende %s (adjust
>>> `send-to-handler-function')"
>>
>> Visuwesh: ^^^^^ Typo here!
>
> Fixed.
>
>>> + (cond ((derived-mode-p 'dired-mode)
>>> + (or
>>> + (send-to--dired-filenames-in-region)
>>> + (dired-get-marked-files)))
>>> + ((use-region-p)
>>> + (list (buffer-substring-no-properties
>>> + (region-beginning)
>>> + (region-end))))
>>> + ((buffer-file-name)
>>> + (list (buffer-file-name)))))
>>
>> Visuwesh: Why not add (thing-at-point 'existing-filename)?
>
> Added.
>
>>> Yup. I do this frequently too. The current implementation
>>> (using
>>> file-exists-p) should handle sending URLs
>>> (ie. https://gnu.org) as
>>> text.
>>
>> Visuwesh: I think this test might fail if someone uses
>> url-handler-mode.
>
> Check now for local files only.
>
>> Visuwesh: 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.
>
> I've added send-to-handlers buffer-local var, which makes things
> more
> modular/pluggable.
>
>>> +(defun send-to--default-support-checker-p ()
>>> + "Return non-nil for platforms supporting send capability."
>>> + (or (and (featurep 'ns) (fboundp 'ns-send-items))
>>> + (executable-find "xdg-open")))
>>> [...]
>>> + ((executable-find "xdg-open")
>>> + (when (y-or-n-p (format "Open externally: %s ?"
>>> + (send-to--format-items
>>> items)))
>>> + (dolist (item items)
>>> + (with-temp-buffer
>>> + (unless (zerop (call-process
>>> + "xdg-open" nil
>>> (current-buffer) t
>>> + (send-to--convert-item-to-filename
>>> + item)))
>>
>> Juri: No need to duplicate (executable-find "xdg-open")
>> since it already exists in shell-command-guess-open
>> used by shell-command-do-open.
>
> Now using shell-command-guess-open, but conditionally loading
> via:
>
> (unless (boundp 'shell-command-guess-open)
> (require 'dired-aux))
>
>>> Can we defer reorganizing dired-aux.el to a separate patch,
>>> please?
>>
>> Juri: Indeed, this would be a separate task.
>
> Until dired-aux bits are moved, I'm requiring conditionally (see
> above) as it caused issues (happy to take an alternate
> approach):
>
> alvaro <at> linux $ make
>
> ...
>
> Error: error ("Eager macro-expansion failure: (void-function
> easy-menu-define)")
> signal(error ("Eager macro-expansion failure: (void-function
> easy-menu-define)"))
> error("Eager macro-expansion failure: %S" (void-function
> easy-menu-define))
> (condition-case err (let ((macroexp--pending-eager-loads (cons
> load-file-name macroexp--pending-eager-loads))) (if full-p
> (macroexpand--all-toplevel form) (macroexpand form))) ((debug
> error) (error "Eager macro-expansion failure: %S" err) form))
> (cond ((eq 'skip (car macroexp--pending-eager-loads)) form)
> ((and
> load-file-name (member load-file-name
> macroexp--pending-eager-loads)) (let* ((bt (delq nil (mapcar
> #'macroexp--trim-backtrace-frame (macroexp--backtrace)))) (elem
> (list 'load (file-name-nondirectory load-file-name))) (tail
> (member
> elem (cdr (member elem bt))))) (if tail (setcdr tail (list
> '…)))
> (if (eq (car-safe (car bt)) 'macroexpand-all) (setq bt (cdr
> bt)))
> (if macroexp--debug-eager (debug 'eager-macroexp-cycle)
> (error
> "Eager macro-expansion skipped due to cycle:\n %s"
> (mapconcat
> #'prin1-to-string (nreverse bt) " => "))) (setq
> macroexp--pending-eager-loads (cons 'skip
> macroexp--pending-eager-loads)) form)) (t (condition-case err
> (let
> ((macroexp--pending-eager-loads (cons load-file-name
> macroexp--pending-eager-loads))) (if full-p
> (macroexpand--all-toplevel form) (macroexpand form))) ((debug
> error) (error "Eager macro-expansion failure: %S" err) form))))
> internal-macroexpand-for-load((eval-when-compile (require
> 'send-to)) nil)
> eval-buffer(#<buffer *load*> nil
> "/home/alvaro/Downloads/emacs/lisp/mouse.el" nil t)
>
> ...
>
>> Visuwesh: Sure. It could be equally well be a defvar.
>
> Switched to defvar-local.
>
>> Richard: It's good enough to use, and I don't have a better
>> suggestion. If we
>> come across better choice, we can switch to that.
>
> Sounds good. Using "send" as agreed.
>
>>> * lisp/send-to.el: New package implements sending to apps or
>>> services.
>> Rudy: The verb sending needs an object, i.e. sending what?
>
> Now says: "New package implements sending files/region."
>
>>> +(non-Emacs) apps or services. See send-to.el for
>>> customisations.
>>
>> Rudy: Two spaces should separate sentences.
>
> Done
>
>>> + "Send item (region, buffer file, or dired files) to app or
>>> service")))
>> Rudy: Dired is a proper noun and so should be capitalized.
>
> Done
>
>>> +(defgroup send-to nil
>>> + "Send files or text to external applications or services."
>>> + :group 'external
>>> + :version "31.1")
>>
>> Rudy: Inconsistent terminology: the patch says "apps"
>> everywhere
>> else.
>>
>> (Personally, I am for saying "applications" everywhere.)
>
> Switched to "applications" everywhere.
>
>>> + (error "Don't know how to sende %s (adjust
>>> `send-to-handler-function')"
>> Rudy: A typo in the word send.
>
> Fixed
>
> [2. text/x-patch;
> 0005-Add-Send-to-context-menu-item-to-mouse-el.patch]...
>
> [3. image/jpeg; macos.jpg]...
>
> [4. image/jpeg; linux.jpg]...
[send-macos.jpg (image/jpeg, attachment)]
[send-gnu-linux.jpg (image/jpeg, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Thu, 13 Mar 2025 13:48:02 GMT)
Full text and
rfc822 format available.
Message #379 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Hi Eli and Stefan
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> Hi folks,
>>
>> Thanks for all the feedback. Attaching the latest iteration of
>> the
>> patch (0005-Add-Send-to-context-menu-item-to-mouse-el.patch),
>> applying your suggestions.
Anything else I should address in the patch
(0005-Add-Send-to-context-menu-item-to-mouse-el.patch)?
>>
>> Patch highlights:
>>
>> - Introduces buffer-local `send-to-handlers' list var to break
>> out
>> concrete handler functionality per platform (also makes it
>> more
>> modular/pluggable).
>> - The list also enables changing platform handler priority.
>> - Now using shell-command-guess-open instead of xdg-open.
>> - I'm deferring changes to direx-aux as discussed with Juri.
>> - Fixes a bug in ns--share-items (native macOS menu displayed
>> in the
>> wrong location, in multi-window layouts).
>> - Other tweaks as per feedback (Thank you Juri, Rudy, and
>> Visuwesh).
>>
>> Re-attaching screenshots although there have been no UX changes
>> applied in this patch.
>
> Sorry. Wrong screenshots before. Please ignore.
>
> Attaching send-gnu-linux.jpg and send-macos.jpg, which show the
> use of
> "Send to..." instead of "Share..." terminology.
>>
>> Please read on for relevant discussion of changes or refer to
>> the
>> patch itself.
>>
>> Alvaro
>>
>>>> +(require 'seq)
>>> Visuwesh: This isn't required since seq is preloaded nowadays
>>> IIRC.
>>
>> Removed.
>>
>>>> +(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")
>>>
>>> Visuwesh: We should document how a filename is distinguished
>>> from
>>> plain text
>>> item here again.
>>
>> Now documented in send-to-handlers.
>>
>>>> +(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")
>>>
>>> Visuwesh: Also should this be buffer-local so different
>>> major-mode
>>> can provide different providers?
>>
>> send-to-handlers is now buffer local.
>>
>>>> + (error "Don't know how to sende %s (adjust
>>>> `send-to-handler-function')"
>>>
>>> Visuwesh: ^^^^^ Typo here!
>>
>> Fixed.
>>
>>>> + (cond ((derived-mode-p 'dired-mode)
>>>> + (or
>>>> + (send-to--dired-filenames-in-region)
>>>> + (dired-get-marked-files)))
>>>> + ((use-region-p)
>>>> + (list (buffer-substring-no-properties
>>>> + (region-beginning)
>>>> + (region-end))))
>>>> + ((buffer-file-name)
>>>> + (list (buffer-file-name)))))
>>>
>>> Visuwesh: Why not add (thing-at-point 'existing-filename)?
>>
>> Added.
>>
>>>> Yup. I do this frequently too. The current implementation
>>>> (using
>>>> file-exists-p) should handle sending URLs
>>>> (ie. https://gnu.org) as
>>>> text.
>>>
>>> Visuwesh: I think this test might fail if someone uses
>>> url-handler-mode.
>>
>> Check now for local files only.
>>
>>> Visuwesh: 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.
>>
>> I've added send-to-handlers buffer-local var, which makes
>> things
>> more
>> modular/pluggable.
>>
>>>> +(defun send-to--default-support-checker-p ()
>>>> + "Return non-nil for platforms supporting send capability."
>>>> + (or (and (featurep 'ns) (fboundp 'ns-send-items))
>>>> + (executable-find "xdg-open")))
>>>> [...]
>>>> + ((executable-find "xdg-open")
>>>> + (when (y-or-n-p (format "Open externally: %s ?"
>>>> + (send-to--format-items
>>>> items)))
>>>> + (dolist (item items)
>>>> + (with-temp-buffer
>>>> + (unless (zerop (call-process
>>>> + "xdg-open" nil
>>>> (current-buffer) t
>>>> + (send-to--convert-item-to-filename
>>>> + item)))
>>>
>>> Juri: No need to duplicate (executable-find "xdg-open")
>>> since it already exists in shell-command-guess-open
>>> used by shell-command-do-open.
>>
>> Now using shell-command-guess-open, but conditionally loading
>> via:
>>
>> (unless (boundp 'shell-command-guess-open)
>> (require 'dired-aux))
>>
>>>> Can we defer reorganizing dired-aux.el to a separate patch,
>>>> please?
>>>
>>> Juri: Indeed, this would be a separate task.
>>
>> Until dired-aux bits are moved, I'm requiring conditionally
>> (see
>> above) as it caused issues (happy to take an alternate
>> approach):
>>
>> alvaro <at> linux $ make
>>
>> ...
>>
>> Error: error ("Eager macro-expansion failure: (void-function
>> easy-menu-define)")
>> signal(error ("Eager macro-expansion failure: (void-function
>> easy-menu-define)"))
>> error("Eager macro-expansion failure: %S" (void-function
>> easy-menu-define))
>> (condition-case err (let ((macroexp--pending-eager-loads (cons
>> load-file-name macroexp--pending-eager-loads))) (if full-p
>> (macroexpand--all-toplevel form) (macroexpand form))) ((debug
>> error) (error "Eager macro-expansion failure: %S" err) form))
>> (cond ((eq 'skip (car macroexp--pending-eager-loads)) form)
>> ((and
>> load-file-name (member load-file-name
>> macroexp--pending-eager-loads)) (let* ((bt (delq nil (mapcar
>> #'macroexp--trim-backtrace-frame (macroexp--backtrace))))
>> (elem
>> (list 'load (file-name-nondirectory load-file-name))) (tail
>> (member
>> elem (cdr (member elem bt))))) (if tail (setcdr tail (list
>> '…)))
>> (if (eq (car-safe (car bt)) 'macroexpand-all) (setq bt (cdr
>> bt)))
>> (if macroexp--debug-eager (debug 'eager-macroexp-cycle)
>> (error
>> "Eager macro-expansion skipped due to cycle:\n %s"
>> (mapconcat
>> #'prin1-to-string (nreverse bt) " => "))) (setq
>> macroexp--pending-eager-loads (cons 'skip
>> macroexp--pending-eager-loads)) form)) (t (condition-case err
>> (let
>> ((macroexp--pending-eager-loads (cons load-file-name
>> macroexp--pending-eager-loads))) (if full-p
>> (macroexpand--all-toplevel form) (macroexpand form))) ((debug
>> error) (error "Eager macro-expansion failure: %S" err)
>> form))))
>> internal-macroexpand-for-load((eval-when-compile (require
>> 'send-to)) nil)
>> eval-buffer(#<buffer *load*> nil
>> "/home/alvaro/Downloads/emacs/lisp/mouse.el" nil t)
>>
>> ...
>>
>>> Visuwesh: Sure. It could be equally well be a defvar.
>>
>> Switched to defvar-local.
>>
>>> Richard: It's good enough to use, and I don't have a better
>>> suggestion. If we
>>> come across better choice, we can switch to that.
>>
>> Sounds good. Using "send" as agreed.
>>
>>>> * lisp/send-to.el: New package implements sending to apps or
>>>> services.
>>> Rudy: The verb sending needs an object, i.e. sending what?
>>
>> Now says: "New package implements sending files/region."
>>
>>>> +(non-Emacs) apps or services. See send-to.el for
>>>> customisations.
>>>
>>> Rudy: Two spaces should separate sentences.
>>
>> Done
>>
>>>> + "Send item (region, buffer file, or dired files) to app or
>>>> service")))
>>> Rudy: Dired is a proper noun and so should be capitalized.
>>
>> Done
>>
>>>> +(defgroup send-to nil
>>>> + "Send files or text to external applications or services."
>>>> + :group 'external
>>>> + :version "31.1")
>>>
>>> Rudy: Inconsistent terminology: the patch says "apps"
>>> everywhere
>>> else.
>>>
>>> (Personally, I am for saying "applications" everywhere.)
>>
>> Switched to "applications" everywhere.
>>
>>>> + (error "Don't know how to sende %s (adjust
>>>> `send-to-handler-function')"
>>> Rudy: A typo in the word send.
>>
>> Fixed
>>
>> [2. text/x-patch;
>> 0005-Add-Send-to-context-menu-item-to-mouse-el.patch]...
>>
>> [3. image/jpeg; macos.jpg]...
>>
>> [4. image/jpeg; linux.jpg]...
>
> [2. image/jpeg; send-macos.jpg]...
>
> [3. image/jpeg; send-gnu-linux.jpg]...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Mar 2025 11:19:01 GMT)
Full text and
rfc822 format available.
Message #382 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: 76120 <at> debbugs.gnu.org
> Date: Tue, 04 Mar 2025 13:08:48 +0000
>
> Thanks for all the feedback. Attaching the latest iteration of the
> patch (0005-Add-Send-to-context-menu-item-to-mouse-el.patch),
> applying your
> suggestions.
Thanks.
Stefan, would you please install this? I don't use macOS, so would
prefer not to install changes I cannot compile.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Mar 2025 12:16:02 GMT)
Full text and
rfc822 format available.
Message #385 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[செவ்வாய் மார்ச் 04, 2025] Alvaro Ramirez wrote:
Sorry, I was busy with $LIFE so couldn't get a chance to look at the
latest patch properly.
> Hi folks,
>
> Thanks for all the feedback. Attaching the latest iteration of the
> patch (0005-Add-Send-to-context-menu-item-to-mouse-el.patch), applying
> your
> suggestions.
>
> Patch highlights:
>
> - Introduces buffer-local `send-to-handlers' list var to break out
> concrete handler functionality per platform (also makes it more
> modular/pluggable).
> - The list also enables changing platform handler priority.
> - Now using shell-command-guess-open instead of xdg-open.
> - I'm deferring changes to direx-aux as discussed with Juri.
> - Fixes a bug in ns--share-items (native macOS menu displayed in the
> wrong location, in multi-window layouts).
> - Other tweaks as per feedback (Thank you Juri, Rudy, and Visuwesh).
>
> Re-attaching screenshots although there have been no UX changes
> applied in this patch.
>
> Please read on for relevant discussion of changes or refer to the
> patch itself.
>
> Alvaro
>
>>> +(require 'seq)
>> Visuwesh: This isn't required since seq is preloaded nowadays IIRC.
>
> Removed.
>
>>> +(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")
>>
>> Visuwesh: We should document how a filename is distinguished from
>> plain text
>> item here again.
>
> Now documented in send-to-handlers.
>
>>> +(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")
>>
>> Visuwesh: Also should this be buffer-local so different major-mode
>> can provide different providers?
>
> send-to-handlers is now buffer local.
>
>>> + (error "Don't know how to sende %s (adjust
>>> `send-to-handler-function')"
>>
>> Visuwesh: ^^^^^ Typo here!
>
> Fixed.
>
>>> + (cond ((derived-mode-p 'dired-mode)
>>> + (or
>>> + (send-to--dired-filenames-in-region)
>>> + (dired-get-marked-files)))
>>> + ((use-region-p)
>>> + (list (buffer-substring-no-properties
>>> + (region-beginning)
>>> + (region-end))))
>>> + ((buffer-file-name)
>>> + (list (buffer-file-name)))))
>>
>> Visuwesh: Why not add (thing-at-point 'existing-filename)?
>
> Added.
>
>>> Yup. I do this frequently too. The current implementation (using
>>> file-exists-p) should handle sending URLs (ie. https://gnu.org) as
>>> text.
>>
>> Visuwesh: I think this test might fail if someone uses
>> url-handler-mode.
>
> Check now for local files only.
>
>> Visuwesh: 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.
>
> I've added send-to-handlers buffer-local var, which makes things more
> modular/pluggable.
>
>>> +(defun send-to--default-support-checker-p ()
>>> + "Return non-nil for platforms supporting send capability."
>>> + (or (and (featurep 'ns) (fboundp 'ns-send-items))
>>> + (executable-find "xdg-open")))
>>> [...]
>>> + ((executable-find "xdg-open")
>>> + (when (y-or-n-p (format "Open externally: %s ?"
>>> + (send-to--format-items items)))
>>> + (dolist (item items)
>>> + (with-temp-buffer
>>> + (unless (zerop (call-process
>>> + "xdg-open" nil (current-buffer) t
>>> + (send-to--convert-item-to-filename
>>> + item)))
>>
>> Juri: No need to duplicate (executable-find "xdg-open")
>> since it already exists in shell-command-guess-open
>> used by shell-command-do-open.
>
> Now using shell-command-guess-open, but conditionally loading via:
>
> (unless (boundp 'shell-command-guess-open)
> (require 'dired-aux))
>
>>> Can we defer reorganizing dired-aux.el to a separate patch, please?
>>
>> Juri: Indeed, this would be a separate task.
>
> Until dired-aux bits are moved, I'm requiring conditionally (see
> above) as it caused issues (happy to take an alternate approach):
>
> alvaro <at> linux $ make
>
> ...
>
> Error: error ("Eager macro-expansion failure: (void-function
> easy-menu-define)")
> signal(error ("Eager macro-expansion failure: (void-function
> easy-menu-define)"))
> error("Eager macro-expansion failure: %S" (void-function
> easy-menu-define))
> (condition-case err (let ((macroexp--pending-eager-loads (cons
> load-file-name macroexp--pending-eager-loads))) (if full-p
> (macroexpand--all-toplevel form) (macroexpand form))) ((debug
> error) (error "Eager macro-expansion failure: %S" err) form))
> (cond ((eq 'skip (car macroexp--pending-eager-loads)) form) ((and
> load-file-name (member load-file-name
> macroexp--pending-eager-loads)) (let* ((bt (delq nil (mapcar
> #'macroexp--trim-backtrace-frame (macroexp--backtrace)))) (elem
> (list 'load (file-name-nondirectory load-file-name))) (tail (member
> elem (cdr (member elem bt))))) (if tail (setcdr tail (list '…)))
> (if (eq (car-safe (car bt)) 'macroexpand-all) (setq bt (cdr bt)))
> (if macroexp--debug-eager (debug 'eager-macroexp-cycle) (error
> "Eager macro-expansion skipped due to cycle:\n %s" (mapconcat
> #'prin1-to-string (nreverse bt) " => "))) (setq
> macroexp--pending-eager-loads (cons 'skip
> macroexp--pending-eager-loads)) form)) (t (condition-case err (let
> ((macroexp--pending-eager-loads (cons load-file-name
> macroexp--pending-eager-loads))) (if full-p
> (macroexpand--all-toplevel form) (macroexpand form))) ((debug
> error) (error "Eager macro-expansion failure: %S" err) form))))
> internal-macroexpand-for-load((eval-when-compile (require
> 'send-to)) nil)
> eval-buffer(#<buffer *load*> nil
> "/home/alvaro/Downloads/emacs/lisp/mouse.el" nil t)
>
> ...
>
>> Visuwesh: Sure. It could be equally well be a defvar.
>
> Switched to defvar-local.
>
>> Richard: It's good enough to use, and I don't have a better
>> suggestion. If we
>> come across better choice, we can switch to that.
>
> Sounds good. Using "send" as agreed.
>
>>> * lisp/send-to.el: New package implements sending to apps or
>>> services.
>> Rudy: The verb sending needs an object, i.e. sending what?
>
> Now says: "New package implements sending files/region."
>
>>> +(non-Emacs) apps or services. See send-to.el for customisations.
>>
>> Rudy: Two spaces should separate sentences.
>
> Done
>
>>> + "Send item (region, buffer file, or dired files) to app or
>>> service")))
>> Rudy: Dired is a proper noun and so should be capitalized.
>
> Done
>
>>> +(defgroup send-to nil
>>> + "Send files or text to external applications or services."
>>> + :group 'external
>>> + :version "31.1")
>>
>> Rudy: Inconsistent terminology: the patch says "apps" everywhere
>> else.
>>
>> (Personally, I am for saying "applications" everywhere.)
>
> Switched to "applications" everywhere.
>
>>> + (error "Don't know how to sende %s (adjust
>>> `send-to-handler-function')"
>> Rudy: A typo in the word send.
>
> Fixed
>
> From ef2debe64a9c909b40d669e779eacc581821e81b Mon Sep 17 00:00:00 2001
> From: Alvaro Ramirez <me <at> xenodium.com>
> From: xenodium <8107219+xenodium <at> users.noreply.github.com>
> Date: Thu, 13 Feb 2025 17:30:01 +0000
> Subject: [PATCH] Add "Send to..." context menu item to mouse.el
>
> * lisp/send-to.el: New package implements sending files/region.
>
> * lisp/mouse.el (context-menu-send-to): Add "Send to..." context menu.
>
> * lisp/term/ns-win.el (ns-send-items): Expose native macOS send API.
>
> * src/nsfns.m (ns-send-items): Implement native macOS sending.
>
> * etc/NEWS: Announce the new feature.
> ---
> etc/NEWS | 7 ++
> lisp/mouse.el | 17 +++-
> lisp/send-to.el | 233 ++++++++++++++++++++++++++++++++++++++++++++
> lisp/term/ns-win.el | 1 +
> src/nsfns.m | 54 ++++++++++
> 5 files changed, 311 insertions(+), 1 deletion(-)
> create mode 100644 lisp/send-to.el
>
> diff --git a/etc/NEWS b/etc/NEWS
> index dea24adb3c9..3b79d3c24d0 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -280,6 +280,13 @@ customize help text for tabs displayed on the tab-bar. Help text is
> normally shown in the echo area or via tooltips. See the variable's
> docstring for arguments passed to a help-text function.
>
> +** Mouse
> +
> +---
> +*** context-menu-mode now includes a "Send to..." menu item.
> +The menu item enables sending current file(s) or region text to external
> +(non-Emacs) apps or services. See send-to.el for customisations.
> +
> ** Project
>
> ---
> diff --git a/lisp/mouse.el b/lisp/mouse.el
> index 1f0ca6a51b6..0d74b1e5ca1 100644
> --- a/lisp/mouse.el
> +++ b/lisp/mouse.el
> @@ -30,6 +30,7 @@
> ;;; Code:
>
> (eval-when-compile (require 'rect))
> +(eval-when-compile (require 'send-to))
>
> ;; Indent track-mouse like progn.
> (put 'track-mouse 'lisp-indent-function 0)
> @@ -393,7 +394,8 @@ context-menu-functions
> context-menu-region
> context-menu-middle-separator
> context-menu-local
> - context-menu-minor)
> + context-menu-minor
> + context-menu-send-to)
> "List of functions that produce the contents of the context menu.
> Each function receives the menu and the mouse click event as its arguments
> and should return the same menu with changes such as added new menu items."
> @@ -536,6 +538,19 @@ context-menu-minor
> (cdr mode))))
> menu)
>
> +(defun context-menu-send-to (menu _click)
> + "Add a \"Send to...\" context MENU entry on supported platforms."
> + (run-hooks 'activate-menubar-hook 'menu-bar-update-hook)
> + (when (send-to-supported-p)
> + (define-key-after menu [separator-send] menu-bar-separator)
> + (define-key-after menu [send]
> + '(menu-item "Send to..." (lambda ()
> + (interactive)
> + (send-to))
> + :help
> + "Send item (region, buffer file, or Dired files) to app or service")))
> + menu)
Sorry for asking this so late in the game... should we allow the backend
itself to return a keymap for the context-menu? This would further
prompting/choosing "where to send" in some backends.
> (defun context-menu-buffers (menu _click)
> "Populate MENU with the buffer submenus to buffer switching."
> (run-hooks 'activate-menubar-hook 'menu-bar-update-hook)
> diff --git a/lisp/send-to.el b/lisp/send-to.el
> new file mode 100644
> index 00000000000..064f5ad6645
> --- /dev/null
> +++ b/lisp/send-to.el
> @@ -0,0 +1,233 @@
> [...]
> +(defvar-local send-to-handlers '(((:supported . send-to--ns-supported-p)
> + (:collect . send-to--collect-items)
> + (:send . send-to--ns-send-items))
> + ((:supported . send-to--open-externally-supported-p)
> + (:collect . send-to--collect-items)
> + (:send . send-to--open-externally)))
I wonder if coupling collect with other items here is a good idea. We
could have a separate var for collect functions akin to
context-menu-functions, that major-mode authors could modify.
BTW, seeing the list makes me wonder if using cl-defgeneric for
support&send functions would be more ergonomic for backend authors. To
select the right backend, we could have something like
xref-backend-functions.
> [...]
> +;;;###autoload
> +(defun send-to-supported-p ()
> + "Return non-nil for platforms where `send-to' is supported."
> + (funcall (map-elt (send-to--resolve-handler) :supported)))
Why not nth? I believe it should be a bit faster.
> [...]
> +(defun send-to--open-externally (items)
> + "Open ITEMS externally (using a non-Emacs application)."
> + (unless (boundp 'shell-command-guess-open)
> + (require 'dired-aux))
> + (when (y-or-n-p (format "Open externally: %s ?"
> + (send-to--format-items items)))
> + (dolist (item items)
> + (with-temp-buffer
> + (unless (zerop (call-process
> + shell-command-guess-open nil (current-buffer) t
> + (send-to--convert-item-to-filename
> + item)))
> + (error "%s" (string-trim (buffer-string))))))))
> +
> +(defun send-to--convert-item-to-filename (item)
> + "Convert ITEM to a filename.
> +
> +Unless ITEM is a verifiable filename, save its content to a file and
> +return its new timestamped filename."
> + (if (and (file-local-name item) ;; Ignore url-handler-mode
> + (file-exists-p item))
> + item
> + (let ((filename (concat temporary-file-directory
> + (format-time-string "%F_%H.%M.%S") ".txt")))
> + (with-temp-file filename
> + (insert item))
> + filename)))
Why this renaming? Wouldn't users want to open the original file
instead of a copy?
> +(defun send-to--collect-items ()
> + "Build a list of items to send based on default context.
> +
> +From a `dired' buffer, chosen items are based on either of these being
> +active:
> +
> + - Marked files
> + - Files in region.
> + - File at point.
> +
> +From any other buffer, either of these two, in order of preference:
> +
> + - Active region text.
> + - Thing at point (via `existing-filename').
> + - Buffer file."
> + (cond ((derived-mode-p 'dired-mode)
> + (or
> + (send-to--dired-filenames-in-region)
> + (dired-get-marked-files)))
> + ((use-region-p)
> + (list (buffer-substring-no-properties
> + (region-beginning)
> + (region-end))))
> + ((thing-at-point 'existing-filename)
> + (thing-at-point 'existing-filename))
> + ((buffer-file-name)
> + (list (buffer-file-name)))))
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Mar 2025 12:38:02 GMT)
Full text and
rfc822 format available.
Message #388 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[சனி மார்ச் 15, 2025] Visuwesh wrote:
One minor nit:
>> +(defun context-menu-send-to (menu _click)
>> + "Add a \"Send to...\" context MENU entry on supported platforms."
>> + (run-hooks 'activate-menubar-hook 'menu-bar-update-hook)
>> + (when (send-to-supported-p)
>> + (define-key-after menu [separator-send] menu-bar-separator)
>> + (define-key-after menu [send]
>> + '(menu-item "Send to..." (lambda ()
>> + (interactive)
>> + (send-to))
>> + :help
>> + "Send item (region, buffer file, or Dired files) to app or service")))
>> + menu)
This should ideally be
(save-excursion
(mouse-set-point click)
(when (send-to-supported-p)
...))
because otherwise dired-get-filename will pick up the filename at point,
instead of at click. See dired-context-menu as well.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Mar 2025 13:10:01 GMT)
Full text and
rfc822 format available.
Message #391 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
> [செவ்வாய் மார்ச் 04, 2025] Alvaro Ramirez wrote:
>
> Sorry, I was busy with $LIFE so couldn't get a chance to look at
> the
> latest patch properly.
No worries. Thanks for the comments.
>> +(defun context-menu-send-to (menu _click)
>> + "Add a \"Send to...\" context MENU entry on supported
>> platforms."
>> + (run-hooks 'activate-menubar-hook 'menu-bar-update-hook)
>> + (when (send-to-supported-p)
>> + (define-key-after menu [separator-send]
>> menu-bar-separator)
>> + (define-key-after menu [send]
>> + '(menu-item "Send to..." (lambda ()
>> + (interactive)
>> + (send-to))
>> + :help
>> + "Send item (region, buffer file, or Dired
>> files) to app or service")))
>> + menu)
>
> Sorry for asking this so late in the game... should we allow the
> backend
> itself to return a keymap for the context-menu? This would
> further
> prompting/choosing "where to send" in some backends.
Can we defer this one as a follow-up feature please? It'd be great
to get usage feedback before adding more features.
>> (defun context-menu-buffers (menu _click)
>> "Populate MENU with the buffer submenus to buffer
>> switching."
>> (run-hooks 'activate-menubar-hook 'menu-bar-update-hook)
>> diff --git a/lisp/send-to.el b/lisp/send-to.el
>> new file mode 100644
>> index 00000000000..064f5ad6645
>> --- /dev/null
>> +++ b/lisp/send-to.el
>> @@ -0,0 +1,233 @@
>> [...]
>> +(defvar-local send-to-handlers '(((:supported
>> . send-to--ns-supported-p)
>> + (:collect
>> . send-to--collect-items)
>> + (:send
>> . send-to--ns-send-items))
>> + ((:supported
>> . send-to--open-externally-supported-p)
>> + (:collect
>> . send-to--collect-items)
>> + (:send
>> . send-to--open-externally)))
>
> I wonder if coupling collect with other items here is a good
> idea. We
> could have a separate var for collect functions akin to
> context-menu-functions, that major-mode authors could modify.
I considered that and opted to include as part of the handlers as
it would possibly simplify/consolidate configuration.
> BTW, seeing the list makes me wonder if using cl-defgeneric for
> support&send functions would be more ergonomic for backend
> authors. To
> select the right backend, we could have something like
> xref-backend-functions.
While I didn't consider cl-defgeneric, cl-defstruct did cross my
mind, and I consciously opted for an alist. Specially when
debugging, alists are so transparent. Evaluating them gives me
access to their content without needing additional tooling for
inspection.
>
>> [...]
>> +;;;###autoload
>> +(defun send-to-supported-p ()
>> + "Return non-nil for platforms where `send-to' is supported."
>> + (funcall (map-elt (send-to--resolve-handler) :supported)))
>
> Why not nth?
I typically have a preference for seq.el. I find the consistent
naming helpful in discovering/finding related functions.
> I believe it should be a bit faster.
We're likely splitting hairs here. Realistically, this list will
only ever have a handful of items.
>> [...]
>> +(defun send-to--open-externally (items)
>> + "Open ITEMS externally (using a non-Emacs application)."
>> + (unless (boundp 'shell-command-guess-open)
>> + (require 'dired-aux))
>> + (when (y-or-n-p (format "Open externally: %s ?"
>> + (send-to--format-items items)))
>> + (dolist (item items)
>> + (with-temp-buffer
>> + (unless (zerop (call-process
>> + shell-command-guess-open nil
>> (current-buffer) t
>> + (send-to--convert-item-to-filename
>> + item)))
>> + (error "%s" (string-trim (buffer-string))))))))
>> +
>> +(defun send-to--convert-item-to-filename (item)
>> + "Convert ITEM to a filename.
>> +
>> +Unless ITEM is a verifiable filename, save its content to a
>> file and
>> +return its new timestamped filename."
>> + (if (and (file-local-name item) ;; Ignore url-handler-mode
>> + (file-exists-p item))
>> + item
>> + (let ((filename (concat temporary-file-directory
>> + (format-time-string "%F_%H.%M.%S")
>> ".txt")))
>> + (with-temp-file filename
>> + (insert item))
>> + filename)))
>
> Why this renaming? Wouldn't users want to open the original
> file
> instead of a copy?
Ah, maybe the docstring needs to be more specific, but the file
generation is only applicable when sending text that's not in a
file. For example, sending the current region. This isn't strictly
necessary for macOS as it can share strings, but I wanted to fill
the gap for GNU/Linux and offer the same functionality via
xdg-open. To do that, I need to write the text region to a file
first.
>> +(defun send-to--collect-items ()
>> + "Build a list of items to send based on default context.
>> +
>> +From a `dired' buffer, chosen items are based on either of
>> these being
>> +active:
>> +
>> + - Marked files
>> + - Files in region.
>> + - File at point.
>> +
>> +From any other buffer, either of these two, in order of
>> preference:
>> +
>> + - Active region text.
>> + - Thing at point (via `existing-filename').
>> + - Buffer file."
>> + (cond ((derived-mode-p 'dired-mode)
>> + (or
>> + (send-to--dired-filenames-in-region)
>> + (dired-get-marked-files)))
>> + ((use-region-p)
>> + (list (buffer-substring-no-properties
>> + (region-beginning)
>> + (region-end))))
>> + ((thing-at-point 'existing-filename)
>> + (thing-at-point 'existing-filename))
>> + ((buffer-file-name)
>> + (list (buffer-file-name)))))
>
> 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? Sending remote
files isn't currently a goal. Neither macOS's
NSSharingServicePicker nor xdg-open (AFAIK) would be able to
handle remote files?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Mar 2025 13:37:01 GMT)
Full text and
rfc822 format available.
Message #394 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[சனி மார்ச் 15, 2025] Alvaro Ramirez wrote:
S> Visuwesh <visuweshm <at> gmail.com> writes:
>
>> [செவ்வாய் மார்ச் 04, 2025] Alvaro Ramirez wrote:
>>
>> Sorry, I was busy with $LIFE so couldn't get a chance to look at the
>> latest patch properly.
>
> No worries. Thanks for the comments.
>
>>> +(defun context-menu-send-to (menu _click)
>>> + "Add a \"Send to...\" context MENU entry on supported
>>> platforms."
>>> + (run-hooks 'activate-menubar-hook 'menu-bar-update-hook)
>>> + (when (send-to-supported-p)
>>> + (define-key-after menu [separator-send] menu-bar-separator)
>>> + (define-key-after menu [send]
>>> + '(menu-item "Send to..." (lambda ()
>>> + (interactive)
>>> + (send-to))
>>> + :help
>>> + "Send item (region, buffer file, or Dired files)
>>> to app or service")))
>>> + menu)
>>
>> Sorry for asking this so late in the game... should we allow the
>> backend
>> itself to return a keymap for the context-menu? This would further
>> prompting/choosing "where to send" in some backends.
>
> Can we defer this one as a follow-up feature please? It'd be great to
> get usage feedback before adding more features.
Fine by me.
>>> (defun context-menu-buffers (menu _click)
>>> "Populate MENU with the buffer submenus to buffer switching."
>>> (run-hooks 'activate-menubar-hook 'menu-bar-update-hook)
>>> diff --git a/lisp/send-to.el b/lisp/send-to.el
>>> new file mode 100644
>>> index 00000000000..064f5ad6645
>>> --- /dev/null
>>> +++ b/lisp/send-to.el
>>> @@ -0,0 +1,233 @@
>>> [...]
>>> +(defvar-local send-to-handlers '(((:supported
>>> . send-to--ns-supported-p)
>>> + (:collect
>>> . send-to--collect-items)
>>> + (:send
>>> . send-to--ns-send-items))
>>> + ((:supported
>>> . send-to--open-externally-supported-p)
>>> + (:collect
>>> . send-to--collect-items)
>>> + (:send
>>> . send-to--open-externally)))
>>
>> I wonder if coupling collect with other items here is a good idea.
>> We
>> could have a separate var for collect functions akin to
>> context-menu-functions, that major-mode authors could modify.
>
> I considered that and opted to include as part of the handlers as it
> would possibly simplify/consolidate configuration.
OK, sounds good.
>>> [...]
>>> +(defun send-to--open-externally (items)
>>> + "Open ITEMS externally (using a non-Emacs application)."
>>> + (unless (boundp 'shell-command-guess-open)
>>> + (require 'dired-aux))
>>> + (when (y-or-n-p (format "Open externally: %s ?"
>>> + (send-to--format-items items)))
>>> + (dolist (item items)
>>> + (with-temp-buffer
>>> + (unless (zerop (call-process
>>> + shell-command-guess-open nil
>>> (current-buffer) t
>>> + (send-to--convert-item-to-filename
>>> + item)))
>>> + (error "%s" (string-trim (buffer-string))))))))
>>> +
>>> +(defun send-to--convert-item-to-filename (item)
>>> + "Convert ITEM to a filename.
>>> +
>>> +Unless ITEM is a verifiable filename, save its content to a file
>>> and
>>> +return its new timestamped filename."
>>> + (if (and (file-local-name item) ;; Ignore url-handler-mode
>>> + (file-exists-p item))
>>> + item
>>> + (let ((filename (concat temporary-file-directory
>>> + (format-time-string "%F_%H.%M.%S")
>>> ".txt")))
>>> + (with-temp-file filename
>>> + (insert item))
>>> + filename)))
>>
>> Why this renaming? Wouldn't users want to open the original file
>> instead of a copy?
>
> Ah, maybe the docstring needs to be more specific, but the file
> generation is only applicable when sending text that's not in a
> file. For example, sending the current region. This isn't strictly
> necessary for macOS as it can share strings, but I wanted to fill the
> gap for GNU/Linux and offer the same functionality via xdg-open. To do
> that, I need to write the text region to a file first.
Thanks for the clarification; now that I read the code more closely, it
says `insert', not `insert-file-contents'. My bad.
>>> +(defun send-to--collect-items ()
>>> + "Build a list of items to send based on default context.
>>> +
>>> +From a `dired' buffer, chosen items are based on either of these
>>> being
>>> +active:
>>> +
>>> + - Marked files
>>> + - Files in region.
>>> + - File at point.
>>> +
>>> +From any other buffer, either of these two, in order of
>>> preference:
>>> +
>>> + - Active region text.
>>> + - Thing at point (via `existing-filename').
>>> + - Buffer file."
>>> + (cond ((derived-mode-p 'dired-mode)
>>> + (or
>>> + (send-to--dired-filenames-in-region)
>>> + (dired-get-marked-files)))
>>> + ((use-region-p)
>>> + (list (buffer-substring-no-properties
>>> + (region-beginning)
>>> + (region-end))))
>>> + ((thing-at-point 'existing-filename)
>>> + (thing-at-point 'existing-filename))
>>> + ((buffer-file-name)
>>> + (list (buffer-file-name)))))
>>
>> 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).
> 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. I routinely do the latter for opening log files in remote HPCs
with molecular visualisers I have on my laptop:
(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))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Mar 2025 13:57:05 GMT)
Full text and
rfc822 format available.
Message #397 received at 76120 <at> debbugs.gnu.org (full text, mbox):
[சனி மார்ச் 15, 2025] Visuwesh 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).
To clarify this a bit more: I would like the ability to send the
filename of a file, but not the file itself. With the current
file-exists-p check, it would always send the file.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Mar 2025 18:12:01 GMT)
Full text and
rfc822 format available.
Message #400 received at 76120 <at> debbugs.gnu.org (full text, mbox):
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))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Sat, 15 Mar 2025 19:10:02 GMT)
Full text and
rfc822 format available.
Message #403 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
> [சனி மார்ச் 15, 2025] Visuwesh 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).
>
> To clarify this a bit more: I would like the ability to send the
> filename of a file, but not the file itself. With the current
> file-exists-p check, it would always send the file.
If we go down the file: approach, we have a similar edge case if
we select a "file:/some/path/to/an/existing/file.txt" region and
attempt to send the path itself.
The cons or similar approach I mentioned in previous email can be
part of a richer description language follow-up feature. If we do
go down this descriptive path, I'd like to avoid defining the
schema prematurely (ie. in the current patch), and wait until we
have multiple clear use-cases based on MVP usage/feedback.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Tue, 27 May 2025 16:12:02 GMT)
Full text and
rfc822 format available.
Message #406 received at 76120 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Alvaro Ramirez <alvaro <at> xenodium.com>
>> Cc: 76120 <at> debbugs.gnu.org
>> Date: Tue, 04 Mar 2025 13:08:48 +0000
>>
>> Thanks for all the feedback. Attaching the latest iteration of
>> the
>> patch (0005-Add-Send-to-context-menu-item-to-mouse-el.patch),
>> applying your
>> suggestions.
>
> Thanks.
>
> Stefan, would you please install this? I don't use macOS, so
> would
> prefer not to install changes I cannot compile.
Hiya folks, apologies for the nudge. Anything else I can help
with?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76120; Package
emacs.
(Wed, 28 May 2025 10:49:02 GMT)
Full text and
rfc822 format available.
Message #409 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: 76120 <at> debbugs.gnu.org
> Date: Tue, 27 May 2025 17:11:06 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> >> Cc: 76120 <at> debbugs.gnu.org
> >> Date: Tue, 04 Mar 2025 13:08:48 +0000
> >>
> >> Thanks for all the feedback. Attaching the latest iteration of
> >> the
> >> patch (0005-Add-Send-to-context-menu-item-to-mouse-el.patch),
> >> applying your
> >> suggestions.
> >
> > Thanks.
> >
> > Stefan, would you please install this? I don't use macOS, so
> > would
> > prefer not to install changes I cannot compile.
>
> Hiya folks, apologies for the nudge. Anything else I can help
> with?
I've asked Stefan to install this, so I guess we are waiting for
Stefan to find some free time to do that.
Thanks.
This bug report was last modified 19 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.