Strange 'n' behavior

Strange 'n' behavior

[Jake Colman]

When I press 'n' in a Summary Buffer I would expect to move to the next
unread message in the thread or the first unread message in the next thread.
Instead, after reading all messages in a thread, an 'n' command moves me to
the earliest unread message of the Summary Buffer - essentially moving me
backwards instead of forwards.  Is this to be expected?

Configuration:

XEmacs 21.0 (sparc-sun-solaris2.4) of Wed Jul 22 1998 on macaroon

Gnus v5.6.22; nntp 5.0; nnml 1.0; nnmh 1.0; nndoc 1.0; nndraft 1.0; 
        nnfolder 1.0; nnimap 0.3.13

--
Jake Colman                     

Principia Partners LLC                  Phone: (201) 946-0300
Harborside Financial Center               Fax: (201) 946-0320
902 Plaza II                           Beeper: (800) 505-2795
Jersey City, NJ 07311                  E-mail: colman@ppllc.com
                                       E-mail: jcolman@jnc.com
                                          web: http://www.ppllc.com

Re: Strange 'n' behavior

[Harry Putnam]

Jake Colman <colman@ppllc.com> writes:

> When I press 'n' in a Summary Buffer I would expect to move to the next
> unread message in the thread or the first unread message in the next thread.
> Instead, after reading all messages in a thread, an 'n' command moves me to
> the earliest unread message of the Summary Buffer - essentially moving me
> backwards instead of forwards.  Is this to be expected?
> 

I had that once -- it took me while to see I had capslock on.

-- 

Harry Putnam  reader@newsguy.com

Re: Strange 'n' behavior

[Jake Colman]

>>>>> "Harry" == Harry Putnam <reader@newsguy.com> writes:

   Harry> Jake Colman <colman@ppllc.com> writes:
   >> When I press 'n' in a Summary Buffer I would expect to move to the next
   >> unread message in the thread or the first unread message in the next thread.
   >> Instead, after reading all messages in a thread, an 'n' command moves me to
   >> the earliest unread message of the Summary Buffer - essentially moving me
   >> backwards instead of forwards.  Is this to be expected?
   >> 

   Harry> I had that once -- it took me while to see I had capslock on.

   Harry> -- 

   Harry> Harry Putnam  reader@newsguy.com

Nope.  That's not it.  Nice try, though... :-)

-- 
Jake Colman                     

Principia Partners LLC                  Phone: (201) 946-0300
Harborside Financial Center               Fax: (201) 946-0320
902 Plaza II                           Beeper: (800) 505-2795
Jersey City, NJ 07311                  E-mail: colman@ppllc.com
                                       E-mail: jcolman@jnc.com
                                          web: http://www.ppllc.com

Re: Strange 'n' behavior

[Lars Magne Ingebrigtsen]

Jake Colman <colman@ppllc.com> writes:

> When I press 'n' in a Summary Buffer I would expect to move to the next
> unread message in the thread or the first unread message in the next thread.
> Instead, after reading all messages in a thread, an 'n' command moves me to
> the earliest unread message of the Summary Buffer - essentially moving me
> backwards instead of forwards.  Is this to be expected?

It is expected if you have set any of the movement variables that give
you this result.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Strange 'n' behavior

[Kai Grossjohann]

>>>>> Jake Colman <colman@ppllc.com> writes:

  > When I press 'n' in a Summary Buffer I would expect to move to the
  > next unread message in the thread or the first unread message in
  > the next thread.  Instead, after reading all messages in a thread,
  > an 'n' command moves me to the earliest unread message of the
  > Summary Buffer - essentially moving me backwards instead of
  > forwards.  Is this to be expected?

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > It is expected if you have set any of the movement variables that
  > give you this result.

Which variable would tell `n' to go backwards?  I used M-x apropos RET
gnus.*summ.*\(goto\|move\) RET and didn't find any.

I know about gnus-summary-goto-unread, but that would tell `n' to move
to the *next* unread message, not to the *first*!

I think Jake is saying that `n' behaves like `.' in some circumstances.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Strange 'n' behavior

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:

> Which variable would tell `n' to go backwards?  I used M-x apropos RET
> gnus.*summ.*\(goto\|move\) RET and didn't find any.

Let's see...

Ah; there it was: `gnus-auto-select-same'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Strange 'n' behavior

[Karl Kleinpaste]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:
>> Which variable would tell `n' to go backwards?  I used M-x apropos RET
>> gnus.*summ.*\(goto\|move\) RET and didn't find any.

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Ah; there it was: `gnus-auto-select-same'.

"`gnus-auto-select-same'
     If non-`nil', all the movement commands will try to go to the next
     article with the same subject as the current.  ("Same" here might
     mean "roughly equal".  See `gnus-summary-gather-subject-limit' for
     details (*note Customizing Threading::.).)  This variable is not
     particularly useful if you use a threaded display."

