A road map for Oort Gnus

A road map for Oort Gnus

[Lars Magne Ingebrigtsen]

I think that we can say that we have a pretty feature-laden newsreader
by now.  And new features will be added, I'm sure, as we think of
them.  However, I don't think that is really what needs focus at this
juncture.

gnu.emacs.gnus is pretty busy.  There seems to be quite a lot of new
Gnus users -- my impression is that there's more new Gnus users now
than ever before, which is pretty surprising.  That view may be wrong,
and it may just be that Gnus is attracting a new kind of user -- the
kind that expects things to, like, work, and doesn't really put up
with having to spend hours setting things up.  This kind of user
generates more traffic on the newsgroup than the hard-core computer
hacker kind of person.

Even so, I think Gnus should focus on ease of (initial) use.  Ideally,
someone who has never used Gnus before should be able to say `M-x
gnus' and just having things work.  That's not realistic, but I think
it should be realistic to have the user spend less time than setting
up, say, Outlook Express.  There you have to maneuver through a quite
large number of menus, and specify some quite bewildering settings, to
get started.  We can do better.

However.  Gnus is an Emacs newsreader.  This is an important point.
It is not our responsibility to explain Emacs to the user.  It is not
Outlook's responsibility to explain how to use a mouse, or what the
"Start" menu in Windows means.  Gnus runs under Emacs, and Emacs is
its operating system.  We must guide the user to appreciate the
genius of Emacs; not to shield the user from its splendiferousness.

These are quite general thoughts on Gnusiness, and I think there are
probably many ways to achieve these goals.  (If that's what we want to
do.  We may, perhaps, not want to do this.)  Kai has suggested
detecting whether the user is a first-time user, and then guiding her
through the setup process.  Per has suggested setup wizards.  I have
(on gnu.emacs.gnus, recently) suggested a different version of setup
wizards.  (I think.  Perhaps I should repost it here?)

So.  Ideas?  Thoughts?  Flames?

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

Re: A road map for Oort Gnus

[Alexandre Oliva]

On Apr 14, 2001, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Kai has suggested detecting whether the user is a first-time user,
> and then guiding her through the setup process.  Per has suggested
> setup wizards.  I have (on gnu.emacs.gnus, recently) suggested a
> different version of setup wizards.

This would be definitely a good thing.  I wonder if it would be hard
to create such a wizard atop `custom'.  I'm thinking of creating a
sequence of customize screens with certain control decisions taken
depending on certain variables customized in previous screens.  I'm
afraid I'm too far from being a custom expert to tell whether this is
easy, or even feasible with the current custom features :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: A road map for Oort Gnus

[Per Abrahamsen]

Alexandre Oliva <oliva@lsd.ic.unicamp.br> writes:

