Copy/paste issue.

["Jérôme M. Berger"]

Hi,

I have an issue with copy/paste. Here are the steps to reproduce:
* Select some text (say "foo") and copy it (M-w);
* Select some other text (say "bar") and paste (C-y):
-> The text "bar" is deleted and the text "foo" is inserted
in its place;
* Select yet some other text (say "zzz") and paste (C-y):
-> Expected behavior: The text "zzz" is deleted and the text
"foo" is inserted in its place;
-> Actual behavior: The text "zzz" is deleted and the text
"bar" is inserted in its place.

This behavior is with my configuration files. If I start emacs with
-Q, pasting over selected text does not erase the selection but
inserts the pasted text at the cursor position. In that case,
pasting multiple times always pastes "foo". I'm not sure what part
of my configuration changes this behavior (grepping for "yank" and
"kill" yields nothing obvious).

I've looked through the docs and code for the "yank" and
"kill-ring-save" functions but could not find anything.

Can somebody give me pointers to what
variables/functions/customizations I should check to get the
behavior I want?

Thanks,
Jerome
--
mailto:jebe...@free.fr
http://jeberger.free.fr
Jabber: jebe...@jabber.fr

["Jérôme M. Berger"]

Sorry, forgot a couple of points:
- OS: ArchLinux 64 bits;
- Emacs version 23.4 (standard Arch package);
- The described behavior happens when selecting with the mouse,
selecting with the keyboard gives the expected behavior.

[Peter Dyballa]

Am 31.3.2012 um 10:51 schrieb Jérôme M. Berger:

> - The described behavior happens when selecting with the mouse,
> selecting with the keyboard gives the expected behavior.

You can try to bisect your init file: comment first have, if effect persists then it comes from other half; if effect is gone then it came from commented half. In case one leave first half commented and now additionally comment first half (a quarter of complete file) of uncommented second half and test again – until you've found the culprit line. If case two was true, then uncomment the commented first half of the init file and comment its second half plus comment the first half (a quarter of the whole file) of the now uncommented first half and test again – until the culprit line is found.

You may find that there is no culprit – except your X server and maybe the window manager. When you select some text with the mouse the X server may serve as the copier and insert a copy of the selection into GNU Emacs' ring of copied or deleted items while the yank command has a previously taken private copy of the ring's last element in its memory. This one is inserted. After that the yank command finds the just inserted copy of the selection as the youngest element in the ring and will insert that one.

--
Greetings

Pete

In a world without walls and fences, who needs gates and windows?

["Jérôme M. Berger"]

Thank you for your reply.

Peter Dyballa wrote:
> Am 31.3.2012 um 10:51 schrieb Jérôme M. Berger:
>
>> - The described behavior happens when selecting with the mouse,
>> selecting with the keyboard gives the expected behavior.
>
> You can try to bisect your init file: comment first have, if
> effect persists then it comes from other half; if effect is gone
> then it came from commented half. In case one leave first half
> commented and now additionally comment first half (a quarter of
> complete file) of uncommented second half and test again – until
> you've found the culprit line. If case two was true, then uncomment
> the commented first half of the init file and comment its second
> half plus comment the first half (a quarter of the whole file) of
> the now uncommented first half and test again – until the culprit
> line is found.
>

I could, but my configuration files total over 5000 lines in 24
files, so I'd rather not if I can avoid it :) Especially since I
prefer the current behavior to the default one anyway, I just think
it could be even better :)

> You may find that there is no culprit – except your X server and
> maybe the window manager. When you select some text with the mouse
> the X server may serve as the copier and insert a copy of the
> selection into GNU Emacs' ring of copied or deleted items while the
> yank command has a previously taken private copy of the ring's last
> element in its memory. This one is inserted. After that the yank
> command finds the just inserted copy of the selection as the
> youngest element in the ring and will insert that one.
>

I thought about that, especially since I have autocutsel configured
to duplicate the application's copied text to the X buffer (i.e if I
hit "M-w" in (X)Emacs or "C-c" in other applications, then I can
paste with the middle mouse button). However, it only copies in one
direction (i.e if I select with the mouse, this copies the text into
the X buffer but not to the application buffer). I have done the
following tests to confirm:
- Stop autocutsel -> emacs' behavior is unchanged;
- Test with emacs -Q -> selecting text with the mouse does not
affect the copied text;
- Test with other applications (namely XEmacs, kate and geany)
-> They all behave the way I want.

