* forward-paragraph
@ 1999-06-16 16:13 Michael Cook
1999-06-24 15:15 ` forward-paragraph Michael Cook
0 siblings, 1 reply; 5+ messages in thread
From: Michael Cook @ 1999-06-16 16:13 UTC (permalink / raw)
In pgnus-0.88, forward-paragraph in *Article* buffers seems to
behave more like forward-line (except around blank lines, where it
tends to move forward multiple lines).
The paragraph-start and paragraph-separate settings seem to be the
same as the have always been.
paragraph-start's value is
"[ \n\f]"
paragraph-separate's value is
"[ \f]*$"
Anyone understand this new odd behavior?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: forward-paragraph
1999-06-16 16:13 forward-paragraph Michael Cook
@ 1999-06-24 15:15 ` Michael Cook
1999-07-03 9:55 ` forward-paragraph Lars Magne Ingebrigtsen
0 siblings, 1 reply; 5+ messages in thread
From: Michael Cook @ 1999-06-24 15:15 UTC (permalink / raw)
> In pgnus-0.88, forward-paragraph in *Article* buffers seems to
> behave more like forward-line (except around blank lines, where it
> tends to move forward multiple lines).
>
> The paragraph-start and paragraph-separate settings seem to be the
> same as the have always been.
>
> paragraph-start's value is
> "[ \n\f]"
> paragraph-separate's value is
> "[ \f]*$"
>
> Anyone understand this new odd behavior?
More data... When this odd behavior starts happening, if I exit
from gnus (don't need to exit from emacs), and restart gnus, the
problem goes away. I'm running GNU Emacs 20.3.1.
M.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: forward-paragraph
1999-06-24 15:15 ` forward-paragraph Michael Cook
@ 1999-07-03 9:55 ` Lars Magne Ingebrigtsen
1999-07-28 18:00 ` forward-paragraph Michael Cook
0 siblings, 1 reply; 5+ messages in thread
From: Lars Magne Ingebrigtsen @ 1999-07-03 9:55 UTC (permalink / raw)
Michael Cook <cook@sightpath.com> writes:
> More data... When this odd behavior starts happening, if I exit
> from gnus (don't need to exit from emacs), and restart gnus, the
> problem goes away. I'm running GNU Emacs 20.3.1.
The only thing that sets the variable in question is message.el, and
it makes it buffer-local first. Do you have any hooks that set it or
something?
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: forward-paragraph
1999-07-03 9:55 ` forward-paragraph Lars Magne Ingebrigtsen
@ 1999-07-28 18:00 ` Michael Cook
1999-07-30 15:15 ` forward-paragraph Michael Cook
0 siblings, 1 reply; 5+ messages in thread
From: Michael Cook @ 1999-07-28 18:00 UTC (permalink / raw)
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> > More data... When this odd behavior starts happening, if I exit
> > from gnus (don't need to exit from emacs), and restart gnus, the
> > problem goes away. I'm running GNU Emacs 20.3.1.
>
> The only thing that sets the variable in question is message.el, and
> it makes it buffer-local first. Do you have any hooks that set it or
> something?
It turns out that `fill-prefix' is causing forward-paragraph to
misbehave. In the *Article* buffer, `fill-prefix' has acquired a
buffer-local value of " " (i.e., several spaces).
By quitting and restarting gnus, I apparently force gnus to destroy
and recreate the *Article* buffer, thereby discarding the
buffer-local value.
Looking in w3-display.el, I see this code:
(defsubst w3-set-fill-prefix-length (len)
(setq fill-prefix (if (< len (- (or w3-strict-width (window-width)) 4))
(w3-get-pad-string len)
(url-warn
'html
"Runaway indentation! Too deep for window width!")
fill-prefix)))
This would be consistent with the pattern I think I've been seeing:
that forward-paragraph ceases to work right in all articles after
viewing any HTML article.
I've noticed in other situations that setting buffer-local variables
in the *Article* buffer has a kind of lingering effect.
So, here's a question: When gnus starts "rendering" an article into
an *Article* buffer, shouldn't gnus first kill-all-local-variables?
Perhaps this:
--- gnus-art.el.~1~ Fri Jul 9 18:22:56 1999
+++ gnus-art.el Wed Jul 28 13:57:20 1999
@@ -2520,6 +2520,7 @@
(current-buffer))
(save-excursion
(set-buffer (gnus-get-buffer-create name))
+ (kill-all-local-variables)
(gnus-article-mode)
(make-local-variable 'gnus-summary-buffer)
(gnus-summary-set-local-parameters gnus-newsgroup-name)
M.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: forward-paragraph
1999-07-28 18:00 ` forward-paragraph Michael Cook
@ 1999-07-30 15:15 ` Michael Cook
0 siblings, 0 replies; 5+ messages in thread
From: Michael Cook @ 1999-07-30 15:15 UTC (permalink / raw)
I wrote:
> When gnus starts "rendering" an article into
> an *Article* buffer, shouldn't gnus first kill-all-local-variables?
> Perhaps this:
>
> --- gnus-art.el.~1~ Fri Jul 9 18:22:56 1999
> +++ gnus-art.el Wed Jul 28 13:57:20 1999
> @@ -2520,6 +2520,7 @@
> (current-buffer))
> (save-excursion
> (set-buffer (gnus-get-buffer-create name))
> + (kill-all-local-variables)
> (gnus-article-mode)
> (make-local-variable 'gnus-summary-buffer)
> (gnus-summary-set-local-parameters gnus-newsgroup-name)
That change is definitely wrong (kill-all-local-variables will have
no effect there). This is what I intended:
--- gnus-art.el.~1~ Fri Jul 9 18:22:56 1999
+++ gnus-art.el Fri Jul 30 11:09:04 1999
@@ -2513,6 +2513,7 @@
(if (get-buffer name)
(save-excursion
(set-buffer name)
+ (kill-all-local-variables)
(buffer-disable-undo)
(setq buffer-read-only t)
(unless (eq major-mode 'gnus-article-mode)
M.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-07-30 15:15 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-06-16 16:13 forward-paragraph Michael Cook
1999-06-24 15:15 ` forward-paragraph Michael Cook
1999-07-03 9:55 ` forward-paragraph Lars Magne Ingebrigtsen
1999-07-28 18:00 ` forward-paragraph Michael Cook
1999-07-30 15:15 ` forward-paragraph Michael Cook
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 NNTP newsgroup(s).