Re: [9fans] ACME mail

Re: [9fans] ACME mail

[Russ Cox]

binary (8-bit) mail seems to be less of a problem
than actually parsing and handling utf-8.
/bin/mail (mailx?) on most unix systems
still can't handle even mime, i gather.  pine complains
every time it gets a utf-8 message (warning!
i don't know that character set.  how about i 
pretend it's us-ascii?)  i know that other unix programs
had the same problems.  until presotto added
the us-ascii hack to marshal, i got a fair number of
complaints from people about my sending them
``uppity'' mail.

the nice thing about upas/fs and marshal is that
they handles all the ugly conversion so that 
nedmail and acme Mail are much easier to
write.  everyone who implements mime does
what they need to get by (even us).  unix authors
each have to roll their own mime parser and character
set converter, so the set of ``what they need to get
by'' differs from mailer to mailer and is a bit
frustrating.

Re: [9fans] Acme Mail

[erik quanstrom]

> This is exactly why IMAPs Thread and Sort extensions are such a big win.

they couldn't do everything wrong.

- erik

Re: [9fans] Acme Mail

[Lyndon Nerenberg]

> it makes more sense to get the skinny on the next n
> messages, akin to page's cache.  but in order to do
> that, the next n messages need to be obvious without
> poking through the whole pile in order to sort.

This is exactly why IMAPs Thread and Sort extensions are such a big win.

Note that upas wouldn't necessarily have to re-order /mail/fs/mbox in
place. Another possibility would be to have a 'sort' file that you would
write a sort request to, then read to get the list of filenames under
/mail/fs returned ordered by the sort. E.g. if /mail/fs/mbox contains
messages 1, 3 45, and 92,

 	open /mail/fs/sort
 	write "recvtime reversed"
 	read
 	close

might return "92\n45\n3\n1\n".

There's a lot of room for experimentation here.

Re: [9fans] Acme Mail

[erik quanstrom]

On Tue May 25 21:56:49 EDT 2010, lyndon@orthanc.ca wrote:
> > Nedmail and acme Mail are operating on the same
> > mailbox, and nedmail already has a nice language
> > built in.  Back when I did that sort of thing, I found
> > it easy to just fire up nedmail in a shell window.
>
> But ultimatly this sort of functionality should be in upas/fs itself,
> driven by commands written to /mail/fs/ctl.

i'd like to disagree, and say this is a ui (ned/Mail/imap4
client) problem, but the current setup is already less
than optimal.

admittedly, minooka is no longer a fast machine, but
here's a fairly generic mailbox in use every day

minooka; time upas/fs -pf /mail/box/xx/mbox
1.12u 0.14s 3.23r 	 upas/fs -pf /mail/box/xx/mbox
minooka; echo q | time upas/nedmail
22875 messages
: 0.40u 2.95s 8.56r 	 upas/nedmail

that's a pretty long wait for ned to get the skinny on
the 22875th message, which i have an approximately
0.27182% chance of reading.

if you don't care about fast, at just over 1k of
memory/message, ned is using 28mb of memory.  that
seems like a lot when i haven't looked at any messages.

it makes more sense to get the skinny on the next n
messages, akin to page's cache.  but in order to do
that, the next n messages need to be obvious without
poking through the whole pile in order to sort.

which leads us directly to lyndon's point.

- erik

Re: [9fans] Acme Mail

[Lyndon Nerenberg]

> Nedmail and acme Mail are operating on the same
> mailbox, and nedmail already has a nice language
> built in.  Back when I did that sort of thing, I found
> it easy to just fire up nedmail in a shell window.

But ultimatly this sort of functionality should be in upas/fs itself,
driven by commands written to /mail/fs/ctl.

Re: [9fans] Acme Mail

[Russ Cox]

Nedmail and acme Mail are operating on the same
mailbox, and nedmail already has a nice language
built in.  Back when I did that sort of thing, I found
it easy to just fire up nedmail in a shell window.

Russ

Re: [9fans] Acme Mail

[Akshat Kumar]

