* gnus-delay.el needs to understand "linefeed" for the sake of xterm
@ 2001-07-31 1:50 Karl Kleinpaste
2001-07-31 8:56 ` Kai Großjohann
0 siblings, 1 reply; 3+ messages in thread
From: Karl Kleinpaste @ 2001-07-31 1:50 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
gnus-delay.el binds `C-c C-j' to gnus-delay-article. This works fine
for XEmacs as an X window. But when running XEmacs in an xterm,
XEmacs translates `C-j' to the XEmacs-internal symbol name "linefeed."
For this reason, the define-key needs to be duplicated, once for `C-j'
as it will be seen within X proper, and once for `linefeed' as it will
be seen via an xterm input stream.
Related question: Why `C-c C-j' in the first place? I don't really
care, but I am curious what the mnemonic value of `C-j' was supposed
to be.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: add `linefeed' keybinding --]
[-- Type: text/x-patch, Size: 477 bytes --]
--- lisp/gnus-delay.el.~1~ Thu Jul 26 09:03:56 2001
+++ lisp/gnus-delay.el Mon Jul 30 21:07:08 2001
@@ -132,6 +132,7 @@
Checking delayed messages is skipped if optional arg NO-CHECK is non-nil."
(unless no-keymap
(require 'message)
+ (define-key message-mode-map [(control c) linefeed] 'gnus-delay-article)
(define-key message-mode-map (kbd "C-c C-j") 'gnus-delay-article))
(unless no-check
(add-hook 'gnus-get-new-news-hook 'gnus-delay-send-drafts)))
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: gnus-delay.el needs to understand "linefeed" for the sake of xterm
2001-07-31 1:50 gnus-delay.el needs to understand "linefeed" for the sake of xterm Karl Kleinpaste
@ 2001-07-31 8:56 ` Kai Großjohann
2001-07-31 13:00 ` Karl Kleinpaste
0 siblings, 1 reply; 3+ messages in thread
From: Kai Großjohann @ 2001-07-31 8:56 UTC (permalink / raw)
Cc: ding
On Mon, 30 Jul 2001, Karl Kleinpaste wrote:
> gnus-delay.el binds `C-c C-j' to gnus-delay-article. This works
> fine for XEmacs as an X window. But when running XEmacs in an
> xterm, XEmacs translates `C-j' to the XEmacs-internal symbol name
> "linefeed."
Maybe we should stick to the same keybinding style. Do you think that
"\C-c\n" will work?
> Related question: Why `C-c C-j' in the first place? I don't really
> care, but I am curious what the mnemonic value of `C-j' was supposed
> to be.
`C-c C-j' is easy to type on a qwerty keyboard. It was free. It just
kinda popped to my mind.
Does anyone prefer a different keybinding?
kai
--
~/.signature: No such file or directory
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: gnus-delay.el needs to understand "linefeed" for the sake of xterm
2001-07-31 8:56 ` Kai Großjohann
@ 2001-07-31 13:00 ` Karl Kleinpaste
0 siblings, 0 replies; 3+ messages in thread
From: Karl Kleinpaste @ 2001-07-31 13:00 UTC (permalink / raw)
Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Maybe we should stick to the same keybinding style. Do you think that
> "\C-c\n" will work?
Yes, you're right -- that was just a line of boilerplate code taken
from somewhere else, substituting a function name and so forth.
"\C-c\n" seems to work:
(define-key message-mode-map "\C-c\n" 'gnus-delay-article)
> `C-c C-j' is easy to type on a qwerty keyboard. It was free. It just
> kinda popped to my mind.
> Does anyone prefer a different keybinding?
`C-c C-d' would have been nice for the mnemonic value of "delay," but
it's already taken for "Don't send". Hm. I don't really have any
better suggestions. As I said, I don't really care, I was just
curious.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-07-31 13:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-31 1:50 gnus-delay.el needs to understand "linefeed" for the sake of xterm Karl Kleinpaste
2001-07-31 8:56 ` Kai Großjohann
2001-07-31 13:00 ` Karl Kleinpaste
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 NNTP newsgroup(s).