unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: Juri Linkov <juri@linkov.net>
Cc: Eshel Yaron <eshelshay.yaron@gmail.com>,
	 emacs-devel@gnu.org,  Jan Wielemaker <jan@swi-prolog.org>
Subject: Re: [NonGNU ELPA] New package: sweep
Date: Wed, 28 Sep 2022 18:56:15 +0000	[thread overview]
Message-ID: <87edvvl44w.fsf@posteo.net> (raw)
In-Reply-To: <868rm376hl.fsf@mail.linkov.net> (Juri Linkov's message of "Wed,  28 Sep 2022 20:49:10 +0300")

Juri Linkov <juri@linkov.net> writes:

>>>> I agree with RMS (<E1odDGZ-0005aw-79@fencepost.gnu.org>) that it might
>>>> be nice to have a more indicative name, or at least something that
>>>> includes "Prolog".  Mor eso because "sweep" makes me think of something
>>>> that cleans.
>>>
>>> I've given it some thought, and all in all I would like to keep the name
>>> `sweep` for this project.  I do see however why this name may be
>>> unhelpful for Emacs users who are not familiar with SWI-Prolog, or who
>>> are looking for some "cleaning" package...  As a possible solution, I'd
>>> be happy to change the name of the Elisp package to `sweeprolog` while
>>> still referring to the project as a whole as `sweep` (e.g. in the
>>> manual).  Does that sounds alright?
>>
>> I think that would be nice, and there shouldn't be a need to rename the
>> entire project.
>
> I wonder where this requirement to put all tags in the package name comes from?
> While looking at the long list of package names, it's hard to find a package
> whose name immediately hints at what it does.  This is a non-problem
> that is solved in all package managers by using tags and full-text search.
> And indeed list-package allows both ways, e.g. when someone is interested
> in Prolog, then it's easy to type '/ k' (package-menu-filter-by-keyword).
> Or try to use '/ d erlang RET' (package-menu-filter-by-description)
> and see that almost no package has it in the package name,
> yet these packages can be easily found:
>
>  auto-complete-distel    melpa  Erlang/distel completion backend for auto-complete-mode
>  company-distel          melpa  Erlang/distel completion backend for company-mode
>  company-erlang          melpa  company backend based on ivy-erlang-complete
>  distel-completion-lib   melpa  Completion library for Erlang/Distel
>  edts                    melpa  Erlang Development Tool Suite
>  erlang                  melpa  Erlang major mode
>  erlstack-mode           melpa  Minor mode for analysing Erlang stacktraces
>  ivy-erlang-complete     melpa  Erlang context sensitive completion at point using ivy
>  lfe-mode                melpa  Lisp Flavoured Erlang mode

The package list does help, but having a name that can be understood on
its own seems like a good thing.  There is no reason to make package
discovery more difficult.

Tough I might be a bit extreme on this topic.  E.g. I remember when
starting out with *nix, not wanting to use grep when searching for a
program to filter a file, just because of the name.



  parent reply	other threads:[~2022-09-28 18:56 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26 11:29 [NonGNU ELPA] New package: sweep Eshel Yaron
2022-09-26 19:32 ` Philip Kaludercic
2022-09-27 16:32   ` Eshel Yaron
2022-09-27 17:46     ` Philip Kaludercic
2022-09-28  6:46       ` Eshel Yaron
2022-09-28  7:27         ` Philip Kaludercic
2022-09-28 17:49           ` Juri Linkov
2022-09-28 18:41             ` Eli Zaretskii
2022-09-28 18:56             ` Philip Kaludercic [this message]
2022-09-30  2:38             ` Richard Stallman
2022-09-30  8:20             ` Stefan Kangas
2022-09-30  9:45               ` Robert Pluim
2022-09-29  2:59         ` Richard Stallman
2022-09-29 16:53           ` [NonGNU ELPA] New package: sweeprolog Eshel Yaron
2022-09-29 16:59             ` Philip Kaludercic
2022-10-01  2:01             ` Richard Stallman
2022-09-27 18:49     ` [NonGNU ELPA] New package: sweep Stefan Monnier
2022-09-28  7:15       ` Eshel Yaron
2022-09-29  3:02     ` Richard Stallman
2022-09-29  5:04       ` Eshel Yaron
2022-09-29  6:17       ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2022-09-26 10:22 Eshel Yaron
2022-09-26 17:41 ` Stefan Monnier
2022-09-27 15:19   ` Eshel Yaron
2022-09-30  2:36     ` Richard Stallman
2022-09-27 16:17 ` Richard Stallman
2022-09-27 18:47   ` Juri Linkov
2022-09-28  5:40     ` Andrea G. Monaco
2022-09-30  2:36     ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87edvvl44w.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=emacs-devel@gnu.org \
    --cc=eshelshay.yaron@gmail.com \
    --cc=jan@swi-prolog.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).