unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alex Schroeder <alex@gnu.org>
Cc: burton@openprivacy.org, emacs-devel@gnu.org
Subject: Re: irepeat.el - repeat through history data FAST
Date: Mon, 25 Mar 2002 11:42:54 +0100	[thread overview]
Message-ID: <87n0wxylld.fsf@gnu.org> (raw)
In-Reply-To: <200203250019.g2P0Jck02925@aztec.santafe.edu> (Richard Stallman's message of "Sun, 24 Mar 2002 17:19:38 -0700 (MST)")

Richard Stallman <rms@gnu.org> writes:

>     I am not sure irepeat should modify the minibuffer to replace
>     the standard completion.
>
> That is the only clean way to do it.  That is the only way that avoids
> the need to redefine individual commands that use the minibuffer.
> That is the only way that works across the board.

Hm, I actually thought that irepeat could be an alternative to or a
replacement for completing-read.  But often this does not make sense,
for example I have used irepeat for finding files -- but since irepeat
searches a list of strings for matches, the really existing files are
not used for completion, the file-name-history is.  In this case, how
would you want to augment find-file with irepeat?  I think this is not
possible.  It makes more sense when switching buffers, but for
switching buffers, we already have a gazillion ways to do it.  It
makes sense when completing symbols, I think, because the list of
symbols is easy to obtain and reasonably fast to search (unlike the
list of existing files).  Thus there perhaps, a transparent
replacement would be the right thing to do.

My point is, replacing standard completion is not that easy.  Or
perhaps you mean that irepeat should work just like icomplete-mode?
Perhaps that is the only "generic" way in which irepeat can be used.
It could be used in more powerful ways, though.  The finding of files
based on the history is one such example.  But these "better" ways of
doing things are difficult to get right, so it seems that you are
asking for the hardest part, first.

Maybe we should add it to Emacs, then let people offer ways to use it
(ie. write functions which use irepeat to do useful stuff), and
then let us consider wether we want to add those to Emacs.  BTW
irepeat comes with some examples, and some of these use the semantic
package which is not part of Emacs, yet.  So perhaps we just want to
take the core of irepeat and add it to Emacs instead of adding the
whole list of functions using it.  Thus we add irepeat and helpers,
which is an alternative to completing-read for elisp authors.  That
seems like a good first step to me.

Alex.
-- 
http://www.emacswiki.org/
Can anybody tell me what is going so dreadfully wrong in Palestine?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


  reply	other threads:[~2002-03-25 10:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87y9glt4h1.fsf@openprivacy.org>
2002-03-23 16:13 ` irepeat.el - repeat through history data FAST Richard Stallman
2002-03-23 18:42   ` Kevin A. Burton
2002-03-25  0:19     ` Richard Stallman
2002-03-25 10:42       ` Alex Schroeder [this message]
2002-03-25 22:38         ` Kim F. Storm
2002-03-26  0:55           ` Kevin A. Burton
2002-03-26  8:51         ` Richard Stallman
2002-03-26  9:12           ` Kevin A. Burton
2002-03-28  7:26         ` Kevin A. Burton

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=87n0wxylld.fsf@gnu.org \
    --to=alex@gnu.org \
    --cc=burton@openprivacy.org \
    --cc=emacs-devel@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).