Gnus development mailing list
 help / color / mirror / Atom feed
* Miscelleous notes/bugs
@ 1996-05-27 22:22 Raja R Harinath
  1996-05-28 19:44 ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 4+ messages in thread
From: Raja R Harinath @ 1996-05-27 22:22 UTC (permalink / raw)


Gnus v5.2.1; nntp 4.0; nnml 1.0; nnmh 1.0; nndir 1.0; nndoc 1.0; nndraft 1.0; nnfolder 1.0

* Local hooks not useful

SGnus uses `gnus-make-local-hook' in two places, but these hooks are
effectively useless.  This is because the `add-hook' immediately after
it does _not_ set the local hook.  `add-hook' has a fourth parameter
that has to be non-nil for it to add to the local hook.  Maybe,
`gnus-add-to-local-hook' has to be defined, which is either plain
`add-hook' for XEmacs, or adds the 'local parameter in case of Emacs.
This could also clean up the ugly tests in `gnus-gl.el', like the
following:

      (if (not (fboundp 'make-local-hook))
          (add-hook 'gnus-select-article-hook 'grouplens-do-time)
        (make-local-hook 'gnus-select-article-hook)
        (add-hook 'gnus-select-article-hook 'grouplens-do-time nil 'local))

This bug became apparent when I exited gnus, and tried to send a
message.  `message-sent-hook' still had `gnus-inews-do-gcc', and it
started complaining about selecting a deleted buffer.

(In fact, I sent a previous bug report on this, but due to this error
during send, I was not sure whether the message was actually sent or
not.  It hadn't appeared on the `gnus-bug' archive a half-hour after I
sent it...)

* Emacs 19.31 timers

Should `gnus-demon' be rewritten to use the new API of Emacs timers
(run-with-timer, run-with-idle-timer)?

* `derived.el'

I saw `derived.el' in the Emacs `lisp/' directory.  It appears to
support major-mode inheritance (keymaps, syntax-tables, etc., are
automatically copied on derivation.)  Should "grouplens" and other
variants of the "summary" mode use this mechanism?

* `nn*.el' independent of `gnus*.el'?

Can `message.el' use some of the features of `nn*.el' without loading
the rest of Gnus? (`message-post-method' uses one of the "nn*"
backends.)  If so, can message archiving be supported without loading
Gnus?

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Miscelleous notes/bugs
  1996-05-27 22:22 Miscelleous notes/bugs Raja R Harinath
@ 1996-05-28 19:44 ` Lars Magne Ingebrigtsen
  1996-05-29  8:49   ` Steinar Bang
  0 siblings, 1 reply; 4+ messages in thread
From: Lars Magne Ingebrigtsen @ 1996-05-28 19:44 UTC (permalink / raw)


Raja R Harinath <harinath@cs.umn.edu> writes:

> * Emacs 19.31 timers
> 
> Should `gnus-demon' be rewritten to use the new API of Emacs timers
> (run-with-timer, run-with-idle-timer)?

Yes.

> * `derived.el'
> 
> I saw `derived.el' in the Emacs `lisp/' directory.  It appears to
> support major-mode inheritance (keymaps, syntax-tables, etc., are
> automatically copied on derivation.)  Should "grouplens" and other
> variants of the "summary" mode use this mechanism?

I don't think so.  `derived.el' is for inheriting between major
modes.  GroupLens (and the rest) use minor modes.

> * `nn*.el' independent of `gnus*.el'?

Yes.

> Can `message.el' use some of the features of `nn*.el' without loading
> the rest of Gnus? (`message-post-method' uses one of the "nn*"
> backends.)  If so, can message archiving be supported without loading
> Gnus?

That should be no problem.  Just call, say, `nnml-request-scan' at
will.  No need to start Gnus first.  (Not that I have ever tried this,
though.  :-)

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Miscelleous notes/bugs
  1996-05-28 19:44 ` Lars Magne Ingebrigtsen
@ 1996-05-29  8:49   ` Steinar Bang
  1996-05-29 21:07     ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 4+ messages in thread
From: Steinar Bang @ 1996-05-29  8:49 UTC (permalink / raw)
  Cc: ding

>>>>> Lars Magne Ingebrigtsen <larsi@ifi.uio.no>:

> Raja R Harinath <harinath@cs.umn.edu> writes:
>> * Emacs 19.31 timers

>> Should `gnus-demon' be rewritten to use the new API of Emacs timers
>> (run-with-timer, run-with-idle-timer)?

> Yes.

Interesting!  I haven't unpacked 19.31 yet (high on the TODO list), so
I don't _know_ what 19.31 timers are... but if they are what I *think*
they are, we can have pseudo multithreading.  Or...?


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Miscelleous notes/bugs
  1996-05-29  8:49   ` Steinar Bang
@ 1996-05-29 21:07     ` Lars Magne Ingebrigtsen
  0 siblings, 0 replies; 4+ messages in thread
From: Lars Magne Ingebrigtsen @ 1996-05-29 21:07 UTC (permalink / raw)


Steinar Bang <sb@metis.no> writes:

> > Raja R Harinath <harinath@cs.umn.edu> writes:

> >> Should `gnus-demon' be rewritten to use the new API of Emacs timers
> >> (run-with-timer, run-with-idle-timer)?

> Interesting!  I haven't unpacked 19.31 yet (high on the TODO list), so
> I don't _know_ what 19.31 timers are... but if they are what I *think*
> they are, we can have pseudo multithreading.  Or...?

Things like `run-with-idle-timer' makes it lots easier to have Emacs
do things "in the background" when Emacs is idle.  So, yes.  It still
isn't trivial to use, though.  And a pain to debug.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1996-05-29 21:07 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-05-27 22:22 Miscelleous notes/bugs Raja R Harinath
1996-05-28 19:44 ` Lars Magne Ingebrigtsen
1996-05-29  8:49   ` Steinar Bang
1996-05-29 21:07     ` Lars Magne Ingebrigtsen

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).