RE: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Drew Adams]

    To me this feature seems as a rather awkward work-around the lack of a
    general way to handle start values in the minibuffer.

    I believe a good handling should allow the user to easily use the start
    value in any of these ways:

    1. As a default value.
    2. As a template.
    3. Not at all.

    1. If the user just hits return, the start value should be used as a
    default value.
    2. If something similar to the start value is needed, it should be
    possible [to] edit it. This is convenient in eg. a rename command if the
    old name is inserted as the start value.
    3. If one don't want to use the start value, it is annoying to have to
    delete it. In this case it should possible to simply type what one wants
    instead.

    For those of you that use pc-selection-mode, I believe there is a
    natural way to fulfill these requirements. Just try this:

    (add-hook 'minibuffer-setup-hook 'select-minibuffer-contents)

    (defun select-minibuffer-contents ()
      "Select minibuffer contents."
      (set-mark (point-max))
      (goto-char (minibuffer-prompt-end)))

    (defadvice next-history-element (after
    select-minibuffer-contents activate)
      "Select minibuffer contents."
      (set-mark (point-max))
      (goto-char (minibuffer-prompt-end))
      (setq deactivate-mark nil))

I think you're speaking of reading minibuffer input with a non-nil
INITIAL-INPUT argument (e.g. to `completing-read'), so that that value
appears initially in the minibuffer (for acceptance, deletion, or editing)
as a "start value".

Your code then makes sure this is preselected. If one is in pc-selection
mode (or delete-selection-mode), then typing will replace the selected start
value, and backspace will delete it.

Do I understand you correctly? If so...

It has been decided that the INITIAL-VALUE parameter to minibuffer-input
functions is more or less deprecated, in favor of the DEF (default-value)
parameter alone. The UI model chosen is not to burden the user with a start
value already in the minibuffer, but rather to let him use M-n to pull the
default value into the minibuffer (to serve as start value), if he wants it.

I don't like that decision, personally, but that's the way it is. I like
your approach, and I use something similar in my own library, icicles.el. I
also provide a user option to control whether or not the default value is
also used as a start value - for those who prefer the standard Emacs
approach to "start values":

icicle-use-default-as-init-value-flag:
 Non-nil means to use default value as init value when reading input.
 This is used by `completing-read'.  When the default-value argument is
 non-nil and the initial-input argument is nil or "",  the default
 value is inserted in the minibuffer as the initial input.

 This has the advantage of not requiring you to use `M-n' to retrieve
 the default value.  It has the disadvantage of making you empty the
 minibuffer if you do not want to use or edit the default value.

However, I think this issue is relatively independent of the treatment of //
and /~ in file-name input. I would not get rid of that special treatment,
even when the general behavior you describe is available. That shortcut is
useful at any time, not just with a "start value", and it erases only the
prefix through the slash, not the entire minibuffer content.