> This would be definitely a good thing.  I wonder if it would be hard
> to create such a wizard atop `custom'. 

That is basically what I suggested in 

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

except that it requires w3.  That is, *don't* use your usual browser
to see the above page, unless your usual browser if w3.  Put the
cursor above the URL, and type 'M-x w3-fetch <ret>'.

It would need some more work to be really useful, but the real problem
is that w3 is not integrated in Emacs.  WM Perry hasn't time to do
more than minimal maintainence, and nobody else have volunteered to
take over w3 or w3 integration.

I think using w3 would be the ultimate solution, but we could invent
an ad-hoc markup language for the purpose.

> I'm thinking of creating a sequence of customize screens with
> certain control decisions taken depending on certain variables
> customized in previous screens.  I'm afraid I'm too far from being a
> custom expert to tell whether this is easy, or even feasible with
> the current custom features :-(

Depending on how much control is needed, it could be build upon either
custom or the widget library.  I don't think the programming part will
be that hard, the real challenge would be designing the wizards
themselves. 

Re: A road map for Oort Gnus

[Lars Magne Ingebrigtsen]

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

> It would need some more work to be really useful, but the real problem
> is that w3 is not integrated in Emacs.  WM Perry hasn't time to do
> more than minimal maintainence, and nobody else have volunteered to
> take over w3 or w3 integration.

I think that w3 is an essential Emacs component.  These days, most
information is out there on the Web, and to access that, we need the
URL library and the HTML parsing functions.  In short, w3.  It's going
to become even more vital in the future, what with all these
XML-RPC/SOAP thingies that are rearing their heads.

Are anybody at the FSF dealing with these issues?  It's not impossible
that funding could be found for such a project, if that's the issue.
(I suspect that it's more a question of time.)

> I think using w3 would be the ultimate solution, but we could invent
> an ad-hoc markup language for the purpose.

I think that would be counter-productive.  w3 is the way.  Who do we
bug to get things set in motion?  (I've Cc'd this to Bill.)

> Depending on how much control is needed, it could be build upon either
> custom or the widget library.  I don't think the programming part will
> be that hard, the real challenge would be designing the wizards
> themselves. 

If we had a proper framework for building wizards, I think writing the
wizards themselves would be quite a lot of typing; yes, but not very
complicated typing.

I envision a kind of rule-based framework.  "The user has input this
and this information, and this and this exists on the system, so we
present the user with this information and these choices."

I don't think writing that kind of framework would be trivial...

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

Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Per Abrahamsen]

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

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> > It would need some more work to be really useful, but the real problem
> > is that w3 is not integrated in Emacs.  WM Perry hasn't time to do
> > more than minimal maintainence, and nobody else have volunteered to
> > take over w3 or w3 integration.
> 
> I think that w3 is an essential Emacs component. 

That was my standpoint 7 years ago, and still is.

> These days, most information is out there on the Web, and to access
> that, we need the URL library and the HTML parsing functions.  In
> short, w3.  It's going to become even more vital in the future, what
> with all these XML-RPC/SOAP thingies that are rearing their heads.
> 
> Are anybody at the FSF dealing with these issues?

If "wishing someone would take up the project" counts as dealing, then
yes.

> It's not impossible that funding could be found for such a project,
> if that's the issue.  (I suspect that it's more a question of time.)

I think so too.  You need someone who is smart enough to understand
both Emacs and W3, yet stupid enough to volunteer.  

Ops, did I say stupid?  I meant, eh, "have time enough to spare".

> > I think using w3 would be the ultimate solution, but we could invent
> > an ad-hoc markup language for the purpose.
> 
> I think that would be counter-productive.  w3 is the way.  

I agree.  However, that notion have delayed wizards for 7 years now.

> Who do we bug to get things set in motion?  (I've Cc'd this to
> Bill.)

I have CC'ed it to the Emacs developers list, both Setup Wizards and
W3 integration are big questions that affect all of Emacs, not just
Gnus.

> > Depending on how much control is needed, it could be build upon either
> > custom or the widget library.  I don't think the programming part will
> > be that hard, the real challenge would be designing the wizards
> > themselves. 
> 
> If we had a proper framework for building wizards, I think writing the
> wizards themselves would be quite a lot of typing; yes, but not very
> complicated typing.

It is not the typing that is hard, but the design.  What are the
really important questions for this application?  Which things can be
safely assume?  How can we prensent the concept in a way the average
user can understand?

> I envision a kind of rule-based framework.  "The user has input this
> and this information, and this and this exists on the system, so we
> present the user with this information and these choices."
> 
> I don't think writing that kind of framework would be trivial...

I envision a markup language with embedded widgets and embedded Lisp.
Trivial stuff to implement, in fact, Bill Perry have already
implemented it (not that W3 is trivial, but this part is).  It just
needs to be integrated, and an example wizard.  As we get practical
experience from writing wizards, we would write more widgets and more
Lisp functions, making the progress evolutionary.

Re: Wizards and W3 integration

[Raymond Scholz]

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

> It is not the typing that is hard, but the design.  What are the
> really important questions for this application?  Which things can be
> safely assume?  How can we prensent the concept in a way the average
> user can understand?

Just to second the idea of wizard like configuration for Gnubies and
to increase my ego, I want to refer to a posting of mine on Robin's
Gnus tutorial mailinglist some months ago.  Back then, I was thinking
of an online HTML formulars generated by a CGI script.  So this comes
close to the idea of using W3 for this task.

https://mail.socha.net/cgi-bin/ezmlm-cgi?5:mss:5:200012:kdbjlnbhehdagjnikpmh

Cheers, Ray
-- 
WYSIWYG is a step backwards. Human labor is used to do that which the
computer can do better.                         (Andrew S. Tanenbaum)

Re[1]: Wizards and W3 integration (was: A road map for Oort Gnus)

[Eric M. Ludlam]

>>> Per Abrahamsen <abraham@dina.kvl.dk> seems to think that:
>Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>> 
  [ ... ]
>> > Depending on how much control is needed, it could be build upon either
>> > custom or the widget library.  I don't think the programming part will
>> > be that hard, the real challenge would be designing the wizards
>> > themselves. 
>> 
>> If we had a proper framework for building wizards, I think writing the
>> wizards themselves would be quite a lot of typing; yes, but not very
>> complicated typing.
>
>It is not the typing that is hard, but the design.  What are the
>really important questions for this application?  Which things can be
>safely assume?  How can we prensent the concept in a way the average
>user can understand?
>
>> I envision a kind of rule-based framework.  "The user has input this
>> and this information, and this and this exists on the system, so we
>> present the user with this information and these choices."
>> 
>> I don't think writing that kind of framework would be trivial...
>
>I envision a markup language with embedded widgets and embedded Lisp.
>Trivial stuff to implement, in fact, Bill Perry have already
>implemented it (not that W3 is trivial, but this part is).  It just
>needs to be integrated, and an example wizard.  As we get practical
>experience from writing wizards, we would write more widgets and more
>Lisp functions, making the progress evolutionary.
  [ ... ]

Hello,

  On the concept of wizards, dialog boxes, what have you, Paul
Kinnucan has a small wizard library, and a dialog box library which he
wrote for dealing with the complexities of the JDE, and all the
options it has.  (I added Paul the CC list above so he can correct me
if I make an error.)

  The dialog box stuff (which I am guessing would interest you most,
since his wizards are targeted at code generation using tempo) is
based on EIEIO (which I wrote, so naturally I think it's cool.  FSF
even has papers for it.)

  The idea is that he has several classes the create and manage dialog
boxes using custom's widgets.  To make a specific dialog box, you can
inherit from a base class, and make a specific instance.  This whole
system is then wired into the `interactive' command to extra spiffy
effect.

  So, the long and short of it is the `markup language' would be Emacs
Lisp, but I doubt that would bum any Emacs hackers out.  If it does,
the FSF just so happens to have papers for my parser generator which
would be perfect for parsing a simple deterministic invented
data-language.

  Not to bomb William Perry's efforts or anything, HTML is great at
this stuff too, and I like w3 in general.  Just another angle where
some solutions already exist.

Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: www.ultranet.com/~zappo            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Eli Zaretskii]

> From: Per Abrahamsen <abraham@dina.kvl.dk>
> Date: 14 Apr 2001 16:42:18 +0200
> 
> I have CC'ed it to the Emacs developers list, both Setup Wizards and
> W3 integration are big questions that affect all of Emacs, not just
> Gnus.

Windows users might know what setup wizards are (assuming that _I_
understood you correctly), but others probably don't.  Regardless,
someone should probably post a summary of the problem and previous
discussions for those on emacs-devel who don't read ding.

Also, Richard Stallman doesn't read emacs-devel, so if you want his
opinion, CC him directly.

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Lars Magne Ingebrigtsen]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Windows users might know what setup wizards are (assuming that _I_
> understood you correctly), but others probably don't.  Regardless,
> someone should probably post a summary of the problem and previous
> discussions for those on emacs-devel who don't read ding.

A "setup wizard" is a program that guides you through setting up
something.  As opposed to preference settings, a wizard lets you take
only certain steps, and checks that the steps are reasonable.

Let's take the simplest wizard possible: Starting reading news (and
only news) with Gnus.  The wizard would ask (after checking the
environment as determining that the user has no previous preference)
-- "do you want to read news from a local spool or from a news
server?"  If the user answers "local spool", the wizard would check
whether there is a spool in any of the usual places, and if it finds
one, it will suggest using that spool.  If not, it will tell the user,
and let the user determine what to do.  (For instance, going back to
choosing a news server.)  The user says "news server", the wizard will
try pinging "news.<isp-name>" to see whether that exists, and if it
does, present that as the choice, and if not, etc.

Ideally, a wizard should let the user press "Ok" several times, and
the user should then have something that works.

The name "setup wizard" sucks, though.  "Setup Saint" would be much
better.  "Let Saint Ignucious Guide You."  With a nice iconic
Ignucious.  Or something.

Perhaps not.

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

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: 16 Apr 2001 18:49:12 +0200
> 
> Let's take the simplest wizard possible: Starting reading news (and
> only news) with Gnus.  The wizard would ask (after checking the
> environment as determining that the user has no previous preference)
> -- "do you want to read news from a local spool or from a news
> server?"  If the user answers "local spool", the wizard would check
> whether there is a spool in any of the usual places, and if it finds
> one, it will suggest using that spool.  If not, it will tell the user,
> and let the user determine what to do.  (For instance, going back to
> choosing a news server.)  The user says "news server", the wizard will
> try pinging "news.<isp-name>" to see whether that exists, and if it
> does, present that as the choice, and if not, etc.

Thanks for a nice summary.

Given this description, I don't understand how did you get to
discussing HTML and W3.  This sounds like a possible extension of
Customize, plus some glue to go through several options in a
predefined order.  Am I missing something?

> Ideally, a wizard should let the user press "Ok" several times, and
> the user should then have something that works.

If the user needs just to press OK, then that user doesn't need a
wizard: the defaults should be automatic.

But this is nitpicking on my part, really.

> The name "setup wizard" sucks, though.

As does every buzzword Microsoft invents...

> "Setup Saint" would be much
> better.  "Let Saint Ignucious Guide You."

iGNUcious?

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Per Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Given this description, I don't understand how did you get to
> discussing HTML and W3.  This sounds like a possible extension of
> Customize, plus some glue to go through several options in a
> predefined order.  Am I missing something?

Basically, there are four proposals.

#1. To use HTML with embedded customize widgets and Emacs Lisp as the
basis for the saints.  Basically, an interactive tutorial where you
can set the options directly from the tutorial using embedded
customize widget, with the smartness (if any) programmed with embedded
Emacs Lisp.

This is already implemented in Bill Perrys W3.  Demonstration at

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

(one embedded customize widget, no smartness).  The page only make
sense with Emacs W3.

In your words, we would use HTML as the glue between the options.

#2. Some kind of rule based knowledge base, proposed by Lars.  I have
no idea what this would 

#3. Use the saint foundation developed for JDE.  Apparently, this is
an Emacs Lisp only solution using a library build on top of customize
and eieio. 

#4. A pure customize solution.  The customize framework already allows
special purpose groups with existing options listed in a specific
order.  I wrote one for Gnus as a demonstration, which I have attached
to this message.  Load the file, and type 'M-x gnus-virgin <ret>'.

...

My preference is #1, but even though it is already implemented, it is
mostly useless as long as w3 is not integrated in Emacs.  


[-- Attachment #2: Gnus Saint --]
[-- Type: application/emacs-lisp, Size: 4262 bytes --]

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Eli Zaretskii]

On 17 Apr 2001, Per Abrahamsen wrote:

> Basically, there are four proposals.
> 
> #1. To use HTML with embedded customize widgets and Emacs Lisp as the
> basis for the saints.  Basically, an interactive tutorial where you
> can set the options directly from the tutorial using embedded
> customize widget, with the smartness (if any) programmed with embedded
> Emacs Lisp.
[...]
> My preference is #1

Could you tell why?  Basically what I don't understand is how does HTML 
come into the equation.  That is, why does it make sense to use HTML for 
such a purpose?

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Per Abrahamsen]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Could you tell why?  Basically what I don't understand is how does HTML 
> come into the equation.  That is, why does it make sense to use HTML for 
> such a purpose?

Why use a markup language as glue, or why use HTML as the markup language?

Reasons to use a markup language as glue: 
-----------------------------------------

I'm more interested in the documentation aspects of the saint, than in
the smartness aspect of the saint.  In most cases, I prefer the saint
to tell the user what to do, instead of just doing it.  It doesn't
hurt if the user learn the basic options during setup, so he easier
can change them later.

Markup languages are much better for documentation than Emacs Lisp or
knowledge bases, that is why I prefer a markup language.

Reasons to use HTML as a markup.
--------------------------------

W3 already exists and its forms are based on the same widget library
as customize which made it easier to .  Also, HTML is well known,
making it easier to get people to write saints.  And because of the
url library, everyone can write saints and place them on their
homepage.  For example, Gnus is very popular and has some very
enthusiastic promoters in Germany.  They would most likely create a
German saint for Gnus, and link to it from the existing German Gnus
pages.

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Eli Zaretskii]

> From: Per Abrahamsen <abraham@dina.kvl.dk>
> Date: 17 Apr 2001 15:43:30 +0200
> 
> Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
> > Could you tell why?  Basically what I don't understand is how does HTML 
> > come into the equation.  That is, why does it make sense to use HTML for 
> > such a purpose?
> 
> Why use a markup language as glue, or why use HTML as the markup language?

The former.

> Reasons to use a markup language as glue: 
> -----------------------------------------
> 
> I'm more interested in the documentation aspects of the saint, than in
> the smartness aspect of the saint.  In most cases, I prefer the saint
> to tell the user what to do, instead of just doing it.

Thanks, I think I understand now.  I was thinking about the other type
of saint (the one which does the setup after asking some simple
questions, instead of telling the user what to do).

> Also, HTML is well known, making it easier to get people to write
> saints.

Well, assuming that the saind is written by the package
author/maintainer, I think they would know enough Lisp as well.

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Per Abrahamsen]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Well, assuming that the saind is written by the package
> author/maintainer, I think they would know enough Lisp as well.

But Lisp is not a markup language.

And the assumption is rarely true, as far as I can see most free
software tutorials are written by someone else than the programmer.  I
suspect that the qualifications for writing robust and flexible
software and easy to understand tutorials are very different.

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Kai Großjohann]

On 17 Apr 2001, Per Abrahamsen wrote:

> And the assumption is rarely true, as far as I can see most free
> software tutorials are written by someone else than the programmer.

Maybe saints occupy a middle ground between gods^H^H^H^Hprogrammers
and mere mortals^H^H^H^H^H^H^H^H^H^H^H^Hnonprogrammers.

kai
-- 
Be indiscrete.  Do it continuously.

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Laura Conrad]

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

    Per> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
    >> Well, assuming that the saind is written by the package
    >> author/maintainer, I think they would know enough Lisp as well.

    Per> But Lisp is not a markup language.

    Per> And the assumption is rarely true, as far as I can see most free
    Per> software tutorials are written by someone else than the programmer.  I
    Per> suspect that the qualifications for writing robust and flexible
    Per> software and easy to understand tutorials are very different.

Also, even if you have both sets of qualifications, right after
designing and implementing a complicated piece of software isn't the
best time to write the instructions for the beginner.

-- 
Laura (mailto:lconrad@laymusic.org)
http://www.laymusic.org : Putting live music back in the living room.

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[William M. Perry]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On 17 Apr 2001, Per Abrahamsen wrote:
> 
> > Basically, there are four proposals.
> > 
> > #1. To use HTML with embedded customize widgets and Emacs Lisp as the
> > basis for the saints.  Basically, an interactive tutorial where you
> > can set the options directly from the tutorial using embedded
> > customize widget, with the smartness (if any) programmed with embedded
> > Emacs Lisp.
> [...]
> > My preference is #1
> 
> Could you tell why?  Basically what I don't understand is how does HTML
> come into the equation.  That is, why does it make sense to use HTML for
> such a purpose?

One reason could be for linking to other web sites with specific
information about where you are in the wizard.  The current :link stuff in
custom isn't really sufficient.  Links should be in the flow of the main
text, not at the end in a see-also section.

Unfortunately with w3 effectively orphaned until I find some time to get
the savannah pages set up and recruit some people to replace me, I think
using an XML file for the description of the steps in the wizard and an
elisp interface to draw text & links & widgets from that is the best way to
go.

-bp

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Eli Zaretskii]

> From: wmperry@gnu.org (William M. Perry)
> Date: 17 Apr 2001 08:57:20 -0500
> > 
> > Could you tell why?  Basically what I don't understand is how does HTML
> > come into the equation.  That is, why does it make sense to use HTML for
> > such a purpose?
> 
> One reason could be for linking to other web sites with specific
> information about where you are in the wizard.

The setup wizards I've seen didn't need any links to Web sites.  What
would they be used for? suggestions to upgrade?

Re: Wizards and W3 integration (was: Re: A road map for Oort Gnus)

[Kai Großjohann]

On 16 Apr 2001, Lars Magne Ingebrigtsen wrote:

> The name "setup wizard" sucks, though.  "Setup Saint" would be much
> better.  "Let Saint Ignucious Guide You."  With a nice iconic
> Ignucious.  Or something.

Way to go!

kai
-- 
Be indiscrete.  Do it continuously.

Re: Wizards and W3 integration

[Robin S. Socha]

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

> The name "setup wizard" sucks, though.  "Setup Saint" would be much
> better.  "Let Saint Ignucious Guide You."  With a nice iconic
> Ignucious.  Or something.

Emacs is ugly enough as it is. Don't bring RMS into this. Please.
-- 
Robin S. Socha  <http://my.gnus.org/>

Re: Wizards and W3 integration

[Eli Zaretskii]

On 16 Apr 2001, Robin S. Socha wrote:

> * Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > The name "setup wizard" sucks, though.  "Setup Saint" would be much
> > better.  "Let Saint Ignucious Guide You."  With a nice iconic
> > Ignucious.  Or something.
> 
> Emacs is ugly enough as it is. Don't bring RMS into this. Please.

I think Emacs is the cleanest, prettiest piece of software ever
written in the history of mankind, and RMS is the nicest and greatest
person I've ever met.

Re: Wizards and W3 integration

[Norbert Koch]

Eli Zaretskii <eliz@is.elta.co.il> writes:

>> Emacs is ugly enough as it is. Don't bring RMS into this. Please.
> 
> I think Emacs is the cleanest, prettiest piece of software ever
> written in the history of mankind, and RMS is the nicest and greatest
> person I've ever met.

Next thing you tell us is that you'd like to run all your apps on a
certain, err, OS created in Redmond :-)

Re: Wizards and W3 integration

[Robin S. Socha]

* Eli Zaretskii <eliz@is.elta.co.il> [010417 02:03]:
> On 16 Apr 2001, Robin S. Socha wrote:
> > * Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > > The name "setup wizard" sucks, though.  "Setup Saint" would be much
> > > better.  "Let Saint Ignucious Guide You."  With a nice iconic
> > > Ignucious.  Or something.
> > 
> > Emacs is ugly enough as it is. Don't bring RMS into this. Please.
> 
> I think Emacs is the cleanest, prettiest piece of software ever
> written in the history of mankind, 

Yeah, right, like
http://my.gnus.org/mig.php?currDir=./Gnus/Kai_Grossjohann&pageType=image&image=ss-article.png

OTOH, we have XEmacs, whichi is good, because XEmacs ist pretty:
http://my.gnus.org/mig.php?currDir=./Gnus/Robin_S_Socha/GTK-XEmacs&pageType=image&image=group-buffer-chrome.gif

> and RMS is the nicest and greatest person I've ever met.

He may be nice and great. But, I mean, ummm... how to put it...
http://www.stallman.org/saintignucius.jpg is not a really pretty sight
to behold.

Re: Wizards and W3 integration

[Michael Livshin]

"Robin S. Socha" <rsocha@kens.com> writes:

> Yeah, right, like
> http://my.gnus.org/mig.php?currDir=./Gnus/Kai_Grossjohann&pageType=image&image=ss-article.png
> 
> OTOH, we have XEmacs, whichi is good, because XEmacs ist pretty:
>
> http://my.gnus.org/mig.php?currDir=./Gnus/Robin_S_Socha/GTK-XEmacs&pageType=image&image=group-buffer-chrome.gif

the only immediately visible differences between these two pictures are:

* the second one features a toolbar.  this is not very important.

* the second one features red text on almost-black background.  this
  is both ugly and, much more importantly, unreadable.

so I'll just assume you are sarcastic, OK?

> He may be nice and great. But, I mean, ummm... how to put it...
> http://www.stallman.org/saintignucius.jpg is not a really pretty sight
> to behold.

you are either sarcastic to a sick degree or you just can't bear a
sight of RMS for some deep psychological reason.

why?  what has he done to you?

I'd rather stare at a thousand pictures of RMS than read red text on
black background.  hell, I'd rather have my eyes clawed out than read
red text on black background.

--mike,
who also happens to use XEmacs but apparently for different reasons.

-- 
(only legal replies to this address are accepted)

Debugging? Klingons do not debug. Our software does not coddle the
weak.
                                        -- Klingon Programmer

Re: Wizards and W3 integration

[Robin S. Socha]

* Michael Livshin <mlivshin@yahoo.com> [010417 10:19]:
> "Robin S. Socha" <rsocha@kens.com> writes:

> > He may be nice and great. But, I mean, ummm... how to put it...
> > http://www.stallman.org/saintignucius.jpg is not a really pretty sight
> > to behold.
> 
> you are either sarcastic to a sick degree or you just can't bear a
> sight of RMS for some deep psychological reason.

Sick, Michael. Very sick. And you need a new irony detector.

[noise] Re: Wizards and W3 integration

[Michael Livshin]

"Robin S. Socha" <robin@socha.net> writes:

> * Michael Livshin <mlivshin@yahoo.com> [010417 10:19]:
> > "Robin S. Socha" <rsocha@kens.com> writes:
> 
> > > He may be nice and great. But, I mean, ummm... how to put it...
> > > http://www.stallman.org/saintignucius.jpg is not a really pretty sight
> > > to behold.
> > 
> > you are either sarcastic to a sick degree or you just can't bear a
> > sight of RMS for some deep psychological reason.
> 
> Sick, Michael. Very sick. And you need a new irony detector.

color me thick, then.  where's the alleged irony?

and what's your point, while you are at it?  that all those fluffy
naive newbies will flee at the sight of St. iGNUcious?  I don't think
so.

-- 
(only legal replies to this address are accepted)

This program posts news to billions of machines throughout the galaxy.  Your
message will cost the net enough to bankrupt your entire planet.  As a result
your species will be sold into slavery.  Be sure you know what you are doing.
Are you absolutely sure you want to do this? [yn] y

Re: A road map for Oort Gnus

[Robin S. Socha]

* Lars Magne Ingebrigtsen <larsi@gnus.org> [010414 06:35]:
> gnu.emacs.gnus is pretty busy.  There seems to be quite a lot of new
> Gnus users -- my impression is that there's more new Gnus users now
> than ever before, which is pretty surprising.  

It isn't. Count the German-speaking ones. A couple of people in the
de.ALL hierarchy have been very, ummm... noisy over the last few years.
And with sites like http://go.to/wingnus/, Gnus is becoming usable for
Wintendo users, too.

> That view may be wrong, and it may just be that Gnus is attracting a
> new kind of user -- the kind that expects things to, like, work, and
> doesn't really put up with having to spend hours setting things up.
> This kind of user generates more traffic on the newsgroup than the
> hard-core computer hacker kind of person.

Hence the idea to put up resources.gnus.org - Gnus rules supreme, but
the new breed of users is also much used to WWW instead of news. They
are also used to communities, hence my playing around with
http://socha.net/. The tool I use there is pretty much ideal for a site
that is geared towards newbies. 

> Even so, I think Gnus should focus on ease of (initial) use.  Ideally,
> someone who has never used Gnus before should be able to say `M-x
> gnus' and just having things work.  That's not realistic, but I think
> it should be realistic to have the user spend less time than setting
> up, say, Outlook Express.  

