[EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Richard M. Stallman]

I don't entirely understand this, but I suggest that someone who uses
Windows read it and DTRT.

------- Start of forwarded message -------
Content-class: urn:content-classes:message
Date: Wed, 3 Aug 2005 09:01:18 -0400
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Kill ring leak in winemacs macros
thread-index: AcWYK3ABQ65m+NXSS0mtGESyg+Ym5A==
From: "Peterson, Eric" <EPeterson@mcdonaldbradley.com>
To: <bug-gnu-emacs@gnu.org>
Subject: Kill ring leak in winemacs macros
Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
X-Spam-Level: 
X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE 
	autolearn=no version=2.63

This is a multi-part message in MIME format.

- --===============0788368949==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5982B.708C97B1"

This is a multi-part message in MIME format.

- ------_=_NextPart_001_01C5982B.708C97B1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

To: bug-gnu-emacs@gnu.org

Subject: Kill ring leak in winemacs macros

- --text follows this line--

This bug report will be sent to the Free Software Foundation,

not to your local site managers!

Please write in English, because the Emacs maintainers do not have

translators to read other languages for them.

=20

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing
list,

and to the gnu.emacs.bug news group.

=20

In GNU Emacs 21.3.1 (i386-mingw-nt5.1.2600)

 of 2004-03-10 on NYAUMO

