all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: RE: should `minibuffer-complete' use `abbreviate-file-name'?
Date: Fri, 12 Oct 2007 13:34:05 -0700	[thread overview]
Message-ID: <BNELLINCGFJLDJIKDGACKEJKCDAA.drew.adams@oracle.com> (raw)
In-Reply-To: <jwvir5c3ytu.fsf-monnier+emacs@gnu.org>

> >> For file-name completion, apply `abbreviate-file-name' to the
> >> user's input. This would let a user take advantage of a customized
> >> `directory-abbrev-alist' during completion.
> >>
> >> Would there be any downside to that?
> >>
> >> I don't think Emacs should alter the names that the user enters.
>
> > `directory-abbrev-alist' is nil by default. Users customize it.
> > It lets them substitute their own abbreviations for directories.
>
> > Why shouldn't completion respect the user's preference for such
> > abbreviations (e.g. symlinks)?
>
> I must say I do not understand what you're asking for.  Can you spell out
> a concrete example?

`directory-abbrev-alist' substitutes matches of its regexps against
directory names with their corresponding directory-name "abbreviations".

The doc shows only examples where the resulting directory names are shorter,
but the reverse relation can be useful as well: expand instead of contract.
The point is to substitute one directory name for another that is more
convenient in some way. The symlink case is only one use case, IIUC.

Here is the original feature request I received, describing a use case. The
user requests that the cars of `directory-abbrev-alist' entries be completed
to the cdrs.

 I've been using Icicles about over 1 year (but still i'm
 a sort of newbie). recently, i found i can use
 'directory-abbrev-alist' not to type very long path that
 is hard to remember in 'find-file'. But I also found that
 Icicles' completion mechanism (including default Emacs' one)
 does not handle this abbrev consistently. for example, when
 i set my directory-abbrev-alist up like
   (("^/exe" . "/very-long-path-here/exe"))
 and, when i enter in minibuffer after 'find-file', "/exe",
 and TAB no expansion occurred. How can i utilize
 abbreviation to long path in Icicle ways?

IOW, `find-file /exe RET' correctly expands the abbreviation. But the same
is not true of `find-file /exe TAB'. The user requests that the latter
feature be added.

To implement this, i just call `abbreviate-file-name' on the user's current
file-name input. Then, in the example above, both `C-x C-f /exe TAB' and
`C-x C-f /whatever/you/might/have//exe TAB' complete to
`/very-long-path-here/exe'.

Seems useful to me. Again, does anyone see a downside to such behavior? The
abbreviation list is under user control (customization), so I don't see the
point of Richard's complaint that Emacs completion would then be altering
what the user entered. That's the whole point of completion, no?

  reply	other threads:[~2007-10-12 20:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-02 19:25 should `minibuffer-complete' use `abbreviate-file-name'? Drew Adams
2007-10-03 18:37 ` Richard Stallman
2007-10-12 19:27   ` Drew Adams
2007-10-12 19:42     ` Stefan Monnier
2007-10-12 20:34       ` Drew Adams [this message]
2007-10-13  3:50         ` Stefan Monnier
2007-10-13  6:03           ` Drew Adams
2007-10-13 14:14             ` Richard Stallman
2007-10-13 15:06               ` Drew Adams
2007-10-14 16:28                 ` Richard Stallman
2007-10-14 16:56                   ` Drew Adams
2007-10-14 19:10                     ` Stefan Monnier
2007-10-15 16:04                     ` Richard Stallman
2007-10-15 16:25                       ` Drew Adams
2007-10-15 18:04                         ` Stefan Monnier
2007-10-15 18:19                           ` Drew Adams
2007-10-16  4:10                         ` Richard Stallman
2007-10-14  1:41             ` Stefan Monnier
2007-10-15  1:36               ` Richard Stallman
2007-10-13  9:50           ` Juanma Barranquero

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BNELLINCGFJLDJIKDGACKEJKCDAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.