* Bad cursor postion when dormat theads activate @ 2010-02-24 19:38 Harry Putnam 2010-02-24 20:08 ` Tassilo Horn 0 siblings, 1 reply; 13+ messages in thread From: Harry Putnam @ 2010-02-24 19:38 UTC (permalink / raw) To: ding [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-02-24 19:38 Bad cursor postion when dormat theads activate Harry Putnam @ 2010-02-24 20:08 ` Tassilo Horn 2010-02-24 20:25 ` Harry Putnam 2010-02-24 21:47 ` Andreas Schwab 0 siblings, 2 replies; 13+ messages in thread From: Tassilo Horn @ 2010-02-24 20:08 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-02-24 20:08 ` Tassilo Horn @ 2010-02-24 20:25 ` Harry Putnam 2010-02-24 20:39 ` Tassilo Horn 2010-02-24 21:47 ` Andreas Schwab 1 sibling, 1 reply; 13+ messages in thread From: Harry Putnam @ 2010-02-24 20:25 UTC (permalink / raw) To: ding 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... ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-02-24 20:25 ` Harry Putnam @ 2010-02-24 20:39 ` Tassilo Horn 0 siblings, 0 replies; 13+ messages in thread From: Tassilo Horn @ 2010-02-24 20:39 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-02-24 20:08 ` Tassilo Horn 2010-02-24 20:25 ` Harry Putnam @ 2010-02-24 21:47 ` Andreas Schwab 2010-03-28 1:42 ` Jose Antonio Ortega Ruiz 1 sibling, 1 reply; 13+ messages in thread From: Andreas Schwab @ 2010-02-24 21:47 UTC (permalink / raw) To: Tassilo Horn; +Cc: ding 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." ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-02-24 21:47 ` Andreas Schwab @ 2010-03-28 1:42 ` Jose Antonio Ortega Ruiz 2010-03-28 14:58 ` Andreas Schwab 2010-06-08 1:06 ` Jose A. Ortega Ruiz 0 siblings, 2 replies; 13+ messages in thread From: Jose Antonio Ortega Ruiz @ 2010-03-28 1:42 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-03-28 1:42 ` Jose Antonio Ortega Ruiz @ 2010-03-28 14:58 ` Andreas Schwab 2010-03-29 20:49 ` Jose A. Ortega Ruiz 2010-06-08 1:06 ` Jose A. Ortega Ruiz 1 sibling, 1 reply; 13+ messages in thread From: Andreas Schwab @ 2010-03-28 14:58 UTC (permalink / raw) To: Jose Antonio Ortega Ruiz; +Cc: ding 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." ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-03-28 14:58 ` Andreas Schwab @ 2010-03-29 20:49 ` Jose A. Ortega Ruiz 2010-03-29 23:19 ` Harry Putnam 0 siblings, 1 reply; 13+ messages in thread From: Jose A. Ortega Ruiz @ 2010-03-29 20:49 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-03-29 20:49 ` Jose A. Ortega Ruiz @ 2010-03-29 23:19 ` Harry Putnam 2010-03-30 0:21 ` Jose A. Ortega Ruiz 0 siblings, 1 reply; 13+ messages in thread From: Harry Putnam @ 2010-03-29 23:19 UTC (permalink / raw) To: ding [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-03-29 23:19 ` Harry Putnam @ 2010-03-30 0:21 ` Jose A. Ortega Ruiz 0 siblings, 0 replies; 13+ messages in thread From: Jose A. Ortega Ruiz @ 2010-03-30 0:21 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-03-28 1:42 ` Jose Antonio Ortega Ruiz 2010-03-28 14:58 ` Andreas Schwab @ 2010-06-08 1:06 ` Jose A. Ortega Ruiz 2010-06-10 2:01 ` Jose A. Ortega Ruiz 1 sibling, 1 reply; 13+ messages in thread From: Jose A. Ortega Ruiz @ 2010-06-08 1:06 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-06-08 1:06 ` Jose A. Ortega Ruiz @ 2010-06-10 2:01 ` Jose A. Ortega Ruiz 2010-06-10 13:07 ` Ted Zlatanov 0 siblings, 1 reply; 13+ messages in thread From: Jose A. Ortega Ruiz @ 2010-06-10 2:01 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bad cursor postion when dormat theads activate 2010-06-10 2:01 ` Jose A. Ortega Ruiz @ 2010-06-10 13:07 ` Ted Zlatanov 0 siblings, 0 replies; 13+ messages in thread From: Ted Zlatanov @ 2010-06-10 13:07 UTC (permalink / raw) To: Jose A. Ortega Ruiz; +Cc: ding 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-06-10 13:07 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-02-24 19:38 Bad cursor postion when dormat theads activate Harry Putnam 2010-02-24 20:08 ` Tassilo Horn 2010-02-24 20:25 ` Harry Putnam 2010-02-24 20:39 ` Tassilo Horn 2010-02-24 21:47 ` Andreas Schwab 2010-03-28 1:42 ` Jose Antonio Ortega Ruiz 2010-03-28 14:58 ` Andreas Schwab 2010-03-29 20:49 ` Jose A. Ortega Ruiz 2010-03-29 23:19 ` Harry Putnam 2010-03-30 0:21 ` Jose A. Ortega Ruiz 2010-06-08 1:06 ` Jose A. Ortega Ruiz 2010-06-10 2:01 ` Jose A. Ortega Ruiz 2010-06-10 13:07 ` Ted Zlatanov
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).