Oort Version

Oort Version

[Jake Colman]

I just updated my Oort installation via the CVS Server for the first time in
a while.  The version number still displays "Oort Gnus v0.01".  This number
does not get updated as the CVS source is updated?  How do we distinguish
between various downloads?

-- 
Jake Colman                     

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

Re: Oort Version

[Kai Großjohann]

On 26 Mar 2001, Jake Colman wrote:

> I just updated my Oort installation via the CVS Server for the first
> time in a while.  The version number still displays "Oort Gnus
> v0.01".  This number does not get updated as the CVS source is
> updated?  How do we distinguish between various downloads?

If you were to update that number every time somebody commits
something, it would grow real fast.  You normally say when you did the
`cvs update'.

The version number is bumped when Lars puts a tarball on gnus.org.

kai
-- 
Be indiscrete.  Do it continuously.

Re: Oort Version

[Karl Kleinpaste]

Let me ask something that's been on my mind a while, as long as this
version question has arisen.

What's the Oort cycle for?

About a year ago, or perhaps a year and a half, we had a general round
of wish-list WIBNI thoughts for what should go into Oort after
Pterodactyl was released.  Gnus 5.8 has been out for quite some time,
and we've formally moved into Oort territory, but so far, Oort is just
ongoing bug fixes to 5.8, mostly.

Is there a plan for where Oort is supposed to go?  Is there a goal in
mind?

--karl

Re: Oort Version

[Simon Josefsson]

Karl Kleinpaste <karl@charcoal.com> writes:

> Is there a plan for where Oort is supposed to go?  Is there a goal in
> mind?

One goal could be PGP/MIME and S/MIME integration.  Improved
disconnected IMAP support might be another.

Re: Oort Version

[Steven E. Harris]

Simon Josefsson <simon@josefsson.org> writes:

> Improved disconnected IMAP support might be another.

I don't know if this is already a wish list item, but building support
for IMAP message structure awareness would be great. That is, we'd
like to be able to download only the body, and maybe then selectively
download an attachment. The attachments could be indicated by some
placeholders just like current non-displayable attachments are.

Granted, this isn't a high priority need, but Gnus already does so
well with handling all kinds of protocols, so it would be good to see
IMAP flexed to its full potential.

-- 
Steven E. Harris        :: seh@speakeasy.org
GnuPG                   :: 0x70248E67

Re: Oort Version

[Robin S. Socha]

* Steven E Harris <sharris@speakeasy.org> writes:
> Simon Josefsson <simon@josefsson.org> writes:

>> Improved disconnected IMAP support might be another.

> I don't know if this is already a wish list item, but building support
> for IMAP message structure awareness would be great. 

I'd like to see some luser-proof clicky-clicky interface to fancy split
rules. Possibly the one and only point where Outlook does better than
Gnus (gotta love the jingles for certain induhviduals).
-- 
Robin S. Socha  <http://mail.socha.net/>

Re: Oort Version

[Karl Kleinpaste]

"Robin S. Socha" <robin@socha.net> writes:
> I'd like to see some luser-proof clicky-clicky interface to fancy
> split rules.

Take off the qualifying end clause and I'd be really interested: Some
very general, very wide-ranging luser-proofing.

That is, it seems to me that there continues to be a huge gap between
us, the Gnus cognoscenti, and people who've managed to install XEmacs
but have just barely figured out that it's got a built-in tutorial.
The latter folks, as exemplified in news.software.readers this week,
have trouble even invoking Gnus for the first time.  I had to write a
brief walk-through for someone, just to help him set gnus-select-
method and start it all up.  Our "market penetration" will be forever
miserable if we always represent such a steep wall to be scaled.

Customize is good, but I would really like to see...

- A set of functions named things like gnus-init-very-first-time,
  gnus-init-mail, gnus-init-topics.  And then have Gnus use these
  functions based on obvious criteria.  For example, the lack of any
  .gnus would be a firm indicator of a need for gnus-init-first-time,
  where the user would be queried for the name of his NNTP server, set
  up authinfo if needed, and perhaps be asked if there are any groups
  he'd like to see immediately subscribed.  Maybe bring up an explanatory
  buffer to sit alongside *Group* to explain server mode, so as to find
  other groups to subscribe.  Make some of these "init" functions into
  toolbar buttons, such as for setting up mail for the very first time.

- Generally, lots of interactive help in setting up mail.  We get lots
  and lots of questions in gnu.emacs.gnus about the umpteen thousand
  ways to suffer through mail configuration.  It should never be this
  hard, and Outlook and Netscape Messenger users have it so easy.
  Conceptually, mail configuration _is_ easy: Pick sources, perhaps
  pick servers + names + passwords, set variables to indicate those
  things.  Joe Luser shouldn't have to invoke setq himself.  We should
  pick one backend as "the standard luser mail backend" and conform
  Joe Luser to that.

- Prepackaged, selectable nnmail-split-rules entries to do "obvious"
  things, such as splitting yahoogroups.com mailing lists to their own
  groups, or selecting classes of users into usable groups (prototypes
  for things like "family", "coworkers", "kinky people I know from
  Usenet"), or punting mailer errors to their own group.  Think of how
  Netscape Messenger walks the user through filtration rules.  Also,
  we should pre-make (`G m') any mail groups requested, so that the
  user needn't (e.g.) go hunting for `F' in *Group*.

