* Re: On improving Bookmarks
2022-11-16 5:25 On improving Bookmarks Gabriel
@ 2022-11-16 7:23 ` Matthias Meulien
2022-11-16 8:05 ` Stefan Kangas
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Matthias Meulien @ 2022-11-16 7:23 UTC (permalink / raw)
To: Gabriel; +Cc: emacs-devel
Gabriel <gabriel376@hotmail.com> writes:
> (...) I think there are some opportunities for improvements in
> Bookmarks (in general and in how it support Types) and would like to
> collect general feedback and directions before reporting bugs or
> proposing patches, especially considering if such changes would be
> useful, the effort to implement them and how to handle compatibility.
Thank you!
> 1) The empty "Type" column on C-x r l (bookmark-bmenu-list)
>
> Bookmarks shows a proper value in the Type column of
> bookmark-bmenu-list for all Types, except for regular "Files" and
> "Directories", in which shows an empty string. I believe that
> displaying the actual Type rather an empty string for these cases
> would make the interface more consistent and easier for navigation.
+1
> See bug#59212 for the open discussion. Besides the question regarding
> the real value of this change, I currently don't know how to easily
> distinguish between "Files" and "Directories" without relying on IO
> calls (e.g. file-directory-p), which could degrade performance in case
> of long Bookmarks lists. We could display the string "File" for both
> "Files" and "Directories", but it would be a worse experience for
> users to not provide such distinction.
Yes you're right.
If I remember correctly, when serialized, those "Files and Directories"
bookmarks aren't associated to a handler. Introducing distinct handlers
for both would help to have a meaningful "type" value.
> 2) The usage of "File" and "Filename" in docs and interface (...)
> 3) Add Type to bookmark-sort-flag
>
> A simple suggestion to add Type to the choices of bookmark-sort-flag.
I am no against, but I'm not sure I'll use it. Extending the / key
(bookmark-bmenu-search) to mimic what is done por packages would be more
interesting from my pov (ie make it a prefix key and for example have /
n filter by name, / t filter by type, and / l filter by location).
> 4) Make R (bookmark-relocate) work for all Types
+1
> 5) Ability to open Bookmarks with external applications (...)
> 6) Add minibuffer completion details to C-x r b (bookmark-jump)
+1
> 7) Add Tags
+1
Let me mention two things I have in my wishlist:
8) Hability to scope bookmarks to Projects.
When setting a bookmark from a buffer attached to a project, I'd like to
have the choice of a bookmark scope: global or current project.
When jumping to a bookmark from a buffer attached to a project, I'd then
expect to have choice from bookmarks with global scope and bookmarks
with scoped to current project.
A project-bookmark-bmenu-list command could be created that displays
bookmarks with global scope and scoped to current project.
I don't know whether one should extend bookmarks with a scope property
or store bookmarks in projects (using .dir-locals.el or a dedicated
file?).
9) Improve support for multiple bookmark files
I first thought 8) wouldn't be a problem if I maintained a bookmark file
in each project. Unfortunately when you press the s key from bookmark
BMenu, the default bookmark file is overwritten with bookmarks coming
from multiple sources...
And when jumping there's no way to select the bookmark source...
--
Matthias
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: On improving Bookmarks
2022-11-16 5:25 On improving Bookmarks Gabriel
2022-11-16 7:23 ` Matthias Meulien
@ 2022-11-16 8:05 ` Stefan Kangas
2022-11-16 17:28 ` bug#59212: " Karl Fogel
2022-11-16 17:37 ` Karl Fogel
3 siblings, 0 replies; 14+ messages in thread
From: Stefan Kangas @ 2022-11-16 8:05 UTC (permalink / raw)
To: Gabriel, emacs-devel
Gabriel <gabriel376@hotmail.com> writes:
> I think there are some opportunities for improvements in Bookmarks (in
> general and in how it support Types) and would like to collect general
> feedback and directions before reporting bugs or proposing patches,
> especially considering if such changes would be useful, the effort to
> implement them and how to handle compatibility.
Some good ideas here, indeed. I think the best way forward is to submit
bug reports (put "Severity: wishlist" on the first line of your email)
for all of these.
> 6) Add minibuffer completion details to C-x r b (bookmark-jump)
See the package `marginalia' for this. Maybe we should even consider
including that package by default.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#59212: On improving Bookmarks
2022-11-16 5:25 On improving Bookmarks Gabriel
2022-11-16 7:23 ` Matthias Meulien
2022-11-16 8:05 ` Stefan Kangas
@ 2022-11-16 17:28 ` Karl Fogel
2022-11-16 19:33 ` Eli Zaretskii
2022-11-16 19:33 ` Eli Zaretskii
2022-11-16 17:37 ` Karl Fogel
3 siblings, 2 replies; 14+ messages in thread
From: Karl Fogel @ 2022-11-16 17:28 UTC (permalink / raw)
To: Gabriel; +Cc: 59212, emacs-devel
[I'm combining the original bug-59212 thread with an emacs-devel
thread here.]
On 12 Nov 2022, Eli Zaretskii wrote in Bug #59212:
>> From: Gabriel <gabriel376@hotmail.com>
>> Date: Sat, 12 Nov 2022 05:56:22 -0300
>>
>> Description:
>> Not a bug per se, but a suggestion for improvement in how
>> Bookmark
>> displays the Type (added by commit
>> 7c995264359824cc1aca40ca37201db5ed44e659).
>>
>> Currently, bookmark-bmenu-list (C-x r l) displays a column
>> named Type,
>> which has a proper value for all handlers (e.g.: Eshell, VC,
>> EWW etc)
>> except for regular files, in which an empty string is
>> displayed. I
>> believe the current behavior could be improved by displaying a
>> default
>> value ("Files") to make the interface more uniform, explicit
>> and to
>> avoid confusion.
>>
>> Steps:
>> 1) emacs -Q
>> 2) M-x eshell
>> 3) C-x r m <RET>
>> 4) C-x C-f ~/foo.bar
>> 5) C-x r m <RET>
>> 6) C-x r b
>>
>> These steps will add two bookmarks (eshell and foo.bar) and
>> will open
>> the Bookmarks list. The Type column will have values "" and
>> "Eshell". After the patch below is applied, the Type column
>> will have
>> values "File" and "Eshell".
>
>Thanks.
>
>Karl, any comments?
I don't have a strong opinion on this UI suggestion.
For users who set mostly file-or-directory bookmarks, and don't
set very many bookmarks of other types, then it probably makes
sense to treat files/directories as the default and not show a
type for them. That way, the unusual bookmarks stand out (which
is useful because they might have different response-time
characteristics, or other interactive idiosyncracies, than that
user's typical bookmark does).
On the other hand, for users for whom file/directory bookmarks are
not more common than other kinds of bookmarks, showing "File" or
"Directory" like any other type would probably be better. Those
users are already accustomed to a variety of interactivity
characteristics from their bookmarks anyway, so it makes less
sense to trade away consistency of display in favor of stand-out
visibility of certain cases.
But these are really minor differences; they're not terribly
persuasive either way. I think I'm still at "no strong opinion".
I wouldn't stand in the way of the change.
Continuing on to the later conversation on emacs-devel about this:
On 16 Nov 2022, Gabriel wrote:
>Hi,
>
>I think there are some opportunities for improvements in
>Bookmarks (in
>general and in how it support Types) and would like to collect
>general
>feedback and directions before reporting bugs or proposing
>patches,
>especially considering if such changes would be useful, the
>effort to
>implement them and how to handle compatibility.
>
>Bookmarks has support for Types besides regular "Files" or
>"Directories"
>(opened with Dired). A quick xref in current Emacs master branch
>shows
>the following Types:
>
>- "DocView"
>- "Eshell"
>- "Gnus"
>- "Help"
>- "Image-Dired"
>- "Info"
>- "Man"
>- "EWW"
>- "VC"
>- "WoMan"
>
>1) The empty "Type" column on C-x r l (bookmark-bmenu-list)
>
>Bookmarks shows a proper value in the Type column of
>bookmark-bmenu-list
>for all Types, except for regular "Files" and "Directories", in
>which
>shows an empty string. I believe that displaying the actual Type
>rather
>an empty string for these cases would make the interface more
>consistent
>and easier for navigation. See bug#59212 for the open
>discussion.
>Besides the question regarding the real value of this change, I
>currently don't know how to easily distinguish between "Files"
>and
>"Directories" without relying on IO calls
>(e.g. file-directory-p), which
>could degrade performance in case of long Bookmarks lists. We
>could
>display the string "File" for both "Files" and "Directories", but
>it
>would be a worse experience for users to not provide such
>distinction.
Could we just use a combined term like "File/Dir" or "File/Path"
or just "Path" or something? Not the perfect user experience, but
an 80% solution. Obviously, we'd want to keep the width small.
>2) The usage of "File" and "Filename" in docs and interface
>
>In docs (e.g. (info "(emacs)Bookmarks")) and interface (e.g. the
>"File"
>column in bookmark-bmenu-list), we can find several occurrences
>of the
>terms "File" and "Filename" (and related terms), which I think is
>inconsistent since Bookmarks supports Types that do not really
>have
>these concepts (e.g. "Help", "Man", "EWW", "Gnus"). A better
>term would
>be "Location", which is already used in some places
>(e.g. bookmark-location, bookmark-relocate, the 'location
>property).
>Thus, I propose to make "Location" the official term in docs,
>interface
>and code, and to obsolete "File", "Filename" and related ones.
+1. This makes a lot of sense, independently of whatever we do in
the Type column of the Bookmark Menu.
The rest of your post on emacs-devel isn't really related to bug
#59212, so I'll follow up separately to it in a moment.
Best regards,
-Karl
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug#59212: On improving Bookmarks
2022-11-16 17:28 ` bug#59212: " Karl Fogel
@ 2022-11-16 19:33 ` Eli Zaretskii
2022-11-16 19:47 ` Karl Fogel
2022-11-16 19:47 ` Karl Fogel
2022-11-16 19:33 ` Eli Zaretskii
1 sibling, 2 replies; 14+ messages in thread
From: Eli Zaretskii @ 2022-11-16 19:33 UTC (permalink / raw)
To: Karl Fogel; +Cc: gabriel376, 59212, emacs-devel
> Cc: 59212@debbugs.gnu.org, emacs-devel@gnu.org
> From: Karl Fogel <kfogel@red-bean.com>
> Date: Wed, 16 Nov 2022 11:28:30 -0600
>
> Could we just use a combined term like "File/Dir" or "File/Path"
> or just "Path" or something?
Not "Path", please. The GNU Coding Standards frown on using "path"
for anything except PATH-style directory lists.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug#59212: On improving Bookmarks
2022-11-16 19:33 ` Eli Zaretskii
@ 2022-11-16 19:47 ` Karl Fogel
2022-11-16 19:47 ` Karl Fogel
1 sibling, 0 replies; 14+ messages in thread
From: Karl Fogel @ 2022-11-16 19:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gabriel376, 59212, emacs-devel
On 16 Nov 2022, Eli Zaretskii wrote:
>> Cc: 59212@debbugs.gnu.org, emacs-devel@gnu.org
>> From: Karl Fogel <kfogel@red-bean.com>
>> Date: Wed, 16 Nov 2022 11:28:30 -0600
>>
>> Could we just use a combined term like "File/Dir" or
>> "File/Path"
>> or just "Path" or something?
>
>Not "Path", please. The GNU Coding Standards frown on using
>"path"
>for anything except PATH-style directory lists.
Thanks -- "Path" is out, then.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#59212: On improving Bookmarks
2022-11-16 19:33 ` Eli Zaretskii
2022-11-16 19:47 ` Karl Fogel
@ 2022-11-16 19:47 ` Karl Fogel
1 sibling, 0 replies; 14+ messages in thread
From: Karl Fogel @ 2022-11-16 19:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gabriel376, 59212, emacs-devel
On 16 Nov 2022, Eli Zaretskii wrote:
>> Cc: 59212@debbugs.gnu.org, emacs-devel@gnu.org
>> From: Karl Fogel <kfogel@red-bean.com>
>> Date: Wed, 16 Nov 2022 11:28:30 -0600
>>
>> Could we just use a combined term like "File/Dir" or
>> "File/Path"
>> or just "Path" or something?
>
>Not "Path", please. The GNU Coding Standards frown on using
>"path"
>for anything except PATH-style directory lists.
Thanks -- "Path" is out, then.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#59212: On improving Bookmarks
2022-11-16 17:28 ` bug#59212: " Karl Fogel
2022-11-16 19:33 ` Eli Zaretskii
@ 2022-11-16 19:33 ` Eli Zaretskii
1 sibling, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2022-11-16 19:33 UTC (permalink / raw)
To: Karl Fogel; +Cc: gabriel376, 59212, emacs-devel
> Cc: 59212@debbugs.gnu.org, emacs-devel@gnu.org
> From: Karl Fogel <kfogel@red-bean.com>
> Date: Wed, 16 Nov 2022 11:28:30 -0600
>
> Could we just use a combined term like "File/Dir" or "File/Path"
> or just "Path" or something?
Not "Path", please. The GNU Coding Standards frown on using "path"
for anything except PATH-style directory lists.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: On improving Bookmarks
2022-11-16 5:25 On improving Bookmarks Gabriel
` (2 preceding siblings ...)
2022-11-16 17:28 ` bug#59212: " Karl Fogel
@ 2022-11-16 17:37 ` Karl Fogel
2022-11-17 10:20 ` Jean Louis
3 siblings, 1 reply; 14+ messages in thread
From: Karl Fogel @ 2022-11-16 17:37 UTC (permalink / raw)
To: Gabriel; +Cc: emacs-devel
[This is the second part of my reply in this thread. The first
part was posted as part of a parallel reply to Bug #59212 and can
be seen here:
https://mail.gnu.org/archive/html/emacs-devel/2022-11/msg01053.html
.]
On 16 Nov 2022, Gabriel wrote:
>3) Add Type to bookmark-sort-flag
>
>A simple suggestion to add Type to the choices of
>bookmark-sort-flag.
+1. I'm not sure how often people would actually use it, but if a
column is present, it should be sortable on.
>4) Make R (bookmark-relocate) work for all Types
>
>The R (bookmark-relocate) currently does not seem to work with
>Types
>other than regular "Files" and "Directories". It causes the
>following
>error:
>
>bookmark-relocate: Wrong type argument: stringp, nil
>
>Would be nice to make it work for all types. I am not sure what
>would
>be the best way to implement it and the required effort. Perhaps
>similar to how VC handles different backends or similar to how
>currently
>bookmarks handles 'bookmark-handler-type. See also comment from
>2010 in
>bookmark-location. As a simple remediation in case this change
>is not
>added to Bookmarks, Emacs could report a better error message for
>users,
>e.g.: "bookmark-relocate is not supported for type EWW".
I think starting by just improving the error would be great. The
larger effort can be tackled on a case-by-case basis -- it doesn't
have to be all solved all at once.
>5) Ability to open Bookmarks with external applications
>
>Add choice to open bookmarks in Emacs using the default
>bookmark-handler-type or using an external application (e.g. open
>a PDF
>with xdg-open rather than DocView or open an URL with Firefox
>rather
>than EWW). Not sure what would be the best way to implement it,
>though.
That's a very interesting idea. +1 to the concept.
But does Emacs already have a generic mechanism for saying "open
things of type X with program Y"? If so, Bookmark should just
rely on that mechanism, rather than have some Bookmark-specific
mechanism. And if there isn't such a generic mechanism in Emacs,
perhaps it be better to create that than to do something special
for Bookmark.
>6) Add minibuffer completion details to C-x r b (bookmark-jump)
>
>A simple suggestion to add minibuffer completion details to
>bookmark-jump so users can know, for example, the Type and
>Location. It
>could be controlled by defcustom completions-detailed.
Again, +1 to the concept.
>7) Add Tags
>
>A "simple" feature that would make Bookmarks much more powerful.
>In
>simple terms, a list of tags would be saved with each bookmark in
>bookmark-default-file, and could be used for better filtering and
>navigation.
Well... I hesitate on this one. Tagging mechanisms often turn out
to be half-baked solutions to sets of only partially-related
problems. And in the case of bookmarks, we already have a lot of
information we could work with, even without tags:
* The bookmark's name Its path Its type Its creation date The
* front and back context strings
I guess I would ask: have you personally encountered situations
with your bookmarks where tags would have been the best solution?
I.e., is this idea based on directly-experienced need, or is it
speculative?
On 16 Nov 2022, Matthias Meulien replied to Gabriel:
>Let me mention two things I have in my wishlist:
>
>8) Hability to scope bookmarks to Projects.
>
>When setting a bookmark from a buffer attached to a project, I'd
>like to
>have the choice of a bookmark scope: global or current project.
>
>When jumping to a bookmark from a buffer attached to a project,
>I'd then
>expect to have choice from bookmarks with global scope and
>bookmarks
>with scoped to current project.
>
>A project-bookmark-bmenu-list command could be created that
>displays
>bookmarks with global scope and scoped to current project.
>
>I don't know whether one should extend bookmarks with a scope
>property
>or store bookmarks in projects (using .dir-locals.el or a
>dedicated
>file?).
Whew. This would complexify Bookmark considerably -- it starts to
transform into a project management system.
You can already use different bookmark-files for this kind of
scoping, with a little bit of UI overhead (which we could improve,
without having to fundamentally change how Bookmark works).
Aha, you touch on that below!...
>9) Improve support for multiple bookmark files
>
>I first thought 8) wouldn't be a problem if I maintained a
>bookmark file
>in each project. Unfortunately when you press the s key from
>bookmark
>BMenu, the default bookmark file is overwritten with bookmarks
>coming
>from multiple sources...
>
>And when jumping there's no way to select the bookmark source...
Maybe just designing a fix for that -- a better UI flow -- is the
solution to the scoping need?
Best regards,
-Karl
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: On improving Bookmarks
2022-11-16 17:37 ` Karl Fogel
@ 2022-11-17 10:20 ` Jean Louis
2022-11-17 21:17 ` Karl Fogel
0 siblings, 1 reply; 14+ messages in thread
From: Jean Louis @ 2022-11-17 10:20 UTC (permalink / raw)
To: Karl Fogel; +Cc: Gabriel, emacs-devel
* Karl Fogel <kfogel@red-bean.com> [2022-11-16 20:40]:
> But does Emacs already have a generic mechanism for saying "open things of
> type X with program Y"? If so, Bookmark should just rely on that mechanism,
> rather than have some Bookmark-specific mechanism. And if there isn't such
> a generic mechanism in Emacs, perhaps it be better to create that than to do
> something special for Bookmark.
I use this variable to open files in Dired, this could be also used
for bookmarks.
dired-guess-shell-alist-user is a variable defined in ‘dired.el’.
Value:
(("\\.gif\\'" "sxiv -a")
("\\.mts\\'" "mpv")
("\\.pdf\\'" "zathura")
("\\.epub\\'" "mupdf")
("\\.djvu\\'" "evince")
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: On improving Bookmarks
2022-11-17 10:20 ` Jean Louis
@ 2022-11-17 21:17 ` Karl Fogel
2022-11-18 3:13 ` Stefan Kangas
2022-11-18 7:53 ` Jean Louis
0 siblings, 2 replies; 14+ messages in thread
From: Karl Fogel @ 2022-11-17 21:17 UTC (permalink / raw)
To: Gabriel; +Cc: emacs-devel
On 17 Nov 2022, Jean Louis wrote:
> * Karl Fogel <kfogel@red-bean.com> [2022-11-16 20:40]:
>> But does Emacs already have a generic mechanism for saying
>> "open things of
>> type X with program Y"? If so, Bookmark should just rely on
>> that mechanism,
>> rather than have some Bookmark-specific mechanism. And if
>> there isn't such
>> a generic mechanism in Emacs, perhaps it be better to create
>> that than to do
>> something special for Bookmark.
>
> I use this variable to open files in Dired, this could be also
> used
> for bookmarks.
>
> dired-guess-shell-alist-user is a variable defined in
> ‘dired.el’.
>
> Value:
> (("\\.gif\\'" "sxiv -a")
> ("\\.mts\\'" "mpv")
> ("\\.pdf\\'" "zathura")
> ("\\.epub\\'" "mupdf")
> ("\\.djvu\\'" "evince")
That's a start -- it covers files at least. But it wouldn't know
what to do if handed (say) a URL, right?
We need something like a generalized MIME-type handler list. And
maybe Emacs has such a thing already? Emacs is so big that I pack
canned goods before I go looking for things in it...
Best regards,
-Karl
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: On improving Bookmarks
2022-11-17 21:17 ` Karl Fogel
@ 2022-11-18 3:13 ` Stefan Kangas
2022-11-18 7:58 ` Jean Louis
2022-11-18 7:53 ` Jean Louis
1 sibling, 1 reply; 14+ messages in thread
From: Stefan Kangas @ 2022-11-18 3:13 UTC (permalink / raw)
To: Karl Fogel, Gabriel; +Cc: emacs-devel
Karl Fogel <kfogel@red-bean.com> writes:
> We need something like a generalized MIME-type handler list. And
> maybe Emacs has such a thing already? Emacs is so big that I pack
> canned goods before I go looking for things in it...
See also the discussion in Bug#18132.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: On improving Bookmarks
2022-11-18 3:13 ` Stefan Kangas
@ 2022-11-18 7:58 ` Jean Louis
0 siblings, 0 replies; 14+ messages in thread
From: Jean Louis @ 2022-11-18 7:58 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Karl Fogel, Gabriel, emacs-devel
* Stefan Kangas <stefankangas@gmail.com> [2022-11-18 06:15]:
> Karl Fogel <kfogel@red-bean.com> writes:
>
> > We need something like a generalized MIME-type handler list. And
> > maybe Emacs has such a thing already? Emacs is so big that I pack
> > canned goods before I go looking for things in it...
>
> See also the discussion in Bug#18132.
That one opens files on local system.
I would like EWW to open content type by predefined applications.
If Emacs would be using ~/.mailcap file that would be already good enough.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: On improving Bookmarks
2022-11-17 21:17 ` Karl Fogel
2022-11-18 3:13 ` Stefan Kangas
@ 2022-11-18 7:53 ` Jean Louis
1 sibling, 0 replies; 14+ messages in thread
From: Jean Louis @ 2022-11-18 7:53 UTC (permalink / raw)
To: Karl Fogel; +Cc: Gabriel, emacs-devel
* Karl Fogel <kfogel@red-bean.com> [2022-11-18 00:19]:
> We need something like a generalized MIME-type handler list. And maybe
> Emacs has such a thing already? Emacs is so big that I pack canned goods
> before I go looking for things in it...
When I have mentioned on the Org mailing list that eww shall be able
to recognize content type, basically MIME type, and that Emacs shall
have possibility to define how to open different content types, people
started speaking of insecurity, how it is not good for Emacs users,
etc.
But I can easily use Iceweasel, fork of Firefox, and setup Emacs to
open text/x-org files.
See:
https://lists.gnu.org/archive/html/emacs-orgmode/2022-10/threads.html#00889
It came out in discussion that Emacs shall not open Org files coming
from WWW servers, while in the same time every other browser can open
Org files by using Emacs.
Makes no sense to me.
Opening MIME types is not related to security. I can have Perl files
to be opened directly with Perl interpreter, that is my user choice.
In my opinion there shall be mechanism in Emacs to open any MIME type.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
^ permalink raw reply [flat|nested] 14+ messages in thread