unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>,
	Nicolas Graner <nicolas.graner@universite-paris-saclay.fr>
Cc: 43227@debbugs.gnu.org
Subject: bug#43227: EWW ignores 'multiple' attribute of 'select'
Date: Mon, 7 Sep 2020 09:05:22 -0700 (PDT)	[thread overview]
Message-ID: <170d9db9-2e46-4cdb-8e2c-e811e2c813db@default> (raw)
In-Reply-To: <87o8mhao1f.fsf@gnus.org>

> > I stand by my suggestion that a multiple select should look similar to a
> > list of checkboxes. Maybe it could actually be converted to checkboxes
> > at the DOM level, before rendering, and then let the normal checkbox
> > code do the job?
> 
> I think it would be kinda surprising to render a <select multiple> as a
> series of checkboxes: You expect a <select> to be kinda small even if
> the number of possible choices is large.

This is from the Icicles doc, but it's about vanilla Emacs:

 Any Emacs command could be defined to use an input loop,
 asking for file names until you do something to signal
 that you're done inputting. It could provide for file-name
 completion by calling 'read-file-name' to read your input.

(The same applies to any completion, of course, not just
file names.)

As food for thought about selecting multiple choices, here
are two Icicles features.  The second probably corresponds
more directly with what you're talking about.

1. Choose multiple completion candidates from the minibuffer.

https://www.emacswiki.org/emacs/Icicles_-_Multi-Commands

Continuation of the text quoted above, about an input loop:

 * But what if you could also filter the domain of discourse
   on the fly, so that the candidate files were only those
   matching a regular expression (regexp) that you typed?
   Then, the command definition would need to provide for
   that behavior too.

 * And what if you could then take the complement of that
   set of candidate file names, with respect to the complete
   set of files in the directory? Or subtract (exclude) some
   set of file names from the set of matching names, to get
   the set of possible choices?

 * And what if the set of potential candidates at each step
   (regexp match, complement, set difference) could also be
   displayed in a multiple-choice menu?

IOW, integrate multiple selection during completion with
other completion enhancements.  Let a function such as
`completing-read' let you choose multiple candidates, and
change the set of completion matches on the fly, so that
your multiple choices can correspond to different kinds
of matches.


2. Mark multiple completion candidates in *Completions*,
to select them for subsequent actions.

The difference here is that the selected candidates are
distinguished in *Completions*.  And they can be reused
in subsequent commands.  They can even be persisted and
reused in a later Emacs session.

Because they are both distinguished visually ("marked")
and reusable later, Icicles calls this "saving" instead
of "marking".

The marking is shown in *Completions*, but you can do it
without switching to that window.

https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#ChooseBeforeYouAct

https://www.emacswiki.org/emacs/Icicles_-_Candidate_Sets

From that page (about marking "saving" a set of candidates:

 Matching, saving, and retrieving candidates is a powerful
 way to interact with completion.  One important use is to
 prepare a list of candidates on which to act, and then
 act on them all at once using `C-!'.  This is a good way
 to proceed when you want to double-check what to act on,
 before you actually act.  This is the same idea behind
 marking files in Dired and then operating on the marked
 files, using 'x'.  It corresponds to what is represented
 in some user interfaces by filling out a checklist
 followed by clicking 'OK'.





      reply	other threads:[~2020-09-07 16:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-05 17:23 bug#43227: EWW ignores 'multiple' attribute of 'select' Nicolas Graner
2020-09-06 23:05 ` Lars Ingebrigtsen
2020-09-07  8:51   ` Nicolas Graner
2020-09-07 10:17     ` Lars Ingebrigtsen
2020-09-07 16:05       ` Drew Adams [this message]

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=170d9db9-2e46-4cdb-8e2c-e811e2c813db@default \
    --to=drew.adams@oracle.com \
    --cc=43227@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=nicolas.graner@universite-paris-saclay.fr \
    /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).