- Help the user auto-graft BBDB onto his universe.  "What address book
  does Gnus provide?" is another perennial gnu.emacs.gnus question.

- Maybe some sort of WYSIWYG buffer configurator.  There are lots of
  viewpoints on what buffers ought to be where in what context.  The
  defaults aren't bad, but a lot of people want to do other things,
  and they tend to be rather confused by gnus-add-configuration.

- ...other stuff of this sort...

Finding a way to overcome the luser barrier interests me most.
Unfortunately, it's precisely the sort of topic that might not garner
the interest of the cognoscenti, generally, specifically because we're
not the lusers that such effort would help.

Related question: It should be possible to customize custom-file in a
buffer-local way, yes?  That is, assuming Joe Luser wants to use one
Emacs for both ordinary editing work as well as Gnus, if he uses
customize for normal stuff, he wants the customizations to end up in
.emacs, but if he customizes Gnus stuff, it should land in .gnus.
Regardless of any luser-proofing, we should ensure that customize does
the Right Thing from within Gnus.

--karl

Re: Oort Version

[Colin Marquardt]

Karl Kleinpaste <karl@charcoal.com> writes:

> Customize is good, but I would really like to see...
> 
> - A set of functions named things like gnus-init-very-first-time,
>   gnus-init-mail, gnus-init-topics.  And then have Gnus use these
>   functions based on obvious criteria.  For example, the lack of any
>   .gnus would be a firm indicator of a need for gnus-init-first-time,
>   where the user would be queried for the name of his NNTP server, set
>   up authinfo if needed, and perhaps be asked if there are any groups
>   he'd like to see immediately subscribed.  Maybe bring up an explanatory

emacro.el has some stuff like this, though not specifically targeted
to Gnus. And I really like the whole idea.

Colin

Re: Oort Version

[Simon Josefsson]

Karl Kleinpaste <karl@charcoal.com> writes:

> "Robin S. Socha" <robin@socha.net> writes:
> > I'd like to see some luser-proof clicky-clicky interface to fancy
> > split rules.
> 
> Take off the qualifying end clause and I'd be really interested: Some
> very general, very wide-ranging luser-proofing.

Part of the emacs/gnus experience is getting used to the awkward and
non-intuitive keyboard, mouse, window and widget behaviour.  To
attract clicky-clicky lusers I think more use of GTK, QT or Windows
widgets by emacs applications (Gnus) would be required, at least.

(Emacs 21 improves many of these issues, but it's far from fitting
into someone's usual desktop environment.  Just consider the scroll
bar behaviour for instance: Most widget packages keep the moveable
scrollbar button to a fixed size depending on buffer size, Emacs
resizes the scrollbar button according to some algorithm I've never
grasped the intuition of.)

Re: Oort Version

[Christoph Conrad]

Hi Karl,

you wrote:

    > Some very general, very wide-ranging luser-proofing.

Yes! Agreed. Today i would count myself to have some knowledge about
Gnus, but i remember when i started with pgnus 0.79 i needed *two*
weeks of configuration (in sum about 30-40h) til it did get it run
satisfying. And without knowing Elisp i didn't have no chance.

Best regards,
cu, -cc-
-- 
=> GNU Emacs Webring @ <http://www.gnusoftware.com/WebRing/> <=
Look Ma, this man can twist his fingers as if they were made of rubber,
isn't that amazing? -- Not really, he's been using emacs for years...!