Why is it unrealistic? If M-x gnus checked for "gnus-never-used-before"
and opened a simplified version of M-x customize gnus, it would work.

> There you have to maneuver through a quite large number of menus, and
> specify some quite bewildering settings, to get started.  We can do
> better.

Make a poll. I mean it. Ask people what they need to have set up to make
their stuff work. I'm sure that 90% or more will go: "newsserver,
username and organization, mail source, IMAP". Put it in that customize
buffer. Done.

> These are quite general thoughts on Gnusiness, and I think there are
> probably many ways to achieve these goals.  (If that's what we want to
> do.  We may, perhaps, not want to do this.)  Kai has suggested
> detecting whether the user is a first-time user, and then guiding her
> through the setup process.  Per has suggested setup wizards.  

That was /ME/!!!1 *harrump* It's still a very valid point, though.

> I have (on gnu.emacs.gnus, recently) suggested a different version of
> setup wizards.  (I think.  Perhaps I should repost it here?)

Please do.

> So.  Ideas?  Thoughts?  Flames?

I think that Gnus is pretty much perfect now. I couldn't think of any
substantial things missing. It's the periphery that could do with some
improvements:

* Website for new users;
* Link farm with ratings, good explanations etc.;
* a tutorial (Kai and Matthias have improved the stuff we're working on,
  take a look at http://www.kens.com/cgi-bin/cvsweb.cgi/gnus-tutorial/).
  You can join the mailing list here:
  mailto:gnus-tutorial-subscribe@socha.net
  The archvives are here: https://mail.socha.net/cgi-bin/ezmlm-cgi?5

Documentation is very boring, but I think it's needed.

Flame away ;-)
Robin

