Bad cursor postion when dormat theads activate

Bad cursor postion when dormat theads activate

[Harry Putnam]

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

I've been noticing this behavior thru several cvs updates and posted
here about it a while back.

I probably did a poor job of describing what I see, so trying again
here. 

After ticking all messages in a thread dormant, when a new message
appears in that thread I see something unusual happen when opening the
group.

If the new message gets threaded with the dormant thread and is the
only new stuff that has arrived or is first in the summary buffer view,
then the threaded subject becomes visible and in dormant face but
instead of the new message appearing below the last dormant message
the thread is collapsed and the cursor is clear over to the right hand
side of the subject line.

Reading what I've written so far seems really confusing... sorry my
prose skills are so lacking.... but I've inlined a screen shot showing
the phenomena... it didn't reproduce all that well but I hope you can
get the idea.

In the screen shot, that summary buffer has just been opened and there
is a new message under the dormant ticked previous messages.

I've never seen this before a couple of mnths ago in many yrs of using
gnus. I'm not sure what in my config may be causing this but have
posted  my ~/.gnus at the URL below.

I cleaned it up a bit by deleting many ancient and other comments but
there is no doubt still plenty of stuff in there that doesn't need to
be. Maybe something there is causing the problem?

  www.jtan.com/~reader/gnus.txt

Here is the screen shot:


[-- Attachment #2: gnus2.png --]
[-- Type: image/png, Size: 64276 bytes --]

Re: Bad cursor postion when dormat theads activate

[Tassilo Horn]

On Wednesday 24 February 2010 20:38:47 Harry Putnam wrote:

> I've never seen this before a couple of mnths ago in many yrs of
> using gnus. I'm not sure what in my config may be causing this but
> have posted  my ~/.gnus at the URL below.

The problem is not related to dormant or ticked articles, but it's an 
ugly side-effect of the latest changes to the summary buffer code.  It 
used to provide the thread folding with a feature called selective 
display, which is deprecated now.  Therefore, gnus uses overlays for 
that task since some few month, and that's where the problems you 
describe started.

That being said, I dunno if something can be done about this...

Bye,
Tassilo

Re: Bad cursor postion when dormat theads activate

[Harry Putnam]

Tassilo Horn <tassilo@member.fsf.org> writes:

> On Wednesday 24 February 2010 20:38:47 Harry Putnam wrote:
>
>> I've never seen this before a couple of mnths ago in many yrs of
>> using gnus. I'm not sure what in my config may be causing this but
>> have posted  my ~/.gnus at the URL below.
>
> The problem is not related to dormant or ticked articles, but it's an 
> ugly side-effect of the latest changes to the summary buffer code.  It 
> used to provide the thread folding with a feature called selective 
> display, which is deprecated now.  Therefore, gnus uses overlays for 
> that task since some few month, and that's where the problems you 
> describe started.

Good to know ... thanks

Do you know why it was deprecated?  Does it interfere with other nifty
features?  

> That being said, I dunno if something can be done about this...

Well, its definitely well above my abilities...

Re: Bad cursor postion when dormat theads activate

[Tassilo Horn]

On Wednesday 24 February 2010 21:25:10 Harry Putnam wrote:

> Do you know why it was deprecated?  Does it interfere with other
> nifty features?

No idea.  And even the docs (Emacs or Elisp info) mention that it's 
deprecated.  It's just marked, the "old style" of hiding buffer 
contents.

But, well, I guess the emacs maintainers have good reasons for that.

Bye,
Tassilo

Re: Bad cursor postion when dormat theads activate

[Andreas Schwab]

Tassilo Horn <tassilo@member.fsf.org> writes:

> That being said, I dunno if something can be done about this...

Basically you need to fix gnus-forward-line-ignore-invisible to handle
more cases, and perhaps use it in more places to replace forward-line.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bad cursor postion when dormat theads activate

[Jose Antonio Ortega Ruiz]

Hi Andreas,

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> 
> Tassilo Horn <tassilo <at> member.fsf.org> writes:
> 
> > That being said, I dunno if something can be done about this...
> 
> Basically you need to fix gnus-forward-line-ignore-invisible to handle
> more cases, and perhaps use it in more places to replace forward-line.
> 

i would like to try to fix this problem (i hit it quite often due to the way i
use gnus), but is not apparent to me what those additional cases are. would you
have any more hints as to what is needed?

thanks!
jao

Re: Bad cursor postion when dormat theads activate

[Andreas Schwab]

Jose Antonio Ortega Ruiz <jao@gnu.org> writes:

> Hi Andreas,
>
> Andreas Schwab <schwab <at> linux-m68k.org> writes:
>
>> 
>> Tassilo Horn <tassilo <at> member.fsf.org> writes:
>> 
>> > That being said, I dunno if something can be done about this...
>> 
>> Basically you need to fix gnus-forward-line-ignore-invisible to handle
>> more cases, and perhaps use it in more places to replace forward-line.
>> 
>
> i would like to try to fix this problem (i hit it quite often due to the way i
> use gnus), but is not apparent to me what those additional cases are. would you
> have any more hints as to what is needed?

You'll have to trace it to see what arguments it needs to handle, and
how the behaviour differs from forward-line.  Most likely N = 0 is
problematic.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bad cursor postion when dormat theads activate

[Jose A. Ortega Ruiz]

Andreas Schwab <schwab@linux-m68k.org> writes:

> You'll have to trace it to see what arguments it needs to handle, and
> how the behaviour differs from forward-line.  Most likely N = 0 is
> problematic.

Thanks for the pointers. I've been trying to solve the problem without
success so far, but i do think that it has to do with dormant (ticked)
articles. There's in fact a very easy way to reproduce it, at least
here:

  1) Put yourself at the beginning of a thread with 2 unread messages
  2) T s/ T h work as expected, no surprises
  3) With the thread hidden, move to the end of the line with C-e:
    point moves not to the end of line, but to the end of the whole
    threads; i.e., you see it *after* the ellipsis (...)
  4) T s won't show the thread: point moves right before the ellipsis
    and the thread remains hidden
  5) If you T s again, now the thread is shown

