hiding lines

hiding lines

[Werner LEMBERG]

Folks,


I would like to hide lines in a buffer which satisfy a regexp --
either the lines get completely hidden (or perhaps indicated with
`...' as in the outline mode), or a search-and-replace function
doesn't match them.

Does Emacs have such a thing?  A lookup in the docs doesn't show
anything relevant.  This would be a very convenient function for
editing lists.


    Werner

Re: hiding lines

[Alan Mackenzie]

Hi, Werner,

On Thu, Apr 02, 2009 at 08:52:01AM +0200, Werner LEMBERG wrote:

> Folks,


> I would like to hide lines in a buffer which satisfy a regexp --
> either the lines get completely hidden (or perhaps indicated with
> `...' as in the outline mode), or a search-and-replace function
> doesn't match them.

> Does Emacs have such a thing?  A lookup in the docs doesn't show
> anything relevant.  This would be a very convenient function for
> editing lists.

The following makes the current region invisible and intangible.  It
doesn't, as yet, make it visible and tangible again very well.  It's not
quite what you're asking for, but you can likely use it as the engine
end of what you want.

    (defun make-region-invisible (beg end &optional arg)
      "Make the current region invisible and intangible.
    With a prefix arg, make it visible again.  With an arg of 0,
    make all such regions visible."
      (interactive "r\nP")
      (let (ov ovs)
        (cond
         ((eq arg 0)
          (setq ovs (overlays-in (point-min) (point-max)))
          (mapc (lambda (o)
                  (when (overlay-get o 'acm-invisible)
                    (delete-overlay o)))
                ovs))
         ((equal arg '(4))
          (setq ovs (overlays-at (point)))
          (mapc (lambda (o)
                  (when (overlay-get o 'acm-invisible)
                    (delete-overlay o)))
                ovs))
         (t
          (setq ov (make-overlay beg end))
          (overlay-put ov 'acm-invisible t)
          (overlay-put ov 'invisible t)
          (overlay-put ov 'intangible t)))))
    (global-set-key "\C-cz" 'make-region-invisible)


>     Werner

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: hiding lines

[Stefan Monnier]

> The following makes the current region invisible and intangible.  It

I'll just remind people that I strongly discourage the use of
the `intangible' property.  Your code should work well with just the
`invisible' property; if not, it might be a bug.


        Stefan

Re: hiding lines

[Andreas Roehler]

Alan Mackenzie wrote:
> Hi, Werner,
> 
> On Thu, Apr 02, 2009 at 08:52:01AM +0200, Werner LEMBERG wrote:
> 
>> Folks,
> 
> 
>> I would like to hide lines in a buffer which satisfy a regexp --
>> either the lines get completely hidden (or perhaps indicated with
>> `...' as in the outline mode), or a search-and-replace function
>> doesn't match them.
> 
>> Does Emacs have such a thing?  A lookup in the docs doesn't show
>> anything relevant.  This would be a very convenient function for
>> editing lists.
> 
> The following makes the current region invisible and intangible.  It
> doesn't, as yet, make it visible and tangible again very well.  It's not
> quite what you're asking for, but you can likely use it as the engine
> end of what you want.
> 
>     (defun make-region-invisible (beg end &optional arg)
>       "Make the current region invisible and intangible.
>     With a prefix arg, make it visible again.  With an arg of 0,
>     make all such regions visible."
>       (interactive "r\nP")
>       (let (ov ovs)
>         (cond
>          ((eq arg 0)
>           (setq ovs (overlays-in (point-min) (point-max)))
>           (mapc (lambda (o)
>                   (when (overlay-get o 'acm-invisible)
>                     (delete-overlay o)))
>                 ovs))
>          ((equal arg '(4))
>           (setq ovs (overlays-at (point)))
>           (mapc (lambda (o)
>                   (when (overlay-get o 'acm-invisible)
>                     (delete-overlay o)))
>                 ovs))
>          (t
>           (setq ov (make-overlay beg end))
>           (overlay-put ov 'acm-invisible t)
>           (overlay-put ov 'invisible t)
>           (overlay-put ov 'intangible t)))))
>     (global-set-key "\C-cz" 'make-region-invisible)
> 
> 
>>     Werner
> 

Thanks to Bastien Guerry Emacs-Lisp Bill-Board is
available for just that kind of tasks.

Please have have a look at http://repo.or.cz/w/elbb.git

The declared bill-board environment allows some
playing, even with git.


Andreas Röhler

Re: hiding lines

[Alan Mackenzie]

Hi, Stefan!

On Thu, Apr 02, 2009 at 08:39:50PM -0400, Stefan Monnier wrote:
> > The following makes the current region invisible and intangible.  It

> I'll just remind people that I strongly discourage the use of
> the `intangible' property.  Your code should work well with just the
> `invisible' property; if not, it might be a bug.

I don't know exactly what `invisible' and `intangible' text/overlay
properties mean.  I don't know when to use each of them, when to use
both of them together.  The documentation is vague and unhelpful.  It
doesn't define these properties, instead merely stating _some_ of the
things they do.

For example, the documentation implies that if I isearch for something
inside the invisible bit, the cursor should end up on the other side of
the invisibility.  Instead, it does the Right Thing.

"Invisible" means you can't see something.  "Intangible" means you can't
touch it.  However, the `invisible' property has bits of intangibility
mixed in with it.  This makes it very confusing.

It seems though, at least in C Mode, that when a user makes part of his
buffer invisible, the invisible bits are still seen by the parsing
routines in CC Mode.  I don't know why this is so.

The documentation, (Elisp manual pages "Invisible Text" and "special
properties") is of no help here.  It says, in effect, "The invisible
property sort of does this".

Are there any complete descriptions of these properties anywhere?  Are
there any guidelines for there use anywhere?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: hiding lines

[Stefan Monnier]

> I don't know exactly what `invisible' and `intangible' text/overlay
> properties mean.

Basically:
- `invisible' means "not displayed".
- `intangible' means "can't put point in it (if you try, point will be
  put at the beginning or the end of the intangible text).
Not being able to put point in a piece of text has far reaching consequences,
e.g. (/= (1+ (point)) (save-excursion (forward-char 1) (point)))
so it tends to introduce bugs in all kinds of places.

The read-eval loop has a built-in post-command-hook (controlled by
disable-point-adjustment and global-disable-point-adjustment) that moves
point outside of `invisible' text (as well as outside of
char-compositions, and outside of images), so `invisible' text is
treated as somewhat intangible, except this kind of intangibility is
only applied after a command is done running, which introduces much
fewer problems than the `intangible' property which is applied at a much
lower level.

> I don't know when to use each of them, when to use both of
> them together.

If you don't know, then you probably don't want to use `intangible'.

> For example, the documentation implies that if I isearch for something
> inside the invisible bit, the cursor should end up on the other side of
> the invisibility.  Instead, it does the Right Thing.

Can you point me to the place that implies this behavior?

> It seems though, at least in C Mode, that when a user makes part of his
> buffer invisible, the invisible bits are still seen by the parsing
> routines in CC Mode.  I don't know why this is so.

Because `invisible' isn't like narrowing: it only prevents the display,
but doesn't remove the text.

> The documentation, (Elisp manual pages "Invisible Text" and "special
> properties") is of no help here.  It says, in effect, "The invisible
> property sort of does this".

> Are there any complete descriptions of these properties anywhere?  Are
> there any guidelines for there use anywhere?

Looks like the doc needs some improvement.  Thanks for pointing it out.


        Stefan

Re: hiding lines

[Werner LEMBERG]

> Basically:
> - `invisible' means "not displayed".
> - `intangible' means "can't put point in it (if you try, point will
>   be put at the beginning or the end of the intangible text).
> Not being able to put point in a piece of text has far reaching
> consequences, e.g. (/= (1+ (point)) (save-excursion (forward-char 1)
> (point))) so it tends to introduce bugs in all kinds of places.

However, I think this is exactly what I need -- thanks, Alan, for the
first try!

Consider this table:

  foo
  bar
  foo=bar
  bar-foo
  baz
  baz=baz
  baz-foo=baz

I would like to make all lines invisable *and* intangible which don't
contain a `='.  Otherwise interactive search-and-replace would try to
modify invisible text.  At least this is my conclusion of your
explanations.


    Werner

Re: hiding lines

[Stefan Monnier]

> I would like to make all lines invisable *and* intangible which don't
> contain a `='.  Otherwise interactive search-and-replace would try to
> modify invisible text.  At least this is my conclusion of your
> explanations.

No, the conclusion of my explanations is that search&replace need to be
changed to ignore (or reveal) invisible text, like isearch does.


        Stefan

Re: hiding lines

[Werner LEMBERG]

>> I would like to make all lines invisable *and* intangible which
>> don't contain a `='.  Otherwise interactive search-and-replace
>> would try to modify invisible text.  At least this is my conclusion
>> of your explanations.
>
> No, the conclusion of my explanations is that search&replace need to
> be changed to ignore (or reveal) invisible text, like isearch does.

And what do you advise me to do?  How can I do what I want without
setting the `intangible' property?


    Werner

Re: hiding lines

[Stefan Monnier]

>>> I would like to make all lines invisable *and* intangible which
>>> don't contain a `='.  Otherwise interactive search-and-replace
>>> would try to modify invisible text.  At least this is my conclusion
>>> of your explanations.
>> No, the conclusion of my explanations is that search&replace need to
>> be changed to ignore (or reveal) invisible text, like isearch does.
> And what do you advise me to do?  How can I do what I want without
> setting the `intangible' property?

Send a patch ;-)


        Stefan

Re: hiding lines

[Werner LEMBERG]

>>>> I would like to make all lines invisable *and* intangible which
>>>> don't contain a `='.  Otherwise interactive search-and-replace
>>>> would try to modify invisible text.  At least this is my
>>>> conclusion of your explanations.
>>>
>>> No, the conclusion of my explanations is that search&replace need
>>> to be changed to ignore (or reveal) invisible text, like isearch
>>> does.
>>
>> And what do you advise me to do?  How can I do what I want without
>> setting the `intangible' property?
> 
> Send a patch ;-)

In other words, with current code I have to use `intangible', right?


    Werner

Re: hiding lines

[Werner LEMBERG]

[-- Attachment #1: Type: Text/Plain, Size: 648 bytes --]


> Consider this table:
> 
>   foo
>   bar
>   foo=bar
>   bar-foo
>   baz
>   baz=baz
>   baz-foo=baz
> 
> I would like to make all lines invisable *and* intangible which
> don't contain a `='.  Otherwise interactive search-and-replace would
> try to modify invisible text.  At least this is my conclusion of
> your explanations.

I've now come up with the code as shown in the attachment.  It works
fine, however, I would like to not have empty lines; in other words,
invisible text should not take any space in the buffer.  Does Emacs
supports such a `compressed invisibility'?  Otherwise it's getting
quite complicated, I fear...


    Werner


[-- Attachment #2: line-invisible.el --]
[-- Type: Text/Plain, Size: 904 bytes --]

(defun make-lines-invisible (regexp &optional arg)
  "Make all lines matching a regexp invisible and intangible.
With a prefix arg, make it visible again.  It is not necessary
that REGEXP matches the whole line; if a hit is found, the
affected line gets automatically selected.

This command affects the whole buffer."
  (interactive "MRegexp: \nP")
  (let (ov
	ovs)
    (cond
     ((equal arg '(4))
      (setq ovs (overlays-in (point-min) (point-max)))
      (mapc (lambda (o)
	      (if (overlay-get o 'make-lines-invisible)
		  (delete-overlay o)))
	    ovs))
     (t
      (save-excursion
	(goto-char (point-min))
	(while (re-search-forward regexp nil t)
	  (setq ov (make-overlay (line-beginning-position)
				 (line-end-position)))
	  (overlay-put ov 'make-lines-invisible t)
	  (overlay-put ov 'invisible t)
	  (overlay-put ov 'intangible t)))))))

(global-set-key "\C-cz" 'make-lines-invisible)

Re: hiding lines

[Andreas Schwab]

Werner LEMBERG <wl@gnu.org> writes:

> I've now come up with the code as shown in the attachment.  It works
> fine, however, I would like to not have empty lines; in other words,
> invisible text should not take any space in the buffer.  Does Emacs
> supports such a `compressed invisibility'?

Make the newline invisible.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: hiding lines

[Werner LEMBERG]

>> I've now come up with the code as shown in the attachment.  It
>> works fine, however, I would like to not have empty lines; in other
>> words, invisible text should not take any space in the buffer.
>> Does Emacs supports such a `compressed invisibility'?
> 
> Make the newline invisible.

Thanks!  This perhaps deserves a notice in the documentation.


    Werner

`make-overlay' very slow (was: hiding lines)

[Werner LEMBERG]

[-- Attachment #1: Type: Text/Plain, Size: 945 bytes --]


>>> I've now come up with the code as shown in the attachment.  It
>>> works fine, however, I would like to not have empty lines; in
>>> other words, invisible text should not take any space in the
>>> buffer.  Does Emacs supports such a `compressed invisibility'?
>>
>> 
>> Make the newline invisible.
> 
> Thanks!  This perhaps deserves a notice in the documentation.

I've now tried the code with my real-world table (containing
approx. 420000 lines):

  git://repo.or.cz/srv/git/wortliste.git

and I found out that it is, alas, unusable.  It starts with about 1000
replacements per second on my GNU/Linux box (using simply `-' as the
regexp), but soon the speed decreases: After approx. 10000
replacements it only can handle 100 replacements per second -- the
attached code now contains a small counter to show the progress.  If
you comment out the call to `make-overlay', the code really flies...

Am I doing something wrong?


    Werner

[-- Attachment #2: line-invisible.el --]
[-- Type: Text/Plain, Size: 1053 bytes --]

(defun make-lines-invisible (regexp &optional arg)
  "Make all lines matching a regexp invisible and intangible.
With a prefix arg, make it visible again.  It is not necessary
that REGEXP matches the whole line; if a hit is found, the
affected line gets automatically selected.

This command affects the whole buffer."
  (interactive "MRegexp: \nP")
  (let (ov
	ovs
	count)
    (cond
     ((equal arg '(4))
      (setq ovs (overlays-in (point-min) (point-max)))
      (mapc (lambda (o)
	      (if (overlay-get o 'make-lines-invisible)
		  (delete-overlay o)))
	    ovs))
     (t
      (save-excursion
	(goto-char (point-min))
	(setq count 0)
	(while (re-search-forward regexp nil t)
	  (setq count (1+ count))
	  (if (= (% count 100) 0)
	      (message "%d" count))
	  (setq ov (make-overlay (line-beginning-position)
				 (1+ (line-end-position))))
;	  (overlay-put ov 'make-lines-invisible t)
;	  (overlay-put ov 'invisible t)
;	  (overlay-put ov 'intangible t)
	  (goto-char (line-end-position))))))))

(global-set-key "\C-cz" 'make-lines-invisible)

Re: `make-overlay' very slow

[Stefan Monnier]

> and I found out that it is, alas, unusable.  It starts with about 1000
> replacements per second on my GNU/Linux box (using simply `-' as the
> regexp), but soon the speed decreases: After approx. 10000
> replacements it only can handle 100 replacements per second -- the
> attached code now contains a small counter to show the progress.  If
> you comment out the call to `make-overlay', the code really flies...

> Am I doing something wrong?

overlays have a poor algorithmic behavior (many operations take a time
proportional to the number of overlays in the buffer).  Better use
text-properties (which are implemented with a tree and should provide
something closer to O(log N) complexity instead).


        Stefan

Re: `make-overlay' very slow

[Werner LEMBERG]

[-- Attachment #1: Type: Text/Plain, Size: 691 bytes --]

> overlays have a poor algorithmic behavior (many operations take a
> time proportional to the number of overlays in the buffer).  Better
> use text-properties (which are implemented with a tree and should
> provide something closer to O(log N) complexity instead).

I did that (see attachment for reference), and it really works at a
reasonable speed.  However, it is the completely wrong concept since
it sets the `modified' flag and stores undo information, and it fails
with modes which use the `invisible' and `intangible' properties.

So here's my item to the Emacs wishlist: Improve speed of
(make-overlay) and related functions to be as fast as setting text
properties.


    Werner

[-- Attachment #2: line-invisible-text-properties.el --]
[-- Type: Text/Plain, Size: 1516 bytes --]

(defun make-lines-invisible (regexp &optional arg)
  "Make all lines matching a regexp invisible and intangible.
With a prefix arg, make them visible again.  It is not necessary
that REGEXP matches the whole line; if a hit is found, the
affected line gets automatically selected.

This function affects the whole buffer.

Note that this function modifies the `invisible' and `intangible'
text properties; it may thus interfere with modes which use them.
Due to implementation restrictions in current Emacs versions it
is not possible to use overlays -- which would avoid text
property modifications -- without becoming unbearably slow for
large buffers with many matches."
  (interactive "MRegexp: \nP")
  (save-excursion
    (cond
     (arg
      (let ((next-pos (point-min)))
	(while (setq next-pos
		     (text-property-any next-pos
					(point-max)
					'make-lines-invisible
					t))
	  (goto-char next-pos)
	  (setq next-pos (or (next-single-property-change
			      (point)
			      'make-lines-invisible)
			     (point-max)))
	  (remove-list-of-text-properties (point)
					  next-pos
					  '(make-lines-invisible
					    invisible
					    intangible)))))
    (t
     (goto-char (point-min))
     (while (re-search-forward regexp nil t)
       (add-text-properties (line-beginning-position)
			    (1+ (line-end-position)) ; handle \n
			    '(make-lines-invisible t
			      invisible t
			      intangible t))
       (goto-char (line-end-position)))))))

(global-set-key "\C-cz" 'make-lines-invisible)

Re: `make-overlay' very slow

[Lennart Borgman]

On Sat, Apr 11, 2009 at 8:11 AM, Werner LEMBERG <wl@gnu.org> wrote:
>> overlays have a poor algorithmic behavior (many operations take a
>> time proportional to the number of overlays in the buffer).  Better
>> use text-properties (which are implemented with a tree and should
>> provide something closer to O(log N) complexity instead).
>
> I did that (see attachment for reference), and it really works at a
> reasonable speed.  However, it is the completely wrong concept since
> it sets the `modified' flag and stores undo information,

There is a macro in font-lock.el that you can use to modify text
properties without storing undo information or setting the modified
flag.

> and it fails
> with modes which use the `invisible' and `intangible' properties.

Re: `make-overlay' very slow

[Werner LEMBERG]

>> I did that (see attachment for reference), and it really works at a
>> reasonable speed.  However, it is the completely wrong concept
>> since it sets the `modified' flag and stores undo information,
> 
> There is a macro in font-lock.el that you can use to modify text
> properties without storing undo information or setting the modified
> flag.

Thanks, will update my code.  However, it isn't a general solution
since my function should essentially work with all modes.


    Werner

Re: `make-overlay' very slow

[Lennart Borgman]

On Sat, Apr 11, 2009 at 9:45 AM, Werner LEMBERG <wl@gnu.org> wrote:
>
>>> I did that (see attachment for reference), and it really works at a
>>> reasonable speed.  However, it is the completely wrong concept
>>> since it sets the `modified' flag and stores undo information,
>>
>> There is a macro in font-lock.el that you can use to modify text
>> properties without storing undo information or setting the modified
>> flag.
>
> Thanks, will update my code.  However, it isn't a general solution
> since my function should essentially work with all modes.

The macro does not depend on font-lock and you have to copy it to your code.

Re: `make-overlay' very slow

[Werner LEMBERG]

>> Thanks, will update my code.  However, it isn't a general solution
>> since my function should essentially work with all modes.
> 
> The macro does not depend on font-lock and you have to copy it to
> your code.

There's a misunderstanding: I mean the overlay vs. text properties
problem.  `save-buffer-state' works just fine.


    Werner

Re: `make-overlay' very slow

[Eli Zaretskii]

> Date: Sat, 11 Apr 2009 08:11:50 +0200 (CEST)
> From: Werner LEMBERG <wl@gnu.org>
> Cc: acm@muc.de, schwab@linux-m68k.org, emacs-devel@gnu.org
> 
> So here's my item to the Emacs wishlist: Improve speed of
> (make-overlay) and related functions to be as fast as setting text
> properties.

I suggest filing a ``wishlist'' bug report about this.

Re: `make-overlay' very slow

[Stefan Monnier]

> I did that (see attachment for reference), and it really works at a
> reasonable speed.

Good.

> However, it is the completely wrong concept since
> it sets the `modified' flag and stores undo information,

Yes, you need to wrap the call to > add-text-properties (actually the
whole loop, preferably) in something like

   (let ((buffer-file-name nil) ;; To prevent locking/unlocking the file.
         (buffer-undo-list t)
         (modified (buffer-modified-p)))
     (unwind-protect
         (...)
       (restore-modified-p modified)))

We definitely need to add a macro for it.

> and it fails with modes which use the `invisible' and
> `intangible' properties.

Since these properties are not used very often, it's probably bearable,
but yes, there is a risk of interference.

> So here's my item to the Emacs wishlist: Improve speed of
> (make-overlay) and related functions to be as fast as setting
> text properties.

Yes, that would be great.  But note that it's not just `make-overlay':
every time we make a modification to the buffer, we have to update the
position of all the overlays (and markers) after point.  So, yes,
a better data-structure for overlays (and markers) would be very welcome.


        Stefan

Re: `make-overlay' very slow

[Kenichi Handa]

In article <jwvr5zz1hzq.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Yes, that would be great.  But note that it's not just `make-overlay':
> every time we make a modification to the buffer, we have to update the
> position of all the overlays (and markers) after point.  So, yes,
> a better data-structure for overlays (and markers) would be very welcome.

I have not yet thought about this idea in deep but perhaps
we can use one more interval tree for overlays.

More radical idea, not related to overlays, is to make one
interval tree for one text property; i.e. one for `face',
one for `fontified'...  I think it not only improves the
processing speed, but also reduces the memory usage
(next-property-change will get slower, but we use
next-single-property-change more often).

---
Kenichi Handa
handa@m17n.org

Re: `make-overlay' very slow

[Stefan Monnier]

>> Yes, that would be great.  But note that it's not just
>> `make-overlay': every time we make a modification to the buffer, we
>> have to update the position of all the overlays (and markers) after
>> point.  So, yes, a better data-structure for overlays (and markers)
>> would be very welcome.

> I have not yet thought about this idea in deep but perhaps
> we can use one more interval tree for overlays.

Yes, to speed up overlays algorithmically, we'd want to implement
them with some kind of tree.  If we could share some of the code with
the text properties's interval tree that would be great, indeed.

> More radical idea, not related to overlays, is to make one
> interval tree for one text property; i.e. one for `face',
> one for `fontified'...  I think it not only improves the
> processing speed, but also reduces the memory usage
> (next-property-change will get slower, but we use
> next-single-property-change more often).

I've been tempted as well, but I'm not sure it'd be much of
an improvement.  You'd end up with many trees, so might need
a hash-table or some other tree to map text-property names to the
corresponding interval tree.


        Stefan

Re: `make-overlay' very slow

[Richard M Stallman]

When you access overlays in nonrandom order, the speed is very much
affected by where the "center" is.  Calling `overlay-recenter'
at suitable times might cause a big speedup.

Re: `make-overlay' very slow

[Kenichi Handa]

In article <jwvprfftn08.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > More radical idea, not related to overlays, is to make one
> > interval tree for one text property; i.e. one for `face',
> > one for `fontified'...  I think it not only improves the
> > processing speed, but also reduces the memory usage
> > (next-property-change will get slower, but we use
> > next-single-property-change more often).

> I've been tempted as well, but I'm not sure it'd be much of
> an improvement.  You'd end up with many trees, so might need
> a hash-table or some other tree to map text-property names to the
> corresponding interval tree.

I think the number of properties is not that much in normal
use and using just `assq' is sufficient.  I seldom see more
than 8 kinds of properties.  And, we can move the lastly
accessed interval tree to the head of interval tree list if
speed up is really necessary.

---
Kenichi Handa
handa@m17n.org

clone-indirect-buffer-hook should be make-indirect-buffer-hook

[klaus.berndl]

Hi all,

AFAICS the new hook `clone-indirect-buffer-hook' of Emacs 23 is not used by the command `make-indirect-buffer' or is it? If not: why not?

IMHO a bug in Emacs 23 because if there is such a hook, then it should be used by both of them - ideally only by `make-indirect-buffer' (because this command is internally called by `clone-indirect-buffer') and then the new hook should also be renamed to `make-indirect-buffer-hook'.

Thoughts?

Regards
Klaus