However, you gave me an idea and I did an extra test: going back to
my original scenario, if I select "bar" then click somewhere else
(to empty the selection) and then paste, the pasted text is "bar"
and not "foo". So, is there some setting in *Emacs* that could cause
text selected with the mouse to be automagically copied to the kill
ring and yank buffer?

[Eli Zaretskii]

> From: "Jérôme M. Berger" <jebe...@free.fr>
> Date: Sat, 31 Mar 2012 10:51:33 +0200

>
> > I have an issue with copy/paste. Here are the steps to reproduce:
> > * Select some text (say "foo") and copy it (M-w);
> > * Select some other text (say "bar") and paste (C-y):
> > -> The text "bar" is deleted and the text "foo" is inserted
> > in its place;
> > * Select yet some other text (say "zzz") and paste (C-y):
> > -> Expected behavior: The text "zzz" is deleted and the text
> > "foo" is inserted in its place;
> > -> Actual behavior: The text "zzz" is deleted and the text
> > "bar" is inserted in its place.
> >
> > This behavior is with my configuration files. If I start emacs with
> > -Q, pasting over selected text does not erase the selection but
> > inserts the pasted text at the cursor position. In that case,
> > pasting multiple times always pastes "foo". I'm not sure what part
> > of my configuration changes this behavior (grepping for "yank" and
> > "kill" yields nothing obvious).
> >
> > I've looked through the docs and code for the "yank" and
> > "kill-ring-save" functions but could not find anything.
> >
> > Can somebody give me pointers to what
> > variables/functions/customizations I should check to get the
> > behavior I want?
> >
> Sorry, forgot a couple of points:
> - OS: ArchLinux 64 bits;
> - Emacs version 23.4 (standard Arch package);

> - The described behavior happens when selecting with the mouse,
> selecting with the keyboard gives the expected behavior.

I think Emacs 24 will fix that; either wait for it to be released, or
try its latest pretest tarball.

[XeCycle]

"Jérôme M. Berger" <jebe...@free.fr> writes:

> Hi,

>
> I have an issue with copy/paste. Here are the steps to reproduce:
> * Select some text (say "foo") and copy it (M-w);
> * Select some other text (say "bar") and paste (C-y):
> -> The text "bar" is deleted and the text "foo" is inserted
> in its place;
> * Select yet some other text (say "zzz") and paste (C-y):
> -> Expected behavior: The text "zzz" is deleted and the text
> "foo" is inserted in its place;
> -> Actual behavior: The text "zzz" is deleted and the text
> "bar" is inserted in its place.
>
> This behavior is with my configuration files. If I start emacs with
> -Q, pasting over selected text does not erase the selection but
> inserts the pasted text at the cursor position. In that case,
> pasting multiple times always pastes "foo". I'm not sure what part
> of my configuration changes this behavior (grepping for "yank" and
> "kill" yields nothing obvious).
>
> I've looked through the docs and code for the "yank" and
> "kill-ring-save" functions but could not find anything.
>
> Can somebody give me pointers to what
> variables/functions/customizations I should check to get the
> behavior I want?

It should come from delete-selection-mode.

Anyway, bisect your configuration should be accurate.

--
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

[Drew Adams]

> It should come from delete-selection-mode.

A must, IMHO.

> Anyway, bisect your configuration should be accurate.

> - Carl Lei (XeCycle)

>> I could, but my configuration files total over 5000
>> lines in 24 files, so I'd rather not if I can avoid it :)

Carl is right about bisecting. It does not matter how large your init file is
or how many other files it loads. That's the point of binary search.

It's easy for any of us (mea culpa) to forget this and think that it will be
easier to just ponder a little more or act on a hunch or two wrt where the
problem might arise (aka "if I can avoid it").

This feeling gets reinforced by the fact that things seem to progress very
slowly with binary search, at first. Remind yourself of the story of the
inventor of chess and the king:

http://en.wikipedia.org/wiki/Exponential_growth#Rice_on_a_chessboard

http://en.wikipedia.org/wiki/Wheat_and_chessboard_problem

http://en.wikipedia.org/wiki/Second_half_of_the_chessboard

[Silvio Levy]

> This feeling gets reinforced by the fact that things seem to progress very
> slowly with binary search, at first. Remind yourself of the story of the
> inventor of chess and the king:

In my experience binary search, while sometimes unavoidable, is far
from logarithmic, because the contents interact with each other.

At the simplest level, cutting a file in half typically cuts it in the
middle of a function. Even if the functions are short and it's easy to
break between functions, the remaining code may depend on the omitted
code, so the division introduces new errors that have to be debugged.

Silvio Levy


Silvio

[Drew Adams]

> In my experience binary search, while sometimes unavoidable, is far
> from logarithmic, because the contents interact with each other.
>
> At the simplest level, cutting a file in half typically cuts it in the
> middle of a function. Even if the functions are short and it's easy to
> break between functions, the remaining code may depend on the omitted
> code, so the division introduces new errors that have to be debugged.

Well, yes of course, one must not use it blindly or measure "halves" so
literally. The point is that Jerome's 5000 lines of code in 24 libraries is not
an obstacle but should rather be an inducement to using binary search.

And yes of course, nothing prohibits adding a little knowledge and reasoning
into the mix. If you can be fairly certain for some reason that some of the
loaded code cannot be the culprit, then leave it out of the search space. (But
as we all know, sometimes what we think is certain is not.)

FWIW - The code that I load in my own Emacs setup is far beyond Jerome's 5000
lines and 24 Lisp files. And yes, I try to think before (and during)
binary-searching, to narrow the search space. I nevertheless surprise myself
periodically by the weakness of my thinking and the strength of binary search.
YMMV.

[Peter Dyballa]

Am 31.3.2012 um 17:44 schrieb Silvio Levy:

> At the simplest level, cutting a file in half typically cuts it in the
> middle of a function. Even if the functions are short and it's easy to
> break between functions, the remaining code may depend on the omitted
> code, so the division introduces new errors that have to be debugged.

That's indeed a hard problem to solve. I tend to think of that and organise my init file(s) in a way that things depending on some variable are close together. And (do)commented! And I have a block at the beginning which is kind of proven that it does not introduce errors – maybe a bit special. Another obstacle, for me, is the support of different GNU Emacs versions and variants (on Mac OS X one can have a real zoo) handled with if etc. Some are quite large, but since it's merely kind of customisation I can comment out such blocks.

Out-sourcing things into files should make bisecting rather easy. You can switch their use off and on find the "culprit" file.

One learns from bisecting...

--
Greetings

Pete === -Q
==<__/% >>
_____________(_)____@_____________________________

["Jérôme M. Berger"]

XeCycle wrote:
> "Jérôme M. Berger" <jebe...@free.fr> writes:
>> Can somebody give me pointers to what
>> variables/functions/customizations I should check to get the
>> behavior I want?
>

> It should come from delete-selection-mode.
>

> Anyway, bisect your configuration should be accurate.
>

Thank you all for your answers.

delete-selection-mode does explain the difference between "emacs
-Q" and just plain "emacs". Unfortunately that did not solve my
problem, which is that the contents of the kill ring get overwritten
when I select with the mouse.

Eli Zaretskii wrote:
> I think Emacs 24 will fix that

It does, thanks!

[David Combs]

In article <mailman.189.133320168...@gnu.org>,
XeCycle <XeC...@Gmail.com> wrote:
>-=-=-=-=-=-
...

>
>It should come from delete-selection-mode.
>

I was first thinking that maybe he had gotten into overwrite-mode.

Now, I'd never hear do delete-selection-mode, so I did a C-h f on it:

| delete-selection-mode is an interactive autoloaded Lisp function in `delsel'.
| (delete-selection-mode &optional arg)
|
| Toggle Delete Selection mode.
| With prefix arg, turn Delete Selection mode on if and only if arg is
| positive.
|
| When Delete Selection mode is enabled, Transient Mark mode is also
| enabled and typed text replaces the selection if the selection is
| active. Otherwise, typed text is just inserted at point regardless of
| any selection.


Question: what are some of the uses of this mode? Maybe name 2 or 3 uses,
so I can understand if it's something I should get familiar with.

THANKS!

David

[David Combs]

Talking about binary search for finding bugs.

In this thread you're talking about binary search on an input file.

Of course, you can also do that on the running of a program. I
use a language ("MainSail") that makes that particularly simple.

When compiled debuggable, there places in the binary where
it lets you set breakpoints.

It also keeps a global variable "brkcnt", break-count, of
the number of possible places you could set a breakpoint
that you have run past thus far.

So, suppose that the program crashes at some surprise place,
and looking around in the debugger shows nothing obvious --
except, HEY!, how'd that file-pointer get nulled out (or
get changed to point not to a file, etc).

And there's nowhere nearby that that pointer gets played with.

What to do? Well, you know what the current brkcnt is right now,
at the crash-point. And you know that early on that file-pointer
was just fine.

So you start setting one breakpoint at each test run, and do
it by bisection. For each run, when it breaks (at the current
bisection point), you check that pointer for correctness. If
it's ok, you kill the program, reset the break point to halfway
between there and the crash point, and run it again.

If it's not ok, you kill the program, set the break point to
halfway in the other direction.

It's just amazing HOW FAST you can home in on THE instruction
that zeros the file pointer. A million instructions (in YOUR
code, not non-debuggable libraries) range -- you find the
error point in just ten runs.

---

Well, I'm sure I'm not telling you guys anything new; you've probably
been doing this for decades. But anyway, I thought it was pretty
cool, an easy way to home in on what would otherwise be an
almost impossible task to find.


David

[Vladimir Murzin]

David,

It seems you replied to the wrong thread ;)

Best wishes,
Vladimir Murzin

[Drew Adams]

> Now, I'd never hear do delete-selection-mode, so I did a C-h f on it:
>

> Question: what are some of the uses of this mode? Maybe name
> 2 or 3 uses, so I can understand if it's something I should get
> familiar with.

`delete-selection-mode' is quite similar to what you are (probably) used to
outside of Emacs: after you select text, what you type replaces the selection.
And Backspace deletes it. (To cancel selection, hit `C-g'.)

>From (emacs) `Using Region':

,----
| By default, text insertion occurs normally even if the mark is
| active--for example, typing `a' inserts the character `a', then
| deactivates the mark. If you enable Delete Selection mode, a minor
| mode, then inserting text while the mark is active causes the text in
| the region to be deleted first. To toggle Delete Selection mode on or
| off, type `M-x delete-selection-mode'.
`----

[IMHO, `delete-selection-mode' should be the default behavior for Emacs. It
took a couple decades to get even `transient-mark-mode' accepted as the default.
(`transient-mark-mode' is a like a neutered `delete-selection-mode'.) Perhaps
in a couple more decades `delete-selection-mode' will be accepted. ;-)]

[Yaoyuan]

oh.. I like it, the delete-selection-mode. it has the same behaviour with other editors. thanks David

Thanks

YaoYuan

[David Combs]

In article <mailman.730.13363720...@gnu.org>,

Thanks!

I'll have to try it -- see if I like it.

One question to make it totally clear. Without that mode turned on,
how would I accomplish the same thing? That is, end up with the
same result.

Then maybe, why it's better done WITH the mode.

(Hey, you've already done enough. Don't answer this unless you want to.
Thanks!)

David

[David Combs]

In article <mailman.731.13363771...@gnu.org>,
Yaoyuan <yaoyu...@gmail.com> wrote:
>-=-=-=-=-=-

>
>oh.. I like it, the delete-selection-mode. it has the same behaviour with other editors. thanks David
>
>Thanks
>YaoYuan
>

Well, emacs is what I use 99% of the time, other than vi (or :Q --> ex).

So I'm not really too sure just what everyone's talking about, even in
followups to my question.


David (a bit puzzled)

[Barry Margolin]

In article <jq19dp$1pj$4...@reader1.panix.com>,

The basic idea is that if you mark a region before performing an
operation that would normally insert or delete something, you're
indicating that you really wanted to replace the region with it.

It's pretty much the way almost every traditional GUI text editor or
word processor works. If all you've ever used have been Unix
character-oriented text editors, then you won't recognize the behavior.

You asked for the "uses" of this mode, and it's mainly just to act like
other applications that most people have become used to.

Here's an example. If you want to cut or copy region-1, then use it to
replace region-2, you'd normally have to do one of the following:

Mark region-2
C-w
Mark region-1
C-w or M-w
Go back to where region-2 used to be
C-y

or

Mark region-1
C-w or M-w
Mark region-2
C-w
C-y M-y or C-2 C-y

With delete-selection-mode, you can simplify it:

Mark region-1
C-w or M-w
Mark region-2
C-y

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***