Re: [9fans] upas : without acme : possible?

Re: [9fans] upas : without acme : possible?

[sl]

> is that "mail" you mention similar to "mailx" under unix-like systems?
> the problem is one of not wanting a captive user-interface to the
> mailing sub-system.

On Plan 9, 'mail' is a shell script that invokes either nedmail(1) or
marshal(1), depending on the flags it consumes.

The nedmail program is nearly identical, from a user interface
standpoint, to the mail command that shipped with the 8th edition of
Research UNIX.  It remains part of the same (though evolved) e-mail
processing system, upas.

Ned is a little different than mailx(1), but it's probably just about
what you're looking for.

Plan 9's mail system itself (upas) relies heavily upon upasfs(4),
filter(1), and simple rc scripts, which make even complex tasks
like custom spam filtering and automatic mailbox management
trivial.

sl

Re: [9fans] upas : without acme : possible?

[Mayuresh Kathe]

On 2018-11-30 09:02 AM, sl@9front.org wrote:
>> is that "mail" you mention similar to "mailx" under unix-like systems?
>> the problem is one of not wanting a captive user-interface to the
>> mailing sub-system.
>
> On Plan 9, 'mail' is a shell script that invokes either nedmail(1) or
> marshal(1), depending on the flags it consumes.
>
> The nedmail program is nearly identical, from a user interface
> standpoint, to the mail command that shipped with the 8th edition of
> Research UNIX.  It remains part of the same (though evolved) e-mail
> processing system, upas.
>
> Ned is a little different than mailx(1), but it's probably just about
> what you're looking for.
>
> Plan 9's mail system itself (upas) relies heavily upon upasfs(4),
> filter(1), and simple rc scripts, which make even complex tasks
> like custom spam filtering and automatic mailbox management
> trivial.

i was looking for a non-captive user-interface email client like "mh" by
rand corporation. i guess i'll either have to learn to use acme with
upas or write my own "mh" replacement for plan 9.

~mayuresh

[9fans] non-captive user-interfaces: some ramblings; Plan 9 possibilities

[Ethan Gardener]

On Fri, Nov 30, 2018, at 3:53 AM, Mayuresh Kathe wrote:
> non-captive user-interface

There's a term for what I've been looking for!  Lately I've been wanting to implement basically everything with non-captive interfaces.  I've been having trouble designing the programs because of my poor memory and other issues.

On the other hand, now I realise that a program I've heard of repeatedly over the last 20 years has the type of interface I'm looking for, I'm wondering why I didn't use it, if there's something wrong with the concept, something I felt but couldn't quantify.  I think maybe a general malaise when using the unix command line, probably initially due to trying to learn by reading init scripts of Red Hat 5.2; a source of brain damage almost on a par with BASIC!  Poor documentation in the 90s and tremendous option bloat obviously contributed to my malaise.  I did try hard at times.

I think netpbm was what finally put me off.  Inconsistent cryptic options, view-updating only by manual means, state-keeping also manual; I think those were the problems.  Ah, not netpbm; Plan 9's image tools are far more consistent, but the other two problems remain.  I guess both are worse in editing (text or images) than in mail.

I'm thinking of a two-pane view, one being a REPL of some sort, the other a display of what you're editing, obviously keeping state, and having an undo facility.  Obviously different display programs for text or images.  This could actually be scripted in Plan 9, especially in 9front where rio's text files are writable.  A minor catch is that you want the filters to operate on the displayed data rather than stdio.  This could be worked around by piping, or by a clever shell inserting redirects if none are specified.  (A wrapper around rc could do it.)  The display programs could (probably should) handle the case of `prog <dispfile >dispfile`.  Now I'm wondering if, when editing text, all output on stdout should go into the displayed text.  I guess that's reasonable, there is always undo, but I'm running out of functioning brain cells, lol.

[9fans] MH port

[Lyndon Nerenberg]

Mayuresh Kathe writes:

> i was looking for a non-captive user-interface email client like "mh" by
> rand corporation. i guess i'll either have to learn to use acme with
> upas or write my own "mh" replacement for plan 9.

A year-or-so ago I started working on my own version of MH, forked
from a then current nmh.  One of the goals for the version I'm doing
is to have a native (as much as is possible) Plan9 build; one that
gets along with upasfs and the plumber as much as possible.

So far most of the work has been cleaning up the code base. E.g.
ripping out all the GNU auto* build nonsense, and getting the code
to compile cleanly in a pure ANSI C environment.

Once that's finished it should be relatively straight forward to
add basic APE build support.  This is a couple of months out yet,
based on my current rate of progress :-(

--lyndon

Re: [9fans] MH port

[Lyndon Nerenberg]

Mayuresh Kathe writes:

> just so that i know, are you targeting plan9 users for your version
> of 'mh'? if yes, will they be interested in migrating away from the
> way they are working currently, i.e. with acme and upas?

Yes, and no.

Yes, in that I intend this MH to fully integrate with the Plan9
environment (upas, plumber, factotum) when run there.  That will
come with time.  The first step is to get the existing code building
and running, with a very basic inc(1) interface that pulls from the
user's inbox (just like with UNIX).

No, in that there will never be a "one true MUA" any more than there
is *any* "one true X" for any value of X.  On Plan9[1] I am constantly
moving back and forth between nedmail, acme Mail, and a basket
full of my own programs, depending on the task at hand.  The upas
filesystem interface makes the latter a breeze to implement.

MH is just another nugget in that basket of tools.

--lyndon

[1] Not just Plan9.  On UNIX systems I can't keep count of the number
of MUAs, MSAs, and the like I use, and almost always in parallel.  Again,
which tool I use is dictated by what I'm trying to accomplish at the
moment.