Re: Fwd: Loading ebrowse file yields warning

Re: Fwd: Loading ebrowse file yields warning

[Stefan Monnier]

> Does anyone disagree with this recommendation?

No, it's 100% correct: the BROWSE buffer is "internal" like the TAGS buffer
for etags.


        Stefan

Re: Fwd: Loading ebrowse file yields warning

[Richard Stallman]

    > Does anyone disagree with this recommendation?

    No, it's 100% correct: the BROWSE buffer is "internal" like the TAGS buffer
    for etags.

Ok.  Could someone please do it?
(Turn off undo for the BROWSE buffer.)

Re: Fwd: Loading ebrowse file yields warning

[Glenn Morris]

Richard Stallman wrote:

>     No, it's 100% correct: the BROWSE buffer is "internal" like the
>     TAGS buffer for etags.
>
> Ok.  Could someone please do it?
> (Turn off undo for the BROWSE buffer.)

If these buffers are "internal", should they be hidden (which would
turn off undo)?

Re: Fwd: Loading ebrowse file yields warning

[Richard Stallman]

    If these buffers are "internal", should they be hidden (which would
    turn off undo)?

I don't know enough about ebrowse to have an answer.
Could you study it and DTRT?

Re: Fwd: Loading ebrowse file yields warning

[Glenn Morris]

Richard Stallman wrote:

>     If these buffers are "internal", should they be hidden (which would
>     turn off undo)?
>
> I don't know enough about ebrowse to have an answer.

My question was addressed to the list. I was/am hoping that people who
use ebrowse/etags will comment on whether they ever actually need to
look at the BROWSE/TAGS buffers.

Re: Fwd: Loading ebrowse file yields warning

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sun, 07 Oct 2007 03:15:35 -0400
> Cc: monnier@iro.umontreal.ca, Richard Stallman <rms@gnu.org>
> 
> Richard Stallman wrote:
> 
> >     If these buffers are "internal", should they be hidden (which would
> >     turn off undo)?
> >
> > I don't know enough about ebrowse to have an answer.
> 
> My question was addressed to the list. I was/am hoping that people who
> use ebrowse/etags will comment on whether they ever actually need to
> look at the BROWSE/TAGS buffers.

Sorry, I don't understand the question.  To use the C++ class browser,
one starts by visiting the file BROWSE (created in advance, e.g., by
running the `ebrowse' utility outside Emacs).  When you visit that
file, you get a buffer called "*Tree*" which visits that BROWSE file.
There's no buffer named BROWSE (or at least I don't see one; am I
missing something?).

This is in contrast to tags tables, where the table is visited by a
special buffer whose name is TAGS.

Are you talking about this *Tree* buffer?  If so, the user certainly
needs to look at it, since that's the buffer that displays the class
hierarchy.

Re: Fwd: Loading ebrowse file yields warning

[Glenn Morris]

Eli Zaretskii wrote:

> Sorry, I don't understand the question.  To use the C++ class browser,
> one starts by visiting the file BROWSE (created in advance, e.g., by
> running the `ebrowse' utility outside Emacs).  When you visit that
> file, you get a buffer called "*Tree*" which visits that BROWSE file.
> There's no buffer named BROWSE (or at least I don't see one; am I
> missing something?).
>
> This is in contrast to tags tables, where the table is visited by a
> special buffer whose name is TAGS.

I have no idea what I'm talking about, because I've never used
ebrowse; so I'll stop talking. The original report referred to a
BROWSE buffer:

    when loading a moderately large BROWSE file, the following warning is
    issued:

    Warning (undo): Buffer `BROWSE' undo info was 3940435 bytes long.
    The undo info was discarded because it exceeded `undo-outer-limit'.

    Recording of undo information should IMO be switched off in the BROWSE
    buffer.

Re: Fwd: Loading ebrowse file yields warning

