issues with read-only summary buffers

issues with read-only summary buffers

[Wes Hardaker]

So, a [long] while back I upgraded (to
f20fa68cc7faa7a6b5d3a89592040852b06203b3) and also switched from XEmacs
to Emacs (which is a story in itself).  Ever since then when I responded
to certain mail messages (without a pattern I could find) it would stop
supercite from properly quoting the message with a "buffer is read-only"
error, and I *think* was the summary buffer but I can't remember but I
think it's related to today's problem.  I wasn't ever sure the problem
wasn't my own, so I haven't reported it until now.

Today (now 1b90ff07f0a40dac64331d4871045af1c681fc01) while trying to
save some articles to a file using c-o I got the exact same error.  It
*seems* that the error is triggering on the top line in a thread, but
not the sub-articles.  Don't quote me on that though as it's an
experiment with about 3 data points.

I'd try and find out where the errors are getting generated from, but
(setq debug-on-error t) doesn't seem to consider read-only violations as
errors, so I can't get a stack trace.  Anyone know how to accomplish
getting a stack trace for read-only errors?

-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: issues with read-only summary buffers

[Wes Hardaker]

>>>>> On Mon, 07 Feb 2011 13:18:31 -0800, Wes Hardaker <wes@hardakers.net> said:

WH> It *seems* that the error is triggering on the top line in a thread,
WH> but not the sub-articles.  Don't quote me on that though as it's an
WH> experiment with about 3 data points.

With a few more data points it seems it's common to be there, but I
found one top-level thread message that didn't trigger it.
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: issues with read-only summary buffers

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On Mon, Feb 07 2011, Wes Hardaker wrote:

> I'd try and find out where the errors are getting generated from, but
> (setq debug-on-error t) doesn't seem to consider read-only violations as
> errors, so I can't get a stack trace.  Anyone know how to accomplish
> getting a stack trace for read-only errors?

Remove read-only from `debug-ignored-errors'.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: issues with read-only summary buffers

[Wes Hardaker]

>>>>> On Tue, 08 Feb 2011 11:03:59 +0100, Julien Danjou <julien@danjou.info> said:

>> I'd try and find out where the errors are getting generated from, but
>> (setq debug-on-error t) doesn't seem to consider read-only violations as
>> errors, so I can't get a stack trace.  Anyone know how to accomplish
>> getting a stack trace for read-only errors?

JD> Remove read-only from `debug-ignored-errors'.

Ah ha!  Thanks!
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: issues with read-only summary buffers

[Wes Hardaker]

>>>>> On Tue, 08 Feb 2011 11:42:09 -0800, Wes Hardaker <wes@hardakers.net> said:

>>>>> On Tue, 08 Feb 2011 11:03:59 +0100, Julien Danjou <julien@danjou.info> said:
>>> I'd try and find out where the errors are getting generated from, but
>>> (setq debug-on-error t) doesn't seem to consider read-only violations as
>>> errors, so I can't get a stack trace.  Anyone know how to accomplish
>>> getting a stack trace for read-only errors?

JD> Remove read-only from `debug-ignored-errors'.

WH> Ah ha!  Thanks!

Drat.  It is my code (my gnus-highlight code that was never integrated
into the main release but I live by it).

The question is, why is placing a text-property on existing text
triggering a read-only error.  Grumble.

Debugger entered--Lisp error: (buffer-read-only #<buffer *Summary nnimap+hardakers:ucd-snmp.mail*>)
  gnus-put-text-property(56 60 face gnus-highlight-autoface-bg-\#c0c0ff)
  gnus-put-text-property-excluding-characters-with-faces(56 60 face gnus-highlight-autoface-bg-\#c0c0ff)
  #[(def) "\b?\205^\306	@!\205^	A;\203\0\307	ABC\202\0	A\310\n\236A\206%\311\224\206+\312 \310\n\236A\2064\311\225\206:\313 \314\n\236\211\203K\315A!\210\202T\316\v\f\317\320\n!$\210\300\n\236\205]\321\211+\207" [stop def facedata start end result looking-at bg match 1 point-at-bol point-at-eol sub gnus-highlight-line-by-expression gnus-put-text-property-excluding-characters-with-faces face gnus-highlight-get-face t] 6]((".*\\(snmp\\)" . "#c0c0ff"))
  mapcar(#[(def) "\b?\205^\306	@!\205^	A;\203\0\307	ABC\202\0	A\310\n\236A\206%\311\224\206+\312 \310\n\236A\2064\311\225\206:\313 \314\n\236\211\203K\315A!\210\202T\316\v\f\317\320\n!$\210\300\n\236\205]\321\211+\207" [stop def facedata start end result looking-at bg match 1 point-at-bol point-at-eol sub gnus-highlight-line-by-expression gnus-put-text-property-excluding-characters-with-faces face gnus-highlight-get-face t] 6] ((".*\\(teststring\\)" (fg . "blue2") (bg . "green1")) ("^*" . "green") ("^=>" . "#ffdddd") ("^......[^EOR].^[^[]*\\[\\([^]]+\\)\\]" (bg . "yellow")) ("^......[^EOR]./[^[]*\\[\\([^]]+\\)\\]" (fg . "brown2")) ("^......[^EOR].\\+[^[]*\\[\\([^]]+\\)\\]" . "#b0e0ff") ("^\\(......\\).*no-99$" (bg . "yellow3")) ("^\\(......\\).*no$" (bg . "yellow")) ("^\\(......\\).*ham(-99|)$" (bg . "#90d0c0")) ("^\\(......\\).*spam(-99|)$" (bg . "orange")) (".*\\(\\[Closed\\]\\)" (bg . "orange")) (".*\\(snmp\\)" . "#c0c0ff")))
  gnus-highlight-line-by-expression()
  run-hooks(gnus-summary-update-hook)
  apply(run-hooks gnus-summary-update-hook)

-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/