Re: About the language for the mutt config tool
[08.03.02 00:03 +0100] Marco Fioretti -- : About this particular project: let's just do it in whatever language the majority of the volunteers is ALREADY proficient with, not with the one which the majority of the list thinks better for any reason. I do not agree to this, one thing I would ask you to consider: Take a language which you can expect to be present on minimal systems. Otherwise you might end up in dependencies which are no advantage for mutt. One of the advantages of console progs is that they do not need hundreds of extra languages installed to get them going. Speaking of installing a distro (which most beginners would do) those are already blown up enough, now imagine you would for example need a jre just for the mutt config tool .. -- speaking of compiling mutt yourself (which more experienced would do but which does not mean that they understand all the muttrc values) is even worse if (often seen) the documentation does not mention all dependencies. And as a result of that, it might happen that a user of netscape/kde/pine.. who has heard of mutts capabilities and wants to try that, will stay with his old one because the only alternate to those depencies would be vim+manual. Viewing from this point, perl would be a good choice and as far as I saw from former postings it might turn out to become perl. -- Erika Pacholleck [EMAIL PROTECTED] mutters: insert vowels of last name
Re: About the language for the mutt config tool
[08.03.02 00:03 +0100] Marco Fioretti -- : About this particular project: let's just do it in whatever language .. I do not agree to this, one thing I would ask you to consider: Take a language which you can expect to be present on minimal systems. Why, yes, of course! I was giving that for granted because we were speaking of console tools, and I assumed (wrongly) it meant the same thing Marco Fioretti
Re: About the language for the mutt config tool
On Fri, Mar 08, 2002 at 09:54:11AM +0100, Erika Pacholleck wrote: [08.03.02 00:03 +0100] Marco Fioretti -- : About this particular project: let's just do it in whatever language the majority of the volunteers is ALREADY proficient with, not with the one which the majority of the list thinks better for any reason. I do not agree to this, one thing I would ask you to consider: Take a language which you can expect to be present on minimal systems. Otherwise you might end up in dependencies which are no advantage for mutt. One of the advantages of console progs is that they do not need hundreds of extra languages installed to get them going. Speaking of installing a distro (which most beginners would do) those are already blown up enough, now imagine you would for example need a jre just for the mutt config tool .. -- speaking of compiling mutt yourself (which more experienced would do but which does not mean that they understand all the muttrc values) is even worse if (often seen) the documentation does not mention all dependencies. And as a result of that, it might happen that a user of netscape/kde/pine.. who has heard of mutts capabilities and wants to try that, will stay with his old one because the only alternate to those depencies would be vim+manual. Viewing from this point, perl would be a good choice and as far as I saw from former postings it might turn out to become perl. -- Erika Pacholleck [EMAIL PROTECTED] mutters: insert vowels of last name I agree with this logic; there's nothing that this shell script needs to do that can't be done with a Bourne shell script. That's the one interpreter you're always guaranteed to have. Now, having said that, I would imagine that most systems that have mutt installed will also have perl... :) -- John Buttery (Web page temporarily unavailable) msg25189/pgp0.pgp Description: PGP signature
Re: About the language for the mutt config tool
On Fri, Mar 08, 2002 at 12:03:56AM +0100, Marco Fioretti wrote: So, what language do the volunteers know better? I'll defenitly help if it's in perl, and will probably be useless in python. :) -- Dan Boger [EMAIL PROTECTED] msg25191/pgp0.pgp Description: PGP signature
Re: About the language for the mutt config tool
I'm going to reply to a bunch of messages all at once. I'm
attaching my first quick attempt at a configuration script; I've
called mutt-makeconfig, for lack of a better name. It's very
brute force, but it works. The config is very basic, enough to
get the bare minimum of personalized part of the process done
(ie, it sets realname, from, alternates, editor, folder,
mbox_type, print_command, and sendmail). It's written in perl,
uses only standard (5.00505+) modules, and runs reasonably fast.
The options it takes are --muttrc (where it should write the
file, default /tmp/muttrc-$USER) and --color (a useless option to
make it purty).
And, just so everyone knows, I'm not really attached to the
script, they way it does things, the language it's written in, or
the choice of colors on the screen, so spare no flames. :)
Quoting Will Yardley [EMAIL PROTECTED] in
[EMAIL PROTECTED]:
regarding cvs space, i've never setup a cvs pserver before; i'm
assuming this will be the easiest way to offer anonymous CVS
access. i doubt it's that hard to setup though.
Anonymous CVS access is not enough, because the folks working on
it will need write access; that means user accounts. If we make
it a sourceforge project, then all the hard work is handled for
us, at least in that department.
Quoting Michael Maibaum [EMAIL PROTECTED] in
[EMAIL PROTECTED]:
That is OK for read access, dubious for write access(which
should be by ssh probably), add a cvs module to the mutt.newbie
project at sourceforge?
This was my thought, either attach ourselves to the mutt-newbie
project or start a new project on sourceforge.
Quoting Erika Pacholleck [EMAIL PROTECTED] in [EMAIL PROTECTED]:
Take a language which you can expect to be present on minimal
systems. Otherwise you might end up in dependencies which are
no advantage for mutt. One of the advantages of console progs
is that they do not need hundreds of extra languages installed
to get them going.
Yes. Similarly:
Quoting John Buttery [EMAIL PROTECTED] in [EMAIL PROTECTED]:
I agree with this logic; there's nothing that this shell script
needs to do that can't be done with a Bourne shell script.
That's the one interpreter you're always guaranteed to have.
I agree entirely. sh is the most likely candidate, if we are
going for it to run absolutely everywhere (I'd say awk would be
the second, followed by perl). The script I've written doesn't
too (too many) Perl-ish things and should be strightforward to
port to whatever languagewe decide to use, if that's what is
wanted.
(darren)
--
The Feynman Problem 1) Write down the problem.
Solving Algorithm 2) Think real hard.
3) Write down the answer.
#!/usr/bin/perl
# --
# $Id$
# --
# Inital version by darren chamberlain [EMAIL PROTECTED]
# --
use strict;
use vars qw| $VERSION |;
use Sys::Hostname; # To determine the hostname
use Text::Wrap;
# --
# Set defaults and local (script-level) variables.
# --
$VERSION = sprintf %d.%02d, q$Revision: 1.1 $ =~ /(\d+)\.(\d+)/;
my $Muttrc = /tmp/muttrc-$ENV{USER};
my $help_only = undef;
# Normally, doing colors this way is kinda dumb; ANSI::Term and friends
# were designed to do this, but I wanted to ensure that no external
# modules were needed here. Besides, you have to explicitly ask for
# color, so by default nothing bad will happen.
my $color = undef;
my $red = ;
my $blue = ;
my $green = ;
my $norm = ;
# $ENV{COLUMNS} is some sh magic. COLUMNS is usually only defined when
# running under X, but we rely on it a little later, so we define
# it if it isn't already defined. Note that this does not propogate
# outwards to the parent process, so we're OK here.
$Text::Wrap::columns = $ENV{COLUMNS} ||= 80;
# --
# Get command line options, using the standard Getopt::Long module.
# --
use Getopt::Long;
GetOptions(
muttrc=s = \$Muttrc,
color! = \$color,
help!= \$help_only,
);
# Perhaps nocolor should be the default?
if (defined $color) {
$red = [1;31m;
$blue = [1;34m;
$green = [1;32m;
$norm = [0m;
}
my @config = ();# Lines that will become the config file
my %env = (); # Elements that will become the values
# ==
# main
# ==
populate_from_environment(\%env);
# --
# This is the banner, our short introduction to
Re: About the language for the mutt config tool
* darren chamberlain ([EMAIL PROTECTED]) wrote: I'm going to reply to a bunch of messages all at once. I'm attaching my first quick attempt at a configuration script; I've called mutt-makeconfig, for lack of a better name. It's very brute force, but it works. The config is very basic, enough to get the bare minimum of personalized part of the process done (ie, it sets realname, from, alternates, editor, folder, mbox_type, print_command, and sendmail). It's written in perl, uses only standard (5.00505+) modules, and runs reasonably fast. The options it takes are --muttrc (where it should write the file, default /tmp/muttrc-$USER) and --color (a useless option to make it purty). I think a major improvement would be to store the configuration file (sorry for the buzzword) metainfo seperately. Have a parsable file containg the options, possible values, and description. This will make adding new configuration directives much easier than writing (and reusing) code for each one. Opinions? And, just so everyone knows, I'm not really attached to the script, they way it does things, the language it's written in, or the choice of colors on the screen, so spare no flames. :) IT SUCKS! :) Quoting Will Yardley [EMAIL PROTECTED] in [EMAIL PROTECTED]: regarding cvs space, i've never setup a cvs pserver before; i'm assuming this will be the easiest way to offer anonymous CVS access. i doubt it's that hard to setup though. Anonymous CVS access is not enough, because the folks working on it will need write access; that means user accounts. If we make it a sourceforge project, then all the hard work is handled for us, at least in that department. sf.net was /made/ for this sort of project. It seems a shame not to use it. [...] I agree entirely. sh is the most likely candidate, if we are going for it to run absolutely everywhere (I'd say awk would be the second, followed by perl). The script I've written doesn't too (too many) Perl-ish things and should be strightforward to port to whatever languagewe decide to use, if that's what is wanted. I vote Perl, but it looks like that's the programming lingua franca for this list anyhow. The Feynman Problem 1) Write down the problem. Solving Algorithm 2) Think real hard. 3) Write down the answer. Have you read /Genius/ by James Gleick? Great book. /me sees the ball start to rock... mike ps: Coincidentily, I'm in the process of developing an ancillary tool for people trying to get GPG+mutt working fast and easy.
Re: About the language for the mutt config tool
Quoting Mike Erickson [EMAIL PROTECTED] [Mar 08, 2002 11:51]: I think a major improvement would be to store the configuration file (sorry for the buzzword) metainfo seperately. *nod* Have a parsable file containg the options, possible values, and description. This will make adding new configuration directives much easier than writing (and reusing) code for each one. Opinions? I tried that, but there seemed to be too many variations for it to be done in a way that (a) didn't take more than a hour or two (I was doing this on the train home last night ;), (b) could be easily ported to another language if we decide to not use Perl, and (c) took all the possibilities into consideration (other than string-based, boolean, and quad-options, there's the issue of alternates, which takes 0 or more addresses and makes a regex -- too hard to do in a generic way, without making each directive be code that gets evaluated at run time, which is cake for Perl but starts to become Perl only very quickly... ;). I like the mon does things: a master script that calls other scripts, and expects the script to send its results to STDOUT. We could do this, make what I wrote a shell script that basically does: for file in config/*; do results=`$i` echo $results $new_muttrc done And the individual config modules can just pull everything from %ENV (or os.environ or getenv() or whatever is appropriate). ps: Coincidentily, I'm in the process of developing an ancillary tool for people trying to get GPG+mutt working fast and easy. Cool! Can it be integrated, and, if not, can you send me a URL? I keep procrastinating... (darren) -- The rebootings will continue until the configuration works.
Re: About the language for the mutt config tool
darren chamberlain wrote:
This was my thought, either attach ourselves to the mutt-newbie
project or start a new project on sourceforge.
yeah that might be the best idea.
a few comments... the script looks like a good starting place. eek i
probably should have put line numbers on it somehow sorry.
i'm glad to see someone putting their money where their mouth is and
making some code : if some other people contribute, i'm sure we'll
have a very helpful tool (that's _hopefully_ easy to use) in no time.
does it create a backup if ~/.muttrc exists? doesn't look that way -
that might be a good idea.
# folder
# Where to put read mail by default (set folder=~/Mail)
i was envisioning checking to see if ~/Mail, ~/mail or both exist (or
don't exist) - then if only one exists that would be suggested as the
default; if both exist or don't exist, ~/Mail would be suggested.
# Where to put read mail (set mbox=~/mbox)
this might be a good place to also deal with move (yes or no) - ie
check first if they WANT to move mail after reading.
another common gotcha is that a lot of people don't like 'mark_old' - so
we might want to explain this variable and let people unset it.
/usr/sbin/sendmail -oem -oi);
not sure about this one - most people will want the default, but then
the real newbies might not want to use sendmail at all - i'm thinking
that giving people a chance to mess up the default flags to sendmail
might be bad though - perhaps better to offer to setup one of the really
lightweight sendmail replacements for them? does the one that's written
in perl actually work?
ie do you have an MTA like sendmail, postfix, or qmail configured on
your system? if not, choose 'n', and we'll explain your options.
however this might be a little outside of the scope of the project.
thoughts?
$env-{username} = $pw[0];
$env-{realname} = $gecos[0];
$env-{hostname} = hostname();
$env-{mailspool} = $ENV{MAIL};
$env-{editor}= $ENV{VISUAL} || $ENV{EDITOR} || builtin;
excellent. also, the script might want to suggest 'nano -t' or 'pico
-t' for newbies or people who are used to pine (even if $EDITOR is set
to something else).
Is user a pine or elm user? Offer contrib/{Pine,Tin}.rc keybindings
yes! i think that the suggestion to take the keybindings itself should
be modular somehow. also i think there is a more comprehensive set of
pine keybindings somewhere (maybe on sven's page) - the one in contrib/
only covers really basic stuff. for instance the main pine keybinding
that i'm attached to is ',' - i have this binding, which isn't quite
right, but close:
bind pager , exit
macro index , change-folder?tab
probably best to check for ~/.pinerc ~/.tin/ ~/.elm/ ~/.elm/ etc... if
more than one exists, ask for each.
is there any other data that we need in the template, or could it just
be as simple as copying contrib/blah.rc over?
3. POP, IMAP, PGP, SSL, etc
i think that IMAP might need to be integraded with spoolfile and folder
collection (ie if you're usng POP3 or IMAP should be one of the first
questions, and should influence the rest of the process).
some more advanced features we _might_ want to ask about. these are
my settings (which mostly differ from the default... i'm sure everyone
has a favorite feature and this list might start to get too long, but i
think we should ask about some / most of these)
* lists? i found the 'lists' feature confusing at first, but it's also one
of the best things about mutt. maybe at least offer a simple explanation
and stick some examples (commented) in the file?
* set delete=yes
* unset confirmappend
* unset mark_old (above)
* smart_wrap / unset markers, etc (wrap settings)
* MAYBE configuring a simple .mailcap for them to view html (if they
don't already have a .mailcap)
* weed settings (which headers to show perhaps offer a sensible
default for this, explaining how to change it???)
* maybe test for programs like enscript, etc on the system, and offer them
as suggestsions if they exist?
--
Will Yardley
william newdream . net
About the language for the mutt config tool
Hello, my two eurocent on this issue. Any language can be made readable or unreadable. Personally, I think that any program is readable if it has complete, up to date embedded comments explaining what is happening and meaningful variable names, even if the actual code looks like ancient Greek, scrambled. About this particular project: let's just do it in whatever language the majority of the volunteers is ALREADY proficient with, not with the one which the majority of the list thinks better for any reason. Otherwise it will never get done. Unless, of course, it already exist in another language and we just have to port it to the command line. Personally, I am very good with Perl and know (almost) nothing of Python, just because it happened so. I will help even if the thing is made in Python, it will be a good occasion to learn it, but of course will be less helpful in debugging. So, what language do the volunteers know better? Ciao, Marco Fioretti -- Any medium powerful enough to extend man's reach is powerful enough to topple his world. To get the medium's magic to work for one's aims rather than against them is to attain literacy. Alan Kay, Computer Software, Scientific American, Sep. 1984
Re: About the language for the mutt config tool
On Fri, Mar 08, 2002 at 12:03:56AM +0100, Marco Fioretti wrote: Any language can be made readable or unreadable. Personally, I think that any program is readable if it has complete, up to date embedded comments explaining what is happening and meaningful variable names, even if the actual code looks like ancient Greek, scrambled. Agreed. About this particular project: let's just do it in whatever language the majority of the volunteers is ALREADY proficient with, not with the one which the majority of the list thinks better for any reason. Otherwise it will never get done. Yup Personally, I am very good with Perl and know (almost) nothing of Python, just because it happened so. I will help even if the thing is made in Python, it will be a good occasion to learn it, but of course will be less helpful in debugging. ditto (modified to proficient rather than very good...) So, what language do the volunteers know better? Perl. Michael -- Dr Michael A. Maibaum - (W)+1 (415) 561 1682 - (H)+1 (415) 626 6733 [EMAIL PROTECTED] URL:http://www.gene-hacker.net/ msg25182/pgp0.pgp Description: PGP signature
Re: About the language for the mutt config tool
Michael Maibaum wrote: On Fri, Mar 08, 2002 at 12:03:56AM +0100, Marco Fioretti wrote: So, what language do the volunteers know better? Perl. my guess is that more people know perl well... that's nothing against python; from everything i've heard, python is a great language. i'm personally for whatever will make it easiest for people to contribute. should we start a list about this (either mutt.org or outside) to reduce all this chatter on the mutt-users list? if this project seems like something that people want to work on, i think that would be a good idea. regarding cvs space, i've never setup a cvs pserver before; i'm assuming this will be the easiest way to offer anonymous CVS access. i doubt it's that hard to setup though. -- Will Yardley william newdream . net
Re: About the language for the mutt config tool
On Thu, Mar 07, 2002 at 03:39:48PM -0800, Will Yardley wrote: Michael Maibaum wrote: On Fri, Mar 08, 2002 at 12:03:56AM +0100, Marco Fioretti wrote: So, what language do the volunteers know better? Perl. my guess is that more people know perl well... that's nothing against python; from everything i've heard, python is a great language. i'm personally for whatever will make it easiest for people to contribute. should we start a list about this (either @mutt.org or outside) to reduce all this chatter on the mutt-users list? if this project seems like something that people want to work on, i think that would be a good idea. Yup regarding cvs space, i've never setup a cvs pserver before; i'm assuming this will be the easiest way to offer anonymous CVS access. i doubt it's that hard to setup though. That is OK for read access, dubious for write access(which should be by ssh probably), add a cvs module to the mutt.newbie project at sourceforge? I set up a pserver for cvs on an intranet once, a while back. The howto we sufficient (google somewhere..). Michael -- Dr Michael A. Maibaum - (W)+1 (415) 561 1682 - (H)+1 (415) 626 6733 [EMAIL PROTECTED] URL:http://www.gene-hacker.net/ msg25184/pgp0.pgp Description: PGP signature
