unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: Richard Stallman <rms@gnu.org>
Cc: Corwin Brust <corwin@bru.st>,
	69132@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Thu, 22 Feb 2024 12:00:52 +0000	[thread overview]
Message-ID: <87a5nswvwr.fsf@posteo.net> (raw)
In-Reply-To: <E1rccmW-0006Hb-KR@fencepost.gnu.org> (Richard Stallman's message of "Tue, 20 Feb 2024 21:56:24 -0500")

Richard Stallman <rms@gnu.org> writes:

>   > As stated: I think it is *not* possible to perform this type of
>   > "client-side" search without using Javascript.
>
> There are two fully moral ways to implement a search feature for a web
> site.  One is to implement it inside the web server.  The other is to
> communicate with a free program that the user has installed in per
> computer, and could replace with any other.

In this case, both options would be overkill.  The search functionality
does little more than just hiding a few elements from a table.  In
practice, it don't offer much more than using the built-in C-f search
functionality, that every browser provides.

[...]

> We could overcome this wih a documented API that users could
> optionally use for ELPA search.  It would provide the package list
> data in a form convenient for programs.  Users could write their own
> code, in Javascript or in some other language, to operate on the API
> output to customize the search as they like.  This would provide the
> benefit you call for, in an even more general way.

ELPA already has a format for listing packages in an archive, and just
like with browsers, it wouldn't really provide anything that M-x
list-packages and C-s doesn't already do.

> (Is there a semistandard web convention for specifying API versions so
> you can say, "Give me this data in the format we used in June 2022"?)
>
> Meanwhile, the rest of us, we who don't use that API, would not be
> asked to run any code straight off the web server.
>
> In a later message you said this:
>
>   > As the entire functionality it provides is just an optional, superficial
>   > enchantment (one that I almost never use), I don't think this is worth
>   > pursuing.  All the ways I can imagine to achieve this would be less
>   > convenient hacks.
>
> Assuming you're talking about the same Javascript code, how about
> directing users to install that code into their browsers themselves
> (if they want this optional, superficial <what?>), and giving them a
> link to it.

We should be talking about the same code; I am not sure what you mean by
instructing users to install the code themselves?  Are you talking about
user-scripts?

> That would avoid the moral problem of Javascript sent implicitly to
> browsers, and these few users would have only a little work to do to
> set it up.





  reply	other threads:[~2024-02-22 12:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14 19:41 bug#69132: [ELPA] Remove jQuery from elpa.gnu.org Philip Kaludercic
2024-02-14 23:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-15  8:12   ` Philip Kaludercic
2024-02-15 11:07     ` Philip Kaludercic
2024-02-15 15:37     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 18:25       ` Stefan Kangas
2024-02-17 20:57       ` Dmitry Gutov
2024-02-17 21:04         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 22:26           ` Dmitry Gutov
2024-02-17 22:44             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 22:49               ` Dmitry Gutov
2024-02-18  4:05                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 12:14                   ` Dmitry Gutov
2024-02-18 14:13                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 14:24                       ` Dmitry Gutov
2024-02-18 14:37                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 14:38                           ` Dmitry Gutov
2024-02-18  3:28       ` Richard Stallman
2024-02-18  4:07         ` Corwin Brust
2024-02-18  4:20           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-21  2:56           ` Richard Stallman
2024-02-22 12:00             ` Philip Kaludercic [this message]
2024-02-25  3:13               ` Richard Stallman
2024-02-25 10:55                 ` Philip Kaludercic
2024-02-25 15:18                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 15:07         ` Philip Kaludercic
2024-02-18 18:19           ` Corwin Brust
2024-02-24 10:03 ` Philip Kaludercic
2024-02-25 10:06   ` Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-25 10:44     ` Philip Kaludercic

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=87a5nswvwr.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=69132@debbugs.gnu.org \
    --cc=corwin@bru.st \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    /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).