From xemacs-m  Sat Sep 20 17:04:47 1997
Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id RAA05059
	for <xemacs-beta@xemacs.org>; Sat, 20 Sep 1997 17:04:47 -0500 (CDT)
Received: from crystal.WonderWorks.COM by relay6.UU.NET with ESMTP 
	(peer crosschecked as: crystal.WonderWorks.com [192.203.206.1])
	id QQdhwi23563; Sat, 20 Sep 1997 18:05:05 -0400 (EDT)
Received: by crystal.WonderWorks.COM 
	id QQdhwi24303; Sat, 20 Sep 1997 18:04:47 -0400 (EDT)
Date: Sat, 20 Sep 1997 18:04:47 -0400 (EDT)
Message-Id: <QQdhwi24303.199709202204@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="5QBkE8gN5n"
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Re: Dired off-by-one-error
In-Reply-To: <m2souzafhn.fsf@altair.xemacs.org>
References: <21124.199707041312@dr2.delcam.com>
	<m2souzafhn.fsf@altair.xemacs.org>
X-Mailer: VM 6.34 under 19.16 "" XEmacs Lucid (beta91)
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V


--5QBkE8gN5n
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

SL Baur writes:
 > As near as I can tell, this bug is still present in beta23.  Anybody
 > have an idea how to fix it?
 > 
 > Paul Bibilo <peb@delcam.com> writes:
 > 
 > > Mime-Version: 1.0 (generated by tm-edit 7.108)
 > > Content-Type: text/plain; charset=US-ASCII
 > 
 > > In `Athens', and versions back to b7 on SGI IRIX 6.2, if in dired mode
 > > you middle mouse click on the first character of a file/directory name
 > > it bleeps at you with a message in the minibuffer
 > 
 > > Buffer is read only: #<buffer "filename">
 > 
 > > You need to click on at least the second character for it to correctly 
 > > visit the file/directory.

Most likely it is the keymap lookup bug that exists if you use a
start-open extent.  I complained about it earlier because VM is having
similar problems.  I think the following is the patch that caused
it.  I would be delighted if it were unapplied.


--5QBkE8gN5n
Content-Type: message/rfc822
Content-Disposition: inline;
	filename="foo"
Content-Transfer-Encoding: 7bit

Return-Path: <xemacs-beta-request@xemacs.org>
Received: from xemacs.org by crystal.WonderWorks.COM with ESMTP 
	(peer crosschecked as: xemacs.cs.uiuc.edu [128.174.252.16])
	id QQcswb08854; Sat, 7 Jun 1997 01:16:09 -0400 (EDT)
Received: (from xemacs-m@localhost)
	by xemacs.org (8.8.5/8.8.5) id AAA21709;
	Sat, 7 Jun 1997 00:12:34 -0500 (CDT)
Resent-Date: Sat, 7 Jun 1997 00:12:34 -0500 (CDT)
To: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: [patch] Keymaps at extent endpoints
X-Attribution: Hrv
X-Face: Mie8:rOV<\c/~z{s.X4A{!?vY7{drJ([U]0O=W/<W*SMo/Mv:58:*_y~ki>xDi&N7XG
        KV^$k0m3Oe/)'e%3=$PCR&3ITUXH,cK>]bci&<qQ>Ff%x_>1`T(+M2Gg/fgndU%k*ft
        [(7._6e0n-V%|%'[c|q:;}td$#INd+;?!-V=c8Pqf}3J
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 07 Jun 1997 07:12:24 +0200
Message-ID: <kigwwo7q9mv.fsf@jagor.srce.hr>
Lines: 58
X-Mailer: Gnus v5.4.52/XEmacs 20.3(beta4)
Resent-Message-ID: <"iKAw82.0.8J5.0tEcp"@xemacs>
Resent-From: xemacs-beta@xemacs.org
X-Mailing-List: <xemacs-beta@xemacs.org> archive/latest/9159
X-Loop: xemacs-beta@xemacs.org
Precedence: list
Resent-Sender: xemacs-beta-request@xemacs.org

The latest widget has a workaround for extent keymaps not being heeded
at the end of extents (even when they are end-closed).  This patch
fixes that.

Per, can you confirm that this patch fixes widget?  Everyone, can you
confirm that this patch didn't break everything horribly? :-)

The idea was to use `at' flag to `extent-at' to catch all the extents
nearby.  Then I use `extent-in-region-p' to catch the naughty ones.
After this patch, the relevant keymap of the extent is looked up
similar to the way extents are adjusted for insertion.

123x
   ^  cursor here

Now, if we have a [1, 4) extent e, its keymap will be ignored -- as
before.  BUT, if the extent is [1, 4], its keymap will be valid at the 
cursor.  The same goes for extent beginning.  IMHO this is highly
logical, and that's the way it was supposed to be implemented from the 
beginning.

I read Kyle's post, and I don't understand exactly why this behaviour
would ever be a bad thing.  As far as I can see, the only bad thing
was the behaviour as it was before.


--- src/keymap.c.orig	Sat Jun  7 06:06:55 1997
+++ src/keymap.c	Sat Jun  7 07:00:51 1997
@@ -2436,14 +2436,17 @@
   if (!NILP (pos))
     {
       Lisp_Object extent;
-      for (extent = Fextent_at (pos, buffer_or_string, Qkeymap, Qnil, Qnil);
+      for (extent = Fextent_at (pos, buffer_or_string, Qkeymap, Qnil, Qat);
 	   !NILP (extent);
-	   extent = Fextent_at (pos, buffer_or_string, Qkeymap, extent, Qnil))
+	   extent = Fextent_at (pos, buffer_or_string, Qkeymap, extent, Qat))
 	{
-	  Lisp_Object keymap = Fextent_property (extent, Qkeymap, Qnil);
-	  if (!NILP (keymap))
-	    relevant_map_push (get_keymap (keymap, 1, 1), closure);
-	  QUIT;
+	  if (!NILP (Fextent_in_region_p (extent, pos, pos, Qnil)))
+	    {
+	      Lisp_Object keymap = Fextent_property (extent, Qkeymap, Qnil);
+	      if (!NILP (keymap))
+		relevant_map_push (get_keymap (keymap, 1, 1), closure);
+	      QUIT;
+	    }
 	}
     }
 }


-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm sure they'll listen to reason! -- Neal Stevenson, _Snow Crash_

--5QBkE8gN5n--

