No copy when killing

[rock69]

Is there some way to disable copying to the clipboard when deleting
something (ex. with M-d or C-k)? I'm asking this because I often find
myself copying something and then deleting successive lines, and when
I have to paste what I had previously copied, it's really annoying to
have to scroll through with C-y M-y.

[Xah]

i doubt there's a buildin customization to let you set that pref.

You might need to write your own function to do delete text without
putting things in ring. (the elisp would be trivial... pls ask if you
want the code)

-------------------------

however, what you want is prob best done by using emacs's so-called
“register”, which basically allow you to have multiple clipborads.

select a region, then do M-x copy-to-register (C-x r x). Then type 1
(as the name of your register)
To paste that, type M-x insert-register (C-x r g), then type 1.

You can of course bind these to shortcuts with a simple elisp, so
that, for example, M-1 copy region to clipboard 1, M-S-1 paste it from
clipboard 1. Similar for 2, 3, etc.

-------------------------

... i've been thinking whether emacs behavior of M-d, C-k etc
automatically put things into kill-ring is a efficient mode of
operation, as opposed to not have these operations auto put into kill-
ring and only copy/cut (M-w,C-w) does. But just never spent the time
to seriously think about this.

I'm used to the emacs way anyhow for 10 years and didn't find any prob
with it. However, this doesn't imply this emacs way is more
efficient... just habit. (of course, emacs old timers are likely to
say it's that way because decades of hacker usage find it to be
efficient and blab blab... which often has no scientific basis
whatsoever and in fact some of emacs ways, such as its default
keybindings and its undo behavior, are very operatively inefficient.)

Xah
∑ http://xahlee.org/

☄

[rock69]

Thank you Xah for the detailed explanation. I would indeed like to see
the code if it's not too much trouble. Although, as a matter of fact,
I most likely am going to follow your suggestion, and use another
register when I'm in one of the situations I mentioned.

Thanks again so much :)

[Xah]

Here's a kill-word command that does not push text into kill-ring.

(defun my-kill-word (arg)
"Kill characters forward until encountering the end of a word.
With argument, do this that many times.
Do not push killed text to kill-ring"
(interactive "p")
(delete-region (point) (progn (forward-word arg) (point))))

it's basically copy-paste of the same code of kill-word, execpt that
kill-region is replaced by delete-region.

here's a simple kill-line that doesn't push to kill-ring.

(defun delete-point-to-line-end ()
"Delete text from current position to end of line char."
(interactive)
(delete-region
(point)
(save-excursion (move-end-of-line 1) (point))
))

> Thanks again so much :)

you are very welcome. :) I got lots help here too.

Xah
∑ http://xahlee.org/

☄

On Jun 14, 3:18 am, rock69 <rocco.ro...@gmail.com> wrote:

> Thank youXahfor the detailed explanation. I would indeed like to see

[Xah]

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)
"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."

(interactive "p")
(delete-region (point) (progn (forward-word arg) (point))))

(defun my-backward-delete-word (arg)
"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."
(interactive "p")
(my-delete-word (- arg)))

(defun my-delete-line ()

"Delete text from current position to end of line char."
(interactive)
(delete-region
(point)
(save-excursion (move-end-of-line 1) (point)))

(delete-char 1)
)

(defun my-delete-line-backward ()
"Delete text between the beginning of the line to the cursor
position."
(interactive)
(let (x1 x2)
(setq x1 (point))
(move-beginning-of-line 1)
(setq x2 (point))
(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 "<M-backspace>") '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 “kill” is meant to
push text into the kill-ring. So, instead of naming “my-kill-line”,
more proper naming in the context of emacs is “delete-line” or “my-
delete-line”, 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 “kill” in their names are supposed to work with the
“kill-ring”.

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 “kill” in them as above. 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 “delete”
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 “kill” 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 “clipboard” 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 “kill” and “clipboard” 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
“clipboard”. In such a occation, of course, you select the text then
hit the delete key, so that the “clipboard” is still intact.
Alternatively, i learned to use the emacs feature of “register” (which
is another form of “clipboard”).

In the end, the interesting question is whether emacs way of pushing
into kill-ring on deleting word/line/sentence is more operatively
efficient. By “operatively efficient”, i meant of less 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.

Xah
∑ http://xahlee.org/

☄

[Steinar Bang]

>>>>> rock69 <rocco...@gmail.com>:

The delete-region function might do the trick for you?

Either
M-x delete-region RET
or bind it to a key (ah,... it's actually on a menu! see below).

The result of `C-h f delete-region RET' :
delete-region is an interactive built-in function in `C source code'.
It is bound to <menu-bar> <edit> <clear>.
(delete-region start end)

Delete the text between point and mark.

When called from a program, expects two arguments,
positions (integers or markers) specifying the stretch to be deleted.

[back]

[Xah]

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:

• Whenever a user does a sequence of deletes of a word or line, is the
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
∑ http://xahlee.org/

☄