configured using `configure --with-gcc (3.2)'

Important settings:

  value of $LC_ALL: nil

  value of $LC_COLLATE: nil

  value of $LC_CTYPE: nil

  value of $LC_MESSAGES: nil

  value of $LC_MONETARY: nil

  value of $LC_NUMERIC: nil

  value of $LC_TIME: nil

  value of $LANG: ENU

  locale-coding-system: iso-latin-1

  default-enable-multibyte-characters: t

=20

Please describe exactly what actions triggered the bug

and the precise symptoms of the bug:

=20

When I create a keyboard macro in which I kill and yank form the EMACS
kill ring and infinitely apply the macro via the "0" prefix argument, I
have to make sure and not copy or kill into the Windows kill ring while
the macro is running.  Otherwise this inadvertently introduces
unwanted/unexpected data into the EMACS kill ring.  My macros can run
for a long time on large files, so this can stop me from doing other
work while I am waiting.  Or I can forget about the danger and corrupt
the data I am manipulating.

=20

A related issue is that EMACS macro's, I believe, used to run keyboard
macros a *Lot* faster back in my Unix days in EMACS.  I quite suspect
that the overhead of keeping the Windows kill ring consistant with the
emacs kill ring is bogging the process down.

=20

I couldn't find a version of or argument for EMACS "kill-line" or
"kill-ring-save" that would help me.  I'm hoping for a solution that
wouldn't require me to code and manipulation of
"interprogram-cut-function" seemed to require codeing.

=20

Anyway, thanks for the EMACS support!!!

=20

- -Eric

=20

Recent input:

C-n C-n C-n C-n C-n C-x o C-a C-f C-f C-f w : C-a C-k=20

C-k C-y C-y C-p C-f C-f C-f C-f C-f C-f C-f C-b C-b=20

C-b C-b C-x o C-v C-x o / C-f C-f C-f C-f C-f C-f C-k=20

> C-h n <lwindow> <help-echo> <mouse-1> <mouse-1> <mouse-1>=20

<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>=20

<mouse-1> <mouse-1> C-h a b u g <return> C-s C-g C-x=20

o C-s r e p o r t C-s C-s C-s C-n C-s C-s C-g C-x o=20

ESC x r e p o r t SPC e m SPC b SPC <return>

=20

Recent messages:

Auto-saving...done

Loading outline...

Loading easy-mmode...done

Loading outline...done

Loading apropos...done

Type C-x 4 b RET to restore the other window.  C-M-v to scroll the help.

isearch-abort: Quit

Mark saved where search started

isearch-abort: Quit

Loading emacsbug...done<


- ------_=_NextPart_001_01C5982B.708C97B1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
- -->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>To: =
bug-gnu-emacs@gnu.org<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Subject: Kill ring leak in winemacs =
macros<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>--text follows this =
line--<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This bug report will be sent to the Free Software
Foundation,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>not to your local site =
managers!<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Please write in English, because the Emacs =
maintainers do
not have<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>translators to read other languages for =
them.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Your bug report will be posted to the =
bug-gnu-emacs@gnu.org
mailing list,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>and to the gnu.emacs.bug news =
group.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In GNU Emacs 21.3.1 =
(i386-mingw-nt5.1.2600)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;of 2004-03-10 on =
NYAUMO<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>configured using `configure --with-gcc =
(3.2)'<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Important settings:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; value of $LC_ALL: =
nil<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; value of $LC_COLLATE: =
nil<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; value of $LC_CTYPE: =
nil<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; value of $LC_MESSAGES: =
nil<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; value of $LC_MONETARY: =
nil<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; value of $LC_NUMERIC: =
nil<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; value of $LC_TIME: =
nil<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; value of $LANG: =
ENU<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; locale-coding-system: =
iso-latin-1<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; default-enable-multibyte-characters: =
t<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Please describe exactly what actions triggered the =
bug<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>and the precise symptoms of the =
bug:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>When I create a keyboard macro in which I kill and =
yank form
the EMACS kill ring and infinitely apply the macro via the &quot;0&quot; =
prefix
argument, I have to make sure and not copy or kill into the Windows kill =
ring
while the macro is running.&nbsp; Otherwise this inadvertently =
introduces
unwanted/unexpected data into the EMACS kill ring.&nbsp; My macros can =
run for a
long time on large files, so this can stop me from doing other work =
while I am
waiting.&nbsp; Or I can forget about the danger and corrupt the data I =
am
manipulating.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>A related issue is that EMACS macro's, I believe, =
used to
run keyboard macros a *Lot* faster back in my Unix days in EMACS.&nbsp; =
I quite
suspect that the overhead of keeping the Windows kill ring consistant =
with the
emacs kill ring is bogging the process =
down.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I couldn't find a version of or argument for EMACS
&quot;kill-line&quot; or &quot;kill-ring-save&quot; that would help =
me.&nbsp; I'm
hoping for a solution that wouldn't require me to code and manipulation =
of
&quot;interprogram-cut-function&quot; seemed to require =
codeing.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Anyway, thanks for the EMACS =
support!!!<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-Eric<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Recent input:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>C-n C-n C-n C-n C-n C-x o C-a C-f C-f C-f w : C-a C-k =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>C-k C-y C-y C-p C-f C-f C-f C-f C-f C-f C-f C-b C-b =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>C-b C-b C-x o C-v C-x o / C-f C-f C-f C-f C-f C-f C-k =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt; C-h n &lt;lwindow&gt; &lt;help-echo&gt; =
&lt;mouse-1&gt;
&lt;mouse-1&gt; &lt;mouse-1&gt; <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&lt;mouse-1&gt; &lt;mouse-1&gt; &lt;mouse-1&gt;
&lt;mouse-1&gt; &lt;mouse-1&gt; &lt;mouse-1&gt; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&lt;mouse-1&gt; &lt;mouse-1&gt; C-h a b u g =
&lt;return&gt;
C-s C-g C-x <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>o C-s r e p o r t C-s C-s C-s C-n C-s C-s C-g C-x o =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>ESC x r e p o r t SPC e m SPC b SPC =
&lt;return&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Recent messages:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Auto-saving...done<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Loading outline...<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Loading =
easy-mmode...done<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Loading outline...done<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Loading apropos...done<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Type C-x 4 b RET to restore the other window.&nbsp; =
C-M-v to
scroll the help.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>isearch-abort: Quit<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Mark saved where search =
started<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>isearch-abort: Quit<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Loading emacsbug...done</span></font><font size=3D1
face=3DArial><span =
style=3D'font-size:9.0pt;font-family:Arial'>&lt;<o:p></o:p></span></font>=
</p>

