Small complaint about M-g

Small complaint about M-g

[Harry Putnam]

When inside a group and wanting to rescan from source with `M-g', `ESC
g' `Z G' is it really necessary to loose all trace of what you were
doing, have the group completely reshuffled and any open but read
messages buried.

Can't we bring in new messages without all that?

Lots of times I just want to bring in a message in a certain thread and
hold my place there.

Re: Small complaint about M-g

[Jussi Yli-Urpo]

Harry Putnam <reader@newsguy.com> writes:

> When inside a group and wanting to rescan from source with `M-g', `ESC
> g' `Z G' is it really necessary to loose all trace of what you were
> doing, have the group completely reshuffled and any open but read
> messages buried.

This was one of the reasons I eventually turned off
marking selected articles automatically as read. Now in all
my mail groups I either manually mark them read one by one
or catchup whole group when I'm sure that I haven't missed
anything important. 

This way I can safely rescan group (or do something else in
some other buffer) as often I wan't and I can still see
all those mails that I haven't read yet (of course ticking
those would also work but it just too easy to forget to do).  

> Can't we bring in new messages without all that?

I have see this same question asked before. Conclusion must
have been that it's not easy to implement.

> Lots of times I just want to bring in a message in a certain thread and
> hold my place there.

Clearing mark of the current message before rescan would also
help to keep at least your current message there. Could you
do same thing for whole thread?

-- 
Jussi.

Re: Small complaint about M-g

[Chris Richards]

Jussi Yli-Urpo <jmy@h32.erkki.ton.tut.fi> writes:
> all those mails that I haven't read yet (of course ticking
> those would also work but it just too easy to forget to do).  

That's the power of gnus.  I am a recent gnus convert and I quickly
learned to 'tick' articles of relevance.  Perhaps if you didn't tick a
message, then it was not that important to begin with...

Though, I am about to write a hook to auto-cache ticked articles.  To
each his own.

Cheers,
cjr

Re: Small complaint about M-g

[Alan Shutko]

Chris Richards <cjr@netpliance.net> writes:

> Though, I am about to write a hook to auto-cache ticked articles.  To
> each his own.