[Richard Stallman]

    My question was addressed to the list. I was/am hoping that people who
    use ebrowse/etags will comment on whether they ever actually need to
    look at the BROWSE/TAGS buffers.

It is not impossible to look at a buffer whose name starts with space.
So the best question is, is it normal to look at them occasionally,
or is that something one does only to investigate bugs, etc.

Re: Fwd: Loading ebrowse file yields warning

[Robert J. Chassell]

   It is not impossible to look at a buffer whose name starts with space.
   So the best question is, is it normal to look at them occasionally,
   or is that something one does only to investigate bugs, etc.

Look at occasionally.  Currently:

   *Echo Area 0*                      
   *Echo Area 1*
   *Minibuf-0*                        
   *Minibuf-1*
   *code-conversion-work*             
   *rmime-tmp*

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Fwd: Loading ebrowse file yields warning

[Markus Gritsch]

Glenn Morris-3 wrote

> Richard Stallman wrote:
>
> >     No, it's 100% correct: the BROWSE buffer is "internal" like the
> >     TAGS buffer for etags.
> >
> > Ok.  Could someone please do it?
> > (Turn off undo for the BROWSE buffer.)
>
> If these buffers are "internal", should they be hidden (which would
> turn off undo)?

No, the buffer should not be hidden.

Kind regards,
Markus

Re: Fwd: Loading ebrowse file yields warning

[Markus Gritsch]

Richard Stallman wrote:
>
> Ok.  Could someone please do it?
> (Turn off undo for the BROWSE buffer.)

Here is the patch:

--- ebrowse_orig.el     2007-01-04 15:02:54.000000000 +0100
+++ ebrowse.el  2007-10-12 16:39:11.699875000 +0200
@@ -1139,6 +1139,7 @@

     (kill-all-local-variables)
     (use-local-map ebrowse-tree-mode-map)
+    (buffer-disable-undo)

     (unless (zerop (buffer-size))
       (goto-char (point-min))

Kind regards,
Markus

Re: Fwd: Loading ebrowse file yields warning

[Richard Stallman]

    > If these buffers are "internal", should they be hidden (which would
    > turn off undo)?

    No, the buffer should not be hidden.

Ok, we won't change that.  We will just turn off undo in it.

Re: Fwd: Loading ebrowse file yields warning

[Eli Zaretskii]

> Date: Fri, 12 Oct 2007 16:43:17 +0200
> From: "Markus Gritsch" <m.gritsch@gmail.com>
> 
> Richard Stallman wrote:
> >
> > Ok.  Could someone please do it?
> > (Turn off undo for the BROWSE buffer.)
> 
> Here is the patch:

Thanks, I installed it.

Re: Fwd: Loading ebrowse file yields warning

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 08 Oct 2007 03:06:30 -0400
> 
> Eli Zaretskii wrote:
> 
> > Sorry, I don't understand the question.  To use the C++ class browser,
> > one starts by visiting the file BROWSE (created in advance, e.g., by
> > running the `ebrowse' utility outside Emacs).  When you visit that
> > file, you get a buffer called "*Tree*" which visits that BROWSE file.
> > There's no buffer named BROWSE (or at least I don't see one; am I
> > missing something?).
> >
> > This is in contrast to tags tables, where the table is visited by a
> > special buffer whose name is TAGS.
> 
> I have no idea what I'm talking about, because I've never used
> ebrowse; so I'll stop talking. The original report referred to a
> BROWSE buffer:
> 
>     when loading a moderately large BROWSE file, the following warning is
>     issued:
> 
>     Warning (undo): Buffer `BROWSE' undo info was 3940435 bytes long.
>     The undo info was discarded because it exceeded `undo-outer-limit'.

Okay, I see now: the buffer BROWSE exists for a short period of time
until ebrowse.el generates a class tree from its information.  Then
this buffer is erased.

>     Recording of undo information should IMO be switched off in the BROWSE
>     buffer.

A change was just installed to do this.