Re: A road map for Oort Gnus

[Harry Putnam]

"Robin S. Socha" <rsocha@kens.com> writes:

> I think that Gnus is pretty much perfect now. I couldn't think of any
> substantial things missing. It's the periphery that could do with some
> improvements:

Not sure what Robin counts as periphery, but since about quassia-16 or
so (pre Robin I think..) the `agent' has been a factor, more or less
central depending on the type hookup people have.  Or there desire to
be able to manipulate news on disk.

That area is still `unfinished'.  It needs to have the many niceties
that are possible with the nnml backend extended to it.

It needs:
1)  sophisticated expiry 
2)  In group editing 
3)  Hand deletion in place if desired
4)  Movement of messages from one group to another if desired

Most importantly
5) gnus-agent-generate-nov-databases  In general and in specific groups

In brief, every kind of file manipulation that pertains to mail files
on disk.

Re: A road map for Oort Gnus

[Lars Magne Ingebrigtsen]

"Robin S. Socha" <rsocha@kens.com> writes:

> It isn't. Count the German-speaking ones. A couple of people in the
> de.ALL hierarchy have been very, ummm... noisy over the last few years.

Gee.  I wonder who that could be.  :-)

> And with sites like http://go.to/wingnus/, Gnus is becoming usable for
> Wintendo users, too.

Gosh.  I had no idea.  "Genug davon, sich belehren zu lassen, daß Gnus
der Newsreader der Götter sei?"  :-)

> > Even so, I think Gnus should focus on ease of (initial) use.  Ideally,
> > someone who has never used Gnus before should be able to say `M-x
> > gnus' and just having things work.  That's not realistic, but I think
> > it should be realistic to have the user spend less time than setting
> > up, say, Outlook Express.  
> 
> Why is it unrealistic? If M-x gnus checked for "gnus-never-used-before"
> and opened a simplified version of M-x customize gnus, it would work.

Yes, that's what I meant.  It's unrealistic to have `M-x gnus' work
without gathering information from the user first.

