Re: Missing day when Calendar prompts for year and month
Thanks for the report and diagnosis - fixed as you suggested. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
On Wed, May 10 2006, Luc Teirlinck wrote: I personally still believe that the best thing to do would just be to simply remove this annoying safe-local-variable clutter from the `C-h v' output entirely. I think Richard decided to include it. Maybe it would be better to shift it down so that it comes _after_ the documentation: --8---cut here---start-8--- *** help-fns.el 11 May 2006 13:10:03 +0200 1.89 --- help-fns.el 11 May 2006 13:12:12 +0200 *** *** 642,656 (princ (if (stringp (car obsolete)) (car obsolete) (format use `%s' instead. (car obsolete (terpri)) (when safe-var ! (princ This variable is safe as a file local variable ) (princ if its value\nsatisfies the predicate ) (princ (if (byte-code-function-p safe-var) ! which is byte-compiled expression.\n !(format `%s'.\n safe-var))) ! (terpri)) ! (princ Documentation:\n) ! (princ (or doc Not documented as a variable.))) ;; Make a link to customize if this variable can be customized. (if (custom-variable-p variable) (let ((customize-label customize)) --- 642,656 (princ (if (stringp (car obsolete)) (car obsolete) (format use `%s' instead. (car obsolete (terpri)) + (princ Documentation:\n) + (princ (or doc Not documented as a variable.)) (when safe-var ! (princ \n\n\nThis variable is safe as a file local variable ) (princ if its value\nsatisfies the predicate ) (princ (if (byte-code-function-p safe-var) ! which is byte-compiled expression. !(format `%s'. safe-var))) ! (terpri))) ;; Make a link to customize if this variable can be customized. (if (custom-variable-p variable) (let ((customize-label customize)) --8---cut here---end---8--- Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fontification problem with fancy diary display
I have another datapoint. When I execute the steps of my original recipe, using the entries given there, with today's date (5 11 2006), the fancy diary display fontifies correctly. However, when I replace the entries in my original recipe with slightly different ones, I see the same fontification problem again (the date string for Wednesday and its separator are fontified with the default face (black)). Here are the entries that show this with (5 11 2006): Monday 14.30 Xx XXXxXx xxx Xxxx Monday 15.30-17.00 Xxxx XXX Monday 16.45 Xxxx xxx XXX xxx Monday 17.15-18.15 Xxxx XXx Tuesday 14.50 Xxxx xxx X xxx Tuesday 15.30-16.00 Xxxx X Wednesday 17.15-18.15 Xxxx XXx Wednesday 20.00-21.15 Xx Xx Thursday 16.00 Xxxx Xx X xXx Friday 15.20-15.50 Xxxx X Friday 17.30-19.00 Xxxx Xx Friday 18.00-19.30 Xxxx XXX Hope this helps in finding a solution to this problem. Steve Berman ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
Reiner Steib [EMAIL PROTECTED] writes: allout-layout (lambda (x) (or (numberp x) (listp x) (integerp x) (member x '(: * + - Simpler (intergerp implies numberp, use memq instead of member): (lambda (x) (or (numberp x) (listp x) (memq x '(: * + - And if `nil' is not a valid value (use consp instead of listp): (lambda (x) (or (numberp x) (consp x) (memq x '(: * + - -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ediff failure if diff doesn't exist
Jesper Harder wrote: On ms-windows when you (require 'ediff) on a computer where the diff executable doesn't exist you get the backtrace below. Of course, ediff probably isn't that useful if you don't have diff, but still it would be nice to fail in a more gracefull way. To reproduce, set ediff-diff-program to something that doesn't exist and require ediff. Debugger entered--Lisp error: (file-error Searching for program no such file or directory diff) call-process(diff nil nil nil --binary NUL NUL) apply(call-process (diff nil nil nil --binary NUL NUL)) ediff-diff-mandatory-option(diff) ediff-reset-diff-options(ediff-diff-options ) custom-initialize-reset(ediff-diff-options ) custom-declare-variable(ediff-diff-options (r:/Dev/Common/Util/Emacs/lisp/ediff-diff.elc . -3371) :set ediff-reset-diff-options :type string :group ediff-diff) require(ediff-diff) I came across a similar problem in one of my own packages that uses call-process to determine what options an external program supports. It's easy to fix by checking first that executable-find returns non-nil, or by wrapping call-process in condition-case. But that wasn't necessary before, so I suspect that call-process has changed to now signal an error. If that's intentional, its doc string should be updated, because currently it says only this: | If BUFFER is 0, `call-process' returns immediately with value nil. | Otherwise it waits for PROGRAM to terminate | and returns a numeric exit status or a signal description string. | If you quit, the process is killed with SIGINT, or SIGKILL if you quit again. -- Kevin ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
i deliberately chose to use the form that defines the variables in the file's bytecode, as well as in loaddefs, because i want to be able to use the most recent version of allout in versions of emacs that are not built with allout (eg, the old emacs version i'm running on my zaurus). i would like to be able to use the same source code in such cases. (i imagine other people might be in the same situation.) AFAICS, Emacs 21 doesn't care about the safe-local-variable properties in the first place, so you there no need for backward compatibility here. (I don't think we should try to be backward compatible with older CVS versions.) I think in the future it will make sense also to separately install the most recent version of allout.el even in conjunction with Emacs-22. So I agree with Ken's motivation and think that keeping the `put' outside of the comment is the right thing to do. For Emacs 22, Richard recommended not to execute it again when the file is loaded, i.e. use... ;;;###autoload(put '... 'safe-local-variable ...) Yes, but if the package is also distributed separately, the other form makes more sense. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
Would you please fix the code in allout.el? I'd rather let Ken take care of it. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Richard Stallman [EMAIL PROTECTED] writes: Every morning for the past weeks, I've had a message in my minibuffer that roughly goes, Desktop undo buffer is 3+ MB, discard? (yes or no). I've been saying yes. This morning, feeling snarky, I said no and Emacs crashed. Could you please provide the precise text of the message? The message includes a buffer name; what is the buffer name? OK, it's back. Here's the message: Buffer `*desktop*' undo info is 3159101 bytes long; discard it? (yes or no) -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
But there are also expressions in `allout.el' where no predefined predicate exists (AFAICS): allout-use-mode-specific-leader allout-reindent-bodies allout-layout is it necessary to have a predefined predicate in all cases, or will quoting the lambda be sufficient? Quoting the lambda is sufficient. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
i deliberately chose to use the form that defines the variables in the file's bytecode, as well as in loaddefs, because i want to be able to use the most recent version of allout in versions of emacs that are not built with allout (eg, the old emacs version i'm running on my zaurus). There is a miscommunication; that's not the issue we were talking about. We're talking about the fact that the lambda expressions get compiled. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
calendar autoloads
The calendar-*-date-string functions aren't interactive but are autoloaded with a non-nil INTERACTIVE arg in calendar.el. This patch removes the erroneous arg. --- calendar.el 11 May 2006 18:39:17 +0200 1.185 +++ calendar.el 11 May 2006 18:51:13 +0200 @@ -1686,12 +1686,10 @@ t) (autoload 'calendar-french-date-string cal-french - String of French Revolutionary date of Gregorian date. - t) + String of French Revolutionary date of Gregorian date.) (autoload 'calendar-mayan-date-string cal-mayan - String of Mayan date of Gregorian date. - t) + String of Mayan date of Gregorian date.) (autoload 'calendar-print-mayan-date cal-mayan Show the Mayan long count, Tzolkin, and Haab equivalents of the date under the cursor. @@ -1734,8 +1732,7 @@ t) (autoload 'calendar-chinese-date-string cal-china - String of Chinese date of Gregorian date. - t) + String of Chinese date of Gregorian date.) (autoload 'calendar-absolute-from-astro cal-julian Absolute date of astronomical (Julian) day number D. @@ -1745,8 +1742,7 @@ Astronomical (Julian) day number of absolute date D.) (autoload 'calendar-astro-date-string cal-julian - String of astronomical (Julian) day number of Gregorian date. - t) + String of astronomical (Julian) day number of Gregorian date.) (autoload 'calendar-goto-astro-day-number cal-julian Move cursor to astronomical (Julian) day number. @@ -1787,8 +1783,7 @@ t) (autoload 'calendar-iso-date-string cal-iso - String of ISO date of Gregorian date. - t) + String of ISO date of Gregorian date.) (autoload 'calendar-goto-islamic-date cal-islam Move cursor to Islamic date. @@ -1799,16 +1794,14 @@ t) (autoload 'calendar-islamic-date-string cal-islam - String of Islamic date of Gregorian date. - t) + String of Islamic date of Gregorian date.) (autoload 'calendar-print-bahai-date cal-bahai Show the Baha'i date equivalents of date. t) (autoload 'calendar-bahai-date-string cal-bahai - String of Baha'i date of Gregorian date. - t) + String of Baha'i date of Gregorian date.) (autoload 'calendar-goto-hebrew-date cal-hebrew Move cursor to Hebrew date. @@ -1819,8 +1812,7 @@ t) (autoload 'calendar-hebrew-date-string cal-hebrew - String of Hebrew date of Gregorian date. - t) + String of Hebrew date of Gregorian date.) (autoload 'calendar-goto-coptic-date cal-coptic Move cursor to Coptic date. @@ -1831,8 +1823,7 @@ t) (autoload 'calendar-coptic-date-string cal-coptic - String of Coptic date of Gregorian date. - t) + String of Coptic date of Gregorian date.) (autoload 'calendar-goto-ethiopic-date cal-coptic Move cursor to Ethiopic date. @@ -1843,8 +1834,7 @@ t) (autoload 'calendar-ethiopic-date-string cal-coptic - String of Ethiopic date of Gregorian date. - t) + String of Ethiopic date of Gregorian date.) (autoload 'calendar-goto-persian-date cal-persia Move cursor to Persian date. @@ -1855,8 +1845,7 @@ t) (autoload 'calendar-persian-date-string cal-persia - String of Persian date of Gregorian date. - t) + String of Persian date of Gregorian date.) (autoload 'show-all-diary-entries diary-lib Show all of the diary entries in the diary file. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: setting tool-bar-border produces strange behavior, including freeze emacs
Miguel V. S. Frasson [EMAIL PROTECTED] writes: Hi I was experiencing with the tool-bar-border variable (which could be customizable) and setting to 0, nil, 1, 15, 20 gives me an meaningless behaviour for this variable. Essentially (at most few --not more than 4-- pixels of difference) the toolbar looks the same. I supposed that the tool-bar had to srink or become large changing the values. It may do that in the future, but for emacs 22.x, the border cannot be larger than the additional space added to the tool-bar to make it an integral multiple of the frame's default line height (due to limitations of the redisplay engine). I.e. the area occupied by the tool-bar + border is always the same. But setting it to 100 just freezes my emacs. Just try the following That was a bug. I have installed a fix. Thank you for the bug report. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Bill Wohler wrote: OK, it's back. Here's the message: Buffer `*desktop*' undo info is 3159101 bytes long; discard it? (yes or no) The patch below should solve your problem, or part of your problem. There is no reason for the `*desktop*' buffer to accumulate a huge undo entry just to allow you to erase the buffer completely using `M-x undo'. So the patch below disables undo while desktop.el writes all these entries in the *desktop* buffer. After that, undo is re-enabled however. So if you then inadvertently mess up the buffer, repeated undo will restore the buffer to what desktop.el wrote in it. But one more undo will not erase the buffer. Instead, it will tell you that there is no further undo info. I said that it might solve part of your problem. The question is whether the 3M of undo is legitimate. Take a look at what is in that buffer. Does the huge size of the buffer seem legitimate, because there really is that much info to save? I guess that you know that you can produce the buffer using `M-x desktop-save'. I believe that my patch should be applied regardless of whether the 3M is legitimate, but if it is not, additional changes may be necessary. ===File ~/desktop.el-diff=== *** desktop.el 10 Feb 2006 08:34:46 -0600 1.99 --- desktop.el 11 May 2006 20:42:50 -0500 *** *** 766,804 (eager desktop-restore-eager) (buf (get-buffer-create *desktop*))) (set-buffer buf) ! (erase-buffer) ! (insert ! ;; -*- mode: emacs-lisp; coding: emacs-mule; -*-\n ! desktop-header ! ;; Created (current-time-string) \n ! ;; Desktop file format version desktop-file-version \n ! ;; Emacs version emacs-version \n\n ! ;; Global section:\n) ! (mapc (function desktop-outvar) desktop-globals-to-save) ! (if (memq 'kill-ring desktop-globals-to-save) ! (insert ! (setq kill-ring-yank-pointer (nthcdr ! (int-to-string (- (length kill-ring) (length kill-ring-yank-pointer))) !kill-ring))\n)) ! (insert \n;; Buffer section -- buffers listed in same order as in buffer list:\n) ! (mapc #'(lambda (l) ! (when (apply 'desktop-save-buffer-p l) ! (insert ( ! (if (or (not (integerp eager)) ! (unless (zerop eager) ! (setq eager (1- eager)) ! t)) ! desktop-create-buffer ! desktop-append-buffer-args) ! ! desktop-file-version) ! (mapc #'(lambda (e) ! (insert \n (desktop-value-to-string e))) ! l) ! (insert )\n\n))) ! info) (setq default-directory dirname) (let ((coding-system-for-write 'emacs-mule)) (write-region (point-min) (point-max) filename nil 'nomessage --- 766,807 (eager desktop-restore-eager) (buf (get-buffer-create *desktop*))) (set-buffer buf) ! (when (consp buffer-undo-list) ! (setq buffer-undo-list nil)) ! (let ((buffer-undo-list t)) ! (erase-buffer) ! (insert !;; -*- mode: emacs-lisp; coding: emacs-mule; -*-\n !desktop-header !;; Created (current-time-string) \n !;; Desktop file format version desktop-file-version \n !;; Emacs version emacs-version \n\n !;; Global section:\n) ! (mapc (function desktop-outvar) desktop-globals-to-save) ! (if (memq 'kill-ring desktop-globals-to-save) ! (insert !(setq kill-ring-yank-pointer (nthcdr !(int-to-string (- (length kill-ring) (length kill-ring-yank-pointer))) ! kill-ring))\n)) ! (insert \n;; Buffer section -- buffers listed in same order as in buffer list:\n) ! (mapc #'(lambda (l) ! (when (apply 'desktop-save-buffer-p l) ! (insert ( ! (if (or (not (integerp eager)) ! (unless (zerop eager) ! (setq eager (1- eager)) ! t)) ! desktop-create-buffer ! desktop-append-buffer-args) ! ! desktop-file-version) ! (mapc #'(lambda (e) ! (insert \n (desktop-value-to-string e))) ! l) ! (insert )\n\n))) ! info)) (setq default-directory dirname) (let ((coding-system-for-write 'emacs-mule)) (write-region (point-min) (point-max) filename nil 'nomessage
Re: Big desktop undo buffer crashes Emacs
From my previous reply: I said that it might solve part of your problem. The question is whether the 3M of undo is legitimate. Take a look at what is in that buffer. Does the huge size of the buffer seem legitimate, because there really is that much info to save? I guess that you know that you can produce the buffer using `M-x desktop-save'. Well, the size of the undo info is not necessarily related to the size of the buffer. In my setup, after `M-x desktop-save', I get a *desktop* buffer of size 2943, but my buffer-undo-list (_without_ my patch applied) is very small: (nil (1 . 2944) (t 0 . 0)) I guess that if you created the *desktop* buffer and did `C-h v buffer-undo-list' in it, you would get a really huge *Help* buffer, assuming it would not make your Emacs crash. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
I believe that we can forget about that potential second undo problem. It is apparently when you do `M-x desktop-save' while you already have a *desktop* buffer that you can accumulate a large undo entry proportional to the size of the buffer. This seems to happen as a result of the call to `erase-buffer'. But after my patch, recording of undo info during the call to `erase-buffer' is disabled anyway. So the problem should be completely solved. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
I mangled Bill's email address in my previous reply, re-included below. So if you follow up, please follow up on this version rather than the original to prevent CC-ing a mangled address: I believe that we can forget about that potential second undo problem. It is apparently when you do `M-x desktop-save' while you already have a *desktop* buffer that you can accumulate a large undo entry proportional to the size of the buffer. This seems to happen as a result of the call to `erase-buffer'. But after my patch, recording of undo info during the call to `erase-buffer' is disabled anyway. So the problem should be completely solved. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
! (when (consp buffer-undo-list) ! (setq buffer-undo-list nil)) ! (let ((buffer-undo-list t)) ! (erase-buffer) Why not just (buffer-disable-undo) ?? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Luc Teirlinck [EMAIL PROTECTED] wrote: From my previous reply: I said that it might solve part of your problem. The question is whether the 3M of undo is legitimate. Take a look at what is in that buffer. Does the huge size of the buffer seem legitimate, because there really is that much info to save? I guess that you know that you can produce the buffer using `M-x desktop-save'. Well, the size of the undo info is not necessarily related to the size of the buffer. In my setup, after `M-x desktop-save', I get a *desktop* buffer of size 2943, but my buffer-undo-list (_without_ my patch applied) is very small: (nil (1 . 2944) (t 0 . 0)) I guess that if you created the *desktop* buffer and did `C-h v buffer-undo-list' in it, you would get a really huge *Help* buffer, assuming it would not make your Emacs crash. Right now my desktop buffer is 32 kB; the size of the *Help* buffer you describe is 68 kB. Running desktop-save did not change the size of either (much, the *Help* buffer grew by 200 bytes after running `C-h v buffer-undo-list' again). By the way, the only two desktop-related items in my .emacs are turning on desktop-save-mode (which is probably obvious ;-) and this: (run-at-time 60 300 'desktop-save ~) ;it would be better to catch HUP and ;call desktop-save before exiting I've yet to write the code to catch a kill or quit and run desktop-save on an as-needed basis rather than regularly--maybe someone can volunteer a trick there--but still, why would the buffer go from 68 kB to 3 MB overnight? I think this is the only cron job *I've* set up. Still, I think Stefan might be correct. What does it mean to have undo in the *desktop* buffer in the first place? -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Stefan Monnier wrote: ! (when (consp buffer-undo-list) ! (setq buffer-undo-list nil)) ! (let ((buffer-undo-list t)) ! (erase-buffer) Why not just (buffer-disable-undo) ?? Because I want to allow people who visit the buffer to undo any changes they deliberately or inadvertently make to it. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
Maybe it would be better to shift it down so that it comes _after_ the documentation: No, because the documentation is much longer than the safe-values info. if you put a small thing after a big thing, people tend not no notice the small thing. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
Would you please fix the code in allout.el? I'd rather let Ken take care of it. I think he does not have write access. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
OK, it's back. Here's the message: Buffer `*desktop*' undo info is 3159101 bytes long; discard it? (yes or no) Does this change give good results? (Lars, do you object?) *** desktop.el 11 Feb 2006 11:43:50 -0500 1.99 --- desktop.el 11 May 2006 22:14:05 -0400 *** *** 766,771 --- 766,772 (eager desktop-restore-eager) (buf (get-buffer-create *desktop*))) (set-buffer buf) + (buffer-disable-undo) (erase-buffer) (insert ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Luc Teirlinck [EMAIL PROTECTED] wrote: Bill Wohler wrote: By the way, the only two desktop-related items in my .emacs are turning on desktop-save-mode (which is probably obvious ;-) and this: (run-at-time 60 300 'desktop-save ~) ;it would be better to catch HUP and ;call desktop-save before exiting The latter was your problem. From `(elisp)Timers': It is usually a bad idea for timer functions to alter buffer contents. When they do, they usually should call `undo-boundary' both before and after changing the buffer, to separate the timer's changes from user commands' changes and prevent a single undo entry from growing to be quite large. So it is no surprise that you accumulated such a large single undo entry. Thanks for the information. Since I don't understand the mechanics of desktop, I have a couple of questions about that. First, I thought desktop-save just saves the buffer to a file. Is it really altering the the *desktop* buffer? Oh, running desktop-save a couple of times shows that it at least updates the Created header field. OK, desktop-save must gather buffer information, write it to *desktop*, and *then* save it to a file. Right? Second, I also don't understand the mechanics of undo very well. I was under the impression that undo-boundary only grouped a set of changes into a single undo entry. As I sit here writing, only a limited amount of changes are saved and at some point the oldest undo information will be discarded. How is the timer different? Interesting, as I typed this, the timer had run a couple of times (I was thinking and trying to understand desktop and undo). I re-ran `C-h v buffer-undo-list' a few times too. It just produced buffers with only 35 kB, not 68 kB. Right now my desktop buffer is 32 kB; So that is approximately 32 kB every five minutes. After eight hours, you exceed 3M. Anyway, my patch, or disabling undo, completely gets rid of this problem. So, which one should I apply? Before I fix my timer ;-). If the *desktop* buffer is ephemeral and recreated when desktop-save is run, it seems that disabling undo is the proper course of action. Otherwise, preserving undo while protecting against abuse would be wise. What do you think? -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Luc Teirlinck [EMAIL PROTECTED] wrote: I now realize that *desktop* is not a file visiting buffer, so it does not matter if people mess it up. Thus one can indeed just disable undo rather than applying the patch I proposed. But that user visible *desktop* buffer is confusing, especially if the user also has a buffer visiting his desktop-base-file-name, since the two buffers are identical. Is there any reason not to rename *desktop* to *desktop (with a leading space) and kill it after it is written to disk? Is there any reason to keep this buffer hanging around consuming some memory and being user visible? Thanks, Luc. This exact thought coursed through my mind. Would Mr. Desktop please chime in? -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
c-subword-mode movement commands are not supported by CUA
The c-subword-mode movement commands (c-forward-subword and c-backward-subword) are not supported correctly in cua-mode. Please add the following code to Emacs: (put 'c-forward-subword 'CUA 'move) (put 'c-backward-subword 'CUA 'move) -- MJF In GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.8.17) of 2006-05-05 on pacem, modified by Debian X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/22.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.50/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.50/leim' '--with-x=yes' '--with-x-toolkit=gtk' 'CFLAGS=-DDEBIAN -g -O2 -Wno-pointer-sign' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu'' 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: nil locale-coding-system: nil default-enable-multibyte-characters: t Major mode: Fundamental/lw Minor modes in effect: global-balanced-mode: t balanced-mode: t hrule-mode: t cua-mode: t c-subword-mode: t global-reveal-mode: t reveal-mode: t global-hi-lock-mode: t hi-lock-mode: t show-paren-mode: t global-c-subword-mode: t tooltip-mode: t auto-compression-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: u t SPC C-h f return C-x o q C-x 4 b return ' C backspace backspace ' s backspace c - b a c k w a r d - s u b w o r d SPC left right ' C U A SPC ' m o v e ) return C-S-left C-S-left C-S-left C-S-left C-S-left C-S-left C-S-left down down down C-x b m e s s return C-x b c o m p C-g menu C-g C-x o C-x o menu r e p o r t SPC e m a c s SPC b tab return Recent messages: Send e-mail to Emacs maintainers Loading emacsbug...done Quit Loading ielm...done Loading eldoc...done Type C-x 4 C-o RET to restore the other window. Can't find completion for c-backsub [2 times] Making completion list...done Quit Type C-x 4 C-o RET to restore the other window. Quit [2 times] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
