From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xah Newsgroups: gmane.emacs.help Subject: Re: No copy when killing Date: Mon, 16 Jun 2008 23:44:28 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <39fbd280-441d-498e-9a53-ce3188f31398@d77g2000hsb.googlegroups.com> <0cd27ea8-87cb-4891-8cce-8887be2aa949@e39g2000hsf.googlegroups.com> <7815d58b-3f37-4320-af94-178611ff3950@z24g2000prf.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1213688450 17921 80.91.229.12 (17 Jun 2008 07:40:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Jun 2008 07:40:50 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jun 17 09:41:33 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K8Von-0002HN-SZ for geh-help-gnu-emacs@m.gmane.org; Tue, 17 Jun 2008 09:41:30 +0200 Original-Received: from localhost ([127.0.0.1]:37736 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K8Vnz-0001uK-IS for geh-help-gnu-emacs@m.gmane.org; Tue, 17 Jun 2008 03:40:39 -0400 Original-Path: news.stanford.edu!newsfeed.stanford.edu!postnews.google.com!p39g2000prm.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 178 Original-NNTP-Posting-Host: 24.6.97.120 Original-X-Trace: posting.google.com 1213685069 31895 127.0.0.1 (17 Jun 2008 06:44:29 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Tue, 17 Jun 2008 06:44:29 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: p39g2000prm.googlegroups.com; posting-host=24.6.97.120; posting-account=bRPKjQoAAACxZsR8_VPXCX27T2YcsyMA User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.18, gzip(gfe), gzip(gfe) Original-Xref: news.stanford.edu gnu.emacs.help:159562 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:54915 Archived-At: just a brief follow up on this thread in case others read this thread in the future. After 2 days, i've ended my experiment on using deleting word/line shortcuts that doesn't push to the kill ring. My prelimary conclusion is that it's not as convenient as emacs default way, of pushing any deleted word/line into the kill-ring/clipboard. My brief thinking is this... whether deleted text are pushed into the clipboard is a more useful interface, depends on this: =E2=80=A2 Whenever a user does a sequence of deletes of a word or line, is t= he existing content in the clipboard useful? Most of the time, the answer is no. Further, when deleting a line, often it is useful that the deleted text be pushed into the clipboard as to be immediately pasted somewhere. my brief experience of using the non-kill version is that, whenever i delete a line and needed to paste the deleted text somewhere else, thet non-kill version forced me to increases keystroke by 1 or 2. A rough guess on the frequency of deleting a line that needs to be pasted elsewhere, is about maybe 1 out of 20 of every delete word/line operation. Also note, that the situation needing the content of clipboard intact, does not happen very often. (from past decade of emacs using, my guess is that it happens once a week) The reason must be that clipboard are often used in such a way that after something is copied, a paste operation immediately follows, and that the clipboard content is no longer useful. So, in general, it is rare that clipboard content remains in a useful state for durations longer than few seconds. Xah =E2=88=91 http://xahlee.org/ =E2=98=84 On Jun 15, 4:27=C2=A0am, Xah wrote: > i thought about the issue a bit. That is, about whether using kill > commands putting erased text into the kill-ring creates more efficient > work mode. > > For this purpose, i wrote the equivalent non-kill versions and gonna > use it myself to experiment. > > Here's the code, a bit more robust than in my previous post. > > (defun my-delete-word (arg) > =C2=A0 "Delete characters forward until encountering the end of a word. > With argument, do this that many times. > This command does not push erased text to kill-ring." > =C2=A0 (interactive "p") > =C2=A0 (delete-region (point) (progn (forward-word arg) (point)))) > > (defun my-backward-delete-word (arg) > =C2=A0 "Delete characters backward until encountering the beginning of a > word. > With argument, do this that many times. > This command does not push erased text to kill-ring." > =C2=A0 (interactive "p") > =C2=A0 (my-delete-word (- arg))) > > (defun my-delete-line () > =C2=A0 "Delete text from current position to end of line char." > =C2=A0 (interactive) > =C2=A0 (delete-region > =C2=A0 =C2=A0(point) > =C2=A0 =C2=A0(save-excursion (move-end-of-line 1) (point))) > =C2=A0 (delete-char 1) > ) > > (defun my-delete-line-backward () > =C2=A0 "Delete text between the beginning of the line to the cursor > position." > =C2=A0 (interactive) > =C2=A0 (let (x1 x2) > =C2=A0 =C2=A0 (setq x1 (point)) > =C2=A0 =C2=A0 (move-beginning-of-line 1) > =C2=A0 =C2=A0 (setq x2 (point)) > =C2=A0 =C2=A0 (delete-region x1 x2))) > > ; Here's the code to bind them with emacs's default shortcut keys: > > (global-set-key (kbd "C-S-k") 'my-delete-line-backward) > (global-set-key (kbd "C-k") 'my-delete-line) > (global-set-key (kbd "M-d") 'my-delete-word) > (global-set-key (kbd "") 'my-backward-delete-word) > > ---------------------------------- > Some random comments and thoughts follows. > > initial first day experience of using the above is that its annoying, > of course due to habit of 10 years with emacs ways. > > Note that emacs commands that contains the word =E2=80=9Ckill=E2=80=9D is = meant to > push text into the kill-ring. So, instead of naming =E2=80=9Cmy-kill-line= =E2=80=9D, > more proper naming in the context of emacs is =E2=80=9Cdelete-line=E2=80= =9D or =E2=80=9Cmy- > delete-line=E2=80=9D, thus i've named them above. > > Also included above is a my-delete-line-backward, which is like kill- > line but from cursor point to begining of line, as opposed to end of > line. I've been using this command together with my ergonomic keyboard > shortcut set for over a year now and find it convenient. > > It seems logical that emacs does not provide a option for the kill > commands to not push to the kill-ring. To provide that option would be > breaking the original design's consistency, because text-erasing > commands with =E2=80=9Ckill=E2=80=9D in their names are supposed to work w= ith the > =E2=80=9Ckill-ring=E2=80=9D. > > But, suppose non-kill is something we absolutely need in emacs, then > it can be still done without breaking design, by providing the set of > new function without using the word =E2=80=9Ckill=E2=80=9D in them as abov= e. When user > opt to the non-kill version, then the keybinding for these kill > commands will switch to the non-kill set of commands that has =E2=80=9Cdel= ete=E2=80=9D > in their names. > > Since about 2005 i thought about many emacs issues of its non-standard > or non-conventional user interface. That is why the =E2=80=9Ckill=E2=80=9D= issue is > interesting to me. For vast majority of professional programers, > perhaps 99.99%, the emacs ways of intermingling the kill-ring with > modern concept of =E2=80=9Cclipboard=E2=80=9D is unfamilar, thus a setback= . > > I started to use emacs in 1998 and by 1999 i live in emacs daily. I > don't remember now, but undoubtly i was also surprised by emacs's mix > of =E2=80=9Ckill=E2=80=9D and =E2=80=9Cclipboard=E2=80=9D in the beginning= , however, i quickly adopted > it and don't remember ever thought about it. > > In the past few years, sometimes i also run into the problem where i > don't want killed text to offset whatever i have copied to the > =E2=80=9Cclipboard=E2=80=9D. In such a occation, of course, you select the= text then > hit the delete key, so that the =E2=80=9Cclipboard=E2=80=9D is still intac= t. > Alternatively, i learned to use the emacs feature of =E2=80=9Cregister=E2= =80=9D (which > is another form of =E2=80=9Cclipboard=E2=80=9D). > > In the end, the interesting question is whether emacs way of pushing > into kill-ring on deleting word/line/sentence is more operatively > efficient. =C2=A0By =E2=80=9Coperatively efficient=E2=80=9D, i meant of le= ss keystrokes or > more intuitive, for general editing tasks. This can be tested at least > theoretically, by imagining 2 groups of emacs users of equal > experience, one group having used a emacs version such that kill-line, > kill-word, backward-kill-word don't push to the kill-ring. While the > other group uses the standard emacs. Then, suppose we record their > keystrokes and command calls for a few months, then we can mine or > analyse the keystroke log and see whether one way is better. This may > sound too complicated to carry out... but actually i think if any long > time emacs user actually tried the above for at least 2 months, he can > get a sense of which one is more operatively efficient. (this would be > like adopting dvorak keyboard, the first week will be extreme pain in > the ass. But only after full adoption, one can truly judge) > > It's my guess that the operative efficiency of the two methods > actually doesn't differ that much. That is, one method might be more > convenient or save keystrokes sometimes, but not always. If this is > so, then emacs would be much better off, if it adopts the more widely > familiar interface by not having the delete word/line/sentence > shorcuts push into the kill-ring/clipboard. > > =C2=A0Xah > =E2=88=91http://xahlee.org/ > > =E2=98=84