unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [m.gritsch@gmail.com: Loading ebrowse file yields warning]
@ 2007-10-02 21:59 Richard Stallman
  2007-10-03  7:04 ` Fwd: Loading ebrowse file yields warning Stefan Monnier
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2007-10-02 21:59 UTC (permalink / raw)
  To: emacs-devel

Does anyone disagree with this recommendation?

------- Start of forwarded message -------
X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
	autolearn=failed version=3.1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	bh=2ZqE2M2uS6sBLk6vih6vPXcOssx78h17HK0hcTjkO5I=;
	b=g3apZyc+Z/Sz2ryAXdVxYCTsLjxd0k/mj0jp4+UfOGCJUMygkI/DON1RaBU723Y1YUXk6qy+9uR0aLUleMFaArXPcP6anlC5m7yKF5PS8iRS7xn4koaxNruASAvSWKzWYli5HouOp9CExDp8uBlKRqVtRPhFI0txkq51+duxcD8=
Date: Tue, 2 Oct 2007 13:31:35 +0200
From: "Markus Gritsch" <m.gritsch@gmail.com>
To: bug-gnu-emacs@gnu.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Subject: Loading ebrowse file yields warning

Hi,

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.

Kind regards,
Markus
------- End of forwarded message -------

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Fwd: Loading ebrowse file yields warning
  2007-10-02 21:59 [m.gritsch@gmail.com: Loading ebrowse file yields warning] Richard Stallman
@ 2007-10-03  7:04 ` Stefan Monnier
  2007-10-04  2:01   ` Richard Stallman
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2007-10-03  7:04 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

> Does anyone disagree with this recommendation?

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


        Stefan

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Fwd: Loading ebrowse file yields warning
  2007-10-03  7:04 ` Fwd: Loading ebrowse file yields warning Stefan Monnier
@ 2007-10-04  2:01   ` Richard Stallman
  2007-10-05  7:15     ` Glenn Morris
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2007-10-04  2:01 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

    > 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.)

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Fwd: Loading ebrowse file yields warning
  2007-10-04  2:01   ` Richard Stallman
@ 2007-10-05  7:15     ` Glenn Morris
  2007-10-07  0:30       ` Richard Stallman
  0 siblings, 1 reply; 11+ messages in thread
From: Glenn Morris @ 2007-10-05  7:15 UTC (permalink / raw)
  To: rms; +Cc: Stefan Monnier, emacs-devel

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)?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Fwd: Loading ebrowse file yields warning
  2007-10-05  7:15     ` Glenn Morris
@ 2007-10-07  0:30       ` Richard Stallman
  2007-10-07  7:15         ` Glenn Morris
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2007-10-07  0:30 UTC (permalink / raw)
  To: Glenn Morris; +Cc: monnier, emacs-devel

    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?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Fwd: Loading ebrowse file yields warning
  2007-10-07  0:30       ` Richard Stallman
@ 2007-10-07  7:15         ` Glenn Morris
  2007-10-07 19:37           ` Eli Zaretskii
  2007-10-08 18:02           ` Richard Stallman
  0 siblings, 2 replies; 11+ messages in thread
From: Glenn Morris @ 2007-10-07  7:15 UTC (permalink / raw)
  To: emacs-devel; +Cc: monnier, Richard Stallman

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Fwd: Loading ebrowse file yields warning
  2007-10-07  7:15         ` Glenn Morris
@ 2007-10-07 19:37           ` Eli Zaretskii
  2007-10-08  7:06             ` Glenn Morris
  2007-10-08 18:02           ` Richard Stallman
  1 sibling, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2007-10-07 19:37 UTC (permalink / raw)
  To: Glenn Morris; +Cc: emacs-devel

> 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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Fwd: Loading ebrowse file yields warning
  2007-10-07 19:37           ` Eli Zaretskii
@ 2007-10-08  7:06             ` Glenn Morris
  2007-10-13 12:57               ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Glenn Morris @ 2007-10-08  7:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Fwd: Loading ebrowse file yields warning
  2007-10-07  7:15         ` Glenn Morris
  2007-10-07 19:37           ` Eli Zaretskii
@ 2007-10-08 18:02           ` Richard Stallman
  2007-10-08 18:37             ` Robert J. Chassell
  1 sibling, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2007-10-08 18:02 UTC (permalink / raw)
  To: Glenn Morris; +Cc: monnier, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Fwd: Loading ebrowse file yields warning
  2007-10-08 18:02           ` Richard Stallman
@ 2007-10-08 18:37             ` Robert J. Chassell
  0 siblings, 0 replies; 11+ messages in thread
From: Robert J. Chassell @ 2007-10-08 18:37 UTC (permalink / raw)
  To: emacs-devel

   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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Fwd: Loading ebrowse file yields warning
  2007-10-08  7:06             ` Glenn Morris
@ 2007-10-13 12:57               ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2007-10-13 12:57 UTC (permalink / raw)
  To: Glenn Morris; +Cc: emacs-devel

> 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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2007-10-13 12:57 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-02 21:59 [m.gritsch@gmail.com: Loading ebrowse file yields warning] Richard Stallman
2007-10-03  7:04 ` Fwd: Loading ebrowse file yields warning Stefan Monnier
2007-10-04  2:01   ` Richard Stallman
2007-10-05  7:15     ` Glenn Morris
2007-10-07  0:30       ` Richard Stallman
2007-10-07  7:15         ` Glenn Morris
2007-10-07 19:37           ` Eli Zaretskii
2007-10-08  7:06             ` Glenn Morris
2007-10-13 12:57               ` Eli Zaretskii
2007-10-08 18:02           ` Richard Stallman
2007-10-08 18:37             ` Robert J. Chassell

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).