unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "jidanni@jidanni.org" <jidanni@jidanni.org>,
	"48134@debbugs.gnu.org" <48134@debbugs.gnu.org>
Subject: bug#48134: [External] : bug#48134: When sitting on top of a M-x item in the manual
Date: Sat, 1 May 2021 16:28:38 +0000	[thread overview]
Message-ID: <SA2PR10MB4474AD47529DBF790D03EA15F35D9@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <83y2cy8qt5.fsf@gnu.org>

Here we go again...

> If you want to suggest that a similar implementation be
> included in Emacs, it is enough to mention the existence
> of the solution.

I did that.  I did better than that.  I suggested
adding a similar, _general_ feature, instead of
arguing for this or that particular way to provide
such a feature.

> You could also describe your proposed implementation,
> while you are at that, as that gives ideas for our
> internal implementation.

... and I described the "solution" whose "existence"
I mentioned (and pointed to its code).

What's missing in Emacs is a simple way to pull text
at point into the minibuffer at point - into ANY
minibuffer (not just for `M-x' or completion).

Just what text gets pulled in, and how, is worth
discussing in the bug thread perhaps.  What I
offered was a suggestion to do so in a general way,
by e.g. binding a key in the most general minibuffer
keymap (not in a completion keymap).

I provided info about one particular example of such
a feature, describing possible behaviors wrt pulling
in text at point.  Maybe worth considering in the
context of the feature request, as food for thought.

But feel free to ignore those food-for-thought
details.  (The general suggestion has been made
before - and ignored.)

How is your rant against my contributed suggestion
helpful?

> looks like a shameless plug to me

I'm not plugging anything.  I made a point of
saying that this feature really has nothing to do
with the rest of Icicles, and that it's simple for
Emacs to implement it or something similar.

It's in Icicles only because it wasn't in Emacs and
because it's useful for interacting with the
minibuffer (which is important for using Icicles).

It would be good for Emacs itself to have such a
feature.  That's the point.  It's not about Icicles
having such a feature.

The doc I pointed to describes what the feature
does.  That info could be helpful in deciding what
to do for Emacs.  That's the point of describing
it for you.  If you don't find it helpful, ignore
it.

> Please don't clutter the bug tracker with such
> useless information.

Please consider implementing the enhancement
requested by Jidanni.  Just how that's done is less
important than doing it.  It could have been done
decades ago, when first suggested.

Do you really want a description of the Icicles
_implementation_ of this, as you say?  Describing
the behavior for users isn't enough?

Here's a high-level implementation description that
should be appropriate for this thread:

 1. Define a user option that provides functions
    that return a string of text at point or else
    nil.

 2. Call one of those functions when a user invokes
    the command for inserting text at point using
    some key (such as `M-.').

The option could be like what Icicles uses
(`icicle-thing-at-point-functions').  But it need
not be - it could be much simpler.

The way one of those functions is chosen could be
similar to what Icicles does.  But it need not be
- it could be much simpler.

I won't bore you more with the particular behavior
Icicles provides, or how.  That's not the point.

If you want more, just ask.  But again, I'm not
proposing that Emacs adopt the same behavior or
implementation.  I offered a description only as
food for thought.

To be extra clear: I _don't want_ more people to
use Icicles.  Really.  I don't have the time or
will to keep up with changes to vanilla Emacs
that make changes to my code necessary.  That's
life.

Icicles can, I think, offer food for thought, in
various ways.  It has already done so, resulting
in several other completion "frameworks" now.
That's all.  Food for thought.

  reply	other threads:[~2021-05-01 16:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-01  5:41 bug#48134: When sitting on top of a M-x item in the manual 積丹尼 Dan Jacobson
2021-05-01  8:59 ` Kévin Le Gouguec
2021-05-01 12:15   ` 積丹尼 Dan Jacobson
2021-05-02  7:14     ` Lars Ingebrigtsen
2021-05-02 14:09       ` Howard Melman
2021-05-02 16:09       ` Kévin Le Gouguec
2021-05-03  9:00         ` Lars Ingebrigtsen
2021-05-01 14:01 ` bug#48134: [External] : " Drew Adams
2021-05-01 14:35   ` Eli Zaretskii
2021-05-01 16:28     ` Drew Adams [this message]
2021-05-01 20:09   ` Juri Linkov
2021-05-01 23:23     ` Drew Adams
2021-05-02 20:52       ` Juri Linkov
2021-05-03  0:35         ` Drew Adams

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=SA2PR10MB4474AD47529DBF790D03EA15F35D9@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=48134@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=jidanni@jidanni.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).