> > These are quite general thoughts on Gnusiness, and I think there are
> > probably many ways to achieve these goals.  (If that's what we want to
> > do.  We may, perhaps, not want to do this.)  Kai has suggested
> > detecting whether the user is a first-time user, and then guiding her
> > through the setup process.  Per has suggested setup wizards.  
> 
> That was /ME/!!!1 *harrump* It's still a very valid point, though.

:-)

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

Re: A road map for Oort Gnus

[Albert Krusbersky]

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

> "Robin S. Socha" <rsocha@kens.com> writes:
> 
> > It isn't. Count the German-speaking ones. A couple of people in the
> > de.ALL hierarchy have been very, ummm... noisy over the last few years.
> 
> Gee.  I wonder who that could be.  :-)
> 
> > And with sites like http://go.to/wingnus/, Gnus is becoming usable for
> > Wintendo users, too.
> 
> Gosh.  I had no idea.  "Genug davon, sich belehren zu lassen, daß Gnus
> der Newsreader der Götter sei?"  :-)
> 

My way (as native german speaking blond man ;-) ) to a Linux-System
was via XEmacs 21.2 for Windows with gnus and the famos Hamster as
local News- and Mail-Server.

I was dissatisfied with the behavior of OutlookExpress, and an other
Hamsteruser told me to give XEmacs/gnus a Chance.

I did the Download, installed XEmacs and tried to run gnus. After some
mails changed with Michael and the Book "Emacs in 24 hours" i got gnus
running. Reading the dinglist was also helpful.

