all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Kill ring leak in winemacs macros
@ 2005-08-03 13:01 Peterson, Eric
  2005-08-03 15:52 ` Kevin Rodgers
  0 siblings, 1 reply; 2+ messages in thread
From: Peterson, Eric @ 2005-08-03 13:01 UTC (permalink / raw)



[-- Attachment #1.1: Type: text/plain, Size: 2949 bytes --]

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.

 

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

and to the gnu.emacs.bug news group.

 

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

 

Please describe exactly what actions triggered the bug

and the precise symptoms of the bug:

 

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.

 

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.

 

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.

 

Anyway, thanks for the EMACS support!!!

 

-Eric

 

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 

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 

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 

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

<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 

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

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 

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

 

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<


[-- Attachment #1.2: Type: text/html, Size: 11656 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Kill ring leak in winemacs macros
  2005-08-03 13:01 Kill ring leak in winemacs macros Peterson, Eric
@ 2005-08-03 15:52 ` Kevin Rodgers
  0 siblings, 0 replies; 2+ messages in thread
From: Kevin Rodgers @ 2005-08-03 15:52 UTC (permalink / raw)


Peterson, Eric wrote:
 > 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.
...
 > 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.

Anything you put in your ~/.emacs file is Lisp, so that's coding -- but
you can use the M-x customize interface to do it for you.

I don't think your problem is with interprogram-cut-function, since that
just causes the killed text in Emacs to be propagated to the window
system's cut buffer.  I think your problem is actually with
interprogram-paste-function, which gets the text to be yanked in Emacs
from the window system's cut buffer instead of from the kill ring.

If you don't ever want Emacs to yank from the window system's cut
buffer: (setq interprogram-paste-function nil)

If you just want to make sure Emacs yanks from its kill ring when
calling a keyboard macro:

(defadvice call-last-kbd-macro (around yank-from-kill-ring activate)
   "Yank text from the kill ring, ignoring the window system's cut buffer."
   (let ((interprogram-paste-function nil))
     ad-do-it))

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-08-03 15:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-03 13:01 Kill ring leak in winemacs macros Peterson, Eric
2005-08-03 15:52 ` Kevin Rodgers

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.