(setq gnus-use-cache 't)

(gnus)Article Caching

       To turn caching on, set `gnus-use-cache' to `t'.  By default, all
    articles ticked or marked as dormant will then be copied over to your
    local cache (`gnus-cache-directory').  Whether this cache is flat or
    hierarchal is controlled by the `gnus-use-long-file-name' variable, as
    usual.


-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
262 days, 17 hours, 58 minutes, 51 till we run away.
A man's house is his hassle.

Re: Small complaint about M-g

[Harry Putnam]

Chris Richards <cjr@netpliance.net> writes:

> Jussi Yli-Urpo <jmy@h32.erkki.ton.tut.fi> writes:
> > all those mails that I haven't read yet (of course ticking
> > those would also work but it just too easy to forget to do).  
> 
> That's the power of gnus.  I am a recent gnus convert and I quickly
> learned to 'tick' articles of relevance.  Perhaps if you didn't tick a
> message, then it was not that important to begin with...

My original post was not looking for a way to `tick' articles.  I like
the way gnus hides read articles after closing a group.  What I
complained mildly about was gnus being so rowdy about doing a rescan
while inside a group.  In that instance only, I may not want read
articles to disappear.  It was that problem that Jussi's comments
addressed.

If you are a new user, you may find after lengthy usage that `ticking'
can get to be a pain in the butt.  Unless you are very judicious about
removing ticks later, then you eventually begin to accumulate vast
quantities of `ticked' hence, visible, articles cluttering up your
groups.  You may  begin to loose track of why you ticked things if
you read lots of groups...  You can end up with messy Summary buffers
after a time.

Many seasoned users have reported here, and on gnu.emacs.gnus that
using `dormant' is really a better choice since they also linger but
can be hidden or not as you choose.  (`/ D'  and  `/ d'.. limiting)

> Though, I am about to write a hook to auto-cache ticked articles.  To
> each his own.
> 
No need to extend yourself gnus has such a provision for the asking.

>From Gnus info:
     To turn caching on, set `gnus-use-cache' to `t'.  By default, all
  articles ticked or marked as dormant will then be copied over to your
  local cache (`gnus-cache-directory').  Whether this cache is flat or
  hierarchal is controlled by the `gnus-use-long-file-name' variable, as
  usual.

A simple (setq gnus-use-cache t)  will do what you want.

Re: Small complaint about M-g

[David S. Goldberg]

> My original post was not looking for a way to `tick' articles.  I like
> the way gnus hides read articles after closing a group.  What I
> complained mildly about was gnus being so rowdy about doing a rescan
> while inside a group.  In that instance only, I may not want read
> articles to disappear.  It was that problem that Jussi's comments
> addressed.

I have often wanted the same thing and this thread got me to thinking
how to do it.  I've come up with this bit of advice around
gnus-summary-rescan-group.  It's slow; the re-marking from ticked to
whatever was there before is noticeable, especially when there's lots
of stuff in the summary, but it does seem to work.  I don't know if it
will work in an nnvirtual group since I get the impression that the
virtual article numbers might change and I have no idea if it does the
right thing in an auto-expire environment which I don't use.  Also, it
will lose any process-marks that existed previously.  I can't find a
good way to get around that.  I can't use the stack of process-marks
(gnus-summary-save/yank-process-marks) because that stack doesn't
survive the invocation of gnus-summary-rescan-group and there's no
reliable way to get a list of all process marked articles.
gnus-summary-work-articles doesn't cut it 100% of the time and I'm not
sure it's worth going through a lot of grief to figure it out
correctly.  So, I've decided I can live with that limitation.  If
someone wants to improve on this please do so and post it.

(defadvice gnus-summary-rescan-group (around save-marks activate)
  (gnus-uu-mark-all)
  (let ((dsg-current-article gnus-current-article)
	(dsg-mark-list
	 (mapcar '(lambda (n) (cons n (gnus-summary-article-mark n)))
		 (gnus-uu-get-list-of-articles nil)))
	(dsg-work-articles (gnus-summary-work-articles nil)))
    (mapcar '(lambda (n) (gnus-summary-mark-article n ?!)) dsg-work-articles)
    ad-do-it
    (mapcar '(lambda (n) (gnus-summary-mark-article (car n) (cdr n)))
	    dsg-mark-list)
    (gnus-summary-goto-article dsg-current-article)))

-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: Small complaint about M-g

[David S. Goldberg]

Damn I hate sending out stuff without sufficient testing.  This fixes
a couple of problems with it.  The only bad thing now is that the
"current" article is automatically selected after M-g.  I only find
this a minor annoyance since I nearly always have something selected
when I type M-g anyway.  YMMV.

(defadvice gnus-summary-rescan-group (around save-marks activate)
  (gnus-uu-mark-all)
  (let ((dsg-current-article (gnus-summary-work-articles 1))
	(dsg-mark-list
	 (mapcar '(lambda (n) (cons n (gnus-summary-article-mark n)))
		 (gnus-uu-get-list-of-articles nil)))
	(dsg-work-articles (gnus-summary-work-articles nil)))
    (mapcar '(lambda (n) (gnus-summary-mark-article n ?!)) dsg-work-articles)
    ad-do-it
    (mapcar '(lambda (n) (gnus-summary-mark-article (car n) (cdr n)))
	    dsg-mark-list)
    (gnus-summary-goto-article (car dsg-current-article))))
-- 
Dave Goldberg (G022)
dsg@mitre.org
MS B325
Bedford x3887

Re: Small complaint about M-g

[Kai Großjohann]

dsg@mitre.org (David S. Goldberg) writes:

> > My original post was not looking for a way to `tick' articles.  I like
> > the way gnus hides read articles after closing a group.  What I
> > complained mildly about was gnus being so rowdy about doing a rescan
> > while inside a group.  In that instance only, I may not want read
> > articles to disappear.  It was that problem that Jussi's comments
> > addressed.
> 
> I have often wanted the same thing and this thread got me to thinking
> how to do it.  I've come up with this bit of advice around
> gnus-summary-rescan-group.  It's slow; the re-marking from ticked to
> whatever was there before is noticeable, especially when there's lots
> of stuff in the summary, but it does seem to work.

Hm.  Wouldn't it be possible to tell Gnus to fetch new mail, then look
for new headers, then just add summary lines for these new messages?

kai
-- 
~/.signature: No such file or directory

Re: Small complaint about M-g

[David S. Goldberg]

> Hm.  Wouldn't it be possible to tell Gnus to fetch new mail, then look
> for new headers, then just add summary lines for these new messages?

Maybe.  I couldn't figure out how to do that though.
-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: Small complaint about M-g

[Kai Großjohann]

dsg@mitre.org (David S. Goldberg) writes:

> > Hm.  Wouldn't it be possible to tell Gnus to fetch new mail, then look
> > for new headers, then just add summary lines for these new messages?
> 
> Maybe.  I couldn't figure out how to do that though.

Hm.  Well, gnus-summary-goto-article knows how to add a line to the
summary buffer.  I'm also not sure how to find out how to add lines
for the new messages.  Hm.  Maybe save the value of
gnus-newsgroup-limit, then run gnus-summary-update-info, then diff
against the new value of gnus-newsgroup-limit, and run
gnus-summary-insert-line on the new articles?

I should try it but I can't promise anything.  After all, I don't use
daemons. 

kai
-- 
~/.signature: No such file or directory

Re: Small complaint about M-g

[Amos Gouaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="", Size: 511 bytes --]

>>>>> On 23 Feb 2000 18:36:58 +0100,
>>>>> Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> (kg) writes:

kg> Hm.  Wouldn't it be possible to tell Gnus to fetch new mail, then look
kg> for new headers, then just add summary lines for these new messages?

Oh, that would be nice!

A while ago I fiddled with the auto extending thing, which would
pick up new messages (nnimap folder), but then things got really
weird.  I'll have to try it again some time so I can be more
precise.  

Amos

Re: Small complaint about M-g

[Kai Großjohann]

Jussi Yli-Urpo <jmy@h32.erkki.ton.tut.fi> writes:

> This was one of the reasons I eventually turned off
> marking selected articles automatically as read. Now in all
> my mail groups I either manually mark them read one by one
> or catchup whole group when I'm sure that I haven't missed
> anything important. 

Some of the users at our site use something which ticks a message when
it is read, rather than marking at as read.

(defun kai-gnus-mark-article-hook ()
  (if (and (not (or (memq gnus-current-article gnus-newsgroup-marked)
		    (memq gnus-current-article gnus-newsgroup-dormant)
		    (memq gnus-current-article gnus-newsgroup-expirable)
		    (memq gnus-current-article gnus-newsgroup-ancient)
                    (memq gnus-current-article gnus-newsgroup-reads))))
	(gnus-summary-tick-article)))
(setq gnus-mark-article-hook '(kai-gnus-mark-article-hook))


kai
-- 
~/.signature: No such file or directory

Marking read articles (was Small complaint about M-g)

[Chris Brierley]

On 2000-02-22, Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
> Jussi Yli-Urpo <jmy@h32.erkki.ton.tut.fi> writes:
> 
> > This was one of the reasons I eventually turned off marking
> > selected articles automatically as read.
> 
> Some of the users at our site use something which ticks a
> message when it is read, rather than marking at as read.

This thread gave me an idea.  I generally like the default
behavior of Gnus, i.e. marking read articles as read/expired and
not showing them to you again.  But, occasionally I get caught by
this.  I go to an article, before I'm done reading it something
comes up, and without thinking I quit the buffer (or whatever), do
the something else, and I've "missed" that article because it's
now marked as read.

I just thought, wouldn't it be nice if there was an option to only
mark the current article as read *after* you've completed reading
it.  E.g., when you hit 'n', the article you were reading is
marked as read, and the new current article is not marked as read
until you leave it in some way ('n', 'N', whatever).  So, it's
still automatically marked, but there is less of a chance of you
"losing" an article you haven't read thoroughly.

Off the top of my head I can see that it might be difficult to
decide what constituted "read completely".  For instance, what
would you do on the last unread article of a group?  Normally
hitting 'q' should not mark the current article as read because
you might not be done with it, but, for the last article in a
group you'd need it to.  Hrm.

Does anyone have any thoughts on this, or ideas on how to
implement it?

Just thinking.

Re: Marking read articles (was Small complaint about M-g)

[Jussi Yli-Urpo]

Chris Brierley <brierley@pobox.com> writes:
> I go to an article, before I'm done reading it something
> comes up, and without thinking I quit the buffer (or
> whatever), do the something else, and I've "missed" that
> article because it's now marked as read.

That is extactly the case I'm worried about. For me, mail
should not be marked as read before it actually *is* read.

> I just thought, wouldn't it be nice if there was an option to only
> mark the current article as read *after* you've completed reading
> it. 

> So, it's still automatically marked, but there is less of
> a chance of you "losing" an article you haven't read
> thoroughly.

This would be really nice. I also thought this solution but
I didn't at least found any existing hook to use.

> Off the top of my head I can see that it might be difficult to
> decide what constituted "read completely".  For instance, what
> would you do on the last unread article of a group?  Normally
> hitting 'q' should not mark the current article as read because
> you might not be done with it, but, for the last article in a
> group you'd need it to.  Hrm.

In case of last message in Group would it be enought to mark
it read when you reach the end of article and get the
message "No more unread acticles"?

> Does anyone have any thoughts on this, or ideas on how to
> implement it?

So, how about adding hook which is called when end of
article is reached?

Well, after thinking more about this solution I don't still
know would this be safe enough to use. I just don't trust
myself so much... :)

> Just thinking.

Me too...

-- 
Jussi.

Re: Marking read articles (was Small complaint about M-g)

[Kai Großjohann]

Jussi Yli-Urpo <jmy@h32.erkki.ton.tut.fi> writes:

> That is extactly the case I'm worried about. For me, mail
> should not be marked as read before it actually *is* read.

Maybe you should tell Gnus not to mark the article at all, when you
select it.  Then you can use `d' to mark it as read manually.

kai
-- 
~/.signature: No such file or directory

Re: Marking read articles (was Small complaint about M-g)

[Jussi Yli-Urpo]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Maybe you should tell Gnus not to mark the article at all, when you
> select it.  Then you can use `d' to mark it as read manually.

Yes, that's the way I do it at the moment in all my mail
groups and I pretty satisfied with it. But of course I'd be
willing try also something little bit more automatic but
still safe way to mark them read. I just don't know if it's
possible...

-- 
Jussi.

Re: Marking read articles (was Small complaint about M-g)

[Amos Gouaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="", Size: 1796 bytes --]

For my nnimap folders, currently I have articles automatically
marked as expireable.  Many folders have a pretty high expire
value.  Then I found I was ticking way to much, so I set
display-all.  That's okay, but then opening that folder takes longer
and longer.  So now I've got gnus-large-newsgroup to a manageable
size, and when I open the folder, just pick a number that I can
handle.  A bit crude, but I haven't settled on a perfect solution
yet, if one exists.

Actually, the business of displaying a subset (like the x most
recent messages) is not new.  I've seen that in other mail clients,
and generally it can be quite convenient, especially if it is a huge
folder and a slow link.  Usually such clients had a button to get
the next X number of messages, as well as possibly a button to get
all the messages.  When I need to read the entire folder, I'll do
C-u SPC or if I'm in the group, C-u M-g.

Though, selecting the number of message each time is getting
tedious.  I just haven't had time to try another way of managing
mail.

I think the problem is that reading mail can at times be at odds
with reading news, which the default behavior I like. 

>>>>> On 23 Feb 2000 23:05:23 +0200,
>>>>> Jussi Yli-Urpo <jmy@h32.erkki.ton.tut.fi> (jy) writes:

jy> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> Maybe you should tell Gnus not to mark the article at all, when you
>> select it.  Then you can use `d' to mark it as read manually.

jy> Yes, that's the way I do it at the moment in all my mail
jy> groups and I pretty satisfied with it. But of course I'd be
jy> willing try also something little bit more automatic but
jy> still safe way to mark them read. I just don't know if it's
jy> possible...

jy> -- 
jy> Jussi.