If now you tick (U) the first article in the thread, exit the group and
re-enter it, you'll see the point is in state (3): seems like the fact
that the article is ticked causes gnus-summary-read-group to position
the point at the end of its thread (after or before hiding all threads,
i'm not sure), so that gnus-summary-show-thread does not have the
desired effect.

Unfortunately, the code is a bit convoluted, and it's not easy for me to
see where/how this state is reached. So i thought that maybe explaining
the situation would ring a bell to someone more familiar with Gnus code.

Thanks!
jao
--
The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners - Ernst Jan Plugge

Re: Bad cursor postion when dormat theads activate

[Harry Putnam]

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

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> If now you tick (U) the first article in the thread, exit the group and
> re-enter it, you'll see the point is in state (3): seems like the fact
> that the article is ticked causes gnus-summary-read-group to position
> the point at the end of its thread (after or before hiding all threads,
> i'm not sure), so that gnus-summary-show-thread does not have the
> desired effect.

I'm not sharp enough about this to help much but as OP, I thought I'd
add another screen shot.

This part of the problem is somewhat disconcerting and confusing.

I normally read news with a 2 buffer setup, split between summary
buffer and article buffer.

I run with `gnus-summary-hide-all-threads' on by default. 

Opening a group in much the same way as you describe above.  There are
many ticked dormant messages in the thread and only 1 new one has arrived.

Opening the group it so happens a thread with ticked messages is first
with a new message. As you can barely see in the screen shot, point
has rushed to the end of the subject line (but not past the ellipsis
as you've mentioned).

Normally with a new message in a thread with dormant messages the
thread should open and show the new message subject line in summary
buffer.

But with the recent changes in gnus (now a few mnths ago I think),
the thread has not opened to show the new message as it should.

If I press `n', without moving point, (`n' to move to first new
message, my normal way of reading) the new message inside the ticked
thread is skipped completely, and point jumps to the next newest
message.

You would never know the new message was there at all.

If I press `enter', then the new message inside the ticked thread is
displayed in the article buffer, but is still hidden in summary.

(In the attached screenshot, I've opened the group, and pressed enter.
As you can see, the message is being displayed in article buffer, but
still hidden in summary.)

So unless I move point back to the left before doing anything else,
gnus will display behavior that is very bad for a newsreader, either
it skips the first new message and actually by-passes it (in the case
of pressing `n') or it opens the message in article buffer but still
not in summary buffer. So in the latter case you cannot see the
Summary buffer subject line of the acticle that is displayed in
`article' buffer at all.


[-- Attachment #2: gnusthreads.png --]
[-- Type: image/png, Size: 63423 bytes --]

Re: Bad cursor postion when dormat theads activate

[Jose A. Ortega Ruiz]

Harry Putnam <reader@newsguy.com> writes:


[...]

> Opening the group it so happens a thread with ticked messages is first
> with a new message. As you can barely see in the screen shot, point
> has rushed to the end of the subject line (but not past the ellipsis
> as you've mentioned).

Sorry, i misspoke: the point is right before the ellipsis, as you say.
It's as if one has gone the the "end of line" (past the ellipsis) and
called gnus-summary-show-thread (or T s), which, instead of showing the
thread, just moves the point from after to before the ellipsis.

I thought that the two behaviours might be connected. At any rate, if
i'm in a summary line with a folded thread and i do a C-e, i would
expect a subsequent Ts to show the thread.


[... very accurate description of the problems ...]

And yes, i can confirm that Gnus behaves for me exactly as you describe
in the rest of your post.

Cheers,
jao

Re: Bad cursor postion when dormat theads activate

[Jose A. Ortega Ruiz]

Hi,

This is an update, and perhaps a fix, for the bug mentioned in the
subject, that precludes expansion of threads with ticked articles upon
entering a group...

On Sun, Mar 28 2010, Jose Antonio Ortega Ruiz wrote:

> Hi Andreas,
>
> Andreas Schwab <schwab <at> linux-m68k.org> writes:
>
>> 
>> Tassilo Horn <tassilo <at> member.fsf.org> writes:
>> 
>> > That being said, I dunno if something can be done about this...
>> 
>> Basically you need to fix gnus-forward-line-ignore-invisible to handle
>> more cases, and perhaps use it in more places to replace forward-line.
>> 
>
> i would like to try to fix this problem (i hit it quite often due to the way i
> use gnus), but is not apparent to me what those additional cases are. would you
> have any more hints as to what is needed?

I'm not sure this is the correct fix, but maybe this will provide a hint
of what's going on. The problem seems to be that, upon entering a group
and with all threads hidden, gnus-summary-show-thread doesn't work.
Here's the code for this function:

  (defun gnus-summary-show-thread ()
  "Show thread subtrees.
Returns nil if no thread was there to be shown."
  (interactive)
  (let* ((orig (point))
	 (end (point-at-eol))
	 ;; Leave point at bol
	 (beg (progn (beginning-of-line) (if (bobp) (point) (1- (point)))))
	 (eoi (when (eq (get-char-property end 'invisible) 'gnus-sum)
		(if (fboundp 'next-single-char-property-change)
		    (or (next-single-char-property-change end 'invisible)
			(point-max))
		  (while (progn
			   (end-of-line 2)
			   (and (not (eobp))
				(eq (get-char-property (point) 'invisible)
				    'gnus-sum))))
		  (point)))))
    (when eoi
      (gnus-remove-overlays beg eoi 'invisible 'gnus-sum)
      (goto-char orig)
      (gnus-summary-position-point)
      eoi)))

The reason the thread is not expanded, is that the guard of the `when'
form that evaluates `eoi', that is

   (eq (get-char-property end 'invisible) 'gnus-sum)

always evaluates to false; i.e., at `end' (which is (point-at-eol)) the
invisible char property is never set. If i change `end' to 
(1- (point-at-eol)), the thread is expanded and the problem seems to go
away. If this is a proper fix, that would mean that there is an
off-by-one error in the computation of `end', but i'm not sure this
change is not having undesirable side-effects elsewhere. The other
possibility i can think off is that the code responsible for setting the
'invisible property to 'gnus-sum is the one having the off-by-one error
(and hence the one to be fixed), but i haven't had the time to locate
that code. Maybe someone privy with that code could chime in?

Thanks!
jao

Re: Bad cursor postion when dormat theads activate

[Jose A. Ortega Ruiz]

As a follow-up to my previous post, i'm using the now the following
workaround for the problem:

--8<---------------cut here---------------start------------->8---
(defsubst gnus-summary--inv (p)                            ;; **
  (and (eq (get-char-property p 'invisible) 'gnus-sum) p)) ;; **

(defun gnus-summary-show-thread ()
  "Show thread subtrees.
Returns nil if no thread was there to be shown."
  (interactive)
  (let* ((orig (point))                                    ;; **
	 (end (point-at-eol))
         (end (or (gnus-summary--inv end)                  ;; **
                  (gnus-summary--inv (1- end))))           ;; **
	 ;; Leave point at bol
	 (beg (progn (beginning-of-line) (if (bobp) (point) (1- (point)))))
	 (eoi (when end                                    ;; **
		(if (fboundp 'next-single-char-property-change)
		    (or (next-single-char-property-change end 'invisible)
			(point-max))
		  (while (progn
			   (end-of-line 2)
			   (and (not (eobp))
				(eq (get-char-property (point) 'invisible)
				    'gnus-sum))))
		  (point)))))
    (when eoi
      (gnus-remove-overlays beg eoi 'invisible 'gnus-sum)
      (goto-char orig)
      (gnus-summary-position-point)
      eoi)))
--8<---------------cut here---------------end--------------->8---

(I just put that at the end of my gnus init file; the lines marked with
** are the ones i've modified from what's in gnus-sum.el). It seems to
fix the issue without causing undesired side-effects. I still think that
this is a workaround and not a real fix, but it works for me.

Cheers,
jao

Re: Bad cursor postion when dormat theads activate

[Ted Zlatanov]

On Thu, 10 Jun 2010 04:01:04 +0200 "Jose A. Ortega Ruiz" <jao@gnu.org> wrote: 

jao> As a follow-up to my previous post, i'm using the now the following
jao> workaround for the problem:
...
jao> (I just put that at the end of my gnus init file; the lines marked with
jao> ** are the ones i've modified from what's in gnus-sum.el). It seems to
jao> fix the issue without causing undesired side-effects. I still think that
jao> this is a workaround and not a real fix, but it works for me.

It would be great if someone with knowledge of the display system could
comment.  FWIW I'm in favor of your fix but would like to understand why
it works and if there's something fundamentally broken.

Ted