GNU bug report logs - #4851
23.1.50; narrowing, indirect buffers and set-buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4851 in the body.
You can then email your comments to 4851 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.1.50; narrowing, indirect buffers and set-buffer
Date: Mon, 02 Nov 2009 15:49:37 +0100

1. emacs -Q
2. C-x b bla RET
3. M-: (insert "This is a test.")
4. M-: (narrow-to-region 5 10) 
=> buffer "bla" now displays " is a"
5. M-: (make-indirect-buffer (current-buffer) "blip")
6. M-: (save-restriction
        (widen)
        (set-buffer (get-buffer-create "bloop")))
=> buffer "bla" now displays "This is a test."

Contrast the above with (after killing buffer "bla") the same steps 1-4
and then step 6, i.e., leaving out step 5: then narrowing in "bla"
remains in effect.  So calling make-indirect-buffer appeared to disable
save-restriction when it contains a set-buffer call.

There is an apparently relevant passage in (elisp)Current Buffer:

   *Warning:* Lisp functions that change to a different current buffer
   should not depend on the command loop to set it back afterwards.
   Editing commands written in Emacs Lisp can be called from other programs
   as well as from the command loop; it is convenient for the caller if
   the subroutine does not change which buffer is current (unless, of
   course, that is the subroutine's purpose).  Therefore, you should
   normally use `set-buffer' within a `save-current-buffer' or
   `save-excursion' (*note Excursions::) form that will restore the
   current buffer when your function is done.

And indeed, if step 6 above (i.e., after make-indirect-buffer) is
replaced by this: 

6.' M-: (save-restriction
         (save-current-buffer
          (widen)
          (set-buffer (get-buffer-create "bloop"))))

or by this:

6.'' M-: (save-restriction
          (save-excursion
           (widen)
           (set-buffer (get-buffer-create "bloop"))))

then the narrowing in "bla" still remains in effect (also if the call to
widen is between save-restriction and save-current-buffer/save-excursion).

So perhaps the failure of narrowing to remain in effect above is not a
bug but a programming error, which should be correctly written as 6' or
6''.  But I'm not sure, since the failure only happens after calling
make-indirect-buffer, which is not what I would expect from the passage
in the Elisp manual quoted above.  If this is not an Emacs bug can someone
explain why the failure of narrowing to remain in effect is only
triggered by make-indirect-buffer?


In GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2009-10-27 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 4851 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#4851: 23.1.50; narrowing, indirect buffers and set-buffer
Date: Tue, 03 Nov 2009 16:34:20 -0500

> 1. emacs -Q
> 2. C-x b bla RET
> 3. M-: (insert "This is a test.")
> 4. M-: (narrow-to-region 5 10) 
> => buffer "bla" now displays " is a"
> 5. M-: (make-indirect-buffer (current-buffer) "blip")
> 6. M-: (save-restriction
>         (widen)
>         (set-buffer (get-buffer-create "bloop")))
> => buffer "bla" now displays "This is a test."

Thanks! I finally tracked this bug down.  Sadly, I think this points out
a more general problem, so while the patch below fixes it, we probably
have several other related bugs.


        Stefan


--- src/editfns.c	19 Oct 2009 04:27:14 -0000	1.473
+++ src/editfns.c	3 Nov 2009 21:32:41 -0000
@@ -3275,12 +3275,26 @@
 save_restriction_restore (data)
      Lisp_Object data;
 {
+  struct buffer *cur = NULL;
+  struct buffer *buf = (CONSP (data)
+			? XMARKER (XCAR (data))->buffer
+			: XBUFFER (data));
+
+  if (buf && buf != current_buffer && !NILP (buf->pt_marker))
+    { /* If `buf' uses markers to keep track of PT, BEGV, and ZV (as
+	 is the case if it is or has an indirect buffer), then make
+	 sure it is current before we update BEGV, so
+	 set_buffer_internal takes care of managing those markers.  */
+      cur = current_buffer;
+      set_buffer_internal (buf);
+    }
+
   if (CONSP (data))
     /* A pair of marks bounding a saved restriction.  */
     {
       struct Lisp_Marker *beg = XMARKER (XCAR (data));
       struct Lisp_Marker *end = XMARKER (XCDR (data));
-      struct buffer *buf = beg->buffer; /* END should have the same buffer. */
+      eassert (buf == end->buffer);
 
       if (buf /* Verify marker still points to a buffer.  */
 	  && (beg->charpos != BUF_BEGV (buf) || end->charpos != BUF_ZV (buf)))
@@ -3305,8 +3319,6 @@
   else
     /* A buffer, which means that there was no old restriction.  */
     {
-      struct buffer *buf = XBUFFER (data);
-
       if (buf /* Verify marker still points to a buffer.  */
 	  && (BUF_BEGV (buf) != BUF_BEG (buf) || BUF_ZV (buf) != BUF_Z (buf)))
 	/* The buffer has been narrowed, get rid of the narrowing.  */
@@ -3318,6 +3330,9 @@
 	}
     }
 
+  if (cur)
+    set_buffer_internal (cur);
+
   return Qnil;
 }
 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.