* bug in save-some-buffers or diff.el? @ 2003-10-22 0:07 David Abrahams 2003-10-22 8:38 ` Juri Linkov 0 siblings, 1 reply; 17+ messages in thread From: David Abrahams @ 2003-10-22 0:07 UTC (permalink / raw) Here's my backtrace: Debugger entered--Lisp error: (wrong-type-argument stringp nil) expand-file-name(nil) find-file-noselect(nil) #[(file subexpr) "???Å ? )Ç\b??{!? ÉÊ\v!q×? !? +B\fB?? [subexpr line save-match-data-internal file compilation-error-list beginning-of-line point-marker string-to-int match-data (...) find-file-noselect goto-line] 4](nil 2) diff-parse-differences(732 nil) compile-reinitialize-errors(nil 732) compilation-handle-exit(exit 1 "exited abnormally with code 1\n") compile-internal("diff -wu \"c:/src/emacs/README\" \"c:/DOCUME~1/dave/LOCALS~1/Temp/buffer-content-2644bjc\"" "No more differences" "Diff" diff-parse-differences nil nil nil nil nil nil t) diff("c:/src/emacs/README" "c:/DOCUME~1/dave/LOCALS~1/Temp/buffer-content-2644bjc" nil t) diff-buffer-with-file(#<buffer README>) funcall(diff-buffer-with-file #<buffer README>) (if (funcall (aref def 0) elt) (setq actions (1+ actions)) (setq next (\` ...))) (cond ((eq def ...) (setq next ...)) ((eq def ...) (funcall actor elt) (setq actions ...)) ((eq def ...)) ((eq def ...) (funcall actor elt) (setq actions ... next ...)) ((eq def ...) (setq quit-flag t) (setq next ...)) ((eq def ...) (if ... ...) (while ... ...)) ((eq def ...) (with-output-to-temp-buffer "*Help*" ... ...) (setq next ...)) ((vectorp def) (if ... ... ...)) ((and ... ...) (setq delayed-switch-frame char) (setq next ...)) (t (message "Type %s for help." ...) (beep) (sit-for 1) (setq next ...))) (cond ((stringp prompt) (setq quit-flag nil) (if use-menus ... ... ...) (cond ... ... ... ... ... ... ... ... ... ...)) (prompt (funcall actor elt) (setq actions ...))) (while (funcall next) (setq prompt (funcall prompter elt)) (cond (... ... ... ...) (prompt ... ...))) (progn (if (stringp prompter) (setq prompter ...)) (while (funcall next) (setq prompt ...) (cond ... ...))) (unwind-protect (progn (if ... ...) (while ... ... ...)) (if delayed-switch-frame (setq unread-command-events ...))) (let* ((actions 0) user-keys mouse-event map prompt char elt tail def use-menus delayed-switch-frame (next ...)) (if (and ... use-dialog-box) (let ... ...) (setq user-keys ... map ...)) (unwind-protect (progn ... ...) (if delayed-switch-frame ...)) (let (...) (message "")) actions) map-y-or-n-p(#[(buffer) "Å!? Here's how I get there: 1. Run emacs with -q 1.5 `M-x set-variable RET debug-on-error RET t' 2. open emacs' README file 3. Go to the beginning of line 48 4. Type `X' 5. Type `C-x s' 6. Type `d' -- Dave Abrahams Boost Consulting www.boost-consulting.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-22 0:07 bug in save-some-buffers or diff.el? David Abrahams @ 2003-10-22 8:38 ` Juri Linkov 2003-10-22 9:35 ` David Abrahams 0 siblings, 1 reply; 17+ messages in thread From: Juri Linkov @ 2003-10-22 8:38 UTC (permalink / raw) Cc: David Abrahams David Abrahams <dave@boost-consulting.com> writes: > Here's my backtrace: > Debugger entered--Lisp error: (wrong-type-argument stringp nil) > expand-file-name(nil) > find-file-noselect(nil) > diff-parse-differences(732 nil) This bug is already fixed and yesterday checked in to CVS (files compile.el and diff.el). This bug was caused by setting the variable `compile-auto-highlight' to t. Now it is nil by default. However, even if you set it back to t, it will not cause the same bug, because function `diff-parse-differences' now is changed not to call the `find-file-noselect' at all. -- http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-22 8:38 ` Juri Linkov @ 2003-10-22 9:35 ` David Abrahams 2003-10-22 12:52 ` Stefan Monnier 2003-10-22 14:35 ` Juri Linkov 0 siblings, 2 replies; 17+ messages in thread From: David Abrahams @ 2003-10-22 9:35 UTC (permalink / raw) Cc: emacs-devel Juri Linkov <juri@jurta.org> writes: > David Abrahams <dave@boost-consulting.com> writes: >> Here's my backtrace: >> Debugger entered--Lisp error: (wrong-type-argument stringp nil) >> expand-file-name(nil) >> find-file-noselect(nil) >> diff-parse-differences(732 nil) > > This bug is already fixed and yesterday checked in to CVS (files > compile.el and diff.el). This bug was caused by setting the variable > `compile-auto-highlight' to t. Now it is nil by default. > However, even if you set it back to t, it will not cause the same bug, > because function `diff-parse-differences' now is changed not to > call the `find-file-noselect' at all. Well, the problem was repro'd in a version of emacs built yesterday at approx. 5pm EST, and neither of those two files has changed since I did my checkout. I appear to have both changes, as well. Hmm, maybe I need to do nmake recompile && nmake install in the lisp directory? It surprises me that nmake && nmake install from the nt directory is insufficient after updating my local CVS image. -- Dave Abrahams Boost Consulting www.boost-consulting.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-22 9:35 ` David Abrahams @ 2003-10-22 12:52 ` Stefan Monnier 2003-10-22 15:22 ` David Abrahams 2003-10-22 14:35 ` Juri Linkov 1 sibling, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2003-10-22 12:52 UTC (permalink / raw) Cc: Juri Linkov, emacs-devel > in the lisp directory? It surprises me that > nmake && nmake install > from the nt directory is insufficient after updating my local CVS > image. That's either because you haven't read INSTALL-CVS carefully, or because INSTALL-CVS does not explain it well enough, in which case you should help us improve it. Stefan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-22 12:52 ` Stefan Monnier @ 2003-10-22 15:22 ` David Abrahams 0 siblings, 0 replies; 17+ messages in thread From: David Abrahams @ 2003-10-22 15:22 UTC (permalink / raw) Cc: Juri Linkov, emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> in the lisp directory? It surprises me that > >> nmake && nmake install > >> from the nt directory is insufficient after updating my local CVS >> image. > > That's either because you haven't read INSTALL-CVS carefully, or because > INSTALL-CVS does not explain it well enough, in which case you should > help us improve it. It was the former; I never noticed that file. Rather than improving INSTALL-CVS I'd put a pointer at the beginning of INSTALL telling people where to look for CVS installation instructions. -- Dave Abrahams Boost Consulting www.boost-consulting.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-22 9:35 ` David Abrahams 2003-10-22 12:52 ` Stefan Monnier @ 2003-10-22 14:35 ` Juri Linkov 2003-10-22 16:28 ` David Abrahams ` (2 more replies) 1 sibling, 3 replies; 17+ messages in thread From: Juri Linkov @ 2003-10-22 14:35 UTC (permalink / raw) Cc: David Abrahams David Abrahams <dave@boost-consulting.com> writes: > Juri Linkov <juri@jurta.org> writes: > > David Abrahams <dave@boost-consulting.com> writes: > >> Here's my backtrace: > >> Debugger entered--Lisp error: (wrong-type-argument stringp nil) > >> expand-file-name(nil) > >> find-file-noselect(nil) > >> diff-parse-differences(732 nil) > > > > This bug is already fixed and yesterday checked in to CVS (files > > compile.el and diff.el). This bug was caused by setting the variable > > `compile-auto-highlight' to t. Now it is nil by default. > > However, even if you set it back to t, it will not cause the same bug, > > because function `diff-parse-differences' now is changed not to > > call the `find-file-noselect' at all. > > Well, the problem was repro'd in a version of emacs built yesterday > at approx. 5pm EST, and neither of those two files has changed since > I did my checkout. I appear to have both changes, as well. > > Hmm, maybe I need to do > > nmake recompile && nmake install > > in the lisp directory? It surprises me that > > nmake && nmake install > > from the nt directory is insufficient after updating my local CVS > image. Your backtrace indicates that you use older version of diff.el, because newest version have no `find-file-noselect' function call at all. I can't tell how to recompile .el files under Windows, but it's clear that your .elc files are older than fixed .el files. BTW, I'm sure that current behavior of `load' is wrong. It always tries to load .elc file first, even if it's older than .el. But often it causes too much trouble after updating .el files. There are many reasons why this happens: user forgets to recompile updated .el files, something goes wrong in the make process, etc. Yes, `load' reports a warning, but usually this warning goes unnoticed, which results in broken functionality. Instead, `load' should load the newest of .el or .elc files, and report the same warning as a simple reminder to recompile updated .el files to execute them faster. -- http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-22 14:35 ` Juri Linkov @ 2003-10-22 16:28 ` David Abrahams 2003-10-22 16:34 ` Kevin Rodgers 2003-10-23 18:38 ` Richard Stallman 2 siblings, 0 replies; 17+ messages in thread From: David Abrahams @ 2003-10-22 16:28 UTC (permalink / raw) Cc: emacs-devel Juri Linkov <juri@jurta.org> writes: > BTW, I'm sure that current behavior of `load' is wrong. It always > tries to load .elc file first, even if it's older than .el. But often > it causes too much trouble after updating .el files. There are many > reasons why this happens: user forgets to recompile updated .el files, > something goes wrong in the make process, etc. Yes, `load' reports > a warning, but usually this warning goes unnoticed, which results in > broken functionality. Instead, `load' should load the newest of .el > or .elc files, and report the same warning as a simple reminder to > recompile updated .el files to execute them faster. Yes, indeed. -- Dave Abrahams Boost Consulting www.boost-consulting.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-22 14:35 ` Juri Linkov 2003-10-22 16:28 ` David Abrahams @ 2003-10-22 16:34 ` Kevin Rodgers 2003-10-22 17:52 ` Eli Zaretskii 2003-10-23 18:38 ` Richard Stallman 2 siblings, 1 reply; 17+ messages in thread From: Kevin Rodgers @ 2003-10-22 16:34 UTC (permalink / raw) Juri Linkov wrote: > BTW, I'm sure that current behavior of `load' is wrong. It always > tries to load .elc file first, even if it's older than .el. But often > it causes too much trouble after updating .el files. There are many > reasons why this happens: user forgets to recompile updated .el files, > something goes wrong in the make process, etc. Yes, `load' reports > a warning, but usually this warning goes unnoticed, which results in > broken functionality. Instead, `load' should load the newest of .el > or .elc files, and report the same warning as a simple reminder to > recompile updated .el files to execute them faster. That may be true for developers running CVS Emacs. But for normal users, it is the historic and expected behavior. For instance, it allows me to develop and test my own .el files while still having a working .elc file for both myself and others to use. -- Kevin Rodgers ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-22 16:34 ` Kevin Rodgers @ 2003-10-22 17:52 ` Eli Zaretskii 2003-10-23 4:53 ` Juri Linkov 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2003-10-22 17:52 UTC (permalink / raw) Cc: emacs-devel > From: Kevin Rodgers <ihs_4664@yahoo.com> > Date: Wed, 22 Oct 2003 10:34:15 -0600 > > > Instead, `load' should load the newest of .el > > or .elc files, and report the same warning as a simple reminder to > > recompile updated .el files to execute them faster. > > That may be true for developers running CVS Emacs. But for normal > users, it is the historic and expected behavior. For instance, it > allows me to develop and test my own .el files while still having a > working .elc file for both myself and others to use. Indeed. I fully agree with Kevin: the current behavior of `load' should not be changed. I do work on developing CVS Emacs, but still I find the current behavior much more useful than the suggested one. For example, it allows me to do a "cvs up" on selected files without worrying about possible inconsistencies that might introduce (because some changes in *.el files require related changes in other files in order for them to work correctly). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-22 17:52 ` Eli Zaretskii @ 2003-10-23 4:53 ` Juri Linkov 2003-10-23 6:06 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Juri Linkov @ 2003-10-23 4:53 UTC (permalink / raw) "Eli Zaretskii" <eliz@elta.co.il> writes: > > From: Kevin Rodgers <ihs_4664@yahoo.com> > > Date: Wed, 22 Oct 2003 10:34:15 -0600 > > > > > Instead, `load' should load the newest of .el > > > or .elc files, and report the same warning as a simple reminder to > > > recompile updated .el files to execute them faster. > > > > That may be true for developers running CVS Emacs. But for normal > > users, it is the historic and expected behavior. For instance, it > > allows me to develop and test my own .el files while still having a > > working .elc file for both myself and others to use. > > Indeed. > > I fully agree with Kevin: the current behavior of `load' should not be > changed. > > I do work on developing CVS Emacs, but still I find the current > behavior much more useful than the suggested one. For example, it > allows me to do a "cvs up" on selected files without worrying about > possible inconsistencies that might introduce (because some changes in > *.el files require related changes in other files in order for them to > work correctly). Seems, it's just matter of habit. I find the less error-prone and more reliable the standard "UNIX-like" development style, where files under development are placed into another directory, whose name is listed in the front of `load-path'. But currently `load-path' implies additional hidden layer for searching files that prefers .elc files over .el ones in every directory. Maybe, a new option could be added to choose between these two cases. Anyhow, I'm just trying to find the solution to the real problem about warnings that go unnoticed because they become overwritten by the new messages in the minibuffer. And user remains unaware that he is using old files until he is hit strongly by the resulting problems, because usually .el files newer than .elc files mean that user forgot to recompile them. One solution to this problem is to display such critical warnings in the separate window instead of minibuffer. -- http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-23 4:53 ` Juri Linkov @ 2003-10-23 6:06 ` Eli Zaretskii 2003-10-23 8:00 ` Juri Linkov 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2003-10-23 6:06 UTC (permalink / raw) Cc: emacs-devel > From: Juri Linkov <juri@jurta.org> > Date: 23 Oct 2003 07:53:22 +0300 > > Anyhow, I'm just trying to find the solution to the real problem about > warnings that go unnoticed because they become overwritten by the > new messages in the minibuffer. My personal imperfect solution is to watch closely the echo area, and if I see any message(s) flash by that I didn't expect, I look them up later in the *Messages* buffer. For messages about *.el files being newer than the corresponding .elc, perhaps we could add an option to sit-for 2 seconds after displaying each such message. It should be off by default, of course. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-23 6:06 ` Eli Zaretskii @ 2003-10-23 8:00 ` Juri Linkov 2003-10-24 14:52 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Juri Linkov @ 2003-10-23 8:00 UTC (permalink / raw) Eli Zaretskii <eliz@elta.co.il> writes: > > From: Juri Linkov <juri@jurta.org> > > Date: 23 Oct 2003 07:53:22 +0300 > > > > Anyhow, I'm just trying to find a solution to the real problem about > > warnings that go unnoticed because they become overwritten by the > > new messages in the minibuffer. > > My personal imperfect solution is to watch closely the echo area, and > if I see any message(s) flash by that I didn't expect, I look them up > later in the *Messages* buffer. This worked on slow machines, but now on faster machines quickly flashing messages are hardly readable. > For messages about *.el files being newer than the corresponding .elc, > perhaps we could add an option to sit-for 2 seconds after displaying > each such message. It should be off by default, of course. This can become irritating for loading files with nested dependencies when this delay occurs after loading every of them. But how about using already existing function `display-warning'? For example: (display-warning 'load "Source file file.el is newer than compiled file.elc" :warning) It has options to control the severity level and suppressed warning types. -- http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-23 8:00 ` Juri Linkov @ 2003-10-24 14:52 ` Eli Zaretskii 0 siblings, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2003-10-24 14:52 UTC (permalink / raw) Cc: emacs-devel > From: Juri Linkov <juri@jurta.org> > Date: 23 Oct 2003 11:00:53 +0300 > > > > My personal imperfect solution is to watch closely the echo area, and > > if I see any message(s) flash by that I didn't expect, I look them up > > later in the *Messages* buffer. > > This worked on slow machines, but now on faster machines quickly flashing > messages are hardly readable. My machines aren't slow. All I need to see is that something flashed there. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-22 14:35 ` Juri Linkov 2003-10-22 16:28 ` David Abrahams 2003-10-22 16:34 ` Kevin Rodgers @ 2003-10-23 18:38 ` Richard Stallman 2003-10-23 19:47 ` David Abrahams 2 siblings, 1 reply; 17+ messages in thread From: Richard Stallman @ 2003-10-23 18:38 UTC (permalink / raw) Cc: dave, emacs-devel BTW, I'm sure that current behavior of `load' is wrong. It always tries to load .elc file first, even if it's older than .el. But often it causes too much trouble after updating .el files. There are many reasons why this happens: user forgets to recompile updated .el files, something goes wrong in the make process, etc. Yes, `load' reports a warning, but usually this warning goes unnoticed, which results in broken functionality. Instead, `load' should load the newest of .el or .elc files, and report the same warning as a simple reminder to recompile updated .el files to execute them faster. the current behavior is necessary and will not be changed. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-23 18:38 ` Richard Stallman @ 2003-10-23 19:47 ` David Abrahams 2003-10-24 10:41 ` Richard Stallman 0 siblings, 1 reply; 17+ messages in thread From: David Abrahams @ 2003-10-23 19:47 UTC (permalink / raw) Cc: Juri Linkov, emacs-devel Richard Stallman <rms@gnu.org> writes: > BTW, I'm sure that current behavior of `load' is wrong. It always > tries to load .elc file first, even if it's older than .el. But often > it causes too much trouble after updating .el files. There are many > reasons why this happens: user forgets to recompile updated .el files, > something goes wrong in the make process, etc. Yes, `load' reports > a warning, but usually this warning goes unnoticed, which results in > broken functionality. Instead, `load' should load the newest of .el > or .elc files, and report the same warning as a simple reminder to > recompile updated .el files to execute them faster. > > the current behavior is necessary and will not be changed. Care to explain? Python users seem to like the one Juri proposed, so it works well at least in some contexts. -- Dave Abrahams Boost Consulting www.boost-consulting.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: bug in save-some-buffers or diff.el? 2003-10-23 19:47 ` David Abrahams @ 2003-10-24 10:41 ` Richard Stallman 2003-10-27 17:44 ` emacshear (was: bug in save-some-buffers or diff.el?) Juri Linkov 0 siblings, 1 reply; 17+ messages in thread From: Richard Stallman @ 2003-10-24 10:41 UTC (permalink / raw) Cc: juri, emacs-devel I have no time for explanations; I have more work than I can handle, and I have a broken arm. I've stated my decision so that neither I nor others will spend any more time discussing this issue. ^ permalink raw reply [flat|nested] 17+ messages in thread
* emacshear (was: bug in save-some-buffers or diff.el?) 2003-10-24 10:41 ` Richard Stallman @ 2003-10-27 17:44 ` Juri Linkov 0 siblings, 0 replies; 17+ messages in thread From: Juri Linkov @ 2003-10-27 17:44 UTC (permalink / raw) Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > and I have a broken arm. Did you try to use some speech recognition packages within Emacs? I can't commend the quality of such packages, but theoretically this is what could help you. Can anyone share the experience of using dictation programs in Emacs? For example, it makes sense to have a package similar to emacspeak, which instead of using Festival for speech output, could use some speech recognizer (e.g. Sphinx) for speech input. -- http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2003-10-27 17:44 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-10-22 0:07 bug in save-some-buffers or diff.el? David Abrahams 2003-10-22 8:38 ` Juri Linkov 2003-10-22 9:35 ` David Abrahams 2003-10-22 12:52 ` Stefan Monnier 2003-10-22 15:22 ` David Abrahams 2003-10-22 14:35 ` Juri Linkov 2003-10-22 16:28 ` David Abrahams 2003-10-22 16:34 ` Kevin Rodgers 2003-10-22 17:52 ` Eli Zaretskii 2003-10-23 4:53 ` Juri Linkov 2003-10-23 6:06 ` Eli Zaretskii 2003-10-23 8:00 ` Juri Linkov 2003-10-24 14:52 ` Eli Zaretskii 2003-10-23 18:38 ` Richard Stallman 2003-10-23 19:47 ` David Abrahams 2003-10-24 10:41 ` Richard Stallman 2003-10-27 17:44 ` emacshear (was: bug in save-some-buffers or diff.el?) Juri Linkov
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.