Re: Oort Version

[Christoph Conrad]

Hi Karl,

you wrote:

    > Some very general, very wide-ranging luser-proofing.

Yes! Agreed. Today i would count myself to have some knowledge about
Gnus, but i remember when i started with pgnus 0.79 i needed *two*
weeks of configuration (in sum about 30-40h) til it did get it run
satisfying. And without knowing Elisp i didn't have no chance.

Best regards,
cu, -cc-
-- 
=> GNU Emacs Webring @ <http://www.gnusoftware.com/WebRing/> <=
Look Ma, this man can twist his fingers as if they were made of rubber,
isn't that amazing? -- Not really, he's been using emacs for years...!

Re: Oort Version

[Christoph Conrad]

Hi Karl,

you wrote:

    > Some very general, very wide-ranging luser-proofing.

Yes! Agreed. Today i would count myself to have some knowledge about
Gnus, but i remember when i started with pgnus 0.79 i needed *two*
weeks of configuration (in sum about 30-40h) til it did get it run
satisfying. And without knowing Elisp i didn't have no chance.

Best regards,
cu, -cc-
-- 
=> GNU Emacs Webring @ <http://www.gnusoftware.com/WebRing/> <=
Look Ma, this man can twist his fingers as if they were made of rubber,
isn't that amazing? -- Not really, he's been using emacs for years...!

Re: Oort Version

[Christoph Conrad]

Hi Karl,

you wrote:

    > Some very general, very wide-ranging luser-proofing.

Yes! Agreed. Today i would count myself to have some knowledge about
Gnus, but i remember when i started with pgnus 0.79 i needed *two*
weeks of configuration (in sum about 30-40h) til it did get it run
satisfying. And without knowing Elisp i didn't have no chance.

Best regards,
cu, -cc-
-- 
=> GNU Emacs Webring @ <http://www.gnusoftware.com/WebRing/> <=
Look Ma, this man can twist his fingers as if they were made of rubber,
isn't that amazing? -- Not really, he's been using emacs for years...!

Re: Oort Version

[Christoph Conrad]

>>>>> "Christoph" == Christoph Conrad <christoph.conrad@gmx.de> writes:

<6 copies in the group>

I apologize for sending the article more than once, but i got an error
message when sending it, so i sent it several times. I had disabled an
old bugfix i installed months ago to test whether this bugs gone, but
obviously it isn't:

(deffoo nntp-request-accept-article( group &optional server last )
  (ignore))


i. A.
Best regards,
Christoph Conrad
-- 
TTi Entwicklungszentrum GmbH,  Matthiashofstr. 28-30,  D-52064 Aachen
Fon: +49 241 47051-0  Fax: +49 241 47051-89 Web: http://www.cli.de
Look Ma, this man can twist his fingers as if they were made of rubber,
isn't that amazing? -- Not really, he's been using emacs for years...!

Wizards (was: Re: Oort Version)

[Per Abrahamsen]

A couple of years ago I did some prelimenary work on integrating
customize with w3, which should allow for the creation of wizards that
guide users through customization.  Unfortunately I didn't get as far
as creating a good example, and the code has likely suffered bit-rot
since.

Karl Kleinpaste <karl@charcoal.com> writes:

> - Prepackaged, selectable nnmail-split-rules entries to do "obvious"
>   things, such as splitting yahoogroups.com mailing lists to their own
>   groups, or selecting classes of users into usable groups (prototypes
>   for things like "family", "coworkers", "kinky people I know from
>   Usenet"), or punting mailer errors to their own group.  Think of how
>   Netscape Messenger walks the user through filtration rules.  Also,
>   we should pre-make (`G m') any mail groups requested, so that the
>   user needn't (e.g.) go hunting for `F' in *Group*.

That sound interesting, it may even being doable now with the : rules.

> - Help the user auto-graft BBDB onto his universe.  "What address book
>   does Gnus provide?" is another perennial gnu.emacs.gnus question.

A problem is that BBDB is FSF code, which makes it problematic to
depend on it in a FSF project like Gnus.  I sometimes fantasize about
writting a LBDB for FSF just to have the functionality present always.

> - Maybe some sort of WYSIWYG buffer configurator.  There are lots of
>   viewpoints on what buffers ought to be where in what context.  The
>   defaults aren't bad, but a lot of people want to do other things,
>   and they tend to be rather confused by gnus-add-configuration.

Kyle Jones apparently have some very good code for VM which could be
rewritten for Gnus.

> Regardless of any luser-proofing, we should ensure that customize does
> the Right Thing from within Gnus.

The Right Thing(TM) is to write in custom-file, and leave .gnus for
manual customization.  The only reason customize write in .emacs is
that RMS only want one customization file.  In XEmacs, they are moving
towards one file for manual customization, and one file for automatic
customization which makes lots of sense.  Splitting the file for
automatic customization further adds complexity without any measurable
benefits.

Re: Wizards (was: Re: Oort Version)

[Karl Kleinpaste]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> A couple of years ago I did some prelimenary work on integrating
> customize with w3, which should allow for the creation of wizards that
> guide users through customization.  Unfortunately I didn't get as far
> as creating a good example, and the code has likely suffered bit-rot
> since.

Do you still have the code?  It would be worth looking at today.  Rot
can be cut out.

>> - Prepackaged, selectable nnmail-split-rules entries to do "obvious"

> That sound interesting, it may even being doable now with the : rules.

Do you mean by using a long (contorted?) list of alternate selectors?
That could get really hairy, I would think.  But it would be good for
a first pass.

> A problem is that BBDB is FSF code, which makes it problematic to
( s/is/isn't/ ?)
> depend on it in a FSF project like Gnus.  I sometimes fantasize about
> writting a LBDB for FSF just to have the functionality present always.

So let's provide BBDB auto-graft iff we detect that BBDB is
available.  Can "require" be wrapped inside "ignore-errors"?

  (if (ignore-errors (require 'bbdb))
     ( ... do whatever it takes to be able to auto-graft on request ... ))

I don't know if this is the right elisp idiom for such a purpose, but
my goal is to try to pull in BBDB, and if it succeeds ("ignore-errors"
returns nil if its contained forms fail; and I assume "require"
returns something other than nil when it successfully finds the
feature or loads the file), then make Gnus available for graft assist.

> Kyle Jones apparently have some very good code for VM which could be
> rewritten for Gnus.

I wish I had any experience using VM, but I've never once invoked it
except by accident.

> Splitting the file for automatic customization further adds
> complexity without any measurable benefits.

Having thought it through a bit more, I agree with you.  But how does
this interact with users who run >1 simultaneous Emacs?

Start an Emacs, run Gnus in it.
Start 2nd Emacs.
Customize Gnus in 1st Emacs.
Exit Gnus from 1st Emacs.
Start Gnus in 2nd Emacs.

The advantage of .gnus is that it is loaded with every start of Gnus.
If we bury customizations in the usual auto-customize file, fresh
invocations of Gnus in a new Emacs don't get needed stuff picked up,
and induce another nightmare for the confused new user.

Re: Wizards (was: Re: Oort Version)

[Per Abrahamsen]

Karl Kleinpaste <karl@charcoal.com> writes:

> Do you still have the code?  It would be worth looking at today.  Rot
> can be cut out.

It may be in W3.  W3 is build upon the same widget library as
customize, and the primary idea was to have a html tag that expanded
into a customize widget, and the secondary idea was to have Emacs Lisp
as an HTML script language (instead of ECMAscript)...

Hey, I actually have a demo-page from back then!  Look at 

        http://www.dina.kvl.dk/~abraham/custom/gnus.html

with w3 to get an idea of what I was trying to achieve.

W3 *is* FSF signed, but I don't think anyone is working on integrating
it.  W3 need to be a "core feature" of both Emacs and XEmacs for this
approach to be feasible, simple minded customization should not
require any extra packages.

The alternative is to write an ad-hoc markup langauge, which I think
is silly.  I'd much rather have W3 used everywhere. 

> Do you mean by using a long (contorted?) list of alternate selectors?
> That could get really hairy, I would think.  But it would be good for
> a first pass.

I don't understand what you mean, but then again, I have never used
the : or ! features.  It was just a thought.

Maybe the best option would be to drop the fancy split, and write a
third value for nnmail-split-methods, say nnmail-split-common, which
understood some not very flexible but easy to understand options.

The default syntax is very simple, too simple for common tasks.

The recursive nature of nnmail-split-fancy is way cool and very
powerful if you have a CS degree, and utter gibberish if not.

The nnmail-split-common should understand some simple lists
corresponding to common splits.  Maybe junk, people, lists, and other.

> > A problem is that BBDB is FSF code, which makes it problematic to
> ( s/is/isn't/ ?)

Yes.

> So let's provide BBDB auto-graft iff we detect that BBDB is
> available.  Can "require" be wrapped inside "ignore-errors"?

Yes.  It doesn't really interest me though, the vast majorioty of
ordinary users just use what is bundled.

> I wish I had any experience using VM, but I've never once invoked it
> except by accident.

It is a long time since I used VM, but Kyle Jones write beautiful code
with nice and clear apis.  I just wish he would agree to sign papers.

> But how does this interact with users who run >1 simultaneous Emacs?

Badly.

Re: Wizards (was: Re: Oort Version)

[Paul Jarc]

Karl Kleinpaste <karl@charcoal.com> writes:
> The advantage of .gnus is that it is loaded with every start of Gnus.
> If we bury customizations in the usual auto-customize file, fresh
> invocations of Gnus in a new Emacs don't get needed stuff picked up,
> and induce another nightmare for the confused new user.

But will new users often be in that situation?  Maybe have a variable
gnus-custom-file, which could be either "~/.gnus-custom" or
'custom-file by default.  Store Gnus custom stuff in there.


paul

Re: Oort Version

[Josh Huber]

Something I'd like to see is a way to update folders with new messages
without closing a re-opening them.  Additionally, I'd like a way to
refresh the Groups buffer without re-polling the news/mail servers
that are listed.  What I'd like to see is the demon update the group
list.

Currently, it updates the contents of the folders, but not the
information displayed in the group list (number of messages, etc).

This sounds like a "next version" kind of thing to me, but it would be
nice if there were a more active link between everything.  For
example, gnus-demon-scan-mail polls an IMAP server and finds new
mail.  The various mail messages are split into groups.  The groups
buffer is updated (in real-time) with the new message count, and the
open Summary buffers (for example, in other frames) are updated with
the new messages as well.

Currently, when I notice that gnus-demon-scan-mail gets new messages,I
have to hit 'g', which causes Gnus to poll my mail/news servers
*again*, then display the updated information.  Also, this would be
nice for showing changes made by B m or B r in real-time in the groups
buffer. (and postponed messages, etc)

I would love to proved wrong about having the ability to do any of
this, though :)

-- 
Josh Huber

Re: Oort Version

[Samuel Padgett]

Simon Josefsson <simon@josefsson.org> writes:

> Most widget packages keep the moveable scrollbar button to a fixed
> size depending on buffer size, Emacs resizes the scrollbar button
> according to some algorithm I've never grasped the intuition of.

I believe it's sized according to the percentage of _characters_
currently visible, not lines (for efficiency reasons?).  This means
the scrollbar knob will be slightly larger when you're looking a
portion of the buffer that has longer lines (i.e. more characters)
than some other portion of the buffer.

Of course, this breaks the Windows NT scrollbar, which doesn't
dynamically resize itself when adjusted.  Thus, you can't always
scroll to the very beginning or very end of the buffer using the NT
scrollbar alone.  :-(

Sam
-- 
Room service?  Send up a larger room.
                -- Groucho Marx

Re: Wizards (was: Re: Oort Version)

[Samuel Padgett]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> The Right Thing(TM) is to write in custom-file, and leave .gnus for
> manual customization.

The Viper package has a some simple invoked-for-the-first-time
messages and prompts for new Viper users.  It writes settings to
~/.viper rather than `custom-file'.  I'm not saying this is the Right
Thing, but it would be nice to see consistency between packages that
perform first-time initialization, particularly those packages that
are a part of do Emacs.

I'm not sure how Viper knows whether it's being invoked for the first
time.  Maybe through the abscence of ~/.viper?

Sam
-- 
Room service?  Send up a larger room.
                -- Groucho Marx

Re: Wizards (was: Re: Oort Version)

[Alex Schroeder]

Karl Kleinpaste <karl@charcoal.com> writes:

>   (if (ignore-errors (require 'bbdb))
>      ( ... do whatever it takes to be able to auto-graft on request ... ))

(condition-case nil
  (require 'bbdb)
(error))

or

(load "bbdb" t)

and not XEmacs compatible: 

(require 'bbdb nil t)

Alex.
-- 
http://www.geocities.com/kensanata/emacs.html
"Your .emacs is either in C:\ or in the directory of %HOME% under Win32."