key to yank text at point into minibuffer?

key to yank text at point into minibuffer?

[Drew Adams]

Perhaps something like this already exists and I'm unaware of it. If not,
perhaps it could be added - it represents a trivial change for users and
implementers. If users don't use it, then it means no change to them.

Some people use ffap.el. It tries to DTRT by placing some text at point
(with sometimes minor changes) into the minibuffer to serve as initial
input. It does this with file names, URLS, etc. in the buffer text.

I tried ffap.el for a while and found I didn't care much for it. In
particular, in Dired I rarely want to use the file name at point when I use
`C-x f' - if I want that then I just use `RET'.  Anyway, if people find
ffap.el handy that's fine. I realize that it also does other things,
including mailto: prefixing and remote-file handling.

Anyway, as a poor-man's replacement for some of the ffap functionality, I
added a minibuffer key (I use `M-.') to all minibuffer maps. This command
just yanks the symbol name at point into the minibuffer, replacing what was
there. It uses Emacs-Lisp symbol syntax, so, in practice, this also picks up
file names and URLs in the buffer. IOW, it provides some of what ffap
provides (the part I want), but without its DTRT second-guessing and only
upon demand (like setting `ffap-require-prefix' to t). Also, the symbol name
at point can be useful input even when it is not a file name or URL.

Sometimes, you might want the word at point (no symbol syntax) instead. So,
I use a user option that is a list of text-grabber functions - by default,
the first function grabs the symbol name at point, the second grabs the word
at point, and the third grabs the URL at point, prefixing it with http:// if
needed. In the minibuffer, a single `M-.' yanks the symbol name at point, a
second `M-.' replaces that with the word at point, and a third yanks the
URL. Other functions could be added to the list to do things like add
mailto: - the list is customizable.  In practice, I use a single `M-.' 90%
of the time, a second `M-.' 10% of the time, and a third `M-.' 0% of the
time (so far). A symbol name is usually the text I want to yank.

The other thing to mention is that many commands offer a default value that
is the word or symbol name at point. But other commands instead offer a
different default value that is deemed better most of the time. Providing
`M-.' lets you get the text at point even when the command's default value
is something else. You can think of it as an extension to `M-n' in this
respect.

Any interest in adding such a feature?  Who will be the first to let me know
that it already exists in some (better) form ;-)?

Re: key to yank text at point into minibuffer?

[Mathias Dahl]

"Drew Adams" <drew.adams@oracle.com> writes:

    Anyway, as a poor-man's replacement for some of the ffap
    functionality, I added a minibuffer key (I use `M-.') to all
    minibuffer maps. This command just yanks the symbol name at point
    into the minibuffer, replacing what was there.
    ...
    Any interest in adding such a feature?

I like the idea.  I use C-w in isearch a lot, and this is similar.  I
cannot see many cases I would use it right now, but I think it would
be useful when doing C-h f and when the word to the left of point is
just a partial function name.

For example, if point is just after `string-match' and I do C-h f I
get string-match suggested as default value.  That is good.  Sometimes
I start writing a function name but I don't know the whole name.  In
those cases C-h f will not help me at all, even if I have written the
first characters of the function name.  In that case, this M-. key
would have been useful to me.

I am curious, what do you use this for?

RE: key to yank text at point into minibuffer?

[Drew Adams]

        Anyway, as a poor-man's replacement for some of the ffap
        functionality, I added a minibuffer key (I use `M-.') to all
        minibuffer maps. This command just yanks the symbol name at point
        into the minibuffer, replacing what was there.
        ...
        Any interest in adding such a feature?

    I like the idea.  I use C-w in isearch a lot, and this is similar.

Yes. `C-w' in isearch was one inspiration for this; the other was ffap.

But there is no need, I think, for the analog of isearch's repeated `C-w'
yanking successive words. That's one reason I instead use repeating to
employ alternative text-grabbing functions.

    I cannot see many cases I would use it right now, but I think it would
    be useful when doing C-h f and when the word to the left of point is
    just a partial function name.

    For example, if point is just after `string-match' and I do C-h f I
    get string-match suggested as default value.  That is good.  Sometimes
    I start writing a function name but I don't know the whole name.  In
    those cases C-h f will not help me at all, even if I have written the
    first characters of the function name.  In that case, this M-. key
    would have been useful to me.

Yes. However:

. Cursor after (complete function name) "string-match" `C-h f' already
proposes `string-match' as the default. The proposal is useful in cases
where the default value is *not* the text at point.

. Wrt the case of a partial name like "string-ma": yes, this would help.
(You also have `ESC-TAB' (`lisp-complete-symbol').)

    I am curious, what do you use this for?

Uh, as I said, to pick up a file name or URL (or other name) in a buffer,
for use as minibuffer input. I use it as a poor-man's ffap.

Example: You're in a SQL script on a line like "@some-long-file-name.sql".
You use `C-x 4 f M-.' to pull that text into the minibuffer, to visit that
file. This saves you selecting the text and pasting it into the minibuffer;
that's all.

This example also points out the "poor-man" aspect: the symbol name at point
is not exactly what you want here, because it includes the `@', which you
must then delete. And if the script didn't explicitly include ".sql" in the
file name, then you would need to add that in the minibuffer (perhaps via
completion). In many cases, this mechanism gives you exactly the text you
need; in some cases you must tweak what it gives you.

Re: key to yank text at point into minibuffer?

[Mathias Dahl]

>     I am curious, what do you use this for?
>
> Uh, as I said, to pick up a file name or URL (or other name) in a buffer,
> for use as minibuffer input.

Yeah yeah yeah, you explained that... :) I was more interested in the below:

> Example: You're in a SQL script on a line like "@some-long-file-name.sql".
> You use `C-x 4 f M-.' to pull that text into the minibuffer, to visit that
> file. This saves you selecting the text and pasting it into the minibuffer;
> that's all.

This was what I was curious about. I'm always interested in how other
Emacs users use Emacs to get things done in an effective way.

RE: key to yank text at point into minibuffer?

[Drew Adams]

    > Example: You're in a SQL script on a line like
    > "@some-long-file-name.sql". You use `C-x 4 f M-.' to pull
    > that text into the minibuffer, to visit that file. This
    > saves you selecting the text and pasting it into the
    > minibuffer; that's all.

    This was what I was curious about. I'm always interested in how other
    Emacs users use Emacs to get things done in an effective way.

Ouchin' yowza! Please don't look to me for effective ways to do anything.
Ineffective ways to do something (or effective ways to do nothing) I might
be able to help you with.

Re: key to yank text at point into minibuffer?

[Kevin Rodgers]

Drew Adams wrote:
> I tried ffap.el for a while and found I didn't care much for it. In
> particular, in Dired I rarely want to use the file name at point when I use
> `C-x f' - if I want that then I just use `RET'.  Anyway, if people find
> ffap.el handy that's fine. I realize that it also does other things,
> including mailto: prefixing and remote-file handling.