In January i changed my Operating System (von Betrübssystem to
Betriebssystem (can't translate it)). The most easy Part was to
migrate my mails from Windows to Linux. Under Windows i also used the
concept of Homedirectory. I burned the custumization Files and Mail-
and News Filestructure on CDRom. These files were copied in my Linux
Home-Directory and that was it. No Messages lost! And the Sorting- and
Scoring-Rules are working fine. The only change was to tell gnus
running agentised. 

Give the Windows-User a Chance to taste the smell of the
World of Linux ;-) Maybe one or more will show Bill Gates their Back.

I believe, with the comming Registration Policy of M*crosoft, more and
more users look for alternatives.

An "easy initalising" script will be helpful, because for GUI-Users,
there is competition (Konkurrenz)  by KMail and KNode. They have the
Look and Feel of Outlook Excess.

Just my 2 cents
Albert.
-- 
Don't take your Organs to Heaven, Heaven knows we need them here.
                  Organspende rettet Leben.
We have 2 Ears and 1 Tounge to listen twice before speaking once, but
I'm wondering to have only 2 Eyes but 10 Fingers to write on Keyboard

Re: A road map for Oort Gnus

[Per Abrahamsen]

"Robin S. Socha" <rsocha@kens.com> writes:

> Make a poll. I mean it. Ask people what they need to have set up to make
> their stuff work. I'm sure that 90% or more will go: "newsserver,
> username and organization, mail source, IMAP". Put it in that customize
> buffer. Done.

Hmm...  Ok, try the code below.  

What a markup language would by us over a pure customize solution
(like the one below) would to get rid of the too general and lispy doc
strings and maybe some more of the customize artifacts, and getting
the options closer (in the buffer) to their English description.

My "imap" explanation is probably off, I have never used imap.

;;; gnus-virgin.el --- Run Gnus for the very first time.
;;
;; Copyright (C) 2001 Free Software Foundation, Inc.
;;
;; Author: Per Abrahamsen <abraham@dina.kvl.dk>
;; Keywords: news, mail, help
;;
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2 of the License, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; if not, write to the
;; Free Software Foundation, Inc., 59 Temple Place, Suite 330,
;; Boston, MA 02111-1307, USA.

;;; Comments:
;;
;; Gentle introduction to Gnus.

;;; Code: 

(defcustom gnus-virgin t 
  "Non-nil (on) means user haven't finished Gnus setup yet.
Set this option to false if you want to avoid getting this buffer next
time you start Gnus.  That is, you *must* unset this flag in order to
start Gnus for real."
  :type 'boolean)
(makunbound 'gnus-virgin)

(defgroup gnus-virgin '((gnus-virgin custom-variable)
			(user-full-name custom-variable)
			(user-mail-address custom-variable)
			(message-user-organization custom-variable)
			(gnus-select-method custom-variable)
			(gnus-secondary-select-methods custom-variable))
  "Setup Gnus for the very first time.

This buffer contains the options that most people need to set in order
to use Gnus for reading Mail and Usenet newsgroups.  You should look
at each of the options below (use the \"Show\" buttons when needed),
set their value as appropriate, and then press the \"Save for Future
Sessions\" button.  Viola!  Gnus should be ready to use.  You can then
start Gnus by typing with `M-x gnus <ret>'. If you ever want to
revisit these option, type `M-x customize-group <ret> gnus-virgin
<ret>'.

Please note that there are many more options in Gnus than those listed
below.  Just about everything about Gnus is customizable.  To see all
the options, type `M-x customize-group <ret> gnus <ret>'.

Now about the individual options:

\"Virgin\": Set this to off using the Toggle button, efter you have
finished with the other options.

\"User Full Name\" and \"User Mail Address\": Type in your name and
e-mail address in the text fields.

\"Message User Organization\": Select \"String\" by clicking the right
mouse button on the Value Menu, then enter the name of the
organization you want to be associated with in your mail and news messages.

\"Select Method\": Select \"nntp\" from teh Value Menu, then type in
the name of your news server in the text field below.  If you don't
know the name of your news server, ask your ISP.

\"Secondary Select Methods\": This one has two purposes, reading mail
and connecting to specialized news servers.  

Here is how to use it for mail.  Ignore it if you don't want to use
Gnus for reading mail.  If you *do* want to use Gnus for mail, be
warned that Gnus will download all your mail so you can't use other
mailers as well.  Stil here?  Good.  Gnus as a mail reader is strange,
but cool.  Type the Ins button.  A \"Select Method\" entry should
appear.  Now select \"nnimap\" from the Value Menu and type the name
of the server you want to read mail from.  Again, your ISP should know
the correct name.

Using it for extra news servers is similar.  Push the Ins button to
get a new \"Select Method\" entry.  Select \"nntp\" from the Value
Menu.  Write the address of the server you want to connect to in the
text field below.  Repeat for each server you want to read news.  Try
for example \"quimby.gnus.org\", a server that onbly carry Gnus
releated newsgroups."
  :link '(custom-manual "(gnus)Top")
  :link '(url-link :tag "Development Page" "http://www.gnus.org/")
  :prefix "gnus-"
  :group 'gnus
  :group 'wizards)

(defun gnus-virgin ()
  "Setup gnus for the very first time.  Please be gentle. 
Or just run it if already experienced."
  (interactive)
  (if gnus-virgin
      (customize-group 'gnus-virgin)
    (call-interactively 'gnus)))

;;; gnus-virgin.el ends here

Re: A road map for Oort Gnus

[Robin S. Socha]

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

> Hmm...  Ok, try the code below.

Ummmm...

Signaling: (void-variable gnus-virgin)
  (if gnus-virgin (customize-group (quote gnus-virgin)) (call-interactively (quote gnus)))
  (lambda nil "Setup gnus for the very first time.  Please be gentle. \nOr just run it if already experienced." (interactive) (if gnus-virgin (customize-group ...) (call-interactively ...)))()
  call-interactively(gnus-virgin)
  command-execute(gnus-virgin t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)
-- 
Robin S. Socha
Visit http://socha.net/gnus/ and submit your Gnus links

Re: A road map for Oort Gnus

[Kai Großjohann]

On 15 Apr 2001, Robin S. Socha wrote:

> Signaling: (void-variable gnus-virgin)

How can this be?  There's a defcustom for it!

kai
-- 
Be indiscrete.  Do it continuously.

Re: A road map for Oort Gnus

[Samuel Padgett]

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

> On 15 Apr 2001, Robin S. Socha wrote:
> 
> > Signaling: (void-variable gnus-virgin)
> 
> How can this be?  There's a defcustom for it!

And a matching `makunbound'...

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

gnus-virgin.el (was: Re: A road map for Oort Gnus)

[Per Abrahamsen]

Oops, I accidently left some debug code in.

;;; gnus-virgin.el --- Run Gnus for the very first time.
;;
;; Copyright (C) 2001 Free Software Foundation, Inc.
;;
;; Author: Per Abrahamsen <abraham@dina.kvl.dk>
;; Keywords: news, mail, help
;;
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2 of the License, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; if not, write to the
;; Free Software Foundation, Inc., 59 Temple Place, Suite 330,
;; Boston, MA 02111-1307, USA.

;;; Comments:
;;
;; Gentle introduction to Gnus.

;;; Code: 

(defcustom gnus-virgin t 
  "Non-nil (on) means user haven't finished Gnus setup yet.
Set this option to false if you want to avoid getting this buffer next
time you start Gnus.  That is, you *must* unset this flag in order to
start Gnus for real."
  :type 'boolean)

(defgroup gnus-virgin '((gnus-virgin custom-variable)
			(user-full-name custom-variable)
			(user-mail-address custom-variable)
			(message-user-organization custom-variable)
			(gnus-select-method custom-variable)
			(gnus-secondary-select-methods custom-variable))
  "Setup Gnus for the very first time.

This buffer contains the options that most people need to set in order
to use Gnus for reading Mail and Usenet newsgroups.  You should look
at each of the options below (use the \"Show\" buttons when needed),
set their value as appropriate, and then press the \"Save for Future
Sessions\" button.  Viola!  Gnus should be ready to use.  You can then
start Gnus by typing with `M-x gnus <ret>'. If you ever want to
revisit these option, type `M-x customize-group <ret> gnus-virgin
<ret>'.

Please note that there are many more options in Gnus than those listed
below.  Just about everything about Gnus is customizable.  To see all
the options, type `M-x customize-group <ret> gnus <ret>'.

Now about the individual options:

\"Virgin\": Set this to off using the Toggle button, efter you have
finished with the other options.

\"User Full Name\" and \"User Mail Address\": Type in your name and
e-mail address in the text fields.

\"Message User Organization\": Select \"String\" by clicking the right
mouse button on the Value Menu, then enter the name of the
organization you want to be associated with in your mail and news messages.

\"Select Method\": Select \"nntp\" from teh Value Menu, then type in
the name of your news server in the text field below.  If you don't
know the name of your news server, ask your ISP.

\"Secondary Select Methods\": This one has two purposes, reading mail
and connecting to specialized news servers.  

Here is how to use it for mail.  Ignore it if you don't want to use
Gnus for reading mail.  If you *do* want to use Gnus for mail, be
warned that Gnus will download all your mail so you can't use other
mailers as well.  Stil here?  Good.  Gnus as a mail reader is strange,
but cool.  Type the Ins button.  A \"Select Method\" entry should
appear.  Now select \"nnimap\" from the Value Menu and type the name
of the server you want to read mail from.  Again, your ISP should know
the correct name.

Using it for extra news servers is similar.  Push the Ins button to
get a new \"Select Method\" entry.  Select \"nntp\" from the Value
Menu.  Write the address of the server you want to connect to in the
text field below.  Repeat for each server you want to read news.  Try
for example \"quimby.gnus.org\", a server that onbly carry Gnus
releated newsgroups."
  :link '(custom-manual "(gnus)Top")
  :link '(url-link :tag "Development Page" "http://www.gnus.org/")
  :prefix "gnus-"
  :group 'gnus
  :group 'wizards)

(defun gnus-virgin ()
  "Setup gnus for the very first time.  Please be gentle. 
Or just run it if already experienced."
  (interactive)
  (if gnus-virgin
      (customize-group 'gnus-virgin)
    (call-interactively 'gnus)))

;;; gnus-virgin.el ends here

Re: gnus-virgin.el

[Robin S. Socha]

* Per Abrahamsen <abraham@dina.kvl.dk> writes:
> Oops, I accidently left some debug code in.

Very nice. I like that a lot!
-- 
Robin S. Socha, Evil Link Collector
Got anything Gnus-ish? Submit your stuff here: <http://socha.net/gnus/>

Re: gnus-virgin.el (was: Re: A road map for Oort Gnus)

[Didier Verna]

Per Abrahamsen wrote:

> Sessions\" button.  Viola!  Gnus should be ready to use.  You can then
                      ^^^^^

        Voilà !

Note: Viola basically means "raped" in French ;-)


-- 
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org

Re: gnus-virgin.el (was: Re: A road map for Oort Gnus)

[Per Abrahamsen]

Didier Verna <didier@lrde.epita.fr> writes:

> Per Abrahamsen wrote:
> 
> > Sessions\" button.  Viola!  Gnus should be ready to use.  You can then
>                       ^^^^^
> 
>         Voilà !
> 
> Note: Viola basically means "raped" in French ;-)

Well, excuse my French.  (I always wanted to say that).

Fixed.

Re: gnus-virgin.el (was: Re: A road map for Oort Gnus)

[Kai Großjohann]

On 17 Apr 2001, Didier Verna wrote:

> Note: Viola basically means "raped" in French ;-)

Viola means largish violin in German.  For whatever that's worth :-)
(The smallest instrument is a violin, then comes a viola, then the
violoncello.  Not sure what all these are in English.)

Hm.  http://dict.leo.org/ tells me it's the same in English as in
German.  Go figure...

I wonder if that has anything to do with the package title we're
talking about?

kai
-- 
Be indiscrete.  Do it continuously.

Re: gnus-virgin.el (was: Re: A road map for Oort Gnus)

[Didier Verna]

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

> Viola means largish violin in German.  For whatever that's worth :-)
> (The smallest instrument is a violin, then comes a viola, then the
> violoncello.  Not sure what all these are in English.)

        A "viola" is a "viole" in French, which is also the present time for
the verb "to rape".

> I wonder if that has anything to do with the package title we're
> talking about?

        ROTFL !

-- 
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org

Re: gnus-virgin.el (was: Re: A road map for Oort Gnus)

[Colin Marquardt]

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

> I wonder if that has anything to do with the package title we're
> talking about?

No idea :-) ... but I propose the following change:

;;; gnus-virgin.el --- To boldly frobnicate what no newbie has grokked before.


Cheers,
  Colin

Re: gnus-virgin.el (was: Re: A road map for Oort Gnus)

[Stainless Steel Rat]

* Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)  on Tue, 17 Apr 2001
| Viola means largish violin in German.  For whatever that's worth :-)
| (The smallest instrument is a violin, then comes a viola, then the
| violoncello.  Not sure what all these are in English.)

Nearly the same, though "cello violin" is usually shortened to "cello".
-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.

Re: A road map for Oort Gnus

[Christoph Rohland]

Hi Robin,

On Sat, 14 Apr 2001, Robin S. Socha wrote:
> Make a poll. I mean it. Ask people what they need to have set up to
> make their stuff work. I'm sure that 90% or more will go:
> "newsserver, username and organization, mail source, IMAP". Put it
> in that customize buffer. Done.

Fine, we agree IMAP is important.

[...]

> I think that Gnus is pretty much perfect now. I couldn't think of
> any substantial things missing. 

Oh boy, IMNSHO that's simply not true. Gnus is far away from
perfection (like any mail reader I know of). I am using Gnus since
several year and a lot. But I am still struggling often. I have three
major technical points:

1) Consistency of options: There are way too many different locations
   where the same information is stored. Two examples: Cached and
   agentized messages, information on the mail server in the various
   select message variables and in .newsrsc.eld.
2) Error recovery: It simply screws up it's different caches too often
   if something failes or changes in unpredicted ways.
3) IMAP support is far from perfect. Specially if you do unplugged
   work a lot over slow links, like I do. I know that there is no
   perfect mail reader. But look at the imap capabilities of mulberry
   and try it offline and you will see what I mean: Partly
   downloading, moving/creating/deleting messages while offline.
   I do not know if handling of uidvalidity issuesis working in
   mulberry but it is a nightmare in Gnus.

Don't get me wrong: Gnus is still the best mailreader I know of but
there is a lot room for improvement.

Greetings
		Christoph

Re: A road map for Oort Gnus

[Amos Gouaux]

>>>>> On 17 Apr 2001 10:49:14 +0200,
>>>>> Christoph Rohland <cr@sap.com> (cr) writes:

cr> 1) Consistency of options: There are way too many different locations
cr>    where the same information is stored. Two examples: Cached and
cr>    agentized messages, information on the mail server in the various
cr>    select message variables and in .newsrsc.eld.

Perhaps there's a way to do this and I just haven't stumbled onto it
yet, but how do you update or alter a server listed in
gnus-secondary-select-methods?  I wanted to alter the settings for
an IMAP server I'm using, and ran into much difficulty.  At the time
I guessed it was because things are so hardcoded in the .newsrsc.eld.

cr> Don't get me wrong: Gnus is still the best mailreader I know of but
cr> there is a lot room for improvement.

I love it too.  Though, when a member of our group asked about it
(being frustrated with PINE), I kinda cringed because it has taken
me quite a bit of time fiddling with things to get them close to
what I want, and typically I've found folks too impatient for that
kind of effort.

One thing I'd like to see, and I know it came up before, the ability
to only download parts of a message.  That's one thing IMAP is
really nice for.  Though I realize this gets back to the dependency
of the backend stuff.

-- 
Amos

Re: A road map for Oort Gnus

[Simon Josefsson]

Amos Gouaux <amos+lists.ding@utdallas.edu> writes:

> Perhaps there's a way to do this and I just haven't stumbled onto it
> yet, but how do you update or alter a server listed in
> gnus-secondary-select-methods?  I wanted to alter the settings for
> an IMAP server I'm using, and ran into much difficulty.  At the time
> I guessed it was because things are so hardcoded in the .newsrsc.eld.

Quit gnus, update gnus-secondary-select-method and search'n'replace
your .newsrc.eld. :-(   You could also C-k the groups, make the change,
restart gnus, and resubscribe to them.

Otherwise (I think) Gnus will create a new ephemeral server a'la
nnimap+yourserver+yourmailbox because it didn't find the .newsrc.eld
server definition in g-s-m or g-s-s-m, and there will be one network
connection for each IMAP group.  But I've never experienced this with
nntp or nnmail-backends, I wonder why?

Re: A road map for Oort Gnus

[Christoph Rohland]

Hi Simon,

On 17 Apr 2001, Simon Josefsson wrote:
> Quit gnus, update gnus-secondary-select-method and search'n'replace
> your .newsrc.eld. :-( You could also C-k the groups, make the
> change, restart gnus, and resubscribe to them.

You see my argument ;-)

Keep up the good work
        		Christoph

Re: A road map for Oort Gnus

[Kai Großjohann]

On 17 Apr 2001, Amos Gouaux wrote:

> Perhaps there's a way to do this and I just haven't stumbled onto it
> yet, but how do you update or alter a server listed in
> gnus-secondary-select-methods?

I have (nnml "") listed in gnus-secondary-select-methods, and the
string `(nnml' occurs nowhere in my ~/.newsrc.eld.  But to do that, I
had to edit .newsrc.eld manually to replace all occurrences of (nnml
"") for the groups with "nnml:".  (The select method a group comes
from is stored with each group, that's the spot I mean.)

Newly subscribed groups should have the server name automatically.

kai
-- 
Be indiscrete.  Do it continuously.

Re: A road map for Oort Gnus

[Kai Großjohann]

Another thing that's missing is the user manual for Gnus.

And there are a number of areas in Gnus where there are different ways
to achieve the same thing.  Maybe we should standardize on one way to
do it?

Some group-specific settings can be in the group parameters, others
need to be in the Local Variables section of the group parameters.
But it doesn't work for all variables -- the variables which are used
from the message buffers don't work as local variables from the group
parameters.

Then there is the possibility of setting things from
gnus-summary-mode-hook and from message-mode-hook.

And then there is gnus-parameters.

A second issue is the server specifications.

It seems that it is possible to put server specs like (nnml "foo"
...parameters...) in gnus-secondary-select-methods, but it's also
possible to create the "nnml:foo" server from the server buffer and
then add the string "nnml:foo" to gnus-secondary-select-methods.

A third issue is gnus-outgoing-message-group versus
gnus-message-archive-group which more or less do the same thing.

I'm sure there are other areas with similar non-orthogonality.

kai
-- 
Be indiscrete.  Do it continuously.

Re: A road map for Oort Gnus

[Lars Magne Ingebrigtsen]

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

> Another thing that's missing is the user manual for Gnus.

Yeah.  But with the tutorial that you and Robert's working on now, I
think we may be on our way to be getting something like that.  A
tutorial web page can be molded into a user manual with some care... 

> And there are a number of areas in Gnus where there are different ways
> to achieve the same thing.  Maybe we should standardize on one way to
> do it?

The things you mention are that way for (more or less) good reasons.
For instance, you have the group parameters, but you also have
variables that match on group names that give the same results as
group parameters.  The reason for that being that some users like to
write Lisp code, and others like to type `G c' on fifty groups.  And
so on.  Since people are different, there has to be different ways of
doing things.

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

Re: A road map for Oort Gnus

[Michael Livshin]

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

> For instance, you have the group parameters, but you also have
> variables that match on group names that give the same results as
> group parameters.  The reason for that being that some users like to
> write Lisp code, and others like to type `G c' on fifty groups.  And
> so on.  Since people are different, there has to be different ways of
> doing things.

now, that's not so simple.

take me for instance.  I'm your tipical mouse hating customize
avoider.

I have this humongous pile of fancy-splitting rules (along with some
helper functions and macros and stuff) that help me sort the incoming
mail into the various mailing list groups etc.

when I first heard about the existance of a way to split mail
according to `mail-to'/`list-to' group parameters, I thought "hey,
nice, I'd like to migrate to that".

well, it's been a year now, and I still haven't done that, and I still
keep adding rules to the fancy-split pile for every mailing list I
subscribe to.

I'd rather there was a way to say
`M-x gnus-dwim-grok-fancy-split-rules-and-set-group-parameters-accordingly'.

I don't know how feasible it is to write such a thing, but I'd rather
not use fancy splitting on the mail that goes into mailing lists.  so
from my POV, there is at least one "it" in Gnus for which there is one
way too many to do it -- but it might be that automatic migration is
just impossible.

sorry for rambling,
--mike

-- 
(only legal replies to this address are accepted)

Who's afraid of the garbage collector?

Re: A road map for Oort Gnus

[Kai Großjohann]

On 14 Apr 2001, Michael Livshin wrote:

> I'd rather there was a way to say `M-x
> gnus-dwim-grok-fancy-split-rules-and-set-group-parameters-accordingly'.

What if you have a fancy split rule that looks at the Subject header?

What if you have a complicated nested if/else structure, only parts of
which can be converted?

It should be possible to do something which works for a number of
cases, but I think it's necessary to at least have some graceful
failure mode in case nnmail-split-fancy turns out to be too complex
for the mechanism to handle.  I don't know how to implement that
graceful failure, though.

kai
-- 
Be indiscrete.  Do it continuously.

Re: A road map for Oort Gnus

[Didier Verna]

Lars Magne Ingebrigtsen wrote:

> The things you mention are that way for (more or less) good reasons.
> For instance, you have the group parameters, but you also have
> variables that match on group names that give the same results as
> group parameters.  The reason for that being that some users like to
> write Lisp code, and others like to type `G c' on fifty groups.  And
> so on.  Since people are different, there has to be different ways of
> doing things.

        Having different ways to do things is indeed a good thing (*not* to be
able to type G c fifty times, though :-). I even think there are somes places
at which more ways to do things would be required.

        For instance, I have on my gnus todo list an entry saying "add a
gnus-group-parameters variable", for when that makes sense of course (not
timestamp and stuff). This should be the usual list of (REGEXP VALUE) pairs,
the regexp matching group names, and the value being group parameters. The
inheritance being:

local group-parameters <- topic parameters <- gnus-group-parameters

pretty much like posting styles, actually.


        Having different ways to do it is indeed important but maybe not for
what you're saying here, Lars (people preferring custom or list code). It is
important because there are so many ways to organize your Gnus session that
there's no reason why things should be orthogonal. For instance, I have a
group buffer that is sorted by Mail / News, but then, I have an XEmacs Mail
topic which contains mostly mailing lists, but also some newsgroups... Without
these many ways to do things, it would be a nightmare to setup your
preferences in a concise (though complex) way.

        The question of actually mastering the Ways, and using them
efficiently is another story.

--
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org

Re: A road map for Oort Gnus

[Kai Großjohann]

On 17 Apr 2001, Didier Verna wrote:

> For instance, I have on my gnus todo list an entry saying "add a
> gnus-group-parameters variable", for when that makes sense of course
> (not timestamp and stuff). This should be the usual list of (REGEXP
> VALUE) pairs, the regexp matching group names, and the value being
> group parameters.

Is gnus-parameters good enough?

kai
-- 
Be indiscrete.  Do it continuously.

Re: A road map for Oort Gnus

[Didier Verna]

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

> Is gnus-parameters good enough?

        F*ck :-) This one is neither defcustom'ed nor documented so I missed
it. That's not exactly removing an entry from my todo list, rather modifying
its contents ;-)

-- 
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org

Re: A road map for Oort Gnus

[Didier Verna]

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

> It seems that it is possible to put server specs like (nnml "foo"
> ...parameters...) in gnus-secondary-select-methods, but it's also
> possible to create the "nnml:foo" server from the server buffer and
> then add the string "nnml:foo" to gnus-secondary-select-methods.

        BTW, what exactly is different between using
gnus-secondary-select-methods and setting up servers in the server buffer
(apart from the fact that secondary methods are read-only) ?  Maybe virtual
servers not in g-s-s-m are not opened at startup ?

-- 
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org

Re: A road map for Oort Gnus

[Kai Großjohann]

On 17 Apr 2001, Didier Verna wrote:

> BTW, what exactly is different between using
> gnus-secondary-select-methods and setting up servers in the server
> buffer (apart from the fact that secondary methods are read-only) ?
> Maybe virtual servers not in g-s-s-m are not opened at startup ?

Gnus checks for new groups in secondary servers, but not in foreign servers.

kai
-- 
Be indiscrete.  Do it continuously.

Re: A road map for Oort Gnus

[NAGY Andras]

Consider the big Gnus<->backend interface redesign too, in order to be
able to support `modern' backends with full functionality and good
performance (yes, I mean IMAP).

As far as I can see, this basically means these things:

- extend the interface to allow more complex `questions' to the
backend (i.e. number of new messages, flagged messages etc, instead of
the nntp-like low and high article number only)

- let the backend store readness and other status settings, if it is
able to, and do not redundantly store them in the frontend in this
case.

- OTOH, let the backend to store certain backend-specific info in the
frontend if it needs to (e.g. uidvalidity in the case of IMAP, which
is currently stored as a group parameter and looks quite ugly as
such).

- wrapper backend around backends understating the old protocol only,
for backwards compatibility.



Andras

Re: A road map for Oort Gnus

[Steinar Bang]

>>>>> NAGY Andras <nagya@inf.elte.hu>:

> Consider the big Gnus<->backend interface redesign too, in order to
> be able to support `modern' backends with full functionality and
> good performance (yes, I mean IMAP).

I'll second that.  Both the backend redesign, and the emphasis on
improving IMAP speed.

> As far as I can see, this basically means these things:
[snip!]

One thing left out: making the interface with the backend/server be
asynchronous. 

This could allow (much) improved IMAP performance, as well as avoid
locking up Gnus and all of emacs while updating or retrieving articles
from backends.

Re: A road map for Oort Gnus

[Kai Großjohann]

On 14 Apr 2001, NAGY Andras wrote:

> Consider the big Gnus<->backend interface redesign too, in order to
> be able to support `modern' backends with full functionality and
> good performance (yes, I mean IMAP).

Seconded.  This would allow one to store everything in one place, and
so maybe it would even become feasible to take some folders on the
road, and Gnus would know what to do with them (because the flags and
everything is stored inside the folder).

kai
-- 
Be indiscrete.  Do it continuously.

Re: A road map for Oort Gnus

[Amos Gouaux]

>>>>> On 16 Apr 2001 01:02:43 +0200,
>>>>> Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> (kg) writes:

kg> On 14 Apr 2001, NAGY Andras wrote:
>> Consider the big Gnus<->backend interface redesign too, in order to
>> be able to support `modern' backends with full functionality and
>> good performance (yes, I mean IMAP).

kg> Seconded.  This would allow one to store everything in one place, and
kg> so maybe it would even become feasible to take some folders on the
kg> road, and Gnus would know what to do with them (because the flags and
kg> everything is stored inside the folder).

Back in the nnimap list days, wasn't there some discussion about the
UID issue... news message IDs... ints.. ????

With the increasing popularity of IMAP, I should think these kinds
of tweaks would further the growth of gnus.

-- 
Amos

Re: A road map for Oort Gnus

[Doug Alcorn]

Amos Gouaux <amos+lists.ding@utdallas.edu> writes:

> With the increasing popularity of IMAP, I should think these kinds
> of tweaks would further the growth of gnus.

As one that has been looking for IMAP client alternatives, this is an
area that Gnus is already way out ahead on.  Providing server side
storage of many things that are done client side now (group
parameters, etc) could make Gnus the definitive IMAP client.
-- 
 (__) Doug Alcorn (mailto:doug@lathi.net http://www.lathi.net)
 oo / PGP 02B3 1E26 BCF2 9AAF 93F1  61D7 450C B264 3E63 D543
 |_/  If you're a capitalist and you have the best goods and they're
      free, you don't have to proselytize, you just have to wait. 

Re: A road map for Oort Gnus

[Paul Jarc]

NAGY Andras <nagya@inf.elte.hu> writes:
> Consider the big Gnus<->backend interface redesign too, in order to be
> able to support `modern' backends with full functionality and good
> performance (yes, I mean IMAP).

Perspective of a backend author: I'd like to see an interface that
doesn't require backends to maintain state independently of Gnus.
E.g., nnchoke-open-server would be passed the full select method, and
would return one of:
(success server-object)
(transient-failure "Error message describing what failed")
(more-serious-failure "Error message describing what failed")
... where the server-object is opaque to Gnus and meaningful to the
backend, and is passed back to the backend functions for operations on
that server; the backend wouldn't need to have a notion of a
"currently active server".

Similarly for groups - nnchoke-request-{list,groups} would return an
alist whose keys are interned group names, and whose data are opaque
group objects.  Or maybe an obarray instead of an alist; I'm not sure
which would be faster most of the time.  The opaque group object would
be handed back to the backend functions (with its associated server)
for operations on that group.

All data should be passed back to Gnus through function return values,
not nntp-server-buffer.  Some backends will easily be able to
structure the data into, e.g., NOV vectors, so it won't have to be
dumped into text form just to be extracted back out again.  Other
backends will have NOV text to deal with, so they can use a common set
of NOV-text-parsing functions.  For example.

> - extend the interface to allow more complex `questions' to the
> backend (i.e. number of new messages, flagged messages etc, instead of
> the nntp-like low and high article number only)

Also, more complex actions, like "move/copy article 123 from group foo
to group bar".

> - let the backend store readness and other status settings, if it is
> able to,

This is already done...

> and do not redundantly store them in the frontend in this case.

... but this is not.

> - OTOH, let the backend to store certain backend-specific info in the
> frontend if it needs to

Each backend could maintain its own data on disk, independently of
Gnus and other backends, maybe.


paul