bug in save-some-buffers or diff.el?

bug in save-some-buffers or diff.el?

[David Abrahams]

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

Re: bug in save-some-buffers or diff.el?

[Juri Linkov]

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/

Re: bug in save-some-buffers or diff.el?

[David Abrahams]

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

Re: bug in save-some-buffers or diff.el?

[Stefan Monnier]

> 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

Re: bug in save-some-buffers or diff.el?

[David Abrahams]

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

Re: bug in save-some-buffers or diff.el?

[Juri Linkov]

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/

Re: bug in save-some-buffers or diff.el?

[David Abrahams]

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

Re: bug in save-some-buffers or diff.el?

[Kevin Rodgers]

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

Re: bug in save-some-buffers or diff.el?

[Eli Zaretskii]

> 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).

Re: bug in save-some-buffers or diff.el?

[Juri Linkov]

"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/

Re: bug in save-some-buffers or diff.el?

[Eli Zaretskii]

> 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.

Re: bug in save-some-buffers or diff.el?

[Juri Linkov]

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/

Re: bug in save-some-buffers or diff.el?

[Eli Zaretskii]

> 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.

Re: bug in save-some-buffers or diff.el?

[Richard Stallman]

    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.

Re: bug in save-some-buffers or diff.el?

[David Abrahams]

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

Re: bug in save-some-buffers or diff.el?

[Richard Stallman]

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.

emacshear (was: bug in save-some-buffers or diff.el?)

[Juri Linkov]

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/