imap-debug buffer exceeds maximum size

imap-debug buffer exceeds maximum size

[Ted Zlatanov]

If you turn imap-debug on, the imap-debug buffer keeps growing and
eventually will get to the max buffer size.  If then you try to do any
IMAP operations they will fail; currently you have to kill the
imap-debug buffer or empty it to continue IMAP usage.

I don't know what's the right fix, but I would guess removing half the
imap-debug buffer's contents (with a suitable message) would be a nice
compromise to keep the debug data.

Ted

Re: imap-debug buffer exceeds maximum size

[Ted Zlatanov]

On Tue, 08 Jan 2008 10:17:38 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> If you turn imap-debug on, the imap-debug buffer keeps growing and
TZ> eventually will get to the max buffer size.  If then you try to do any
TZ> IMAP operations they will fail; currently you have to kill the
TZ> imap-debug buffer or empty it to continue IMAP usage.

TZ> I don't know what's the right fix, but I would guess removing half the
TZ> imap-debug buffer's contents (with a suitable message) would be a nice
TZ> compromise to keep the debug data.

Anyone with an opinion?  nnimap-debug-buffer has the same problem.

Ted

Re: imap-debug buffer exceeds maximum size

[Reiner Steib]

On Tue, Jan 15 2008, Ted Zlatanov wrote:

> On Tue, 08 Jan 2008 10:17:38 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>
> TZ> If you turn imap-debug on, the imap-debug buffer keeps growing and
> TZ> eventually will get to the max buffer size.  If then you try to do any
> TZ> IMAP operations they will fail; currently you have to kill the
> TZ> imap-debug buffer or empty it to continue IMAP usage.
>
> TZ> I don't know what's the right fix, but I would guess removing half the
> TZ> imap-debug buffer's contents (with a suitable message) would be a nice
> TZ> compromise to keep the debug data.

It would be okay, I'd guess.  But the debug output is created via the
Emacs functionality `trace.el'.  I'm not familiar with this, but
I don't see a possibility to limit the output buffer.

(when imap-debug			; (untrace-all)
  (require 'trace)
  (buffer-disable-undo (get-buffer-create imap-debug-buffer))
  (mapc (lambda (f) (trace-function-background f imap-debug-buffer))
	'(
	  imap-utf7-encode
	  ;; [...]
	  imap-parse-body
	  )))

> nnimap-debug-buffer has the same problem.

Maybe `imap-log-buffer', too.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: imap-debug buffer exceeds maximum size

[Ted Zlatanov]

On Tue, 15 Jan 2008 23:59:15 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Tue, Jan 15 2008, Ted Zlatanov wrote:
>> On Tue, 08 Jan 2008 10:17:38 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>> 
TZ> If you turn imap-debug on, the imap-debug buffer keeps growing and
TZ> eventually will get to the max buffer size.  If then you try to do any
TZ> IMAP operations they will fail; currently you have to kill the
TZ> imap-debug buffer or empty it to continue IMAP usage.
>> 
TZ> I don't know what's the right fix, but I would guess removing half the
TZ> imap-debug buffer's contents (with a suitable message) would be a nice
TZ> compromise to keep the debug data.

RS> It would be okay, I'd guess.  But the debug output is created via the
RS> Emacs functionality `trace.el'.  I'm not familiar with this, but
RS> I don't see a possibility to limit the output buffer.

RS> (when imap-debug			; (untrace-all)
RS>   (require 'trace)
RS>   (buffer-disable-undo (get-buffer-create imap-debug-buffer))
RS>   (mapc (lambda (f) (trace-function-background f imap-debug-buffer))
RS> 	'(
RS> 	  imap-utf7-encode
RS> 	  ;; [...]
RS> 	  imap-parse-body
RS> 	  )))

>> nnimap-debug-buffer has the same problem.

RS> Maybe `imap-log-buffer', too.

I think this is for the Emacs developers list, since trace.el is in
their tree.

My suggestions for the fix are above; I can write a patch if it's
necessary.  Looks like trace.el:trace-make-advice() needs to be adjusted
to check the buffer size.  It could set trace-inhibit but I think
trimming the buffer is a nicer solution for the user.

Ted