I don't understand.  The point Jake was making is that, when finishing
with one thread, within which this variable seems to keep you
in-thread, the subsequent choice by `n' is to go to the _earliest_
unread article, rather than moving downward for a _following_ unread
article beyond the current-but-now-finished thread.  Presumably,
"downward" would include wraparound back to the top if there aren't
any more unread articles below point, but there are some above.

Perhaps there is a semantic confusion as to the concept of "next,"
i.e., Jake (and others) want "next" to be "farther down, with
wraparound," but Gnus currently implements "next" as "follow the
thread, but then start over from the top."

The info blurb even says, "not particularly useful if you use a
threaded display."

Re: Strange 'n' behavior

[Jake Colman]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:
    >> Which variable would tell `n' to go backwards?  I used M-x apropos RET
    >> gnus.*summ.*\(goto\|move\) RET and didn't find any.

    Lars> Let's see...

    Lars> Ah; there it was: `gnus-auto-select-same'.

gnus-auto-select-same's value is 
nil

Documentation:
*If non-nil, select the next article with the same subject.

So if it is nil, it searches backwards for the next unread message?  I am
finding that within a thread it searches forwards anyway!  

And if it is non-nil, but you've reached the end of the thread, what would it
do next?  Give you the next unread message of the next thread or search
backwards again?

-- 
Jake Colman                     

Principia Partners LLC                  Phone: (201) 946-0300
Harborside Financial Center               Fax: (201) 946-0320
902 Plaza II                           Beeper: (800) 505-2795
Jersey City, NJ 07311                  E-mail: colman@ppllc.com
                                       E-mail: jcolman@jnc.com
                                          web: http://www.ppllc.com

Re: Strange 'n' behavior

[Kai Grossjohann]

>>>>> Jake Colman <colman@ppllc.com> writes:

  > So if it is nil, it searches backwards for the next unread
  > message?  I am finding that within a thread it searches forwards
  > anyway!

No, if t, it selects the next msg with a similar subject, if nil, it
selects the next msg with any subject.

I think there's still a misunderstanding between you and Lars.  I
think I know what you're trying to say but don't know how to explain
to Lars...

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Strange 'n' behavior

[Jake Colman]

>>>>> "Karl" == Karl Kleinpaste <karl@jprc.com> writes:

    Karl> Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:
    >>> Which variable would tell `n' to go backwards?  I used M-x apropos
    >>> RET gnus.*summ.*\(goto\|move\) RET and didn't find any.

    Karl> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
    >> Ah; there it was: `gnus-auto-select-same'.

    Karl> "`gnus-auto-select-same' If non-`nil', all the movement commands
    Karl> will try to go to the next article with the same subject as the
    Karl> current.  ("Same" here might mean "roughly equal".  See
    Karl> `gnus-summary-gather-subject-limit' for details (*note Customizing
    Karl> Threading::.).)  This variable is not particularly useful if you
    Karl> use a threaded display."

    Karl> I don't understand.  The point Jake was making is that, when
    Karl> finishing with one thread, within which this variable seems to keep
    Karl> you in-thread, the subsequent choice by `n' is to go to the
    Karl> _earliest_ unread article, rather than moving downward for a
    Karl> _following_ unread article beyond the current-but-now-finished
    Karl> thread.  Presumably, "downward" would include wraparound back to
    Karl> the top if there aren't any more unread articles below point, but
    Karl> there are some above.

    Karl> Perhaps there is a semantic confusion as to the concept of "next,"
    Karl> i.e., Jake (and others) want "next" to be "farther down, with
    Karl> wraparound," but Gnus currently implements "next" as "follow the
    Karl> thread, but then start over from the top."

    Karl> The info blurb even says, "not particularly useful if you use a
    Karl> threaded display."

BINGO!  You've made my point exactly.  I use a threaded display. I want
"next" to mean follow the messages in this thread and continue on to the next
thread BELOW this one when viewing the summary buffer.  Not to search again
from the top of the summary buffer and find the next, EARLIEST, unread
thread.  The current behavior is to read next messages within the current
thread but to start again from the top once this thread is completed.

So, can I get the behavior I am looking for by tweaking something or is this
the way it is supposed to be?

-- 
Jake Colman                     

Principia Partners LLC                  Phone: (201) 946-0300
Harborside Financial Center               Fax: (201) 946-0320
902 Plaza II                           Beeper: (800) 505-2795
Jersey City, NJ 07311                  E-mail: colman@ppllc.com
                                       E-mail: jcolman@jnc.com
                                          web: http://www.ppllc.com

Re: Strange 'n' behavior

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@jprc.com> writes:

> "`gnus-auto-select-same'
>      If non-`nil', all the movement commands will try to go to the next
>      article with the same subject as the current.  ("Same" here might
>      mean "roughly equal".  See `gnus-summary-gather-subject-limit' for
>      details (*note Customizing Threading::.).)  This variable is not
>      particularly useful if you use a threaded display."

I've now fixed the manual.

"If there are no more articles with the same subject, go to the first
unread article."

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Strange 'n' behavior

[Lars Magne Ingebrigtsen]

Jake Colman <colman@ppllc.com> writes:

>     Lars> Ah; there it was: `gnus-auto-select-same'.
> 
> gnus-auto-select-same's value is 
> nil

It's not that, then.  Hm.  Could you send a bug report with `M-x gnus-bug'?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen