Discussion:
[Fwd: Fwd: Suckless word processing solution?]
pancake
2009-10-06 08:43:53 UTC
Permalink
Sorry for the fwd:fwd..i had some mail issues
Szabolcs Nagy
2009-10-06 13:09:26 UTC
Permalink
Post by pancake
Sorry for the fwd:fwd..i had some mail issues
Content-Type: multipart/alternative; boundary=Apple-Mail-4--577211373


ffffffffffff
pancake
2009-10-06 14:26:21 UTC
Permalink
Post by Szabolcs Nagy
Post by pancake
Sorry for the fwd:fwd..i had some mail issues
Content-Type: multipart/alternative; boundary=Apple-Mail-4--577211373
Yeah I know, i'm a evil guy for replying mails from my ipod.

Did you got access to the rest of the mail and be able to construct a more
constructive response?
Post by Szabolcs Nagy
ffffffffffff
Is this -1?

PD: Actually I have not found a more fast, usable and simplest mail client
than the one shipped with iphone-os. And no, fetchmail,mutt,claws,telnet
are not decent solutions. Should we open another thread to create a suckless
mail client?

--pancake
Kurt H Maier
2009-10-06 14:44:14 UTC
Permalink
Post by pancake
PD: Actually I have not found a more fast, usable and simplest mail client
than the one shipped with iphone-os. And no, fetchmail,mutt,claws,telnet
are not decent solutions. Should we open another thread to create a suckless
mail client?
I wouldn't bother. IMAP is just as broken as the web.
--
# Kurt H Maier
markus schnalke
2009-10-06 15:09:40 UTC
Permalink
Post by pancake
PD: Actually I have not found a more fast, usable and simplest mail client
than the one shipped with iphone-os. And no, fetchmail,mutt,claws,telnet
are not decent solutions. Should we open another thread to create a suckless
mail client?
What do you mean with ``mail client''? MTA, MUA, MDA, or all of them in one?


meillo
pancake
2009-10-06 16:24:14 UTC
Permalink
Post by markus schnalke
Post by pancake
PD: Actually I have not found a more fast, usable and simplest mail client
than the one shipped with iphone-os. And no, fetchmail,mutt,claws,telnet
are not decent solutions. Should we open another thread to create a suckless
mail client?
What do you mean with ``mail client''? MTA, MUA, MDA, or all of them in one?
A solution that manages MTA, MUA, MDA and MDMA plus LSD in a simple
way.

This is:
- Keep a partial local cache of the mails (only last 50?)
- imap support server search, so why i have to mirror the folders
with 53200 mails?
- Only sync selected folders automatically or every N minutes
- Attachments should be only retrieved in a second stage (on slow
connections
is really useful)

Client must provide a simple tree way to walk on folders (filesystem?)
every time a mail is fetched a file is created and it is touched with
the specified timestamp.

I already wrote a patch for msmtp that checks for the MX entry for a
domain to
automatically specify the remote SMTP server, so no need to configure
any smtp
server for sending mails. I find this solution much simpler for most
situations (unless
you are on a restricted network that only allows you to connect to your
local smtp)

So, what I see here is a simple application that manages files in
directories and allows to create formatted files (using a template) on
some directories using $EDITOR,
a command to check files in Outbox to push them to remote servers and commit
them into the Sent directory.

The basic imap operations can be easily mapped as filesystem ones:
- list, copy, move, remove

Just having a simple application to manage pop3/smtp with those minimal
operations
and writing a simple frontend to edit files on certain directories based
on templates.

Stuff like gpg, html2text (or text2html for those who wants to raise
hate on mailing
lists), filters to format a mail into a 'reply' format prefixing lines
with '>' ... are just
pre and post-hooks when calling the $EDITOR or $PAGER.

The only missing thing I see in this model is the part of attached
files. This can be
solved by having a directory with the same filename of the mail plus
.files and have
an application to serialize mail+attachments into a single text stream
before sending
it to the smtp (maybe using msmtp) can be ideal.

To setup accounts I can think on a single entrypoint with simple format
that configures
the rest of applications to work with.

Multiple accounts should be managed by this approach. Marking emails as
read/...
can be just a sed script changing a header.

I have never understood why there is no decent mail implementation like
the one
explained above. The only problematic to implement such thing is the
lack of decent
smtp/pop/imap clients. I think that ssl support can be done by local
openssl bouncers.

Another *important* thing is that the SSL stuff must be checked, so in
this way you
can setup any kind of secure connection without having to reconfigure
your mail
client. This is: connecting to localhost:110 to bounce the socket to an
VPN or an DNSTX
network (or TOR, etc...), the client will just know nothing about the
underlying network,
and the bouncer app will be the one to ensure that the connection is not
broken.

Network *must* be an async dependency for a mail client, so I hate when
the client gets
locked because of a network cut or slowdown, it is just something that
cannot be understood
nowadays.

By having all this simple setup done (in a single package, please, i
dont want to configure
3 or 4 programs to get my email working) i can imagine a lot of
automatizations in scripts
to autoreply emails, filter spam, etc.. And the GUI is actually a
filesystem.

Email syncing is not only a thing of pop3/imap, we can also think on
using ssh or fuse to
access/sync to our remote mailboxes or maildirs.

--pancake
Kurt H Maier
2009-10-06 16:39:35 UTC
Permalink
Check out tinymail[1]. This guy took a pretty cerebral approach to
developing his MUA back-end library. I've used it in the form of
Modest[2] on my Nokia n810.

Personally, I'd hate to see any more dev hours wasted on garbage like
imap or pop3. ssh/rsyncing maildir to form a 'local copy,' then
'commiting' changes back seems much saner to me.

[1] - http://tinymail.org/
[2] - http://modest.garage.maemo.org/
--
# Kurt H Maier
Axel Bayerl
2009-10-06 18:46:19 UTC
Permalink
I have updated the patch of status colors to the latest hg rev (2bcd25cce4ab).
It works for me.



Yahoo! Cocina

Encontra las mejores recetas con Yahoo! Cocina.


http://ar.mujer.yahoo.com/cocina/
Anselm R Garbe
2009-10-13 16:54:18 UTC
Permalink
Feel free to always commit patches to the sites directory/wiki and add
the links to the right markdown page:

See http://suckless.org/wiki/ for how to use the wiki.

Thanks and kind regards,
Anselm
Post by Axel Bayerl
I have updated the patch of status colors to the latest hg rev (2bcd25cce4ab).
It works for me.
pancake
2009-10-07 14:10:00 UTC
Permalink
I've managed to build tinymail..but a gobject framework of 16MB size is
not exactly
minimal, tiny or suckless in any way.

The repository comes with no commandline or non-gtk dependent example.

I still think that it is possible to implement a smtp/pop3/imap protocol
handler in less
than 1000LOC, all protocols are text based and by just defining a few
functions for
handling timeouts, responses and so on shouldnt be that hard.

6 years ago I wrote a mail daemon (SMTP) in about 500LOC able to manage
mbox,
several auth methods and mutliple connections at the same time.

fetchmail has lot of unnecessary features and lacks many useful
functionalities.

msmtp is cool, but I always find it unnecesarily complex for the things
it has to do. For
example, the network layer if wrapped by a bouncer can permit to keep
connections
alive, add encription, tunels and many other funny stuff.

What I'm proposing is a simple setup with wrappers for
sendmail,msmtp,whatever that
can be exchanged by just changing a hook script.

About attaching files I have some minimal base64 algorithms, so it
should be that hard
to make it work in stream like:

$ cat mail | add-attachments mail.d/* | msmtp ***@to.com

And the same for extracting the attachments.

I dont really think this is a loss of time (yeah, you can hate me), but
I hate to be forced
to use bloatware everywhere.

I also use tinymail on the n810 because is the one that comes by default
in the last
firmwares because is just much better than the monolitic approach from
Nokia, but
having 16MB++ of memory slurped by a mail library on an embedded device
is imho
not a good thing. But I understand that having dbus to avoid doing
innecessary stuff
when the device is offline and earn battery is a good thing, but at
least I would prefer
to have my own minimal stack of mail management.


--pancake
Post by Kurt H Maier
Check out tinymail[1]. This guy took a pretty cerebral approach to
developing his MUA back-end library. I've used it in the form of
Modest[2] on my Nokia n810.
Personally, I'd hate to see any more dev hours wasted on garbage like
imap or pop3. ssh/rsyncing maildir to form a 'local copy,' then
'commiting' changes back seems much saner to me.
[1] - http://tinymail.org/
[2] - http://modest.garage.maemo.org/
Илья Илембитов
2009-10-07 14:43:34 UTC
Permalink
May I suggest you also take a look at OpenBSD's new smtpd? They will include it with the upcoming 4.6 release - a long awaited alternative to sendmail with a more clean config syntax (inspired by other OBSD-developed tools).
http://www.openbsd.org/cgi-bin/man.cgi?query=smtpd&sektion=8
Post by pancake
I've managed to build tinymail..but a gobject framework of 16MB size is
not exactly
minimal, tiny or suckless in any way.
The repository comes with no commandline or non-gtk dependent example.
I still think that it is possible to implement a smtp/pop3/imap protocol
handler in less
than 1000LOC, all protocols are text based and by just defining a few
functions for
handling timeouts, responses and so on shouldnt be that hard.
6 years ago I wrote a mail daemon (SMTP) in about 500LOC able to manage
mbox,
several auth methods and mutliple connections at the same time.
fetchmail has lot of unnecessary features and lacks many useful
functionalities.
msmtp is cool, but I always find it unnecesarily complex for the things
it has to do. For
example, the network layer if wrapped by a bouncer can permit to keep
connections
alive, add encription, tunels and many other funny stuff.
What I'm proposing is a simple setup with wrappers for
sendmail,msmtp,whatever that
can be exchanged by just changing a hook script.
About attaching files I have some minimal base64 algorithms, so it
should be that hard
And the same for extracting the attachments.
I dont really think this is a loss of time (yeah, you can hate me), but
I hate to be forced
to use bloatware everywhere.
I also use tinymail on the n810 because is the one that comes by default
in the last
firmwares because is just much better than the monolitic approach from
Nokia, but
having 16MB++ of memory slurped by a mail library on an embedded device
is imho
not a good thing. But I understand that having dbus to avoid doing
innecessary stuff
when the device is offline and earn battery is a good thing, but at
least I would prefer
to have my own minimal stack of mail management.
--pancake
Check out tinymail[1]. This guy took a pretty cerebral approach to
developing his MUA back-end library. I've used it in the form of
Modest[2] on my Nokia n810.
Personally, I'd hate to see any more dev hours wasted on garbage like
imap or pop3. ssh/rsyncing maildir to form a 'local copy,' then
'commiting' changes back seems much saner to me.
[1] - http://tinymail.org/
[2] - http://modest.garage.maemo.org/
--
wbr, Илембитов
Antoni Grzymala
2009-10-06 18:14:12 UTC
Permalink
Post by pancake
Stuff like gpg, html2text (or text2html for those who wants to raise
hate on mailing lists), filters to format a mail into a 'reply' format
prefixing lines with '>' ... are just pre and post-hooks when calling
the $EDITOR or $PAGER.
Isn't that what mh (nmh) and the surrounding ecosystem have been doing
for the past 25 or so years?
--
[a]
markus schnalke
2009-10-06 18:54:45 UTC
Permalink
Post by Antoni Grzymala
Post by pancake
Stuff like gpg, html2text (or text2html for those who wants to raise
hate on mailing lists), filters to format a mail into a 'reply' format
prefixing lines with '>' ... are just pre and post-hooks when calling
the $EDITOR or $PAGER.
Isn't that what mh (nmh) and the surrounding ecosystem have been doing
for the past 25 or so years?
Yes. It's the MUA that fits best into the Unix system.

Unfortunately, email is no longer like it was back then when MH was designed.
Hence, MIME was retro-fitted, GPG needs to be done by hand, and UTF-8 is not
supported at all.

I switched to nmh just these days and I'm greatly impressed. It gives this
feeling that you know from using Unix. But you need to do a lot of stuff by
hand. (OTOH you can!)

It should definately be reworked. (At least to add UTF-8 support.)



But back on topic: nmh is only a MUA that operates on local mail boxes. IMO
that's all it should be. The separation between the different mail clients
makes sense.

Mounting remote mail boxes into your local file system seems to be the right
thing. Then there is no local--remote difference. (This kind of thinking is
what I learned from Plan9.)


meillo
Antoni Grzymala
2009-10-06 19:26:40 UTC
Permalink
Post by markus schnalke
Post by Antoni Grzymala
Post by pancake
Stuff like gpg, html2text (or text2html for those who wants to raise
hate on mailing lists), filters to format a mail into a 'reply' format
prefixing lines with '>' ... are just pre and post-hooks when calling
the $EDITOR or $PAGER.
Isn't that what mh (nmh) and the surrounding ecosystem have been doing
for the past 25 or so years?
Yes. It's the MUA that fits best into the Unix system.
Unfortunately, email is no longer like it was back then when MH was designed.
Hence, MIME was retro-fitted, GPG needs to be done by hand, and UTF-8 is not
supported at all.
I switched to nmh just these days and I'm greatly impressed. It gives this
feeling that you know from using Unix. But you need to do a lot of stuff by
hand. (OTOH you can!)
/me envies somewhat. Been planning to take the plunge and switch over
from mutt, but there's just too much in my config file that I depend on
and won't have time of reworking in mh in foreseeable future.
Post by markus schnalke
It should definately be reworked. (At least to add UTF-8 support.)
Agreed.
Post by markus schnalke
But back on topic: nmh is only a MUA that operates on local mail boxes. IMO
that's all it should be. The separation between the different mail clients
makes sense.
Right. I also second the notion of (r)syncing mailboxes from a remote
host somebody proposed. mh or other local MUAs fit well in such a
scenario.
Post by markus schnalke
Mounting remote mail boxes into your local file system seems to be the right
thing. Then there is no local--remote difference. (This kind of thinking is
what I learned from Plan9.)
That's another solution. However this would require a good filesystem
with local caching and graceful disconnection handling. I think syncing
over SSH is at the moment simpler and good enough.

Best,
--
[a]
markus schnalke
2009-10-06 19:54:06 UTC
Permalink
Post by Antoni Grzymala
Post by markus schnalke
I switched to nmh just these days and I'm greatly impressed. It gives this
feeling that you know from using Unix. But you need to do a lot of stuff by
hand. (OTOH you can!)
/me envies somewhat. Been planning to take the plunge and switch over
from mutt, but there's just too much in my config file that I depend on
and won't have time of reworking in mh in foreseeable future.
Don't depend so much on your personalized stuff. Just switch! ;-)

I had this plan for quite a long time and always pushed it forward but
did not switch. Now a nice guy gave me a hit on the topic, and finally I
just did it. (In less than a week.)

It wasn't such a big thing, acutally, cause I already used the MH
mailbox format. Hence I still can use mutt in parallel, if necessary.
Post by Antoni Grzymala
Post by markus schnalke
Mounting remote mail boxes into your local file system seems to be the right
thing. Then there is no local--remote difference. (This kind of thinking is
what I learned from Plan9.)
That's another solution. However this would require a good filesystem
with local caching and graceful disconnection handling. I think syncing
over SSH is at the moment simpler and good enough.
I prefer to work remotely to avoid all that stuff. But this requires an
own server of course.

Syncing file systems is a problem if you want to use mail servers that
don't belong to you (e.g. free mailers). I think this was the setup of
interest: Several computers and a free mail account.


meillo
Premysl Hruby
2009-10-06 20:46:52 UTC
Permalink
Date: Tue, 06 Oct 2009 18:24:14 +0200
Subject: Re: [dev] Suckless mail client solution?
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
List-Id: dev mail list <dev.suckless.org>
I already wrote a patch for msmtp that checks for the MX entry for a
domain to
automatically specify the remote SMTP server, so no need to
configure any smtp
server for sending mails. I find this solution much simpler for most
situations (unless
you are on a restricted network that only allows you to connect to
your local smtp)
Well, that's completly unusable in case of temporary only error's or
when SPF for your domain is in use, etc.

-Ph
--
Premysl "Anydot" Hruby, http://www.redrum.cz/
-
I'm a signature virus. Please add me to your signature and help me spread!
Marc Andre Tanner
2009-10-08 22:36:25 UTC
Permalink
Post by pancake
A solution that manages MTA, MUA, MDA and MDMA plus LSD in a simple
way.
- Keep a partial local cache of the mails (only last 50?)
- imap support server search, so why i have to mirror the
folders with 53200 mails?
- Only sync selected folders automatically or every N minutes
- Attachments should be only retrieved in a second stage (on slow
connections
is really useful)
I am also interested in mail handling tools which suck less. In my opinion
a useable solution should be built around IMAP (although imap obviously does
suck, it is one of those standards that you just have to accept and work with
if you want to talk to the outside world).

My current mail setup uses imapfilter and offlineimap. This actually works
quite well but the implementation of offlineimap in particular sucks rocks.
Last time I checked they factored out the user interface and provided at least
3 different ones. Which is just plain crazy if you ask me.

What is missing is a good libimap written in C. Or is there one that I am not
aware of? The last time I googled for it everything I found was either ugly or
written in a scripting language.

The functionality of imapfilter, offlineimap or some fuse based solution could
then be implemented on top of this libimap.

The client itself shouldn't need to know about imap.

Marc
--
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Jessta
2009-10-09 05:05:53 UTC
Permalink
Post by Marc Andre Tanner
What is missing is a good libimap written in C. Or is there one that I am
not aware of? The last time I googled for it everything I found was either ugly
or written in a scripting language.
Yeah there is c-client from uw-imap which is the reference implementation.
http://www.washington.edu/imap/
Not really sure if it's good, it's rather big. It's what al/pine use.
--
=====================
http://jessta.id.au
Anselm R Garbe
2009-10-13 17:00:43 UTC
Permalink
Post by pancake
Post by markus schnalke
Post by pancake
PD: Actually I have not found a more fast, usable and simplest mail client
than the one shipped with iphone-os. And no, fetchmail,mutt,claws,telnet
are not decent solutions. Should we open another thread to create a suckless
mail client?
What do you mean with ``mail client''? MTA, MUA, MDA, or all of them in one?
A solution that manages MTA, MUA, MDA and MDMA plus LSD in a simple
way.
 - Keep a partial local cache of the mails (only last 50?)
   - imap support server search, so why i have to mirror the folders with
53200 mails?
 - Only sync selected folders automatically or every N minutes
 - Attachments should be only retrieved in a second stage (on slow
connections
  is really useful)
Client must provide a simple tree way to walk on folders (filesystem?) every
time a mail is fetched a file is created and it is touched with the
specified timestamp.
I already wrote a patch for msmtp that checks for the MX entry for a domain
to
automatically specify the remote SMTP server, so no need to configure any
smtp
server for sending mails. I find this solution much simpler for most
situations (unless
you are on a restricted network that only allows you to connect to your
local smtp)
So, what I see here is a simple application that manages files in
directories and allows to create formatted files (using a template) on some
directories using $EDITOR,
a command to check files in Outbox to push them to remote servers and commit
them into the Sent directory.
 - list, copy, move, remove
Just having a simple application to manage pop3/smtp with those minimal
operations
and writing a simple frontend to edit files on certain directories based on
templates.
Stuff like gpg, html2text (or text2html for those who wants to raise hate on
mailing
lists), filters to format a mail into a 'reply' format prefixing lines with
'>' ... are just
pre and post-hooks when calling the $EDITOR or $PAGER.
The only missing thing I see in this model is the part of attached files.
This can be
solved by having a directory with the same filename of the mail plus .files
and have
an application to serialize mail+attachments into a single text stream
before sending
it to the smtp (maybe using msmtp) can be ideal.
To setup accounts I can think on a single entrypoint with simple format that
configures
the rest of applications to work with.
Multiple accounts should be managed by this approach. Marking emails as
read/...
can be just a sed script changing a header.
I have never understood why there is no decent mail implementation like the
one
explained above. The only problematic to implement such thing is the lack of
decent
smtp/pop/imap clients. I think that ssl support can be done by local openssl
bouncers.
Another *important* thing is that the SSL stuff must be checked, so in this
way you
can setup any kind of secure connection without having to reconfigure your
mail
client. This is: connecting to localhost:110 to bounce the socket to an VPN
or an DNSTX
network (or TOR, etc...), the client will just know nothing about the
underlying network,
and the bouncer app will be the one to ensure that the connection is not
broken.
Network *must* be an async dependency for a mail client, so I hate when the
client gets
locked because of a network cut or slowdown, it is just something that
cannot be understood
nowadays.
By having all this simple setup done (in a single package, please, i dont
want to configure
3 or 4 programs to get my email working) i can imagine a lot of
automatizations in scripts
to autoreply emails, filter spam, etc.. And the GUI is actually a
filesystem.
As a follow up of our IRC discussion today, I like the idea of
following (n)mh in this respect, though I'd really appreciate having
some kind of mail dir pager, perhaps the relevant parts ripped from
mutt or written from scratch. I always found that the threading
display in mutt is excellent and I'd really think the basic mail
lister + previewer as an addition tool in the mh tool chain for
listing mails and threads would be nice, it's the only feature I'd
really miss and the only feature with a crappy curses dependency in
the toolchain ;)

(Though I wouldn't mind doing such a lister in X instead, following
the paradigms of curses but having an X based implementation of a text
based UI).

Kind regards,
Anselm
pancake
2009-10-15 18:17:27 UTC
Permalink
Post by Anselm R Garbe
following (n)mh in this respect, though I'd really appreciate having
some kind of mail dir pager, perhaps the relevant parts ripped from
mutt or written from scratch. I always found that the threading
display in mutt is excellent and I'd really think the basic mail
lister + previewer as an addition tool in the mh tool chain for
listing mails and threads would be nice, it's the only feature I'd
really miss and the only feature with a crappy curses dependency in
the toolchain ;)
I have always hated the threaded views..Well that's not true at all,
few years ago I used to use them a lot, and yeah, mutt owns the best
threading view (compared to thunderbird, claws..)

But actually I dont find them useful or practical because they hide the
timeline of the mailbox by strange trees of mails.

What I would really find useful is a decent filtering system , but always
keeping the timeline, which is in mail one of the most important things.

If you are not following a thread you can just hide it with grep, or
viceversa,
you can also autoremove all the mails related to a thread, etc..

I think that hypermail also has a threaded algorithm implemented, you
can get a look on it if you are interested, but I dont think this is useful
in mail handling. I would prefer a flat view like

[thread1] -> go inside to view only these mails , Show between parenthesis
the number of new mails in this thread.
[thread2] ...
Post by Anselm R Garbe
(Though I wouldn't mind doing such a lister in X instead, following
the paradigms of curses but having an X based implementation of a text
based UI).
I want to create a simple pipe-based with some daemons usable from
other programs in batch mode to retrieve info or launch actions.

The frontend should just manage a queue of processes doing some
tasks. I dont really like ncurses, and for this kind of interface I
would just
write a ansi-based frontend able to run commands, hook keys to commands,
this should be enought for launching $EDITOR, manage the addressbook,
apply filters on mail lists, etc..

The current state is quite incomplete, but I hope to publish soemthing
usable
for the end of this month.

Once all this stuff is working I would like to work on the design of the
frontend,
but I think that a simple list manager should be enought for most of the
situations.

Did you ever look the 'menush' app in hg.youterm.com ? I wrote a 'emenu'
program
that it is something like dmenu, but for shell, allowing autocomplete in
single line
and ansi-based interactive menu with arrows and so on. I use it to
launch scripts
in my n770 (yeah many years ago) and actually im using it in the dingoo
console
to run emulators and roms from commandline without a keyboard.

--pancake
Antoni Grzymala
2009-10-15 18:23:11 UTC
Permalink
Post by pancake
Post by Anselm R Garbe
following (n)mh in this respect, though I'd really appreciate having
some kind of mail dir pager, perhaps the relevant parts ripped from
mutt or written from scratch. I always found that the threading
display in mutt is excellent and I'd really think the basic mail
lister + previewer as an addition tool in the mh tool chain for
listing mails and threads would be nice, it's the only feature I'd
really miss and the only feature with a crappy curses dependency in
the toolchain ;)
I have always hated the threaded views..Well that's not true at all,
few years ago I used to use them a lot, and yeah, mutt owns the best
threading view (compared to thunderbird, claws..)
But actually I dont find them useful or practical because they hide the
timeline of the mailbox by strange trees of mails.
What I would really find useful is a decent filtering system , but always
keeping the timeline, which is in mail one of the most important things.
I use the S key to instantly switch between threaded and time-sorted
views in mutt:

### in muttrc:

# By default we want threaded sort
source ~/.mutt/sort-threads.rc

### sort-threads.rc:

set sort=threads
macro index S "<enter-command>source ~/.mutt/sort-date.rc<enter>"

### sort-date.rc:

set sort=date
macro index S "<enter-command>source ~/.mutt/sort-threads.rc<enter>"
--
[a]
Steven Blatchford
2009-10-15 19:13:26 UTC
Permalink
Post by pancake
Post by Anselm R Garbe
following (n)mh in this respect, though I'd really appreciate having
some kind of mail dir pager, perhaps the relevant parts ripped from
mutt or written from scratch. I always found that the threading
display in mutt is excellent and I'd really think the basic mail
lister + previewer as an addition tool in the mh tool chain for
listing mails and threads would be nice, it's the only feature I'd
really miss and the only feature with a crappy curses dependency in
the toolchain ;)
I have always hated the threaded views..Well that's not true at all,
few years ago I used to use them a lot, and yeah, mutt owns the best
threading view (compared to thunderbird, claws..)
But actually I dont find them useful or practical because they hide the
timeline of the mailbox by strange trees of mails.
What I would really find useful is a decent filtering system , but always
keeping the timeline, which is in mail one of the most important things.
-- snip --

In mutt one can press 'o' and 'd' to sort by date and 'o' 't' to sort by
thread. One can supply defaults with hooks -- eg:

folder-hook inbox "set sort=date"
folder-hook dwm "set sort=threads"

-steve
s***@cs.tu-berlin.de
2009-10-15 19:47:24 UTC
Permalink
Post by pancake
Post by Anselm R Garbe
following (n)mh in this respect, though I'd really appreciate having
some kind of mail dir pager, perhaps the relevant parts ripped from
mutt or written from scratch. I always found that the threading
display in mutt is excellent and I'd really think the basic mail
lister + previewer as an addition tool in the mh tool chain for
listing mails and threads would be nice, it's the only feature I'd
really miss and the only feature with a crappy curses dependency in
the toolchain ;)
I have always hated the threaded views..Well that's not true at all,
few years ago I used to use them a lot, and yeah, mutt owns the best
threading view (compared to thunderbird, claws..)
But actually I dont find them useful or practical because they hide the
timeline of the mailbox by strange trees of mails.
Well, I can't tell which view is more useful in mutt -- threaded or
timeline. Which is proved by the fact that I have changed couple of times
in the past the default view from one to another, and switched views at
least once a day anyway. Which proves for me that they are equally useful
for different tasks: a mailbox is a

- queue of messages , but
- collection of discussions/conversations, too

I rely on both ...
Post by pancake
What I would really find useful is a decent filtering system , but always
keeping the timeline, which is in mail one of the most important things.
Threads do keep the causal relationship, which is equally important.
Post by pancake
I would prefer a flat view like
[thread1] -> go inside to view only these mails , Show between parenthesis
the number of new mails in this thread.
[thread2] ...
In mutt you can collapse threads (default key binding <esc>v/V I think) --
also a thing I like.

In summary: I would love a less sucking alternative to existing mail
clients, in nmh style, i.e. a collection of tools to handle different
aspects of the mail processing and to delegate non-mail tasks to $EDITOR,
grep, whatever. But there are some features I consider crucial, e.g. decent
unicode support and threaded/timeline view. Until the alternative comes I'm
forced to stuck with mutt.

IMHO it doesn't make sense to cut things which serve you good tens of times
every day. SLOC less sometimes sucks more... :o)
Post by pancake
Did you ever look the 'menush' app in hg.youterm.com ? I wrote a 'emenu'
program that it is something like dmenu, but for shell, allowing
autocomplete in single line and ansi-based interactive menu with arrows
and so on.
I gave it a try.
cute :o)


cheers
--
stanio_
markus schnalke
2009-10-18 08:18:52 UTC
Permalink
Post by s***@cs.tu-berlin.de
Well, I can't tell which view is more useful in mutt -- threaded or
timeline. Which is proved by the fact that I have changed couple of times
in the past the default view from one to another, and switched views at
least once a day anyway. Which proves for me that they are equally useful
for different tasks: [...]
IMO threads are very useful for mailing lists. (With nmh, I really miss
them there.)

The inbox, in contrast, is best sorted by time, I think.
Post by s***@cs.tu-berlin.de
In summary: I would love a less sucking alternative to existing mail
clients, in nmh style, i.e. a collection of tools to handle different
aspects of the mail processing and to delegate non-mail tasks to $EDITOR,
grep, whatever. But there are some features I consider crucial, e.g.
decent unicode support
Would it be so much work to add it to nmh?
Post by s***@cs.tu-berlin.de
and threaded/timeline view.
One only needs to write a single program to have threaded viewing in
nmh. For next-in-thread some minor changed in existing programs would be
neccesary.
Post by s***@cs.tu-berlin.de
IMHO it doesn't make sense to cut things which serve you good tens of times
every day.
It's not about cutting out stuff, but switching to the Unix style. ;-)


meillo
Robert C Corsaro
2009-10-18 14:56:00 UTC
Permalink
Post by markus schnalke
Post by s***@cs.tu-berlin.de
Well, I can't tell which view is more useful in mutt -- threaded or
timeline. Which is proved by the fact that I have changed couple of times
in the past the default view from one to another, and switched views at
least once a day anyway. Which proves for me that they are equally useful
for different tasks: [...]
IMO threads are very useful for mailing lists. (With nmh, I really miss
them there.)
The inbox, in contrast, is best sorted by time, I think.
I've started to use nntp for mailing lists. It seems to be better, but
I can't put my finger on exactly why. What does suckless thing? What's
the best suckless newsreader? I've been using pan but I'd rather a
command line program.
Moritz Wilhelmy
2009-10-19 00:04:20 UTC
Permalink
Post by Robert C Corsaro
Post by markus schnalke
Post by s***@cs.tu-berlin.de
Well, I can't tell which view is more useful in mutt -- threaded or
timeline. Which is proved by the fact that I have changed couple of times
in the past the default view from one to another, and switched views at
least once a day anyway. Which proves for me that they are equally useful
for different tasks: [...]
IMO threads are very useful for mailing lists. (With nmh, I really miss
them there.)
The inbox, in contrast, is best sorted by time, I think.
I've started to use nntp for mailing lists. It seems to be better, but
I can't put my finger on exactly why. What does suckless thing? What's
the best suckless newsreader? I've been using pan but I'd rather a
command line program.
What about slrn as newsreader?

Regards
s***@cs.tu-berlin.de
2009-10-20 12:10:17 UTC
Permalink
Post by markus schnalke
Post by s***@cs.tu-berlin.de
Well, I can't tell which view is more useful in mutt -- threaded or
timeline. Which is proved by the fact that I have changed couple of times
in the past the default view from one to another, and switched views at
least once a day anyway. Which proves for me that they are equally useful
for different tasks: [...]
IMO threads are very useful for mailing lists. (With nmh, I really miss
them there.)
The inbox, in contrast, is best sorted by time, I think.
I need both views in both cases. With threads, in general, you can't see
the most recent posts overall. Even if you collapse them, all threads don't
necessarily fit in one page.

Date sort alone hides the structure of a conversation, as long as
conversations tend to fork sub-themes, which is often the case with people
worth communicating with :o)
Post by markus schnalke
Post by s***@cs.tu-berlin.de
In summary: I would love a less sucking alternative to existing mail
clients, in nmh style, i.e. a collection of tools to handle different
aspects of the mail processing and to delegate non-mail tasks to $EDITOR,
grep, whatever. But there are some features I consider crucial, e.g.
decent unicode support
Would it be so much work to add it to nmh?
I think it is not that big deal. I did it for a Win32 application at work
couple of years ago. But still needs time... And I am by far not the god of
code anyway.
Post by markus schnalke
Post by s***@cs.tu-berlin.de
IMHO it doesn't make sense to cut things which serve you good tens of times
every day.
It's not about cutting out stuff, but switching to the Unix style. ;-)
Agreed.

If it's good, (it's unix style) XOR (it's illegal, OR immoral OR it makes you
fat).
:o)


cheers
--
stanio_
pancake
2009-10-20 16:53:04 UTC
Permalink
The current state of my minimalist email solution is quite hacky and
incomplete
but is starting to be functional and usable. I plan to publish the hg
repo where
the source is being developed in a week or two..

Actually I have a pop3 implementation in 100 LOC and imap4 in 130LOC, for
smtp i have delegated the task to msmtp (i will write the smtp protocol
later),
and a main shellscript that manages all the rest. this will rewritten to
C at
some point. But actually i want the functionality.

pop3/imap4 works on plain and ssl connections by using nc and openssl. No
extra security checks (like IP and certificate changes), but this will
be done soon too.

There is no decent syncronization mechanisms, just basic folder fetching
from
pop3 and imap4. For the attachments Nibble will write a mime
packer/unpacker,
so this will be about 100LOC more.

At the end I think that the first working version will be about 1000LOC, but
the code can be easily improved and cleaned up. But ATM i'm priorizing the
functionaility.

About threads I think the best way is to grep for a subject and sort by
date.
The problem I see in threads is that you loss the timeline and for long
threads
you get just lines (no text) because of the recursively nesting nature
of the
threads. If you want to 'ban' somebody comments, its just another grep
filter
to the list, etc...

I don't plan to add threading support at the moment, just plain and
filtered lists.

The code of 'dmc' the 'dynamic mail client' that im actually writing is
going to
work only on *nix-based systems (no plans for w32 atm)

About functionalities I dont want to chop any of them, but I want to
keep the
core as simple as possible, keeping the configuration minimal, and make the
core actions enought to be extended by user scripts.

About the frontend..well i would like to write a simple gtk-based GUI,
but it
will relay on the core dmc. So it will be plain simple to write web
based interfaces,
commandline ones, or whatever.

There's a long way to go, but half of it is already known :)

--pancake
Post by s***@cs.tu-berlin.de
Post by markus schnalke
Post by s***@cs.tu-berlin.de
Well, I can't tell which view is more useful in mutt -- threaded or
timeline. Which is proved by the fact that I have changed couple of times
in the past the default view from one to another, and switched views at
least once a day anyway. Which proves for me that they are equally useful
for different tasks: [...]
IMO threads are very useful for mailing lists. (With nmh, I really miss
them there.)
The inbox, in contrast, is best sorted by time, I think.
I need both views in both cases. With threads, in general, you can't see
the most recent posts overall. Even if you collapse them, all threads don't
necessarily fit in one page.
Date sort alone hides the structure of a conversation, as long as
conversations tend to fork sub-themes, which is often the case with people
worth communicating with :o)
Post by markus schnalke
Post by s***@cs.tu-berlin.de
In summary: I would love a less sucking alternative to existing mail
clients, in nmh style, i.e. a collection of tools to handle different
aspects of the mail processing and to delegate non-mail tasks to $EDITOR,
grep, whatever. But there are some features I consider crucial, e.g.
decent unicode support
Would it be so much work to add it to nmh?
I think it is not that big deal. I did it for a Win32 application at work
couple of years ago. But still needs time... And I am by far not the god of
code anyway.
Post by markus schnalke
Post by s***@cs.tu-berlin.de
IMHO it doesn't make sense to cut things which serve you good tens of times
every day.
It's not about cutting out stuff, but switching to the Unix style. ;-)
Agreed.
If it's good, (it's unix style) XOR (it's illegal, OR immoral OR it makes you
fat).
:o)
cheers
Dieter Plaetinck
2009-10-20 17:08:58 UTC
Permalink
On Tue, 20 Oct 2009 18:53:04 +0200
Post by pancake
The current state of my minimalist email solution is quite hacky and
incomplete
but is starting to be functional and usable. I plan to publish the hg
repo where
the source is being developed in a week or two..
Actually I have a pop3 implementation in 100 LOC and imap4 in 130LOC,
for smtp i have delegated the task to msmtp (i will write the smtp
protocol later),
and a main shellscript that manages all the rest. this will rewritten
to C at
some point. But actually i want the functionality.
pop3/imap4 works on plain and ssl connections by using nc and
openssl. No extra security checks (like IP and certificate changes),
but this will be done soon too.
There is no decent syncronization mechanisms, just basic folder
fetching from
pop3 and imap4. For the attachments Nibble will write a mime
packer/unpacker,
so this will be about 100LOC more.
At the end I think that the first working version will be about
1000LOC, but the code can be easily improved and cleaned up. But ATM
i'm priorizing the functionaility.
About threads I think the best way is to grep for a subject and sort
by date.
The problem I see in threads is that you loss the timeline and for
long threads
you get just lines (no text) because of the recursively nesting
nature of the
threads. If you want to 'ban' somebody comments, its just another
grep filter
to the list, etc...
I don't plan to add threading support at the moment, just plain and
filtered lists.
The code of 'dmc' the 'dynamic mail client' that im actually writing
is going to
work only on *nix-based systems (no plans for w32 atm)
About functionalities I dont want to chop any of them, but I want to
keep the
core as simple as possible, keeping the configuration minimal, and
make the core actions enought to be extended by user scripts.
About the frontend..well i would like to write a simple gtk-based
GUI, but it
will relay on the core dmc. So it will be plain simple to write web
based interfaces,
commandline ones, or whatever.
There's a long way to go, but half of it is already known :)
--pancake
sounds great!

Dieter

Robert C Corsaro
2009-10-07 14:13:37 UTC
Permalink
Post by pancake
Post by Szabolcs Nagy
Post by pancake
Sorry for the fwd:fwd..i had some mail issues
Content-Type: multipart/alternative; boundary=Apple-Mail-4--577211373
Yeah I know, i'm a evil guy for replying mails from my ipod.
Did you got access to the rest of the mail and be able to construct a more
constructive response?
Post by Szabolcs Nagy
ffffffffffff
Is this -1?
PD: Actually I have not found a more fast, usable and simplest mail client
than the one shipped with iphone-os. And no, fetchmail,mutt,claws,telnet
are not decent solutions. Should we open another thread to create a suckless
mail client?
--pancake
An interesting idea would be to setup your mail server to automatically
convert outgoing mail from html to text and whatever other cleanups you
need. Then you could use retarded clients like ipod without worrying.
markus schnalke
2009-10-06 15:39:12 UTC
Permalink
[2009-10-06 10:43] pancake <***@youterm.com>
or better
Vi is the visual ed, but I have never seen any implementation using
ed. They just embed it inside the 'GUI' .
I think that having all the editing engine implemented in ed is
simple to wrap it into a GUI based on X11 or ncurses.
Okay. Now I see a difference. But also difficulties.

What about unlimited undo for example? Ed does not provide this. Thus,
if you want it (We *do* want it.), you have to put it in the UI. But
that's the wrong place.

We also should do performance experiments first, because it's important
that the editor responds directly. Splitting it into two processes might
cause bad performance.

What I like, however, is the idea of having one UI and several eds
behind -- one for each file you edit.
Vim supports launching apps to filter text, but it is not the main
way to work. Because is more optimal and easy to port to other os
like dos or w32.
Syntax highlighting is something that can be implemented in a
filter program.
Syntax highlighting is bad on terminals. Seems there is no sane way to
have it. Don't know about X applications.
The same for indent, line numbering, text
alignment, etc..
The question is: Do you really want this stuff to be outside the
editor? You'd need constantly a whole lot of forks.
I love vim, but I feel that most of the capabilities it supports
are embedded in the editor instead of using a unixlike design based
on pipes and filters.
Autocompletion, ctags, searchs,,.. Can be implemented outside the
GUI without much pain.
I think search (read: RegExp) is crutial to be a core part of the
editor. Ed already offers it.

For the other stuff, I agree. If one needs them (at all) then through
external programs.
We just need a GUI that supports X11, ncurses, sdl or OpenGL that
allows to bind some keybindings to run commands at Ed level or
change the filters for example.
We probably don't want sdl and OpenGL.
The main problem in this application is to find the good
simplification of the design to allow good flexibility, performance.
Any proposal?
Have a look at sam. That's what the former users of ed use today.
You'll probably find interesting approaches there.

First try to get a prototype ready, which excludes the extreme parts.
You'll may notice that some of the ideas simply don't work. But if the
design holds, go on in a second iteration.

In other words: Don't try to get a micro kernel right on the first try
... i've heard of some guys who still work on it. :-)


I'm looking forward for the project


meillo
pancake
2009-10-06 16:42:42 UTC
Permalink
Post by markus schnalke
or better
Vi is the visual ed, but I have never seen any implementation using
ed. They just embed it inside the 'GUI' .
I think that having all the editing engine implemented in ed is
simple to wrap it into a GUI based on X11 or ncurses.
Okay. Now I see a difference. But also difficulties.
What about unlimited undo for example? Ed does not provide this. Thus,
if you want it (We *do* want it.), you have to put it in the UI. But
that's the wrong place.
We also should do performance experiments first, because it's important
that the editor responds directly. Splitting it into two processes might
cause bad performance.
What I like, however, is the idea of having one UI and several eds
behind -- one for each file you edit.
Yep, I know that this approach enables so many issues in fronts
like performance or features that are mixed between UI and ED.

The idea is that ED is used to edit lines, so the communication between
gui and backend must be only done after editing a line. The GUI must
understand at least a block of information from the backend. it needs
a context.
Post by markus schnalke
Vim supports launching apps to filter text, but it is not the main
way to work. Because is more optimal and easy to port to other os
like dos or w32.
Syntax highlighting is something that can be implemented in a
filter program.
Syntax highlighting is bad on terminals. Seems there is no sane way to
have it. Don't know about X applications.
Yeah, I have always seen syntax highlighting a pretty slow and buggy
thing. emacs and vim have problem with syntaxes so many times
because the performance or because they lack of enought context
to colorize a big comment block or so.

In files mixing more than one syntax it makes the problem much bigger
(like html+css+js or gtkaml+vala,. ..)

I dont really see a clean and optimal solution for syntax highlight.
But I cant live without it :)

At least by having a set of regexpes colorizing list of keywords and
text between quotes should be enought for most of situations. The
problem appears when a line changes the syntax rules of the following
ones.
Post by markus schnalke
The same for indent, line numbering, text
alignment, etc..
The question is: Do you really want this stuff to be outside the
editor? You'd need constantly a whole lot of forks.
I never use real-time indentation or text align, and line numbering
can be provided by ed. The only times I use text indent is when
in vim I choose a block of code and press = or gg=G to indent the
whole file.
Post by markus schnalke
I love vim, but I feel that most of the capabilities it supports
are embedded in the editor instead of using a unixlike design based
on pipes and filters.
Autocompletion, ctags, searchs,,.. Can be implemented outside the
GUI without much pain.
I think search (read: RegExp) is crutial to be a core part of the
editor. Ed already offers it.
For the other stuff, I agree. If one needs them (at all) then through
external programs.
yep, and also search+replace with regexpes.
Post by markus schnalke
We just need a GUI that supports X11, ncurses, sdl or OpenGL that
allows to bind some keybindings to run commands at Ed level or
change the filters for example.
We probably don't want sdl and OpenGL.
yeah I was joking at this point.
Post by markus schnalke
The main problem in this application is to find the good
simplification of the design to allow good flexibility, performance.
Any proposal?
Have a look at sam. That's what the former users of ed use today.
You'll probably find interesting approaches there.
For sure, sam have good ideas, but it lacks a keyboard interaction.

I think that if we want to manage different files on a single implementation
we have to think on a more global approach using the WM to manage
multiple instances of the same file allowing interactive editing with more
than one user, or supporting the edition from local and remote of the
box (screen is just an ugly hack). Applications must be independent
from the backend and the data they work on. This is the only way
we can move or manage it without depending on a terminal or Xwindows.
(what if your Xwindows get locked, or you want to continue editing a file
from a remote box via ssh?). lock files should be only useful as timestamps
and watermarks to define who and when has changed the contents of the
file. This is probably one of the most anoying things of vim.
Post by markus schnalke
First try to get a prototype ready, which excludes the extreme parts.
You'll may notice that some of the ideas simply don't work. But if the
design holds, go on in a second iteration.
I think we probably need more discussion on this topic to get the right
design for 'ved' or 'sved' (i think ved already exists), I will think more
on the way to solve the missing parts of this design. Ideas are welcome :)
Post by markus schnalke
In other words: Don't try to get a micro kernel right on the first try
... i've heard of some guys who still work on it. :-)
Hehe, microkernel discussions are endless ones, I'm just trying to
push some light about the problems we face when editing text and
the tools we already have and the ones we miss to get a simpler
implementation.
Post by markus schnalke
I'm looking forward for the project
I'm probably more interested on working for the email project than
the editor one, but i'll be happy to discuss things if any of you is
interested on writing a POC of the above ideas.

At least (nowadays) I'm spending more time thinking on how to make
a good design before coding any line (yeah, im getting old ;)

If I get a bright idea about how to get this splitted reinvented wheel
working i'll push some sources for review. But feel free to do it by
yourself if you want, writing a text editor is not in my short TODO
plans actually :)

--pancake
Loading...