hack-local-variables-confirm loops forever when running keyboard macro

hack-local-variables-confirm loops forever when running keyboard macro

[Richard Stallman]

Would someone please fix this, then ack?

------- Start of forwarded message -------
Date: Fri, 19 Jan 2007 23:04:49 +0100
From: Chris Moore <dooglus@gmail.com>
To: emacs-pretest-bug@gnu.org, Chris Moore <dooglus@gmail.com>
Cc: 
Subject: hack-local-variables-confirm loops forever when running keyboard
	macro
X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=failed 
	version=3.0.4

 1. ensure temp file doesn't exist

  $ rm /tmp/file.txt

 2. create a temp file with 'risky' local variable:

  $ printf "# Local Variables:\n# eval: (put 'w 't 'f)\n# End:\n" > /tmp/file.txt

 3. run Emacs:

  $ emacs -Q

 4. visit the temp file.  it will prompt for whether to run the risky
    code:

  C-x C-f /tmp/file.txt RET

 5. answer that you don't want to run it:

  n

 6. start recording a macro:

  C-x (

 7. visit the risky temp file.  it won't prompt this time, since the
    file is already visited

  C-x C-f /tmp/file.txt RET

 8. stop recording the macro

  C-x )

 9. kill the temp file's buffer

  C-x k RET

10. run the macro.  Emacs will hang forever:

  C-x e

In GNU Emacs 22.0.92.18 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2007-01-19 on trpaslik
X server distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--with-gtk' '--prefix' '/usr/local'
 '--with-xpm' '--with-jpeg' '--with-png' '--with-gif''


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: hack-local-variables-confirm loops forever when running keyboard macro

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Would someone please fix this, then ack?

I don't think any fix is necessary---one simply ought to be careful
when defining keyboard macros to avoid situations like this.  Note
that C-g successfully breaks the loop, as it should.

> From: Chris Moore <dooglus@gmail.com>
> Subject: hack-local-variables-confirm loops forever when running keyboard macro
> To: emacs-pretest-bug@gnu.org, Chris Moore <dooglus@gmail.com>
> Cc: 
>
>  1. ensure temp file doesn't exist
>
>   $ rm /tmp/file.txt
>
>  2. create a temp file with 'risky' local variable:
>
>   $ printf "# Local Variables:\n# eval: (put 'w 't 'f)\n# End:\n" > /tmp/file.txt
>
>  3. run Emacs:
>
>   $ emacs -Q
>
>  4. visit the temp file.  it will prompt for whether to run the risky
>     code:
>
>   C-x C-f /tmp/file.txt RET
>
>  5. answer that you don't want to run it:
>
>   n
>
>  6. start recording a macro:
>
>   C-x (
>
>  7. visit the risky temp file.  it won't prompt this time, since the
>     file is already visited
>
>   C-x C-f /tmp/file.txt RET
>
>  8. stop recording the macro
>
>   C-x )
>
>  9. kill the temp file's buffer
>
>   C-x k RET
>
> 10. run the macro.  Emacs will hang forever:
>
>   C-x e

Re: hack-local-variables-confirm loops forever when running keyboard macro

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Would someone please fix this, then ack?
>
> I don't think any fix is necessary---one simply ought to be careful
> when defining keyboard macros to avoid situations like this.  Note
> that C-g successfully breaks the loop, as it should.

I agree.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: hack-local-variables-confirm loops forever when running keyboard macro

[Richard Stallman]

    > Would someone please fix this, then ack?

    I don't think any fix is necessary---one simply ought to be careful
    when defining keyboard macros to avoid situations like this.

What happens with other queries from C-x f, when it is used in a
keyboard macro?  Does it do the same thing?

Re: hack-local-variables-confirm loops forever when running keyboard macro

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > Would someone please fix this, then ack?
>
>     I don't think any fix is necessary---one simply ought to be careful
>     when defining keyboard macros to avoid situations like this.
>
> What happens with other queries from C-x f, when it is used in a
> keyboard macro?  Does it do the same thing?

If you mean C-x C-f, there seems to be no problem.

Re: hack-local-variables-confirm loops forever when running keyboard macro

[Richard Stallman]

    >     I don't think any fix is necessary---one simply ought to be careful
    >     when defining keyboard macros to avoid situations like this.
    >
    > What happens with other queries from C-x f, when it is used in a
    > keyboard macro?  Does it do the same thing?

    If you mean C-x C-f, there seems to be no problem.

Yes, I meant C-x C-f.

Are you saying that the OTHER queries C-x C-f makes do not cause the
same problem as this query?  If so, that is peculiar, and it suggests
we ought to be able to fix this one to be like the others.

If they all cause the same problem, then it's just normal,
so there's no need to do anything.

Re: hack-local-variables-confirm loops forever when running keyboard macro

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

> Are you saying that the OTHER queries C-x C-f makes do not cause the
> same problem as this query?

The "File ... changed on disk.  Reread from disk? (yes or no)" prompt
works fine inside a keyboard macro.  It seems that it's just the
'risky variable' question which causes the problem.

When Emacs hangs, it consumes all available CPU time.  I don't think
this is acceptable:

  1) it's not acceptable to use all available CPU time or to get stuck
     in an infinite loop when simply attempting to open a file

  2) Emacs gives no indication of what it's doing.  The question isn't
     displayed to the user.

> If so, that is peculiar,

It's just a bug, I think.

Re: hack-local-variables-confirm loops forever when running keyboard macro

[Chong Yidong]

Chris Moore <dooglus@gmail.com> writes:

> When Emacs hangs, it consumes all available CPU time.  I don't think
> this is acceptable

I see the problem now.  I've checked in a fix into CVS.  Thanks.