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'.
prev parent 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).