</div>

</body>

</html>

- ------_=_NextPart_001_01C5982B.708C97B1--



- --===============0788368949==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs

- --===============0788368949==--
------- End of forwarded message -------

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Stuart D. Herring]

> I don't entirely understand this, but I suggest that someone who uses
> Windows read it and DTRT.

This doesn't seem to be Windows-specific at all; he says that using the
system clipboard while running a (long/repeated) macro that uses Emacs'
kill ring loses because they're constantly being synchronized.  That
should be true on any system with interprogram cut/paste.

He also attributes a perceived slowness on W32 to this synchronization,
but that seems unlikely (I'd think it more likely to be slower redisplay
or so on W32).

So, what he really wants is to not have the system clipboard consulted or
updated during the execution of a keyboard macro, when the kill-ring
should be "internal" data.  If that sounds like a good idea, I can whip up
a patch.

Davis Herring

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Lennart Borgman]

Stuart D. Herring wrote:

>>I don't entirely understand this, but I suggest that someone who uses
>>Windows read it and DTRT.
>>    
>>
>
>This doesn't seem to be Windows-specific at all; he says that using the
>system clipboard while running a (long/repeated) macro that uses Emacs'
>kill ring loses because they're constantly being synchronized.  That
>should be true on any system with interprogram cut/paste.
>
>He also attributes a perceived slowness on W32 to this synchronization,
>but that seems unlikely (I'd think it more likely to be slower redisplay
>or so on W32).
>
>So, what he really wants is to not have the system clipboard consulted or
>updated during the execution of a keyboard macro, when the kill-ring
>should be "internal" data.  If that sounds like a good idea, I can whip up
>a patch.
>
>Davis Herring
>  
>
Is not the variable `x-select-enable-clipboard' for this?

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Stuart D. Herring]

> Is not the variable `x-select-enable-clipboard' for this?

No, that enables the use of the X "clipboard selection" in addition to the
X "primary selection", and is only relevant on X (not Windows, which has a
clipboard but doesn't have "selections").  The variables
`interprogram-cut-function' and `interprogram-paste-function' can be set
to nil to suppress the synchronization, but this isn't just a
customization issue (as in "this isn't a problem, you should set X to Y")
because the issue only arises during keyboard macro execution.  If we want
to support this, presumably we want a new variable thusly:

(defcustom macro-private-kills nil
  "*Non-nil means kill and yank commands executed by a keyboard macro
don't interact with window system cut and paste facilities."
  :type 'boolean
  :group 'killing
  :version "22.1")

Then `kill-new', `kill-append', and `current-kill' would be modified to
ignore `interprogram-*-function' if `macro-private-kills' is set and a
keyboard macro is executing.  Better variable names and/or docstrings are
of course welcome.

Davis Herring

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Lennart Borgman]

Stuart D. Herring wrote:

>>Is not the variable `x-select-enable-clipboard' for this?
>>    
>>
>
>No, that enables the use of the X "clipboard selection" in addition to the
>X "primary selection", and is only relevant on X (not Windows, which has a
>clipboard but doesn't have "selections").  The variables
>`interprogram-cut-function' and `interprogram-paste-function' can be set
>to nil to suppress the synchronization, but this isn't just a
>customization issue (as in "this isn't a problem, you should set X to Y")
>because the issue only arises during keyboard macro execution.  If we want
>to support this, presumably we want a new variable thusly:
>  
>
I believe you can do (setq x-select-enable-clipboard nil) on MS Windows 
too to avoid sync with Windows clipboard. I just did a test, but that 
was with the CVS version (next version) of Emacs. That would mean that 
if you can set this during the execution of the keyboard macro then the 
bevaviour of kill-new etc would be as you want them too. Or am I 
seriously misunderstanding you? My apologizes in that case.

