Re: how to implement function copy-subword-to-irc-buffer

[Kevin Rodgers <kevin.d.rodgers@gmail.com>]

B. T. Raven wrote:
> Kevin Rodgers wrote:
>> B. T. Raven wrote:
>>> I think I need (thing-at-point 'word), (buffer-list), set point and
>>> mark, copy-region-as-kill-no-mark, and other usual suspects to implement
>>> this but really want to automatically copy the substring of the word
>>> before point or the whole word if point is in whitespace after the word.
>>> This (sub)string should go to the point in the irc buffer (one whose
>>> buffer-name starts with #) and then make that irc buffer current.
>> 
>> Looking at rcirc.el, it does not look like that is a reliable method to
>> select
>> "the" IRC buffer.  It actually supports multiple IRC buffers, maintained in
>> rcirc-buffer-alist (which is local to the server buffer, of which there may
>> also be more than 1).
>>
>> Glossing over that for the moment, how about:
> 
> I was glossing over that too. Just to get started I was planning on
> using the function with only one open server and channel. In fact, I
> probably will never need it to go to more than one irc buffer. It's just
> to move foreign language dictionary entries quickly into a particular
> channel during a live session.

The code below simply selects the first buffer returned by buffer-list whose
name starts with "#" and has an rcirc server buffer associated with it.

>> (let* ((subword (if (looking-at "\\>")
>>             (thing-at-point 'word)
> 
> ;; already the \> regex was new to me. If I C-s to the word "the" RET,
> ;; then point is already past the word

Yes, just as you requested: point is after the word.

>>           (buffer-substring (or (car (bounds-of-thing-at-point 'word))
>>                     (point))
>>                     (point))))
> 
> I can't get my mind around this either; why the (or ... ? Don't I always
> want car of the cons returned by bounds-of-thing-at-point ?

Yes, but there are corner cases where it may be nil, which causes
buffer-substring to signal an error.

>>        (buffer-list (buffer-list))
>>        (irc-buffer (catch 'irc-buffer
>>              (while buffer-list
>>                (when (and (string-match "^#"
>>                         (buffer-name (car buffer-list)))
>>                   (buffer-local-value 'rcirc-server-buffer
>>                               (car buffer-list)))
>>              (throw 'irc-buffer (car buffer-list)))
>>                (setq buffer-list (cdr buffer-list))))))
>>   (when irc-buffer
>>     (funcall rcirc-switch-to-buffer-function irc-buffer)
>>     (insert subword)))
> 
> I couldn't wrap this in a defun and get it to work because I am in ver.
> 22.3 Can I copy rcirc.el from /emacs23/lisp/net over to ver 22.3?  If
> not, is it safe to just overwrite all the ver 22.3 files, directories,
> etc. with the equivalent ver. 23 ones. I tried to use my old .emacs with
> 23.1 but it wouldn't work because of (ucs-tables) in my .emacs.
> 
> Anyway, thanks a lot for the code. I may have to postpone any more study
> of it until I dare to move everything to ver. 23.

No it is not safe.  If you want to experiment with such an approach, put
the newer files in the site-lisp directory.

But as far as I know, there are no dependencies in that code on version
23 -- in fact, there couldn't be, as I am running 22.3 as well and
tested it successfully.

You should be able to wrap that in a defun and put it in your emacs as is.
What happened when you tried?

>>> Is this doable? I want to assign this function to some keychord but am
>>> not sure what would be suitable (in keeping with traditional key
>>> assignment philosophy). I have standard binding for almost every thing
>>> but single character cursor movement. Is there a way of getting a list
>>> of all key combos (and/or ranges of key combos) that are not currently
>>> bound?
>> From the Keymaps node of the Emacs manual:
>>
>> ,----
>> |    As a user, you can redefine any key; but it is usually best to stick
>> | to key sequences that consist of `C-c' followed by a letter (upper or
>> | lower case).  These keys are "reserved for users," so they won't
>> | conflict with any properly designed Emacs extension.  The function keys
>> | <F5> through <F9> are also reserved for users.  If you redefine some
>> | other key, your definition may be overridden by certain extensions or
>> | major modes which redefine the same key.
>> |
>> `----
>>
> 
> It may be overridden but from what I know now it probably won't be. For
> instance  if I type (at random) C-h k and then C-M S-h I find that the
> shifted combo has been translated to C-M h but C-h S-k (C-h K)isn't
> translated to C-h k. If I avoid C-M combos and known prefixes (C-x, C-h,
> and ESC) then most combos will be undefined (M-s, C-s, shifted versions
> of these, and Alt combos if there are keyboards with both Alt and Meta).
> Emacs didn't use to discriminate between shifted and unshifted combos
> but now it seems to in many contexts.
> 
> I thought there might be a way to get the complement to the set of
> defined key bindings. Maybe there is no easy way to do that.

If you want to use a binding that is "in keeping with traditional key
assignment philosophy", then use C-c LETTER.

-- 
Kevin Rodgers
Denver, Colorado, USA