(define-key dired-mode-map "\C-x\C-f" 'find-file) ; override ffap-bindings

-- 
Kevin Rodgers

RE: key to yank text at point into minibuffer?

[Drew Adams]

    > I tried ffap.el for a while and found I didn't care much for it. In
    > particular, in Dired I rarely want to use the file name at
    > point when I use `C-x f' - if I want that then I just use `RET'.
    > Anyway, if people find ffap.el handy that's fine. I realize that it
    > also does other things, including mailto: prefixing and remote-file
    > handling.

    (define-key dired-mode-map "\C-x\C-f" 'find-file) ; override
                                                      ; ffap-bindings

Well, that wasn't the real point of my posting, but yes, that would do the
trick for `C-x C-f' in Dired. However, ffap.el does a lot more in Dired, and
there are other such bindings to override.

I no longer use ffap.el, but when I did, I added an option to inhibit it,
and set the option as a local variable when in Dired mode. That might be
overkill, but it accomplished what I wanted.

Re: key to yank text at point into minibuffer?

[Kevin Rodgers]

Drew Adams wrote:
>     > I tried ffap.el for a while and found I didn't care much for it. In
>     > particular, in Dired I rarely want to use the file name at
>     > point when I use `C-x f' - if I want that then I just use `RET'.
>     > Anyway, if people find ffap.el handy that's fine. I realize that it
>     > also does other things, including mailto: prefixing and remote-file
>     > handling.
> 
>     (define-key dired-mode-map "\C-x\C-f" 'find-file) ; override
>                                                       ; ffap-bindings
> 
> Well, that wasn't the real point of my posting, but yes, that would do the
> trick for `C-x C-f' in Dired. However, ffap.el does a lot more in Dired, and
> there are other such bindings to override.

ffap.el itself says:

;; For the default installation, add this line to your .emacs file:
;;
;; (ffap-bindings)                      ; do default key bindings
;;
;; ffap-bindings makes the following global key bindings:
;;
;; C-x C-f		find-file-at-point (abbreviated as ffap)
;; C-x C-r		ffap-read-only
;; C-x C-v		ffap-alternate-file
;;
;; C-x d		dired-at-point
;; C-x C-d		ffap-list-directory
;;
;; C-x 4 f		ffap-other-window
;; C-x 4 r		ffap-read-only-other-window
;; C-x 4 d		ffap-dired-other-window
;;
;; C-x 5 f		ffap-other-frame
;; C-x 5 r		ffap-read-only-other-frame
;; C-x 5 d		ffap-dired-other-frame
;;
;; S-mouse-3     ffap-at-mouse
;; C-S-mouse-3   ffap-menu
;;
;; ffap-bindings also adds hooks to make the following local bindings
;; in vm, gnus, and rmail:
;;
;; M-l         ffap-next, or ffap-gnus-next in gnus (l == "link")
;; M-m         ffap-menu, or ffap-gnus-menu in gnus (m == "menu")
;;
;; If you do not like these bindings, modify the variable
;; `ffap-bindings', or write your own.

That last part is muy importante.

> I no longer use ffap.el, but when I did, I added an option to inhibit it,
> and set the option as a local variable when in Dired mode. That might be
> overkill, but it accomplished what I wanted.

I think that would be a userful feature.

-- 
Kevin Rodgers

RE: key to yank text at point into minibuffer?

[Drew Adams]

    ffap.el itself says:

    ;; For the default installation, add this line to your .emacs file:
    ;;
    ;; (ffap-bindings)                      ; do default key bindings
    ;;
    ;; ffap-bindings makes the following global key bindings:
    ...
    ;; If you do not like these bindings, modify the variable
    ;; `ffap-bindings', or write your own.

    That last part is muy importante.

Yes, I read that. That was why I suggested that ffap instead have a minor
mode. I'm not crazy about that way of turning a set of bindings on.

    > I no longer use ffap.el, but when I did, I added an option to
    > inhibit it, and set the option as a local variable when in Dired mode.
    > That might be overkill, but it accomplished what I wanted.

    I think that would be a userful feature.

I think ffap.el should instead have a minor mode with its own keymap.

(BTW, I like "userful" for "user useful", whether it was a typo or not.)

Re: key to yank text at point into minibuffer?

[Kevin Rodgers]

Drew Adams wrote:
 >     ffap.el itself says:
 >
 >     ;; For the default installation, add this line to your .emacs file:
 >     ;;
 >     ;; (ffap-bindings)                      ; do default key bindings
 >     ;;
 >     ;; ffap-bindings makes the following global key bindings:
 >     ...
 >     ;; If you do not like these bindings, modify the variable
 >     ;; `ffap-bindings', or write your own.
 >
 >     That last part is muy importante.
 >
 > Yes, I read that. That was why I suggested that ffap instead have a minor
 > mode. I'm not crazy about that way of turning a set of bindings on.

I agree, and I like your minor mode idea.

 >     > I no longer use ffap.el, but when I did, I added an option to
 >     > inhibit it, and set the option as a local variable when in 
Dired mode.
 >     > That might be overkill, but it accomplished what I wanted.
 >
 >     I think that would be a userful feature.
 >
 > I think ffap.el should instead have a minor mode with its own keymap.

Is it as simple as this:

(defvar ffap-mode-map
   (let ((map (make-sparse-keymap)))
      ;; see ffap-bindings:

      (define-key map [S-mouse-3] 'ffap-at-mouse)
      (define-key map [C-S-mouse-3] 'ffap-menu)

      (define-key map "\C-x\C-f" 'find-file-at-point)
      (define-key map "\C-x\C-r" 'ffap-read-only)
      (define-key map "\C-x\C-v" 'ffap-alternate-file)

      (define-key map "\C-x4f"   'ffap-other-window)
      (define-key map "\C-x5f"   'ffap-other-frame)
      (define-key map "\C-x4r"   'ffap-read-only-other-window)
      (define-key map "\C-x5r"   'ffap-read-only-other-frame)

      (define-key map "\C-xd"    'dired-at-point)
      (define-key map "\C-x4d"   'ffap-dired-other-window)
      (define-key map "\C-x5d"   'ffap-dired-other-frame)
      (define-key map "\C-x\C-d" 'ffap-list-directory)

      ;; (add-hook 'gnus-summary-mode-hook 'ffap-gnus-hook)
      ;; (add-hook 'gnus-article-mode-hook 'ffap-gnus-hook)
      ;; (add-hook 'vm-mode-hook 'ffap-ro-mode-hook)
      ;; (add-hook 'rmail-mode-hook 'ffap-ro-mode-hook)

      map))

(defvar ffap-mode-hook nil
   "Hook run by `ffap-mode'.")

(define-minor-mode ffap-mode
   "Toggle `ffap' bindings in every buffer.

\\{ffap-mode-map}"
   :global t :lighter ""
   (run-hooks 'ffap-mode-hook))

 > (BTW, I like "userful" for "user useful", whether it was a typo or not.)

It was a typo, but a serendipitous one.  I was going to add it to
Wikipedia's list of portmanteau words, but then Google pointed me to
userful.com, a company that markets a GNU/Linux-based PC for public
places like libraries.

-- 
Kevin Rodgers

RE: key to yank text at point into minibuffer?

[Drew Adams]

     > I think ffap.el should instead have a minor mode with its own keymap.

    Is it as simple as this:
    (defvar ffap-mode-map
       (let ((map (make-sparse-keymap)))
          (define-key map [S-mouse-3] 'ffap-at-mouse)
          ...
          map))
    (defvar ffap-mode-hook nil "Hook run by `ffap-mode'.")
    (define-minor-mode ffap-mode
       "Toggle `ffap' bindings in every buffer.
    \\{ffap-mode-map}"
       :global t :lighter ""
       (run-hooks 'ffap-mode-hook))

Yes, I think so.

However:

. Does "" for :lighter act the same as nil? I'm not sure - the doc only
speaks of nil. Logically, I guess "" would display an empty string when the
mode is on and display nothing when it is off ;-).

. Isn't it good practice to show the mode name in the lighter? Shouldn't
people see whether or not they are in ffap mode?

Re: key to yank text at point into minibuffer?

[Kevin Rodgers]

Drew Adams wrote:
 >      > I think ffap.el should instead have a minor mode with its own 
keymap.
 >
 >     Is it as simple as this:
 >     (defvar ffap-mode-map
 >        (let ((map (make-sparse-keymap)))
 >           (define-key map [S-mouse-3] 'ffap-at-mouse)
 >           ...
 >           map))
 >     (defvar ffap-mode-hook nil "Hook run by `ffap-mode'.")
 >     (define-minor-mode ffap-mode
 >        "Toggle `ffap' bindings in every buffer.
 >     \\{ffap-mode-map}"
 >        :global t :lighter ""
 >        (run-hooks 'ffap-mode-hook))
 >
 > Yes, I think so.
 >
 > However:
 >
 > . Does "" for :lighter act the same as nil? I'm not sure - the doc only
 > speaks of nil. Logically, I guess "" would display an empty string 
when the
 > mode is on and display nothing when it is off ;-).

I guess so, too.  The difference is that an entry isn't added to
minor-mode-alist for :lighter nil.

 > . Isn't it good practice to show the mode name in the lighter? Shouldn't
 > people see whether or not they are in ffap mode?

I don't know.  I figure the global minor modes I'm familiar with
(auto-compression, font-lock, and mouse-wheel) don't show up in the mode
line so I'd leave it out.  But then, those modes don't override default
keybindings either.  What does everyone think?

There's also a bug above: define-minor-mode already arranges for
ffap-mode-hook (and either ffap-mode-on-hook or ffap-mode-off-hook) to
be run, so calling run-hooks is redundant at best.

-- 
Kevin Rodgers

Re: key to yank text at point into minibuffer?

[Juri Linkov]

>> . Isn't it good practice to show the mode name in the lighter? Shouldn't
>> people see whether or not they are in ffap mode?
>
> I don't know.  I figure the global minor modes I'm familiar with
> (auto-compression, font-lock, and mouse-wheel) don't show up in the mode
> line so I'd leave it out.  But then, those modes don't override default
> keybindings either.  What does everyone think?

The mode line is already too overburdened, so I think adding a label
for ffap is not desirable.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: key to yank text at point into minibuffer?

[Juri Linkov]

> Providing `M-.' lets you get the text at point even when the command's
> default value is something else. You can think of it as an extension to
> `M-n' in this respect.

Then why not use `M-n' directly, with every successive `M-n' inserting the
next symbol/URL/file name to the minibuffer?  I have a simple patch that
does this for the grep prompt, but it was held due to the feature freeze.
However, to implement a replacement for ffap, it should be improved further
to allow extending the list of default values with more user-defined values.
I.e. instead of giving the list of default values as an argument of one of
the minibuffer functions, there should be a new buffer-local variable with
a user-defined function to get some text from the buffer and add it to
the list of default values.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: key to yank text at point into minibuffer?

[Drew Adams]

    > Providing `M-.' lets you get the text at point even when the command's
    > default value is something else. You can think of it as an
    > extension to `M-n' in this respect.

    Then why not use `M-n' directly,

Because it often makes sense for a given command to use a default value that
is *not* the word/symbol/whatever at point - the command provides a value
that is (in principle) smarter, more specific to that command (DTRT). The
thing at point can sometimes be useful, but there is sometimes a better
default value, which might be totally unrelated to the buffer text.

There is no reason not to have both available: 1) an intelligent,
command-specific default value and 2) something at point (available always).

    with every successive `M-n' inserting the next symbol/URL/file
    name to the minibuffer?

Do you mean insert (so, accumulate) or replace what's in the minibuffer?
Your grep example below makes me think the former.

Successive `M-n' have the meaning now of traversing the history list. There
is no reason to confuse people by mapping an additional meaning onto
successive `M-n'. And there is no reason not to provide this orthogonal
feature (value) via a different key.

Also, assuming you mean to accumulate (not replace) successive words, there
are relatively few commands that expect/accept minibuffer input of multiple
words - `grep' is one such (provided you quote the string). For those
exceptional commands, users could simply select the words and then paste
them into the minibuffer.

This is a design choice - whether successive `M-.' (or `M-n', in your
suggestion) should accumulate text at point, as you suggest, or should
provide alternative kinds of thing at point, as I suggested. I can see
arguments for each approach.

I admitted, for instance, that 90% of the time I use simply the symbol at
point, and the other 9-10% of the time I use the word at point. One might
argue, then, that there is not much need for providing alternative
text-grabbing functions. I expect that such alternatives can be useful,
especially with buffer-local values specific to particular modes, but that's
just my intuition speaking.

My guess is that being able to grab successive words at point is less useful
than being able to grab different kinds of thing at point.

Note too that one could have a particular text-grabbing function that would
do just what you describe: it could, itself, let you grab successive words.
There are several ways it could do this. So, in this sense, your approach
could be a particular implementation of mine (just use a particular
text-grabbing function).

    I have a simple patch that does this for the grep prompt, but
    it was held due to the feature freeze.

    However, to implement a replacement for ffap,

To be clear about my proposal, anyway: I wasn't suggesting to get rid of
ffap. I meant only that (even independently of employing it as a poor-man's
ffap) using `M-.' to retrieve something at point would be useful. We can
forget about ffap in this discussion.

    it should be improved further to allow extending the list of
    default values with more user-defined values.
    I.e. instead of giving the list of default values as an
    argument of one of the minibuffer functions, there should be
    a new buffer-local variable with a user-defined function to
    get some text from the buffer and add it to
    the list of default values.

I don't follow you completely. Could you give an example of what you mean,
contrasting it with the behavior I described?

I think (but please clarify) that you're saying a few things: 1) Use a
single buffer-local function, not a list of functions, to retrieve the thing
at point; 2) Make the function buffer-local; 3) Add the retrieved thing to
the standard list of default values.

I spoke to #3 above: I'd prefer to keep the default-value list separate from
this text-grabbing feature. They are logically independent: one is decided
by the command; the other is decided by the text at point and the user.

Wrt #1: I'd prefer a list of different grab functions, as I said (with
successive `M-.' using successive functions), rather than a single function.

Wrt #2: Nothing would prevent a library or user from making the list of
functions buffer-local and giving it different values in particular buffers.

That is, I don't see the "further improvement" needed: Just have a variable
that is the list of grab functions. Users and programs can always make it
buffer-local and give it different values. (Yes, I know, there is a conflict
between having the variable be a user option and letting programs modify it,
but that can be resolved in different ways.)

Re: key to yank text at point into minibuffer?

[Juri Linkov]

>     with every successive `M-n' inserting the next symbol/URL/file
>     name to the minibuffer?
>
> Do you mean insert (so, accumulate) or replace what's in the minibuffer?

I mean to replace i.e. exactly how M-p works.

> Successive `M-n' have the meaning now of traversing the history list. There
> is no reason to confuse people by mapping an additional meaning onto
> successive `M-n'.

There is no reason to limit the default value list only to one value.

> This is a design choice - whether successive `M-.' (or `M-n', in your
> suggestion) should accumulate text at point, as you suggest, or should
> provide alternative kinds of thing at point, as I suggested. I can see
> arguments for each approach.

These approaches are not conflicting.  You suggest `M-.' to accumulate
text at point with replacing alternative kinds of thing at point. And I
suggest `M-n' to replace the minibuffer contents with default values
pre-constructed from alternative kinds of thing at point.  So these
approaches are rather complementary.

>     I have a simple patch that does this for the grep prompt, but
>     it was held due to the feature freeze.
>
>     However, to implement a replacement for ffap,
>
> To be clear about my proposal, anyway: I wasn't suggesting to get rid of
> ffap. I meant only that (even independently of employing it as a poor-man's
> ffap) using `M-.' to retrieve something at point would be useful. We can
> forget about ffap in this discussion.

This is what I meant too: to leave ffap alone, and to develop a simpler way
to do the same things as ffap.

>     it should be improved further to allow extending the list of
>     default values with more user-defined values.
>     I.e. instead of giving the list of default values as an
>     argument of one of the minibuffer functions, there should be
>     a new buffer-local variable with a user-defined function to
>     get some text from the buffer and add it to
>     the list of default values.
>
> I think (but please clarify) that you're saying a few things: 1) Use a
> single buffer-local function, not a list of functions, to retrieve the thing
> at point; 2) Make the function buffer-local; 3) Add the retrieved thing to
> the standard list of default values.

Yes, exactly.

> I spoke to #3 above: I'd prefer to keep the default-value list separate
> from this text-grabbing feature.

Yes, they are separate features.

> They are logically independent: one is decided by the command; the other
> is decided by the text at point and the user.

They are not completely independent: often the text at point is what the
user wants to have in a particular place inside the command in the minibuffer.
And `M-n' does this just fine.  OTOH, `M-.' does the same thing the other way
with more keystrokes required from the user, and still is restricted in what
the user might expect from this feature: to grab successive characters, words,
maybe even lines to the minibuffer the same way as e.g. isearch does with
C-w and C-y.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: key to yank text at point into minibuffer?

[Drew Adams]

    >     with every successive `M-n' inserting the next symbol/URL/file
    >     name to the minibuffer?
    >
    > Do you mean insert (so, accumulate) or replace what's in the
    > minibuffer?

    I mean to replace i.e. exactly how M-p works.

OK, me too.

    > Successive `M-n' have the meaning now of traversing the
    > history list. There is no reason to confuse people by mapping
    > an additional meaning onto successive `M-n'.

    There is no reason to limit the default value list only to one value.

That may be, but I think it's beside the point I was making: There would
still be two different things that `M-n' would be doing (promoting
confusion, IMO): 1) cycle among the values in your default-value list and 2)
what it does now: advance in the history list.

    > This is a design choice - whether successive `M-.' (or `M-n', in your
    > suggestion) should accumulate text at point, as you suggest, or should
    > provide alternative kinds of thing at point, as I suggested. I can see
    > arguments for each approach.

    These approaches are not conflicting.  You suggest `M-.' to accumulate
    text at point with replacing alternative kinds of thing at point.

Not sure what you mean by "accumulate...replacing". I suggested to _replace_
the minibuffer input successively by different alternative things at point.
There was no accumulation.

    And I suggest `M-n' to replace the minibuffer contents with default
    value pre-constructed from alternative kinds of thing at point.

Again, I'm not sure what you mean here. Previously you suggested that M-n
would replace (I wasn't sure whether it was accumulate or replace, but
you've confirmed replace) the minibuffer input with increasingly greater
numbers of words at point.

    So these approaches are rather complementary.

IIUYC, that's also what I said, mentioning that your suite of alternatives
(longer strings of words) could be implemented as one of the list of
alternative text-grabbing functions that I proposed.

    >     I have a simple patch that does this for the grep prompt, but
    >     it was held due to the feature freeze.
    >
    >     However, to implement a replacement for ffap,
    >
    > To be clear about my proposal, anyway: I wasn't suggesting to
    > get rid of ffap. I meant only that (even independently of employing
    > it as a poor-man's ffap) using `M-.' to retrieve something at point
    > would be useful. We can forget about ffap in this discussion.

    This is what I meant too: to leave ffap alone, and to develop a
    simpler way to do the same things as ffap.

Some of the same things, yes.

    >     it should be improved further to allow extending the list of
    >     default values with more user-defined values.
    >     I.e. instead of giving the list of default values as an
    >     argument of one of the minibuffer functions, there should be
    >     a new buffer-local variable with a user-defined function to
    >     get some text from the buffer and add it to
    >     the list of default values.
    >
    > I think (but please clarify) that you're saying a few things:
    > 1) Use a single buffer-local function, not a list of functions,
    > to retrieve the thing at point; 2) Make the function buffer-local;
    > 3) Add the retrieved thing to the standard list of default values.

    Yes, exactly.

    > I spoke to #3 above: I'd prefer to keep the default-value
    > list separate from this text-grabbing feature.

    Yes, they are separate features.

    > They are logically independent: one is decided by the
    > command; the other is decided by the text at point and the user.

    They are not completely independent: often the text at point is what the
    user wants to have in a particular place inside the command in
    the minibuffer.

They are _logically_ independent. Some commands provide text at point as the
default value, so in those cases the two coincide. But in the general case
they don't.

I don't know what you mean by "in a particular place inside the command". If
you are talking about inserting the text at point in a particular place
within the existing input string, then I'm confused. I thought you were (as
I am) talking about the text at point _replacing_ the existing minibuffer
input, not being inserted into it.

    And `M-n' does this just fine.  OTOH, `M-.' does the same thing
    the other way with more keystrokes required from the user,

Sorry, I must not be following you at all. How is `M-.' more keystrokes than
`M-n'?

    and still is restricted in what the user might expect from this
    feature: to grab successive characters, words,
    maybe even lines to the minibuffer the same way as e.g. isearch
    does with C-w and C-y.

Sorry, I'm lost. I don't see the restriction you're suggesting. Perhaps a
concrete example would clear this up. I think I have not understood you.

Re: key to yank text at point into minibuffer?

[Juri Linkov]

>     > This is a design choice - whether successive `M-.' (or `M-n', in your
>     > suggestion) should accumulate text at point, as you suggest, or should
>     > provide alternative kinds of thing at point, as I suggested. I can see
>     > arguments for each approach.
>
>     These approaches are not conflicting.  You suggest `M-.' to accumulate
>     text at point with replacing alternative kinds of thing at point.
>
> Not sure what you mean by "accumulate...replacing". I suggested to _replace_
> the minibuffer input successively by different alternative things at point.
> There was no accumulation.

I mean accumulating only on the first `M-.', and replacing the thing
inserted to the minibuffer by the first `M-.' with other things on all
successive `M-.'.  It would be useful to keep the initial minibuffer
input intact, and to insert/replace things within the existing minibuffer
input.

> I don't know what you mean by "in a particular place inside the command". If
> you are talking about inserting the text at point in a particular place
> within the existing input string, then I'm confused. I thought you were (as
> I am) talking about the text at point _replacing_ the existing minibuffer
> input, not being inserted into it.

I think `M-.' should not replace the existing minibuffer input, because I
imagine such a situation when the user types e.g. `M-!', types a command
and wants to *add* the thing at point to the end of the command in
the minibuffer.

>     And `M-n' does this just fine.  OTOH, `M-.' does the same thing
>     the other way with more keystrokes required from the user,
>
> Sorry, I must not be following you at all. How is `M-.' more keystrokes
> than `M-n'?

`M-.' requires more keystrokes than `M-n' only for the cases where
a complex input string is constructed from things at point (like the grep
case).  Thus `M-.'  requires from the user typing the input string,
navigating to the correct place in it and typing `M-.'.

>     and still is restricted in what the user might expect from this
>     feature: to grab successive characters, words,
>     maybe even lines to the minibuffer the same way as e.g. isearch
>     does with C-w and C-y.
>
> Sorry, I'm lost. I don't see the restriction you're suggesting. Perhaps a
> concrete example would clear this up. I think I have not understood you.

I think a single key is not enough to unleash the full potential
of `M-.'.  I expect that users might want additional keybindings
to yank successive characters/words/lines to the minibuffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: key to yank text at point into minibuffer?

[Drew Adams]

    > Not sure what you mean by "accumulate...replacing". I
    > suggested to _replace_ the minibuffer input successively by
    > different alternative things at point. There was no accumulation.

    I mean accumulating only on the first `M-.', and replacing the thing
    inserted to the minibuffer by the first `M-.' with other things on all
    successive `M-.'.  It would be useful to keep the initial minibuffer
    input intact, and to insert/replace things within the existing
    minibuffer input.

    I think `M-.' should not replace the existing minibuffer input,
    because I imagine such a situation when the user types e.g. `M-!', types
    a command and wants to *add* the thing at point to the end of the
command in
    the minibuffer.

The version I currently use replaces all minibuffer input, even the first
time. But I can see your point. It probably makes sense not to replace
minibuffer input on the first use of `M-.' It should only replace stuff that
it has previously inserted itself (immediately before).

    > Sorry, I must not be following you at all. How is `M-.' more
    > keystrokes than `M-n'?

    `M-.' requires more keystrokes than `M-n' only for the cases where
    a complex input string is constructed from things at point
    (like the grep case).  Thus `M-.'  requires from the user typing the
    input string, navigating to the correct place in it and typing `M-.'.

I don't see this. Whether the new behavior being discussed is bound to `M-n'
or `M-.', it has the same behavior, so the same number of keystrokes would
be required in each case. The only issue wrt the key binding is the
double-duty that you want `M-n' to perform: minibuffer history traversal and
text-grabbing at point. I want to put those two different behaviors on
different bindings.

    >     and still is restricted in what the user might expect from this
    >     feature: to grab successive characters, words,
    >     maybe even lines to the minibuffer the same way as e.g. isearch
    >     does with C-w and C-y.
    >
    > Sorry, I'm lost. I don't see the restriction you're
    > suggesting. Perhaps a concrete example would clear this up.
    > I think I have not understood you.

Still no concrete example, BTW. Maybe you're right, but how can I tell
without a reason or an example of what you mean?

    I think a single key is not enough to unleash the full potential
    of `M-.'.  I expect that users might want additional keybindings
    to yank successive characters/words/lines to the minibuffer.

I think you're now making my argument - not the part about needing more key
bindings, but the part about the utility of having alternative text-grabbing
functions.

To be clear, here are my points, after adopting your proposal to not replace
initial input, and after thinking some more about the utility of
successively grabbing more of the same kind of thing (e.g. words) at point:

1. Use a separate key, not `M-n' (which is history traversal), for
text-grabbing. E.g. `M-.'.

2. Bind `M-.' to a list of two things: a) a list of alternative
text-grabbing functions - my approach and b) a single function that grabs
successive things (e.g. words) - your approach. Either component could be
nil, in which case that behavior would not be available. The default value
could be this:

  ((symbol-grabber word-grabber line-grabber URL-grabber) word-grabber).

If you never wanted my approach, you would use (nil word-grabber). If I
never wanted your approach, I would use ((symbol-grabber word-grabber
line-grabber URL-grabber) nil)

3. If both components are present, one of them is the default, to be
determined by a new user option.

Alternatively, the order of the components could determine which is the
default, but in that case you could not use a lambda list for the
single-function component (or else we we need to recognize lambda, quoted
lambda, function, #', etc).

4. When you use `M-.', you always get the default behavior, as determined by
the new option, unless you first use `C-u', in which case you get the
alternate behavior.

Example: I like the default behavior to cause successive `M-.' to grab
alternative things, so I set the option to choose this (i.e. to use the
first component). You like the default behavior to cause successive `M-.' to
grab successive things of the same kind (e.g. words), so you set the option
to choose that (i.e. to use the second component). Each of us is happy.

If at some point while inputting I want your preferred behavior, I use `C-u
M-.' in the minibuffer. From then on, as long as I keep doing `M-.', I get
your behavior of grabbing successive words.

If at some point while inputting you want my preferred behavior, you use
`C-u M-.'. From then on, as long as you keep using `M-.', you get my
behavior of grabbing different kinds of thing at point. Each of us is happy
to be able to get the alternate behavior for a one-off use.

5. `C-u' could be more sophisticated yet. If you use a numeric arg, not just
plain `C-u', then the numeric arg could specify the number of things to
grab, in the case of alternative types of things (first component of the
`M-.' list). The second component does let you grab multiple things, but
they are always of the same type (e.g. words). Using this, I could use `C-u
6 M-. M-.' to grab 6 of whatever kind of thing the second grabbing function
grabs.

For example, if I wanted to insert 6 lines, then I could use `C-u 6 M-. M-.
M-.'. Granted, for the default grabbing functions this might have limited
utility, but users might have special grabbers for which this could be
useful.

RE: key to yank text at point into minibuffer?

[Drew Adams]

I wrote:

    2. Bind `M-.' to a list of two things: a) a list of alternative
    text-grabbing functions and b) a single function that grabs
    successive things (e.g. words). Either component could be nil,
    in which case that behavior would not be available. The default
    value could be this:

      ((symbol-grabber word-grabber line-grabber URL-grabber) word-grabber).

    3. If both components are present, one of them is the default, to be
    determined by a new user option.

    4. When you use `M-.', you always get the default behavior, as
    determined by the new option, unless you first use `C-u', in which
    case you get the alternate behavior.

    5. If you use a numeric arg, not just plain `C-u', then the numeric arg
    could specify the number of things to grab.  Using this, you could use
    `C-u 6 M-. M-.' to grab 6 of whatever kind of thing the second grabbing
    function grabs.

FWIW, there is now an implementation of this here:
http://www.emacswiki.org/cgi-bin/wiki/icicles.el. See command
`icicle-insert-string-at-point' (`M-.') and options
`icicle-thing-at-point-functions' and `icicle-default-thing-insertion'. It
was a bit trickier than I expected.

To try it, just load the file. During minibuffer input, try repeated `M-.'
with or without a prefix arg.

I made one change: the second component in #2 is a function that moves
forward a thing, not a function that grabs a thing. That's easier for
accumulating things. See the doc string of
`icicle-thing-at-point-functions'.

Re: key to yank text at point into minibuffer?

[Juri Linkov]

> During minibuffer input, try repeated `M-.'  with or without a prefix arg.

Basically I like this functionality.  But it still doesn't work as I expected.
It is not easy to use as ffap.  For instance I can't easily put URLs at point
to the minibuffer created by C-x C-f.  Unlike ffap that puts the URL to the
minibuffer just after typing C-x C-f, `M-.' requires typing more keys:
C-x C-f C-a C-k C-u M-.

When I suggested adding the thing at point instead of replacing the
minibuffer input, I meant that preserving the minibuffer input is needed
only for the input typed by the user, but not for the initial input.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: key to yank text at point into minibuffer?

[Drew Adams]

    Basically I like this functionality.  But it still doesn't work
    as I expected. It is not easy to use as ffap.  For instance I can't
    easily put URLs at point to the minibuffer created by C-x C-f.
    Unlike ffap that puts the URL to the minibuffer just after typing
    C-x C-f, `M-.' requires typing more keys:
    C-x C-f C-a C-k C-u M-.

Ffap tries to do only one thing - it always replaces the existing input,
IIUC. That was the way I approached this initially, but you made me see the
light ;-).

(BTW, everyone should have a key bound in the minibuffer to a command that
erases the minibuffer. I use `M-S-backspace'.)

    When I suggested adding the thing at point instead of replacing the
    minibuffer input, I meant that preserving the minibuffer input is needed
    only for the input typed by the user, but not for the initial input.

That difference can be known perhaps at the beginning of minibuffer input,
by the particular command that reads input (and inserts the initial value).
Ffap operates with such knowledge (although I don't think it does anything
particular with it). Ffap replaces particular input-reading commands with
others, in effect.

The approach being discussed is, on the other hand, very general. `M-n' is
not a top-level command; it is a minibuffer command. You can use `M-.' at
any position in the minibuffer to yank things there - as you suggested.
Because of this, there is no way for the `M-.' command to know if what is
currently in the minibuffer is stuff that you typed or stuff that was put
there initially (by the command using the minibuffer to read). At best, it
can know what it has, itself, inserted previously.

Further, there is certainly no way for `M-.' to know when _you want_ to add
to the input vs replace it. Unless you somehow tell it.

`C-u C-u', for instance, might be used to indicate that you want to first
erase the minibuffer, before inserting grabbed text - or vice versa, if
replacement were the default behavior. However, the very different behaviors
of `C-u' and `C-u C-u' might result in confusion. And of course `C-u C-u' is
no easier than `C-a C-k'.

As I see it, the main alternative to explicitly indicating one's intention
wrt the existing input is to return to the behavior I had before: when
alternative text-grabbing functions are cycled, they each replace the
existing input (no matter where it came from) - no insertion without
replacement in the case of alternative grab functions.

My preference would be what I currently have: insertion without replacement,
requiring you to first empty the minibuffer if you want replacement.

----

FYI, I just uploaded a new version that also lets you use a negative prefix
arg to successively grab text to the left of the cursor. A numeric prefix
arg (not plain `C-u') imposes the grab direction for all subsequent `M-.' -
until the next numeric prefix arg of course. And, as before, the magnitude
of the arg determines the number of things to grab.

For instance, `M-- M-.' grabs and inserts the word to the left of point.
Subsequent `M-.' continue to yank words further to the left, so that you can
build up the string to the left of point (in order of course).

If you then use `C-u 2 M-.', the previously yanked input is replaced by the
two (prefix value=2) words to the right of point. Subsequent `M-.' then
continue to grab successive words to the right. Yes, I said "replaced".

You can get the effect of grabbing text both to the left and to the right,
by simply doing something (e.g. `C-b C-f') to interrupt the chain of
consecutive `M-n'. For instance, `M-x foobar M-- M-. M-. M-. C-b C-f C-u 1
M-.' will yank three words to the left of point and one word to the right of
it.  This is quicker than it sounds - again, it's easier to experience than
to describe. In this way, the exact position of point is not so critical.

Try it here: http://www.emacswiki.org/cgi-bin/wiki/icicles.el

Re: key to yank text at point into minibuffer?

[Mathias Dahl]

> (BTW, everyone should have a key bound in the minibuffer to a command that
> erases the minibuffer. I use `M-S-backspace'.)

I agree. Many shells have that and in a way, Emacs' different prompts
have the same function. Such a key bound by default in Emacs would be
useful, and I think it should do `delete', not `kill'.

Re: key to yank text at point into minibuffer?

[Mathias Dahl]

> And of course `C-u C-u' is
> no easier than `C-a C-k'.

Really? I find that the former is much easier to type. Keep Ctrl
pressed and quickly press `u' two times with the same finger.

Re: key to yank text at point into minibuffer?

[Miles Bader]

"Mathias Dahl" <mathias.dahl@gmail.com> writes:
>> And of course `C-u C-u' is
>> no easier than `C-a C-k'.
>
> Really? I find that the former is much easier to type. Keep Ctrl
> pressed and quickly press `u' two times with the same finger.

Well, I have plain "C-u" bound to erase the minibuffer -- surprises me
occasionally, but very convenient!

However, I've always found "C-a C-k" _very_ easy and quick to type --
the initial pinky reach to the control key takes far longer than the
following "a" and "k", and because of the way your fingers are
positioned on the keyboard, the "a" and "k" are almost free:  the "a" is
right under your ring finger while you're holding the control key, and
the "k" is on the home row of the opposite hand (which hasn't moved).

C-a C-k is also pretty much an emacs idiom for killing the current line
in situations where a more specialized binding isn't available (I use a
program that has "emacs like" keybindings, but where C-k does something
nasty, and I have to constantly remind myself not to use C-a C-k...

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: key to yank text at point into minibuffer?

[Johan Bockgård]

"Drew Adams" <drew.adams@oracle.com> writes:

> (BTW, everyone should have a key bound in the minibuffer to a
> command that erases the minibuffer. I use `M-S-backspace'.)

[etc/NEWS]

    ** New command `kill-whole-line' kills an entire line at once. By
    default, it is bound to C-S-<backspace>.

-- 
Johan Bockgård

RE: key to yank text at point into minibuffer?

[Drew Adams]

    > (BTW, everyone should have a key bound in the minibuffer to a
    > command that erases the minibuffer. I use `M-S-backspace'.)
    
        ** New command `kill-whole-line' kills an entire line at once. By
        default, it is bound to C-S-<backspace>.

Sure, that's fine. There are also other commands (some bound by default) that, just like `kill-whole-line' clear out all or most of the minibuffer in most contexts. Whatever works and is handy...

BTW, the minibuffer content is rarely more than one line, but it can be.

Re: key to yank text at point into minibuffer?

[Miles Bader]

On 2/23/06, Johan Bockgård <bojohan+news@dd.chalmers.se> wrote:
> > (BTW, everyone should have a key bound in the minibuffer to a
> > command that erases the minibuffer. I use `M-S-backspace'.)
>
> [etc/NEWS]
>
>     ** New command `kill-whole-line' kills an entire line at once. By
>     default, it is bound to C-S-<backspace>.

BTW, this is a potentially dangerous binding, as I learned to my dismay:

Because there are many common C-M- ... bindings in Emacs and my
fingers are very used to hitting C-M- (whereas C-S- bindings are very
rare), when I decided to try this new binding, I reflexively hit
C-M-bs by mistake ... and C-M-bs is a special key-sequence that _kills
the X server_!  Ouch!!

I suspect more than a few people will do the same thing...

-Miles
--
Do not taunt Happy Fun Ball.

RE: key to yank text at point into minibuffer?

[Drew Adams]

    On 2/23/06, Johan Bockgård <bojohan+news@dd.chalmers.se> wrote:
    > > (BTW, everyone should have a key bound in the minibuffer to a
    > > command that erases the minibuffer. I use `M-S-backspace'.)
    >
    > [etc/NEWS]
    >
    >     ** New command `kill-whole-line' kills an entire line at once. By
    >     default, it is bound to C-S-<backspace>.

    BTW, this is a potentially dangerous binding, as I learned to my dismay:

    Because there are many common C-M- ... bindings in Emacs and my
    fingers are very used to hitting C-M- (whereas C-S- bindings are very
    rare), when I decided to try this new binding, I reflexively hit
    C-M-bs by mistake ... and C-M-bs is a special key-sequence that _kills
    the X server_!  Ouch!!

    I suspect more than a few people will do the same thing...

Sounds like maybe `C-M-bs' is the dangerous binding. Why would such a
command be bound to a key at all? Or are you perhaps referring not to an
Emacs key binding but to something that Emacs never sees, as in Control +
Alt + Delete on Windows?

BTW, how do you type `C-M-bs'? Is `bs' here <backspace>? When I try Control
+ Meta + the Backspace key in emacs -q on Windows, at least, it says
"undefined".

FWIW, in my own customization, I have `C-M-DEL' (Backspace) bound globally
(all modes) to `backward-kill-sexp'.

Re: key to yank text at point into minibuffer?

[Miles Bader]

On 2/27/06, Drew Adams <drew.adams@oracle.com> wrote:
>     Because there are many common C-M- ... bindings in Emacs and my
>     fingers are very used to hitting C-M- (whereas C-S- bindings are very
>     rare), when I decided to try this new binding, I reflexively hit
>     C-M-bs by mistake ... and C-M-bs is a special key-sequence that _kills
>     the X server_!  Ouch!!
>
> Sounds like maybe `C-M-bs' is the dangerous binding. Why would such a
> command be bound to a key at all? Or are you perhaps referring not to an
> Emacs key binding but to something that Emacs never sees, as in Control +
> Alt + Delete on Windows?

Yes, it is "bound" by the X-server.  I agree that it is an unfortunate
binding (though I've found it very useful on a few odd occasions), but
it's been like that since approximately the beginning of time, so
basically isn't going to change anytime soon.

> BTW, how do you type `C-M-bs'? Is `bs' here <backspace>? When I try Control
> + Meta + the Backspace key in emacs -q on Windows, at least, it says
> "undefined".

I hit the "control", the "meta" (actually labelled alt, but mapped to
meta by the X-server), and the "backspace" (by "bs" I meant
"<backspace>") keys simultaneously.  [On my keyboard, the physical key
is actually labelled "Delete", and generates an ascii DEL character,
but apparently in some contexts (with modifier key?) it is interpreted
to mean backspace.]

> FWIW, in my own customization, I have `C-M-DEL' (Backspace) bound globally
> (all modes) to `backward-kill-sexp'.

Heh; since meta is commonly mapped to "Alt", that one sound
potentially awkward as well... C-Alt-Del   :-)

-Miles
--
Do not taunt Happy Fun Ball.

RE: key to yank text at point into minibuffer?

[Drew Adams]

    I hit the "control", the "meta", and the "backspace" keys
    simultaneously.  [On my keyboard, the physical key
    is actually labelled "Delete", and generates an ascii DEL character,
    but apparently in some contexts (with modifier key?) it is interpreted
    to mean backspace.]

     > FWIW, in my own customization, I have `C-M-DEL' (Backspace)
     > bound globally (all modes) to `backward-kill-sexp'.

    Heh; since meta is commonly mapped to "Alt", that one sound
    potentially awkward as well... C-Alt-Del   :-)

So, on X Window (at least your setup of it), Control-Alt-Backspace (or ASCII
DEL) kills the X server. And on MS Windows, Control-Alt-Delete (not ASCII
DEL) reboots or displays the login screen or Task Manager. It seems that
whichever is chosen as an Emacs binding, Backspace or Delete with
Control-Alt will present problems for one or the other platform. Too bad
they couldn't at least agree on which key to use for interference with Emacs
;-).

Re: key to yank text at point into minibuffer?

[Thien-Thi Nguyen]

"Miles Bader" <miles@gnu.org> writes:

> it's been like that since approximately the beginning of time, so
> basically isn't going to change anytime soon.

this is configurable (at X Windows start time), at least for certain
implementations.  i use the following in /etc/X11/XF86Config-4, e.g.:

Section "ServerFlags"
	Option "DontZap" "true"
EndSection

i added this (other non-germaine options elided) specifically
to be able to use C-M-<backspace>.

thi

Re: key to yank text at point into minibuffer?

[Miles Bader]

Thien-Thi Nguyen <ttn@gnu.org> writes:
>> it's been like that since approximately the beginning of time, so
>> basically isn't going to change anytime soon.
>
> this is configurable (at X Windows start time), at least for certain
> implementations.  i use the following in /etc/X11/XF86Config-4, e.g.:

It doesn't really matter though -- the default seemes to be for it to be
bound, so many users will run into this problem.  I'd say Emacs is
better off avoiding any C-Modifier-BS/DEL default bindings.

-Miles
-- 
I'd rather be consing.

Re: key to yank text at point into minibuffer?

[Richard Stallman]

    It doesn't really matter though -- the default seemes to be for it to be
    bound, so many users will run into this problem.  I'd say Emacs is
    better off avoiding any C-Modifier-BS/DEL default bindings.

I tend to agree.  Anyone who wants to use those bindings,
and is prepared to turn off their other meanings in the system,
can surely bind them in Emacs as he wants to.

Would you like to get rid of them, in the code and in the Emacs Manual?

Re: key to yank text at point into minibuffer?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     It doesn't really matter though -- the default seemes to be for it to be
>     bound, so many users will run into this problem.  I'd say Emacs is
>     better off avoiding any C-Modifier-BS/DEL default bindings.
>
> I tend to agree.  Anyone who wants to use those bindings,
> and is prepared to turn off their other meanings in the system,
> can surely bind them in Emacs as he wants to.
>
> Would you like to get rid of them, in the code and in the Emacs Manual?

Sure.

-miles
-- 
Fast, small, soon; pick any 2.

Re: key to yank text at point into minibuffer?

[Luc Teirlinck]

Richard Stallman wrote:

   I tend to agree.  Anyone who wants to use those bindings,
   and is prepared to turn off their other meanings in the system,
   can surely bind them in Emacs as he wants to.

Just to make sure that you understand correctly: the binding in
question, C-S-BS, has no other meaning that would have to be turned
off, in any OS I am aware of.  C-M-BS and C-M-DEL do.

Sincerely,

Luc.

Re: key to yank text at point into minibuffer?

[Miles Bader]

On 3/4/06, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
> Just to make sure that you understand correctly: the binding in
> question, C-S-BS, has no other meaning that would have to be turned
> off, in any OS I am aware of.  C-M-BS and C-M-DEL do.

My point was that it's too easy to mistype it because control-shift
bindings are quite rare, and one's fingers naturally err towards using
the more common alt/meta modifier key instead -- and the consequences
of doing so are disasterous.

-Miles
--
Do not taunt Happy Fun Ball.

Re: key to yank text at point into minibuffer?

[Richard Stallman]

    Just to make sure that you understand correctly: the binding in
    question, C-S-BS, has no other meaning that would have to be turned
    off, in any OS I am aware of.  C-M-BS and C-M-DEL do.

Yes, the latter two are the ones I think we should delete
because they risk enticing people to reboot.

Re: key to yank text at point into minibuffer?

[Luc Teirlinck]

Richard Stallman wrote:

       Just to make sure that you understand correctly: the binding in
       question, C-S-BS, has no other meaning that would have to be turned
       off, in any OS I am aware of.  C-M-BS and C-M-DEL do.

   Yes, the latter two are the ones I think we should delete
   because they risk enticing people to reboot.

We _already_ deleted those.  Miles is suggesting deleting the C-S-BS
binding for kill-whole-line because he believes that many users will
mistakenly hold down the Meta key rather than the Shift key.

>From the NEWS:

+++
** The old bindings C-M-delete and C-M-backspace have been deleted,
since there are situations where one or the other will shut down
the operating system or your X server.

Sincerely,

Luc.

Re: key to yank text at point into minibuffer?

[Richard Stallman]

    We _already_ deleted those.

My memory is getting old.  Please forgive me.

      Miles is suggesting deleting the C-S-BS
    binding for kill-whole-line because he believes that many users will
    mistakenly hold down the Meta key rather than the Shift key.

I don't think we need to go that far to avoid the risk someone will
make an unusual double mistake.

Re: key to yank text at point into minibuffer?

[Miles Bader]

On 3/6/06, Richard Stallman <rms@gnu.org> wrote:
>       Miles is suggesting deleting the C-S-BS
>     binding for kill-whole-line because he believes that many users will
>     mistakenly hold down the Meta key rather than the Shift key.
>
> I don't think we need to go that far to avoid the risk someone will
> make an unusual double mistake.

Well it's only one mistake (Alt vs. Shift), not two, but I'm
suggesting this change because I really did make that mistake, not out
of random worry:  I noticed the News entry, tried to type C-S-BS to
test this new binding, but my fingers ended up hitting Alt instead,
and killing my entire session.  I don't think this happened because of
clumsiness, but rather because Alt is a far, far, more common modifier
in conjunction with Control than Shift is, and muscle memory
apparently treats chorded modifier keys as a unit...

If the consequences of C-Alt-BS weren't so severe, I wouldn't worry
about it -- people mistype all the time -- but they _are_ fairly
severe, so it seems worthy of extra caution.

-Miles
--
Do not taunt Happy Fun Ball.

Re: key to yank text at point into minibuffer?

[Kim F. Storm]

"Miles Bader" <miles@gnu.org> writes:

> If the consequences of C-Alt-BS weren't so severe, I wouldn't worry
> about it -- people mistype all the time -- but they _are_ fairly
> severe, so it seems worthy of extra caution.

I agree.  

I don't dare use that binding myself for the very same reason.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: key to yank text at point into minibuffer?

[Juri Linkov]

> `M-x foobar M-- M-. M-. M-. C-b C-f C-u 1 M-.' will yank three words to
> the left of point and one word to the right of it.

Repeating `M-.' many times to find the necessary thing to yank doesn't
seem very convenient.  What do you think about using `M-.' as a prefix key?
E.g.

`M-. s' - yank symbol at point to the minibuffer
`M-. u' - yank URL at point
`M-. w' - yank word at point
`M-. c' - yank character at point

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: key to yank text at point into minibuffer?

[Drew Adams]

    > `M-x foobar M-- M-. M-. M-. C-b C-f C-u 1 M-.' will yank
    > three words to the left of point and one word to the right of it.

    Repeating `M-.' many times to find the necessary thing to yank doesn't
    seem very convenient.  What do you think about using `M-.' as a
    prefix key?

    `M-. s' - yank symbol at point to the minibuffer
    `M-. u' - yank URL at point
    `M-. w' - yank word at point
    `M-. c' - yank character at point

1. I think you missed the point of that example. It was in the cumulative
mode where `M-.' grabs and yanks successive words, not the mode where `M-.'
cycles among various kinds of thing. Making `M-.' a prefix key would make
matters worse, not better. The above example would then become: `M-x foobar
M-- M-. w  M-. w  M-. w  C-b C-f C-u 1 M-.' - note the added `w's.

Without a prefix binding, you can simply press and hold `M-.' until you've
accumulated as much text (e.g. as many words) as you want. In my
implementation, this single-grabber-function (words), append/accumulate
behavior is the default. (You proposed this cumulative behavior, and I agree
that it is very useful.)


2. Ignoring the cumulative example, and replying to your point (which speaks
to the non-cumulative mode, where `M-.' cycles among various kinds of
thing):

This kind of decision (prefix key or not) really rests on determining the
most common use pattern(s). As I said, in my case I use only a single `M-.'
(yank symbol) 90% of the time, so I have never experienced the inconvenience
you cite. Symbol syntax also picks up file names and URLs. (The separate
URL-grabbing function goes to the trouble of prefixing "http://" if it's
missing.)

In your proposal, I would need to use two keystrokes (`M-. <whatever>')
instead of one (`M-.') 90% of the time, which is less, not more, convenient.

And, just as in the cumulative mode, a prefix key works against ease of
repetition. If the binding is simply `M-.' (my proposal), then, in the case
where `M-.' cycles among alternative grab+yank functions, you can just hold
down Meta and repeatedly hit `.' to cycle among the alternatives. With a
prefix key (your proposal), you must remember, find, and hit a separate key
(s, u, w, or c).

With an alternatives list of length 3, the worst case for my approach is
hitting `.' 3 times. That's still quicker, for me, than coming up with the
correct two-key sequence `M-. <whatever>'. Even if the list were length 20,
I would probably still find repetition of the same key `.' 20 times to be
more convenient than remembering 20 different bindings. But different people
have different ideas of convenience.

To make an analogy, imagine that, instead of having `C-s M-p' cycle among
search-ring elements, you had a separate binding for each element, and `M-p'
was just a prefix key to indicate that you wanted to use the search-ring.
You would use one of `C-s M-p 1', `C-s M-p 2', and so on, instead of simply
repeating `M-p': `C-s M-p M-p M-p'. Would you find that more convenient?
(Granted, the analogy is not entirely fair, because 1, 2, ... are not
mnemonic as are s, u, w, c, or, rather, even if 3 clearly stands for the
third history element, it's unlikely that you would know that you wanted the
third element, without seeing what it is.)

Anyway, as I say, it's the various use cases, and especially the most common
use case, that should guide us here. Try the implementation I pointed to,
and see what you think. You can easily change the bindings to those that you
proposed (prefix key) and compare. Try a few different scenarios and let us
know what you find.

Meta-anyway: It sounds like you and I, Juri, think similarly about this
general idea, but no one else has spoken up about it. Perhaps that's because
people are concentrating on putting out the release (that would be good). Or
perhaps it's because everyone agrees with the idea (also good). Or perhaps
we (like the answer, my friend) are blowin' in the wind.

Re: key to yank text at point into minibuffer?

[Mathias Dahl]

> Meta-anyway: It sounds like you and I, Juri, think similarly about this
> general idea, but no one else has spoken up about it. Perhaps that's because
> people are concentrating on putting out the release (that would be good). Or
> perhaps it's because everyone agrees with the idea (also good). Or perhaps
> we (like the answer, my friend) are blowin' in the wind.

I am following this discussion with some interest because I like ideas
like this in general, but I think that as long as I don't see an every
day use case for this myself I won't involve myself in it.

RE: key to yank text at point into minibuffer?

[Drew Adams]

    > Meta-anyway: It sounds like you and I, Juri, think similarly
    > about this general idea, but no one else has spoken up about it.
    > Perhaps that's because people are concentrating on putting out
    > the release (that would be good). Or perhaps it's because
    > everyone agrees with the idea (also good). Or perhaps
    > we (like the answer, my friend) are blowin' in the wind.

    I am following this discussion with some interest because I like ideas
    like this in general, but I think that as long as I don't see an every
    day use case for this myself I won't involve myself in it.

Fair enough, Mathias. Thanks for weighing in.

IIRC, you've also mentioned in the past that you don't have much need for
the functionality of ffap.el, because you don't often have a buffer with
names of files that you might like to visit. If that's the case, it might
also explain why this proposal wouldn't sound too useful to you.