Perhaps would it be convenient to put a defadvice around on 
execute-kbd-macro for this?

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Kevin Rodgers]

Stuart D. Herring wrote:
 > The variables `interprogram-cut-function' and
 > `interprogram-paste-function' can be set to nil to suppress the
 > synchronization, but this isn't just a customization issue (as in
 > "this isn't a problem, you should set X to Y") because the issue only
 > arises during keyboard macro execution.  If we want to support this,
 > presumably we want a new variable thusly:
 >
 > (defcustom macro-private-kills nil
 >   "*Non-nil means kill and yank commands executed by a keyboard macro
 > don't interact with window system cut and paste facilities."
 >   :type 'boolean
 >   :group 'killing
 >   :version "22.1")
 >
 > Then `kill-new', `kill-append', and `current-kill' would be modified to
 > ignore `interprogram-*-function' if `macro-private-kills' is set and a
 > keyboard macro is executing.

It would be simpler to temporarily bind the interprogram-*-functions
variables to nil in execute-kbd-macro.

 > Better variable names and/or docstrings are of course welcome.

How about:

(defcustom kbd-macro-disable-interprogram-functions nil
   "Disable `interprogram-cut-function' and `interprogram-paste-function'
while executing a keyboard macro.  This allows keyboard macros to run
independently of other programs."
   :type 'boolean
   :group 'killing) ; no keyboard macro or window system group

(defadvice execute-kbd-macro (around
                               kbd-macro-disable-interprogram-functions
                               activate)
   "Respect `kbd-macro-disable-interprogram-fuctions'."
   (let ((interprogram-cut-function
          (if kbd-macro-disable-interprogram-functions
              nil
            interprogram-cut-function))
         (interprogram-paste-function
          (if kbd-macro-disable-interprogram-functions
              nil
            interprogram-paste-function)))
     ad-do-it))

Or perhaps -ignore- is preferred over -disable- in variable names.

P.S.  I know that execute-kbd-macro is a built-in function defined in
src/macros.c, and defadvice is not allowed in the lisp/*.el files.  This
is for illustration only.

-- 
Kevin Rodgers

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Eli Zaretskii]

> Date: Wed, 03 Aug 2005 23:41:04 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: emacs-devel@gnu.org
> 
> Stuart D. Herring wrote:
> 
> >>Is not the variable `x-select-enable-clipboard' for this?
> >>    
> >>
> >
> >No, that enables the use of the X "clipboard selection" in addition to the
> >X "primary selection", and is only relevant on X (not Windows, which has a
> >clipboard but doesn't have "selections").  The variables
> >`interprogram-cut-function' and `interprogram-paste-function' can be set
> >to nil to suppress the synchronization, but this isn't just a
> >customization issue (as in "this isn't a problem, you should set X to Y")
> >because the issue only arises during keyboard macro execution.  If we want
> >to support this, presumably we want a new variable thusly:
> >  
> >
> I believe you can do (setq x-select-enable-clipboard nil) on MS Windows 
> too to avoid sync with Windows clipboard.

That's because on Windows, there's _only_ the clipboard.  On other
systems, you need to use the interprogram-* vars.  So Stuart is
correct, I think: one needs to use the interprogram-* vars so that
this works on all supported systems.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Lennart Borgman]

Eli Zaretskii wrote:

>That's because on Windows, there's _only_ the clipboard.  On other
>systems, you need to use the interprogram-* vars.  So Stuart is
>correct, I think: one needs to use the interprogram-* vars so that
>this works on all supported systems.
>  
>
Thanks, the solution with the interprogram-* vars is of course much better.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Richard M. Stallman]

    (defcustom macro-private-kills nil
      "*Non-nil means kill and yank commands executed by a keyboard macro
    don't interact with window system cut and paste facilities."

Please remember the convention that the first line of every doc string
must stand on its own.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Lennart Borgman]

Richard M. Stallman wrote:

>    Perhaps would it be convenient to put a defadvice around on 
>    execute-kbd-macro for this?
>
>No!  Emacs code should not use defadvice.
>
>When you're trying to make improvements in Emacs or fix problems in
>Emacs, please do NOT think of defadvice as the way to do it.
>  
>
Sorry, I was just suggesting an easy way to achieve the result, not 
something to implement in Emacs. But it looks like I misunderstood the 
magnitude of the problem and the intention of the question.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Juanma Barranquero]

On 8/4/05, Richard M. Stallman <rms@gnu.org> wrote:

> No!  Emacs code should not use defadvice.

  follow.el
  ibuf-ext.el
  ses.el
  uniquify.el
  woman.el
  emulation/viper.el
  mh-e/mh-acros.el
  net/tramp.el
  net/tramp-vc.el
  progmodes/ada-mode.el
  progmodes/gdb-ui.el
  progmodes/idlw-shell.el
  textmodes/org.el

at the very least.  Some use defadvice for compatibility with older
Emacsen, but not all.

-- 
                    /L/e/k/t/u

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Stuart D. Herring]

> It would be simpler to temporarily bind the interprogram-*-functions
> variables to nil in execute-kbd-macro.

Do all invocations of keyboard macros go through that function?  If so,
that's of course the right idea, unless there's some reason someone might
want to affect those variables from within a keyboard macro (seems
unlikely).

Davis Herring

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Richard M. Stallman]

    > No!  Emacs code should not use defadvice.

      follow.el
      ibuf-ext.el
      ses.el
      uniquify.el
      woman.el
      emulation/viper.el
      mh-e/mh-acros.el
      net/tramp.el
      net/tramp-vc.el
      progmodes/ada-mode.el
      progmodes/gdb-ui.el
      progmodes/idlw-shell.el
      textmodes/org.el

These are all bugs that ought to be fixed.  In general I did not know
they used defadvice when the code was installed.

Since gdb-ui.el and org.el and tramp are new, they ought to be
fixed first.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Juanma Barranquero]

On 8/5/05, Richard M. Stallman <rms@gnu.org> wrote:

> Since gdb-ui.el and org.el and tramp are new

Also ibuf-ext.el and ses.el. They're not on 21.4.

-- 
                    /L/e/k/t/u

Re: defadvice in Emacs code (was: Kill ring leak in winemacs macros]

[Lennart Borgman]

Richard M. Stallman wrote:

>These are all bugs that ought to be fixed.  In general I did not know
>they used defadvice when the code was installed.
>  
>
I looked at the help text for defadvice and followed the link to Info (a 
very useful link!). In the help text I found nothing about defadvice 
usage in Emacs. The text in Info says "This is a clean method for a 
library to customize functions defined within Emacs--cleaner than 
redefining the whole function". Maybe it should be pointed out somewhere 
that this should not be used within Emacs itself?

Viper also has a lot of defadvice. It might be necessary in the case of 
viper, I do not know.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Richard M. Stallman]

    > Since gdb-ui.el and org.el and tramp are new

    Also ibuf-ext.el and ses.el. They're not on 21.4.

Ok, I wrote to the authors of those packages.  We will try to
eliminate the uses of defadvice.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Stuart D. Herring]

Kevin Rodgers wrote:
>  > Then `kill-new', `kill-append', and `current-kill' would be modified to
>  > ignore `interprogram-*-function' if `macro-private-kills' is set and a
>  > keyboard macro is executing.
>
> It would be simpler to temporarily bind the interprogram-*-functions
> variables to nil in execute-kbd-macro.

I realize I never did implement this -- can I get some opinions on which
of these approaches to follow?  So far my reasoning is that the
execute-kbd-macro path is simpler and cleaner, but the kill-functions path
is more transparent (as well as having the trivial advantage that it would
remain possible to permanently affect the interprogram-*-functions
variables from a keyboard macro).

Davis Herring

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Jason Rumney]

Stuart D. Herring wrote:

>I realize I never did implement this -- can I get some opinions on which
>of these approaches to follow?  So far my reasoning is that the
>execute-kbd-macro path is simpler and cleaner, but the kill-functions path
>is more transparent (as well as having the trivial advantage that it would
>remain possible to permanently affect the interprogram-*-functions
>variables from a keyboard macro).
>  
>
I'm not convinced this change is a good one. What if your macro involves 
a call-process call to an external program that interacts with Emacs via 
the keyboard?

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Jason Rumney]

Jason Rumney wrote:

> Stuart D. Herring wrote:
>
>> I realize I never did implement this -- can I get some opinions on which
>> of these approaches to follow?  So far my reasoning is that the
>> execute-kbd-macro path is simpler and cleaner, but the kill-functions 
>> path
>> is more transparent (as well as having the trivial advantage that it 
>> would
>> remain possible to permanently affect the interprogram-*-functions
>> variables from a keyboard macro).
>>  
>>
> I'm not convinced this change is a good one. What if your macro 
> involves a call-process call to an external program that interacts 
> with Emacs via the keyboard?

clipboard, of course, not keyboard.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Stuart D. Herring]

> I'm not convinced this change is a good one. What if your macro involves
> a call-process call to an external program that interacts with Emacs via
> the [clipboard]?

What kind of keyboard macro could communicate asynchronously with another
program, via the clipboard or otherwise?  Something like that would seem
to require real Lisp anyway.  Moreover, this whole change would be
optional (customizable), so the user of any such macro could turn off that
option (maybe even temporarily and within the macro to make it
self-contained).  So I don't think this change can hurt anything.

...I realize, reading the previous paragraph, that this answers the
question of which implementation to pursue.  The obvious value of a macro
that temporarily enables (or disables) clipboard communication means that
the customize option should be checked within the macro, not in
execute-kbd-macro.

One point, remains, though: Richard said he wanted the kill-ring
re-synchronized with the external world at the end of a keyboard macro
that desynched them; I guess that would have to go in execute-kbd-macro. 
But what should happen if both Emacs and the window system have new text
at that point (where no ordering exists between them)?

Davis Herring

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Jason Rumney]

"Stuart D. Herring" <herring@lanl.gov> writes:

> Moreover, this whole change would be optional (customizable), so the
> user of any such macro could turn off that option

OK. I don't expect my hypothetical case will come up often, but it is
possible. I just wanted to make sure that simply binding some
variables to nil was not the final solution to this.

> One point, remains, though: Richard said he wanted the kill-ring
> re-synchronized with the external world at the end of a keyboard macro
> that desynched them; I guess that would have to go in execute-kbd-macro. 
> But what should happen if both Emacs and the window system have new text
> at that point (where no ordering exists between them)?

Leave the clipboard alone in such a case.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Richard M. Stallman]

    > I'm not convinced this change is a good one. What if your macro 
    > involves a call-process call to an external program that interacts 
    > with Emacs via the keyboard?

    clipboard, of course, not keyboard.

That must be very rare--are there any programs that could be invoked
this way that would use the clipboard?  Normally such programs
would communicate thru files.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Kevin Rodgers]

Jason Rumney wrote:
 > Jason Rumney wrote:
 >> I'm not convinced this change is a good one. What if your macro
 >> involves a call-process call to an external program that interacts
 >> with Emacs via the keyboard?
 >
 > clipboard, of course, not keyboard.

If the proposed new option's default preserves the current behavior, you
don't have to do anything.  But if the default is to disable interaction
via the clipboard, then you'd have to customize the option before
executing the macro.

-- 
Kevin Rodgers

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Kevin Rodgers]

Stuart D. Herring wrote:
 > What kind of keyboard macro could communicate asynchronously with another
 > program, via the clipboard or otherwise?  Something like that would seem
 > to require real Lisp anyway.  Moreover, this whole change would be
 > optional (customizable), so the user of any such macro could turn off 
that
 > option (maybe even temporarily and within the macro to make it
 > self-contained).  So I don't think this change can hurt anything.
 >
 > ...I realize, reading the previous paragraph, that this answers the
 > question of which implementation to pursue.  The obvious value of a macro
 > that temporarily enables (or disables) clipboard communication means that
 > the customize option should be checked within the macro, not in
 > execute-kbd-macro.

I think you mean it should be checked while defining a macro, as well as
when executing one, because the first time a macro is executed is when
it is defined -- right?

In that case, start-kbd-macro should also respect the proposed new
option (by setting the interprogram-*-function variables) and
end-kbd-macro should restore them (which means start-kbd-macro would
need to save their original values).  But that can't be done with simple
let bindings, as it can in execute-kbd-macro.

 > One point, remains, though: Richard said he wanted the kill-ring
 > re-synchronized with the external world at the end of a keyboard macro
 > that desynched them; I guess that would have to go in execute-kbd-macro.
 > But what should happen if both Emacs and the window system have new text
 > at that point (where no ordering exists between them)?

Where did he say that?

-- 
Kevin Rodgers

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Kevin Rodgers]

Jason Rumney wrote:
 > "Stuart D. Herring" <herring@lanl.gov> writes:
 >>Moreover, this whole change would be optional (customizable), so the
 >>user of any such macro could turn off that option
 >
 > OK. I don't expect my hypothetical case will come up often, but it is
 > possible. I just wanted to make sure that simply binding some
 > variables to nil was not the final solution to this.

What is wrong with that solution?

-- 
Kevin Rodgers

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Stuart D. Herring]

> I think you mean it should be checked while defining a macro, as well as
> when executing one, because the first time a macro is executed is when
> it is defined -- right?

The idea is that a macro running without user interaction -- one that may
take minutes to run (repeatedly) -- shouldn't interact with the window
system clipboard because the user may be doing so concurrently.  I think
it's more than a bit strange to use the system clipboard (presumably using
windows other than Emacs) while defining a keyboard macro that itself uses
kill-ring commands, since the interaction with the window system (and/or
other applications) can't be included in the macro.

In other words, it doesn't make much sense to define a macro while you're
copying text between windows.  It does make sense to run a macro while
you're copying text, and the two operations shouldn't interfere. 
Moreover, while defining a macro the user is in control and the clipboard
is thus in control; while running a macro there's no such connection.  So
I think that doing this separation during macro execution is sufficient.

>  > One point, remains, though: Richard said he wanted the kill-ring
>  > re-synchronized with the external world at the end of a keyboard macro
>  > that desynched them; I guess that would have to go in
> execute-kbd-macro.
>  > But what should happen if both Emacs and the window system have new
> text
>  > at that point (where no ordering exists between them)?
>
> Where did he say that?

http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00108.html

Jason Rumney made a reasonable suggestion in
http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00778.html, but
I'd like to hear Richard's answer to the question (if he has a
preference), since he raised the issue.

Davis Herring

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Jason Rumney]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Jason Rumney wrote:
>  > Jason Rumney wrote:
>  >> I'm not convinced this change is a good one. What if your macro
>  >> involves a call-process call to an external program that interacts
>  >> with Emacs via the keyboard?
>  >
>  > clipboard, of course, not keyboard.
>
> If the proposed new option's default preserves the current behavior, you
> don't have to do anything.  But if the default is to disable interaction
> via the clipboard, then you'd have to customize the option before
> executing the macro.

I'm still not convinced this change is worth making now. On X, even
with clipboard enabled, the actual copying to the clipboard is only
performed if another application requests it. Andrew Innes suggested
many years ago that the W32 clipboard should work the same way, but
noone has picked up that job yet. I don't know which way Mac does it,
but that can probably be modified to use delayed copying if it does
not already. So we are talking about reducing the functionality of
keyboard macros to get around a performance problem that does not
exist on the most important platforms, and that we know can be fixed
on others.

Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

[Stuart D. Herring]

> I'm still not convinced this change is worth making now. On X, even
> with clipboard enabled, the actual copying to the clipboard is only
> performed if another application requests it. Andrew Innes suggested
> many years ago that the W32 clipboard should work the same way, but
> noone has picked up that job yet. I don't know which way Mac does it,
> but that can probably be modified to use delayed copying if it does
> not already. So we are talking about reducing the functionality of
> keyboard macros to get around a performance problem that does not
> exist on the most important platforms, and that we know can be fixed
> on others.

The performance problem is entirely secondary (if it even exists); this is
a correctness problem.  Consider a macro like, say, this:

C-e C-w C-f C-y C-s . RET

(which would shuffle chunks of lines around based on periods).  Now set it
running enough times to take, say, 15 minutes of real time (unlikely for a
macro this simple, but just suppose).  While waiting you naturally want to
do something else; you switch into Firefox and do some searches on the
emacs-devel archives.  Finding a neat phrase to search for, you copy it. 
Unbeknownst to you, Emacs had just finished doing `forward-char' and was
about to do `yank', which then gets your search string instead of whatever
was killed last.  Now your text is corrupted, possibly irreversibly (if
the change falls off the end of the undo list and the mark ring before you
can try to recover it).  Moreover, it's quite likely that before you can
paste your text, Emacs loops around and kills some more text; your
copy/paste in Firefox has also been broken.

Sorry if this is belaboring the point too much; I just wanted to explain
what the original issue really was.

That said:
Eric Peterson (the bug reporter) did also say that macros seemed slower on
W32 than on some Unix system, and attributed it to the actual
data-copying.  I don't know if the slowdown is real, or if the clipboard
is to blame.  However, I don't see how copying on W32 (to the clipboard)
can be made any faster, since the W32 clipboard functions much like the
old X cut buffers and is actually real data storage on the part of the
window system.  I don't think there's a way to only interact with it "when
you have to", but I could be wrong.

Davis Herring

PS - Eric Peterson is cc'ed on this email in case he doesn't know the
issue is being resolved.  Eric: there are several ways to fix this
(emacs-devel is currently deciding among them), and it should be a
customizable option in the next version of Emacs.

Until then, here's two workarounds (put them in your .emacs or so, bind
keys to them, whatever).  The first function is self-contained and more
convenient, but if you have some reason to avoid recursive edits, use the
rest of it all together.  Note that the "real" fix may look nothing like
this!

(defun private-kills-recursive-edit ()
  "Disable interprogram cut and paste and do a recursive edit.
When the recursive edit finishes, any new text available from the window
system will be available for yanking."
  (interactive)
  (let (interprogram-cut-function interprogram-paste-function)
    (recursive-edit)))

(defvar suspended-interprogram-functions nil
  "\"Real\" interprogram functions, as a cons: (CUT . PASTE).")

(defun suspend-interprogram-kills ()
  "Disable interprogram cut and paste (temporarily).
It can be re-enabled with `resume-interprogram-kills'."
  (interactive)
  (if suspended-interprogram-functions
      (error "Interprogram kills already suspended")
    (setq suspended-interprogram-functions
          (cons interprogram-cut-function interprogram-paste-function)
          interprogram-cut-function nil
          interprogram-paste-function nil)))

(defun resume-interprogram-kills ()
  "Undo `suspend-interprogram-kills'.
Any new text available from the window system becomes available for
yanking."
  (interactive)
  (if suspended-interprogram-functions
      (setq interprogram-cut-function
            (car suspended-interprogram-functions)
            interprogram-paste-function
            (cdr suspended-interprogram-functions)
            suspended-interprogram-functions nil)
    (error "Interprogram kills not suspended")))

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.