Menu
▾
▴
cc-mode-help
|
From: Eli Z. <el...@is...> - 2001-04-02 14:13:20
|
On Thu, 29 Mar 2001, Richard Stallman wrote:
> but in c-mode the <delete> deletes backwards because in that mode
> <delete> runs the command `c-electric-delete'
>
> I think C mode is doing things wrong. C mode should follow the
> convention used for other modes: bind DEL and maybe C-d, and let
> <delete> alias to one or the other depending on the circumstances.
If delete-key-deletes-forward is not boundp (as will be when we rename
them to normal-erase-is-backspace), C mode already binds DEL
(i.e. "\177") to c-electric-backspace. The problem is with
c-electric-delete: it is only bound (to <delete>) if
delete-key-deletes-forward is boundp.
It should be possible to bind C-d to c-electric-delete, but this seems
to be contrary to what C mode authors intended to do: they
specifically do not rebind C-d, leaving it at its normal binding.
Thus, c-electric-delete is unavailable if delete-key-deletes-forward
is not supported or nil.
I wonder if something like the following will DTRT for Emacs 21:
(if (and (boundp 'normal-erase-is-backspace)
normal-erase-is-backspace)
(define-key c-mode-base-map [delete] 'c-electric-delete))
with a corresponding change in the c-electric-delete function.
What do people think about this?
|
|
From: Richard S. <rm...@gn...> - 2001-04-03 12:58:18
|
If delete-key-deletes-forward is not boundp (as will be when we rename
them to normal-erase-is-backspace), C mode already binds DEL
(i.e. "\177") to c-electric-backspace. The problem is with
c-electric-delete: it is only bound (to <delete>) if
delete-key-deletes-forward is boundp.
C mode should follow the conventions for all modes. It should bind
DEL, and maybe C-d. It should not *ever* bind <delete> or <backspace>
under *any* circumstances.
Would someone please fix this?
I wonder if something like the following will DTRT for Emacs 21:
(if (and (boundp 'normal-erase-is-backspace)
normal-erase-is-backspace)
(define-key c-mode-base-map [delete] 'c-electric-delete))
The whole idea of binding delete is a mistake--see above.
|
|
From: Eli Z. <el...@is...> - 2001-04-03 14:10:08
|
On Tue, 3 Apr 2001, Richard Stallman wrote: > If delete-key-deletes-forward is not boundp (as will be when we rename > them to normal-erase-is-backspace), C mode already binds DEL > (i.e. "\177") to c-electric-backspace. The problem is with > c-electric-delete: it is only bound (to <delete>) if > delete-key-deletes-forward is boundp. > > C mode should follow the conventions for all modes. It should bind > DEL, and maybe C-d. It should not *ever* bind <delete> or <backspace> > under *any* circumstances. Martin, could you please tell why does cc-mode refrain from binding C-d to c-electric-delete? From looking at the code of cc-mode, it seems like a deliberate decision not to touch C-d, but I cannot find any comments that would explain why. If there's no problem to bind C-d to c-electric-delete, it would solve the problem of doing the right thing for Emacs 21's <delete> key support, because Emacs 21 remaps <delete> to either "\177" or C-d, based on whether a separate <bacskpace> key is available. TIA |
|
From: Martin S. <ma...@ly...> - 2001-05-02 10:16:36
|
Eli Zaretskii <el...@is...> wrote:
> On Tue, 3 Apr 2001, Richard Stallman wrote:
>
> > If delete-key-deletes-forward is not boundp (as will be when we rename
> > them to normal-erase-is-backspace), C mode already binds DEL
> > (i.e. "\177") to c-electric-backspace. The problem is with
> > c-electric-delete: it is only bound (to <delete>) if
> > delete-key-deletes-forward is boundp.
> >
> > C mode should follow the conventions for all modes. It should bind
> > DEL, and maybe C-d. It should not *ever* bind <delete> or <backspace>
> > under *any* circumstances.
>
> Martin, could you please tell why does cc-mode refrain from binding C-d
> to c-electric-delete? From looking at the code of cc-mode, it seems like
> a deliberate decision not to touch C-d, but I cannot find any comments
> that would explain why.
Well, the comments in the following code snippet is a bit illuminating
on the situation, I think (this was written a long time ago, long
before I became involved in CC Mode):
;; Caution! Enter here at your own risk. We are trying to support
;; several behaviors and it gets disgusting. :-(
;;
(if (boundp 'delete-key-deletes-forward)
(progn
;; In XEmacs 20 it is possible to sanely define both backward
;; and forward deletion behavior under X separately (TTYs are
;; forever beyond hope, but who cares? XEmacs 20 does the
;; right thing with these too).
(define-key c-mode-base-map [delete] 'c-electric-delete)
(define-key c-mode-base-map [backspace] 'c-electric-backspace))
;; In XEmacs 19, Emacs 19, and Emacs 20, we use this to bind
;; backwards deletion behavior to DEL, which both Delete and
;; Backspace get translated to. There's no way to separate this
;; behavior in a clean way, so deal with it! Besides, it's been
;; this way since the dawn of BOCM.
(define-key c-mode-base-map "\177" 'c-electric-backspace))
I.e. the first clause is intended to do it the XEmacs way and the
second the Emacs and old XEmacs way. If delete-key-deletes-forward
isn't defined (which is true up to Emacs 20), then [delete] and
[backspace] are left alone.
What's needed is that the test is updated to choose the second clause
also in Emacs 21. I see that delete-key-deletes-forward is defined in
the beta I have installed (21.0.100), but if I understand you
correctly that variable is intended to be replaced with
normal-erase-is-backspace. That ought to solve the problem
automatically.
Also, the comment in second clause seems a bit inaccurate; afaik it
works well already back in Emacs 19.34 if you have the right magic
spells in .emacs or wherever. So I think it should be updated with an
entry for C-d, as you suggest. But c-electric-delete currently deletes
backward in Emacs (or, more specifically, whenever
delete-key-deletes-forward is unbound or nil). I intend to introduce a
new function c-electric-delete-forward that always deletes forward and
bind that to C-d.
I think the above should solve the situation, providing that
delete-key-deletes-forward disappears from Emacs again. Am I correct
about that?
|
|
From: Eli Z. <el...@is...> - 2001-05-02 11:47:59
|
> From: Martin Stjernholm <ma...@ly...> > Date: 02 May 2001 12:16:27 +0200 > > ;; Caution! Enter here at your own risk. We are trying to support > ;; several behaviors and it gets disgusting. :-( > ;; > (if (boundp 'delete-key-deletes-forward) > (progn > ;; In XEmacs 20 it is possible to sanely define both backward > ;; and forward deletion behavior under X separately (TTYs are > ;; forever beyond hope, but who cares? XEmacs 20 does the > ;; right thing with these too). > (define-key c-mode-base-map [delete] 'c-electric-delete) > (define-key c-mode-base-map [backspace] 'c-electric-backspace)) > ;; In XEmacs 19, Emacs 19, and Emacs 20, we use this to bind > ;; backwards deletion behavior to DEL, which both Delete and > ;; Backspace get translated to. There's no way to separate this > ;; behavior in a clean way, so deal with it! Besides, it's been > ;; this way since the dawn of BOCM. > (define-key c-mode-base-map "\177" 'c-electric-backspace)) > > I.e. the first clause is intended to do it the XEmacs way and the > second the Emacs and old XEmacs way. If delete-key-deletes-forward > isn't defined (which is true up to Emacs 20), then [delete] and > [backspace] are left alone. > > What's needed is that the test is updated to choose the second clause > also in Emacs 21. Not entirely true; see below. > I see that delete-key-deletes-forward is defined in > the beta I have installed (21.0.100), but if I understand you > correctly that variable is intended to be replaced with > normal-erase-is-backspace. That ought to solve the problem > automatically. delete-key-deletes-forward is already gone from the current Emacs 21 pretests, but the issue is a bit deeper. Unlike XEmacs, Emacs 21 does not bind [backspace] and [delete] neither in the global map nor in any of the mode-specific maps. Instead, it uses function-key-map to remap [delete] into C-d and [backspace] into DEL--if normal-erase-is-backspace mode is on (otherwise, the old Emacs 20 behavior takes place). normal-erase-is-backspace mode is turned on at startup when Emacs can establish that the terminal has both Backspace and Delete keys that are distinguishable by Emacs. The reason that we don't bind [backspace] and [delete] directly is because that breaks many modes which bind important functions to DEL and C-d, and because users of those modes are used to hit Backspace or Delete and have Emacs invoke the command bound to DEL or C-D. For example, this is what happens in Info mode: users type Backspace and expect Emacs to go back one screenful. If we rebind [backspace] to something else, we instantly break all those modes (unless we go over all those modes and change their bindings in non-trivial ways). (This is not a theoretical issue: early pretests indeed did bind [delete] and [backspace] directly, and then we were flooded by bug reports about broken keybindings in many modes. Given that experience, we decided not to bind [delete] and [backspace] directly in any mode-specific map.) One of the reasons we renamed delete-key-deletes-forward to something else is this subtle difference between how Emacs 21 binds these two keys and how XEmacs does that. Therefore, to have Emacs 21 invoke c-electric-delete when the user presses the Delete key, we need Emacs 21 to bind c-electric-delete to C-d not to [delete]. But to me, it looked like cc-mode deliberately avoids binding C-d, thus my question. If it is okay with you to bind C-d in c-mode-map to c-electric-delete (if normal-erase-is-backspace mode is turned on), I will submit changes to do that. This is a solution we prefer for Emacs 21, because it makes the Delete key behave similarly in all modes, no matter whether normal-erase-is-backspace mode is on or off. > c-electric-delete currently deletes backward in Emacs (or, more > specifically, whenever delete-key-deletes-forward is unbound or > nil). That's true, but it can be easily fixed. I didn't do that until now because I thought you had specific reasons not to bind C-d. > I intend to introduce a new function c-electric-delete-forward that > always deletes forward and bind that to C-d. If you are going to do that, Emacs 21 will not need anything special, because it maps [delete] to C-d when normal-erase-is-backspace mode is on. |
|
From: Martin S. <ma...@ly...> - 2001-05-02 21:47:24
|
"Eli Zaretskii" <el...@is...> wrote:
> delete-key-deletes-forward is already gone from the current Emacs 21
> pretests, /.../
Good.
> Unlike XEmacs, Emacs 21 does not bind [backspace] and [delete]
/... explanation snipped .../
Yes, I've gathered that. (It's also a much nicer solution than the
XEmacs way, which forces the applications to look at a variable to
decide what to do.) That's why I think that the code that binds
[backspace] and [delete] should not be executed in Emacs, just as
before. Whether to bind C-d is a separate issue; more about that
below.
> Therefore, to have Emacs 21 invoke c-electric-delete when the user
> presses the Delete key, we need Emacs 21 to bind c-electric-delete to
> C-d not to [delete]. But to me, it looked like cc-mode deliberately
> avoids binding C-d, thus my question.
I don't know for sure either, but I think it looks more like an
oversight; seems like Barry wanted to have the two electric behaviors
on the backspace/delete keys, and since he concluded that they
couldn't be distinguished in Emacs he only bound one of them to DEL.
He simply didn't think of that C-d is used by itself, I guess.
At least I can't see any point in leaving C-d unaffected by this
electric behavior, and since no doc or code mentions that as a feature
I conclude it's just a bug.
> > I intend to introduce a new function c-electric-delete-forward that
> > always deletes forward and bind that to C-d.
I've made the following patches in my sources. You're welcome to check
them out and apply them to the Emacs sources. I've also included
another small fix I've made since 5.29, in that case.
Wed May 02 2001 Martin Stjernholm <bug...@gn...>
* cc-cmds.el, cc-mode.el (c-electric-delete,
c-electric-delete-forward): Split `c-electric-delete' into two
functions where `c-electric-delete-forward' always deletes
forward and `c-electric-delete' only contains the code
necessary for XEmacs to choose between backward and forward
deletion. `c-electric-delete-forward' is now bound to C-d to
get the electric behavior on that key too.
Wed Mar 14 2001 Martin Stjernholm <bug...@gn...>
* cc-cmds.el (c-fill-paragraph): Fixed bogus direct use of
c-comment-prefix-regexp, which caused an error when it's a
list.
Index: cc-cmds.el
===================================================================
RCS file: /cvsroot/cc-mode/cc-mode/cc-cmds.el,v
retrieving revision 5.176
retrieving revision 5.178
diff -c -r5.176 -r5.178
*** cc-cmds.el 2001/02/21 02:06:50 5.176
--- cc-cmds.el 2001/05/02 20:26:49 5.178
***************
*** 105,126 ****
;; Electric keys
- ;; Note: In XEmacs 20.3 the Delete and BackSpace keysyms have been
- ;; separated and "\177" is no longer an alias for both keys. Also,
- ;; the variable delete-key-deletes-forward controls in which direction
- ;; the Delete keysym deletes characters. The functions
- ;; c-electric-delete and c-electric-backspace attempt to deal with
- ;; this new functionality. For Emacs 19 and XEmacs 19 backwards
- ;; compatibility, the old behavior has moved to c-electric-backspace
- ;; and c-backspace-function.
-
(defun c-electric-backspace (arg)
"Deletes preceding character or whitespace.
If `c-hungry-delete-key' is non-nil, as evidenced by the \"/h\" or
\"/ah\" string on the mode line, then all preceding whitespace is
! consumed. If however an ARG is supplied, or `c-hungry-delete-key' is
! nil, or point is inside a literal then the function in the variable
! `c-backspace-function' is called.
See also \\[c-electric-delete]."
(interactive "*P")
--- 105,117 ----
;; Electric keys
(defun c-electric-backspace (arg)
"Deletes preceding character or whitespace.
If `c-hungry-delete-key' is non-nil, as evidenced by the \"/h\" or
\"/ah\" string on the mode line, then all preceding whitespace is
! consumed. If however a prefix argument is supplied, or
! `c-hungry-delete-key' is nil, or point is inside a literal then the
! function in the variable `c-backspace-function' is called.
See also \\[c-electric-delete]."
(interactive "*P")
***************
*** 135,170 ****
(funcall c-backspace-function 1)
))))
(defun c-electric-delete (arg)
"Deletes preceding or following character or whitespace.
! The behavior of this function depends on the variable
! `delete-key-deletes-forward'. If this variable is nil (or does not
! exist, as in older Emacsen), then this function behaves identical to
! \\[c-electric-backspace].
!
! If `delete-key-deletes-forward' is non-nil and is supported in your
! Emacs, then deletion occurs in the forward direction. So if
! `c-hungry-delete-key' is non-nil, as evidenced by the \"/h\" or
! \"/ah\" string on the mode line, then all following whitespace is
! consumed. If however an ARG is supplied, or `c-hungry-delete-key' is
! nil, or point is inside a literal then the function in the variable
! `c-delete-function' is called."
(interactive "*P")
(if (or (and (fboundp 'delete-forward-p) ;XEmacs 21
(delete-forward-p))
(and (boundp 'delete-key-deletes-forward) ;XEmacs 20
delete-key-deletes-forward))
! (if (or (not c-hungry-delete-key)
! arg
! (c-in-literal))
! (funcall c-delete-function (prefix-numeric-value arg))
! (let ((here (point)))
! (skip-chars-forward " \t\n")
! (if (/= (point) here)
! (delete-region (point) here)
! (funcall c-delete-function 1))))
! ;; act just like c-electric-backspace
(c-electric-backspace arg)))
(defun c-electric-pound (arg)
--- 126,171 ----
(funcall c-backspace-function 1)
))))
+ (defun c-electric-delete-forward (arg)
+ "Deletes following character or whitespace.
+ If `c-hungry-delete-key' is non-nil, as evidenced by the \"/h\" or
+ \"/ah\" string on the mode line, then all following whitespace is
+ consumed. If however a prefix argument is supplied, or
+ `c-hungry-delete-key' is nil, or point is inside a literal then the
+ function in the variable `c-delete-function' is called."
+ (interactive "*P")
+ (if (or (not c-hungry-delete-key)
+ arg
+ (c-in-literal))
+ (funcall c-delete-function (prefix-numeric-value arg))
+ (let ((here (point)))
+ (skip-chars-forward " \t\n")
+ (if (/= (point) here)
+ (delete-region (point) here)
+ (funcall c-delete-function 1)))))
+
(defun c-electric-delete (arg)
"Deletes preceding or following character or whitespace.
+ This function either deletes forward as `c-electric-delete-forward' or
+ backward as `c-electric-backspace', depending on the configuration:
! If the function `delete-forward-p' is defined (XEmacs 21) and returns
! non-nil, it deletes forward. Else, if the variable
! `delete-key-deletes-forward' is defined (XEmacs 20) and is set to
! non-nil, it deletes forward. Otherwise it deletes backward.
!
! Note: This is the way in XEmacs 20 and later to choose the correct
! action for the [delete] key, whichever key that means. In other
! flavors this function isn't used, instead it's left to the user to
! bind [delete] to either \\[c-electric-delete-forward] or \\[c-electric-backspace] as appropriate
! \(the keymap `function-key-map' is useful for that). Emacs 21 handles
! that automatically, though."
(interactive "*P")
(if (or (and (fboundp 'delete-forward-p) ;XEmacs 21
(delete-forward-p))
(and (boundp 'delete-key-deletes-forward) ;XEmacs 20
delete-key-deletes-forward))
! (c-electric-delete-forward arg)
(c-electric-backspace arg)))
(defun c-electric-pound (arg)
***************
*** 2283,2289 ****
(save-excursion
(goto-char (car lit-limits))
(if (looking-at (if (eq lit-type 'c++)
! c-comment-prefix-regexp
comment-start-skip))
(goto-char (match-end 0))
(forward-char 2)
--- 2284,2290 ----
(save-excursion
(goto-char (car lit-limits))
(if (looking-at (if (eq lit-type 'c++)
! c-current-comment-prefix
comment-start-skip))
(goto-char (match-end 0))
(forward-char 2)
Index: cc-mode.el
===================================================================
RCS file: /cvsroot/cc-mode/cc-mode/cc-mode.el,v
retrieving revision 5.127
retrieving revision 5.129
diff -c -r5.127 -r5.129
*** cc-mode.el 2001/02/25 07:07:26 5.127
--- cc-mode.el 2001/05/02 21:40:46 5.129
***************
*** 198,220 ****
;; fill-paragraph-or-region.
(substitute-key-definition 'fill-paragraph-or-region 'c-fill-paragraph
c-mode-base-map global-map)
! ;; Caution! Enter here at your own risk. We are trying to support
! ;; several behaviors and it gets disgusting. :-(
! ;;
! (if (boundp 'delete-key-deletes-forward)
! (progn
! ;; In XEmacs 20 it is possible to sanely define both backward
! ;; and forward deletion behavior under X separately (TTYs are
! ;; forever beyond hope, but who cares? XEmacs 20 does the
! ;; right thing with these too).
! (define-key c-mode-base-map [delete] 'c-electric-delete)
! (define-key c-mode-base-map [backspace] 'c-electric-backspace))
! ;; In XEmacs 19, Emacs 19, and Emacs 20, we use this to bind
! ;; backwards deletion behavior to DEL, which both Delete and
! ;; Backspace get translated to. There's no way to separate this
! ;; behavior in a clean way, so deal with it! Besides, it's been
! ;; this way since the dawn of BOCM.
! (define-key c-mode-base-map "\177" 'c-electric-backspace))
;; these are new keybindings, with no counterpart to BOCM
(define-key c-mode-base-map "," 'c-electric-semi&comma)
(define-key c-mode-base-map "*" 'c-electric-star)
--- 198,216 ----
;; fill-paragraph-or-region.
(substitute-key-definition 'fill-paragraph-or-region 'c-fill-paragraph
c-mode-base-map global-map)
! ;; Bind the electric deletion functions to C-d and DEL. Emacs 21
! ;; automatically maps the [delete] and [backspace] keys to these two
! ;; depending on window system and user preferences. (In earlier
! ;; versions it's possible to do the same by using `function-key-map'.)
! (define-key c-mode-base-map "\C-d" 'c-electric-delete-forward)
! (define-key c-mode-base-map "\177" 'c-electric-backspace)
! (when (boundp 'delete-key-deletes-forward)
! ;; In XEmacs 20 and later we fix the forward and backward deletion
! ;; behavior by binding the keysyms for the [delete] and
! ;; [backspace] keys directly, and use `delete-forward-p' or
! ;; `delete-key-deletes-forward' to decide what [delete] should do.
! (define-key c-mode-base-map [delete] 'c-electric-delete)
! (define-key c-mode-base-map [backspace] 'c-electric-backspace))
;; these are new keybindings, with no counterpart to BOCM
(define-key c-mode-base-map "," 'c-electric-semi&comma)
(define-key c-mode-base-map "*" 'c-electric-star)
|
|
From: Richard M. S. - A. M. <rms...@gn...> - 2001-05-02 21:47:17
|
[This message was generated by an automated system.] I am not on vacation, but I am at the end of a long time delay. I am located somewhere on Earth, but as far as responding to email is concerned, I appear to be well outside the solar system. After your message arrives at gnu.org, I will collect it in my next batch of incoming mail, some time within the following 24 hours. I will spend much of the following day reading that batch of mail and will come across your message at some point. If I can write a response for it immediately, the response will go out in the next outgoing batch--typically around 24 hours after I collected your message, but occasionally sooner or later than that. As a result, you should expect a minimum delay of between 24 and 48 hours in seeing any response to your mail to me. If you are having a conversation with me, please keep in mind that each message you receive from me is probably a response to the mail you sent 24 to 48 hours earlier, and any subsequent mail you sent has not yet been seen by me. If you are in a hurry to speak with me, try sending mail to <rms...@gn...> saying what you would like to talk with me about, and giving your telephone number. Another option to reach me urgently is to call the Free Software Foundation office at 617-542-5942 and ask them to contact me on your behalf. If you aren't in an immediate hurry, there is no need to contact rms...@gn... nor the Free Software Foundation office. I will get back to you as soon as I possibly can. If you do not wish to receive this message ever again, please send a message to rms...@gn... with the subject "OFF". Otherwise, you'll receive a reply like this one every month. |
|
From: Eli Z. <el...@is...> - 2001-05-03 07:32:25
|
On 2 May 2001, Martin Stjernholm wrote: > I've made the following patches in my sources. You're welcome to check > them out and apply them to the Emacs sources. I've also included > another small fix I've made since 5.29, in that case. > > > Wed May 02 2001 Martin Stjernholm <bug...@gn...> > > * cc-cmds.el, cc-mode.el (c-electric-delete, > c-electric-delete-forward): Split `c-electric-delete' into two > functions where `c-electric-delete-forward' always deletes > forward and `c-electric-delete' only contains the code > necessary for XEmacs to choose between backward and forward > deletion. `c-electric-delete-forward' is now bound to C-d to > get the electric behavior on that key too. > > Wed Mar 14 2001 Martin Stjernholm <bug...@gn...> > > * cc-cmds.el (c-fill-paragraph): Fixed bogus direct use of > c-comment-prefix-regexp, which caused an error when it's a > list. Thanks, this is almost exactly what I had in mind. Richard, is it okay to install these now? |
|
From: Richard S. <rm...@gn...> - 2001-05-04 08:19:21
|
I think these should be installed. |
|
From: Eli Z. <el...@is...> - 2001-05-04 10:07:54
|
> Date: Fri, 4 May 2001 02:19:15 -0600 (MDT) > From: Richard Stallman <rm...@gn...> > > I think these should be installed. I installed them. |
|
From: Eli Z. <el...@is...> - 2001-04-04 14:12:50
|
On Tue, 3 Apr 2001, Richard Stallman wrote: > If delete-key-deletes-forward is not boundp (as will be when we rename > them to normal-erase-is-backspace), C mode already binds DEL > (i.e. "\177") to c-electric-backspace. The problem is with > c-electric-delete: it is only bound (to <delete>) if > delete-key-deletes-forward is boundp. > > C mode should follow the conventions for all modes. It should bind > DEL, and maybe C-d. It should not *ever* bind <delete> or <backspace> > under *any* circumstances. > > Would someone please fix this? Someone just did ;-) |
Thanks for helping keep SourceForge clean.
X