From xemacs-m  Wed Sep 17 21:23:24 1997
Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id VAA17522
	for <xemacs-beta@xemacs.org>; Wed, 17 Sep 1997 21:23:19 -0500 (CDT)
Received: from orion.kurims.kyoto-u.ac.jp (orion.kurims.kyoto-u.ac.jp [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.8.5/3.4W2) with SMTP id LAA14530; Thu, 18 Sep 1997 11:22:30 +0900 (JST)
Received: (from petersen@localhost) by orion.kurims.kyoto-u.ac.jp (SMI-8.6/3.5Wbeta) id LAA07246; Thu, 18 Sep 1997 11:22:30 +0900
To: Remek Trzaska <remek@postoffice.npac.syr.edu>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: C-g pressed while typing in minibuffer
References: <rwxd8m7el11.fsf@greatwall.npac.syr.edu>
X-Face: fOOYdM>Ct-+jZ!MfKWRl?5e=(j4]xHE~<%D)$=FuN"@nP]"fi8stnK9>1fW>1HR[fj\=i%q0'l2G]0[H'R*m(fm^Og;iG>lBmr{anp!LG[)PD}g^XbG.(@oIi8;y)8+C"HV5}8NQ`HR7~P{+$AEEPo,N>,IwIbd:Dq6\"Bi#Aq\^lJ~dmwnUkc-Xb{k3\dZnF7j,$enH=Ybr<9v,Kzi-T|urefU:c{$pC)T5yvnRO0T+D&Z9{B8ulAd5X#c?Z|}vv^qhBjEj
X-Emacs: 20.3 "Tirana" XEmacs  Lucid (beta20) with mule
Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.86 "Naka-Tsurugi")
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Sep_18_11:22:29_1997-1"
Content-Transfer-Encoding: 7bit
From: Jens-Ulrik Holger Petersen <petersen@kurims.kyoto-u.ac.jp>
Date: 18 Sep 1997 11:22:29 +0900
In-Reply-To: Remek Trzaska's message of "17 Sep 1997 16:35:22 -0400"
Message-ID: <lb3en39x96.fsf@orion.kurims.kyoto-u.ac.jp>
Lines: 83
X-Mailer: Gnus v5.4.65 + SEMI patch (r2.1)/XEmacs 20.3(beta20) - "Tirana"

--Multipart_Thu_Sep_18_11:22:29_1997-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "RT" == Remek Trzaska <remek@postoffice.npac.syr.edu> writes:

    RT> Hi guys!
    RT> I remember a patch be Hrvoje (one of those 'How many times have
    RT> you...' ;-)) that fixed bad behavior of C-g pressed in minibuffer.

I don't think this has anything to do with Hrvoje's patch.  It is
probably due to some package you load.

    RT> Everything worked well in several betas: regardless of a
    RT> region being selected or not, while you were M-x'ing something
    RT> pressing C-g *once* aborted your operation in minibuffer.

    RT> I noticed that for some time now C-g behaves differently:

    RT> 1. 'M-x C-g' beeps, displays 'Quit' and deactivates minibuffer.  Fine.
    RT>    I like it.

    RT> 2. 'M-x foo C-g' beeps, displays 'Quit', and leaves the point in the
    RT>    minibuffer just as if nothing happened, displaying 'M-x foo'[1].
    RT>    Pressing C-g once again aborts.

    RT> *I* don't like it.  Maybe others do, I don't know.  Tell me.

I have been suffering from this myself for sometime now.
I didn't have time to try to track it down yet. [time passes...]

Ok, I think this is caused by "lazy-lock"!  I can reproduce this in
20.3beta{19,20} (and earlier betas too, I think) with

    xemacs -q -no-site-file

and then loading:


--Multipart_Thu_Sep_18_11:22:29_1997-1
Content-Type: application/octet-stream; type=emacs-lisp
Content-Disposition: attachment; filename="lazy-minibuf.el"
Content-Transfer-Encoding: 7bit

(require 'font-lock)
(add-hook 'font-lock-mode-hook 'turn-on-lazy-lock)
(find-file "~/.emacs")

--Multipart_Thu_Sep_18_11:22:29_1997-1
Content-Type: text/plain; charset=US-ASCII


Then after typing

     M-x blah C-g

I am still in the minibuffer.  A second C-g takes me out, just as
Ramek reported.

Not sure how to fix that yet, but I did find the following comment in
"lazy-lock.el"!

(defun lazy-lock-pre-idle-fontify-windows ()
  ;; Do groovy things always unless we're in one of the ignored commands.
  ;; The old version did the following five checks:
  ;;
  ;; (a) not in a macro,
  ;; (b) no input pending,
  ;; (c) got a real command (i.e. not an ignored command)
  ;; (d) not in the minibuffer
  ;; (e) no input after waiting for `lazy-lock-continuity-time'.
  ;;
  ;; (a), (b), and (e) are automatically taken care of by `pre-idle-hook'.
  ;; I removed (d) because there doesn't seem to be any reason for it.

I wonder if putting (d) back in would solve this?  Anyone have an old
enough version of Ben's "lazy-lock.el"?
-- 
Jens
---
Weiner's Law of Libraries:
	There are no answers, only cross references.

--Multipart_Thu_Sep_18_11:22:29_1997-1--