> thanks. that will go a long way toward what i need. hopefully the patch
> is easy to apply to the latest Plan9 sources.

If you make any modifications to
Mathieu's patch for p9p, in order to
apply it to Plan 9, then could you
please post the new patch sources
somewhere?  I could definitely make use
of such work.


Best,
ak

Re: [9fans] Acme Mail

[Skip Tavakkolian]

thanks. that will go a long way toward what i need. hopefully the patch
is easy to apply to the latest Plan9 sources.

> I had only replied to the OP because I didn't think other people could
> be interested, and I had announced it a while ago already, but here goes
> again, just in case.
>
> I patched p9p acme Mail to have a sort by conversation/subject
> (http://codereview.appspot.com/264043/show), so if what you want is being
> able to delete a bunch of messages with the same subject it's very easy
> to do in one mouse swipe once they're all grouped together by this sort.
>
> Of course that does not really help with spam because they won't have
> the same subject, only similar ones all matching "viagra", as in your
> example.
>
> I've been using it the whole time since then, no issue so far.
>
> Hope that helps,
> Mathieu

Re: [9fans] Acme Mail

[Mathieu Lonjaret]

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

I had only replied to the OP because I didn't think other people could
be interested, and I had announced it a while ago already, but here goes
again, just in case.

I patched p9p acme Mail to have a sort by conversation/subject
(http://codereview.appspot.com/264043/show), so if what you want is being
able to delete a bunch of messages with the same subject it's very easy
to do in one mouse swipe once they're all grouped together by this sort.

Of course that does not really help with spam because they won't have
the same subject, only similar ones all matching "viagra", as in your
example.

I've been using it the whole time since then, no issue so far.

Hope that helps,
Mathieu

[-- Attachment #2: Type: message/rfc822, Size: 5337 bytes --]

From: ron minnich <rminnich@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Acme Mail
Date: Tue, 25 May 2010 08:55:10 -0700
Message-ID: <AANLkTimTEnvBf-Eq_-Q8gd2407fQck0idWfyssvpIQl_@mail.gmail.com>

On Tue, May 25, 2010 at 8:42 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
> i was wrong; it doesn't work. Put doesn't actually delete the messages. i think
> this will require mods to /acme/mail/src/mail.c

we had a back and forth a long time ago about this. I wanted a way to
match a subject and delete all messages on that subject. There was no
apparent way.

the conclusion was that we needed a way to say "middle button action"
in a command line. Russ kindly offered to take a patch if someone
would write it.

So we could say something like
x/viagra/whatever
where whatever corresponded to 'middle-button-Del' or some such.

You can't just change what's in the window AFAIK. That's a reflection
of state, not the state itself.

ron

Re: [9fans] Acme Mail

[erik quanstrom]

> You can't just change what's in the window AFAIK. That's a reflection
> of state, not the state itself.

Mail's inspection of the selection confused me
try typing (deleted- in front of a message. now
try deleting it by selecting that line and b2ing
Delmesg.

Nothing happens.

i can't find the discussion, so i hope this isn't
a repeat of wild speculation.

it would be cool if acme had an edit command
that would allow the executation of an
acme command on the given selection.  suppose
!|<> executed acme commands rather than plan
9 commands.  then you could have

	Edit X:/mail/fs: ,x:^.*$: g:<u.example.com>: !Delmsg

- erik

p.s. don't try substituing | for ! in the above command:
qunlock called qith qlock not held , from 0x1f350.

/sys/src/cmd/acme/wind.c:165
 160		 */
 161		f = w->body.file;
 162		for(i=f->ntext-1; i>=0; i--){
 163			w = f->text[i]->w;
 164			w->owner = 0;
>165			qunlock(w);

☺

Re: [9fans] Acme Mail

[ron minnich]

On Tue, May 25, 2010 at 8:42 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
> i was wrong; it doesn't work. Put doesn't actually delete the messages. i think
> this will require mods to /acme/mail/src/mail.c

we had a back and forth a long time ago about this. I wanted a way to
match a subject and delete all messages on that subject. There was no
apparent way.

the conclusion was that we needed a way to say "middle button action"
in a command line. Russ kindly offered to take a patch if someone
would write it.

So we could say something like
x/viagra/whatever
where whatever corresponded to 'middle-button-Del' or some such.

You can't just change what's in the window AFAIK. That's a reflection
of state, not the state itself.

ron

Re: [9fans] Acme Mail

[Skip Tavakkolian]

i was wrong; it doesn't work. Put doesn't actually delete the messages. i think
this will require mods to /acme/mail/src/mail.c

> sorry, i meant all messages meeting a pattern in the subject line. combining
> your suggestion with pattern marking works correctly:
>
> Edit ,x/pattern/ --+ s/^[0-9]+/(deleted)-&/
>
>>> is there a way to mark *all* messages in a mail box for later
>>> processing - e.g.  Delmesg.  in nedmail one can do g/pattern/d
>>> unfortunately
>>>
>>> Edit ,x/pattern/ --+
>>>
>>> marks only one.
>>
>> what about:
>>
>> Edit s:^[0-9].*$:(deleted-)&:g
>>
>> nupas Mail has a nonstandard Save in the main window.
>> iirc, adding commands to the main screen did take a bit
>> of code.  so running ned might be easier for some tasks.
>>
>> - erik

Re: [9fans] Acme Mail

[Skip Tavakkolian]

sorry, i meant all messages meeting a pattern in the subject line. combining
your suggestion with pattern marking works correctly:

Edit ,x/pattern/ --+ s/^[0-9]+/(deleted)-&/

>> is there a way to mark *all* messages in a mail box for later
>> processing - e.g.  Delmesg.  in nedmail one can do g/pattern/d
>> unfortunately
>>
>> Edit ,x/pattern/ --+
>>
>> marks only one.
>
> what about:
>
> Edit s:^[0-9].*$:(deleted-)&:g
>
> nupas Mail has a nonstandard Save in the main window.
> iirc, adding commands to the main screen did take a bit
> of code.  so running ned might be easier for some tasks.
>
> - erik

Re: [9fans] Acme Mail

[erik quanstrom]

> is there a way to mark *all* messages in a mail box for later
> processing - e.g.  Delmesg.  in nedmail one can do g/pattern/d
> unfortunately
>
> Edit ,x/pattern/ --+
>
> marks only one.

what about:

Edit s:^[0-9].*$:(deleted-)&:g

nupas Mail has a nonstandard Save in the main window.
iirc, adding commands to the main screen did take a bit
of code.  so running ned might be easier for some tasks.

- erik

Re: [9fans] Acme Mail

[David Leimbach]

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

Edit ,

selects the whole thing doesn't it?  When I want to clear out an entire Acme
window I just do Edit ,d for example.

I don't really use Acme Mail though, so I'm unsure of what the difference is
in "marking" vs "selecting"

Daev

On Tue, May 25, 2010 at 12:11 AM, Skip Tavakkolian <9nut@9netics.com> wrote:

> is there a way to mark *all* messages in a mail box for later
> processing - e.g.  Delmesg.  in nedmail one can do g/pattern/d
> unfortunately
>
> Edit ,x/pattern/ --+
>
> marks only one.
>
>
>

[-- Attachment #2: Type: text/html, Size: 882 bytes --]

[9fans] Acme Mail

[Skip Tavakkolian]

is there a way to mark *all* messages in a mail box for later
processing - e.g.  Delmesg.  in nedmail one can do g/pattern/d
unfortunately

Edit ,x/pattern/ --+

marks only one.

[9fans] Acme Mail

[Lucio De Re]

>From the "silly requests department": would it be unreasonable to switch "Save" to "Undo" in the tag line of a message being inspected when one, as I often do, starts typing in it instead of first selecting to reply to or quote it?

    /mail/fs/mbox/930/ Del Snarf | Look Q Reply all Delmesg Save  Post 
                                                            ^^^^/Undo

++L

Re: [9fans] ACME mail

[okamoto]

>the nice thing about upas/fs and marshal is that
>they handles all the ugly conversion so that 
>nedmail and acme Mail are much easier to

Yes, I agree with this completely.  I made just a several line
changes for reading ISO-2022-JP encoded mail.

I forgot to write something when I replied to Charles's mail,
and please forgive me to add things here.

I've never received UTF-8 encoded mails from Japanese
except of myself.  This is probably from culture thing.
 From the early stage of computer developping in the world,
Japanese uses JIS (=ISO-2002-JP) or Shift JIS encoded Japanese
text, and we have too many documents writeen in JIS code.
Someone can call this Japanese culture, I think.  I agree that
Unicode is more beatiful for internal expression of OS, however,
I feel that no one can force to change this Japanese culture
in computer science.

I hope thi may help someone other than Japanese.

Kenji

Re: [9fans] ACME mail

[okamoto]

> Is there a way for it to tell the difference
>between ISO-2022-JP and utf-8?  

I think no.
Therefore, I used the method to put Content-Type explicitely
in the header lines, and then, if there is such ISO-2022-JP
line, it should be recongnized as such.

As ISO-2022-JP is really considered to be used only
within Japan, I managed to change Acme mail as such.  This may
also be done by putting user's header for upas alone.

Kenji

Re: [9fans] ACME mail

[Boyd Roberts]

    From: <okamoto@granite.cias.osakafu-u.ac.jp>

the nail that sticksp be hammered down...

Re: [9fans] ACME mail

[presotto]

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

I guess I don't completely understand.  Marshal tries to
sniff out the content and figure out the character set that's
being used.  Is there a way for it to tell the difference
between ISO-2022-JP and utf-8?  If so, I'm happy saying that
the charset is ISO-2022-JP when it is.  The user just has
to feed the input through a converter before marshal sees
it.

[-- Attachment #2: Type: message/rfc822, Size: 2447 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ACME mail
Date: Tue, 8 Aug 2000 12:48:37 0900
Message-ID: <200008080347.XAA11396@cse.psu.edu>

Thanks Bob.

>we keep ed around for use on our unix systems.  ned uses
>the upas/fs to serve a mailbox and marshall to compose a

I looked the source of marshall, and found that it supposes only
UTF-8 or US-ASCII for sending out charset.  In Japan, many
living in the other world than us use ISO-2022-JP charset
for exchanging email.

So, the interest is:

(1)We should send out ISO-2022-JP charset email, if we want to
keep good relation with them.  Of course, we can send Mime
formatted UTF-8, but in that case, we may lose something. 
(This is mailing-list is aliased to "UTF-8 mailing-list", so we
can use UTF-8 ?).

(2) I want to have UTF-8 charset files in our disk if it is plain/text, 
for the sake that we can read it anytime.  Then, I suppose it may 
be better to convert ISO-2022-JP formatted mail to UTF-8 when 
we received it.  In this case, then, we'll have a UTF-8 charset
file of, say,

<UTF-8 charset headers>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP.

<body of UTF-8 charset content>

When I see the sources under /sys/src/cmd/upas, there
seems to be a different principle.  There, we'll have IS-2022-JP
charset file same to its orignal form. How do you think (all)?

Kenji

Re: [9fans] ACME mail

[okamoto]

>presumably that means commercial unix systems?

No, I'm using exmh on Linux, and it's not supoort UTF-8.
Many Windows users in Japan do not use Outlook (I don't know
why (I'm a Outlook user in home), and they cannot use UTF-8
recognizable mailer, either.  Something anti-Unicode phenomenon
is here. ☺

kenji

Re: [9fans] ACME mail

[forsyth]

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

>>UTF-8 MIME, I suppose( for many UNIX users).  Of course, this may 

presumably that means commercial unix systems?
i'd have thought that linux, xBSD & company all would support
utf-8.  also, do you mean the 8 bit encoding or just any form
of UTF at all?  i can see avoiding 8-bit transfer encodings because
there are gateways that strip the top bit (and 7-bit transfer might
still be in the RFCs).



[-- Attachment #2: Type: message/rfc822, Size: 1656 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ACME mail
Date: Tue, 8 Aug 2000 13:54:04 0900
Message-ID: <200008080452.AAA12430@cse.psu.edu>

>i don't see the point in that:  aren't they invariably using software
>that understands MIME?  

MIME can be understood, however, many mailers do not understand
UTF-8 MIME, I suppose( for many UNIX users).  Of course, this may 
change in time.

Kenji

Re: [9fans] ACME mail

[okamoto]

>i don't see the point in that:  aren't they invariably using software
>that understands MIME?  

MIME can be understood, however, many mailers do not understand
UTF-8 MIME, I suppose( for many UNIX users).  Of course, this may 
change in time.

Kenji

Re: [9fans] ACME mail

[forsyth]

>>(1)We should send out ISO-2022-JP charset email, if we want to
>>keep good relation with them.

i don't see the point in that:  aren't they invariably using software
that understands MIME?  on the other hand, it is irritating
to receive a message sent with a default non-utf charset
and having Outlook insist on downloading a huge
update and fonts and other things just to discover that it was
english text after all!  (i have more experience with big5 that
way than 2022-jp, but i've seen the latter too.)
isn't this `default charset' requirement effectively obsolete?
apart from old Plan 9, i'd have thought that nearly everyone
was using MIME-enabled mailers.  are they using mainframes?
the `default charset' mail ends up being
tagged with MIME headers anyhow, as far as i can tell
(which triggers Outlook to download the fonts).
is it really worthwhile tagging 2022-jp instead
of utf-n for outgoing mail from Plan 9?
there must be something obvious i'm missing.

Re: [9fans] ACME mail

[okamoto]

Thanks Bob.

>we keep ed around for use on our unix systems.  ned uses
>the upas/fs to serve a mailbox and marshall to compose a

I looked the source of marshall, and found that it supposes only
UTF-8 or US-ASCII for sending out charset.  In Japan, many
living in the other world than us use ISO-2022-JP charset
for exchanging email.

So, the interest is:

(1)We should send out ISO-2022-JP charset email, if we want to
keep good relation with them.  Of course, we can send Mime
formatted UTF-8, but in that case, we may lose something. 
(This is mailing-list is aliased to "UTF-8 mailing-list", so we
can use UTF-8 ?).

(2) I want to have UTF-8 charset files in our disk if it is plain/text, 
for the sake that we can read it anytime.  Then, I suppose it may 
be better to convert ISO-2022-JP formatted mail to UTF-8 when 
we received it.  In this case, then, we'll have a UTF-8 charset
file of, say,

<UTF-8 charset headers>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP.

<body of UTF-8 charset content>

When I see the sources under /sys/src/cmd/upas, there
seems to be a different principle.  There, we'll have IS-2022-JP
charset file same to its orignal form. How do you think (all)?

Kenji

Re: [9fans] ACME mail

[bobf]

> There are two kinds of directory in /sys/src/cmd/upas, ned
> and ed.   I guess ned means new ed, if so :-), ed is not used for
> other than pop3 protocol?
> 
> Am I neccessary to look sources only under ned?

we keep ed around for use on our unix systems.  ned uses
the upas/fs to serve a mailbox and marshall to compose a
message.  we could probably port the latter to unix, but
the former is problematic.

you can change either ed or ned depending on which
you use to read your mail.  acme uses upas/fs but i
don't think it uses ned or ed.  see the comments in
/acme/mail/readme.

Re: [9fans] ACME mail

[okamoto]

>9fans is by far the most suitable candidate to test the
>implementation :-).

Hahaha!

By the way, I have to add ISO-2022-JP charset to upas.
There are two kinds of directory in /sys/src/cmd/upas, ned
and ed.   I guess ned means new ed, if so :-), ed is not used for
other than pop3 protocol?

Am I neccessary to look sources only under ned?

Kenji

[9fans] ACME mail

[lucio]

9fans is by far the most suitable candidate to test the
implementation :-).

++L