Hello Walter!
|I gave s-nail a try, and I like it to the point I'm thinking in leaving
|mutt, which I've been using since years. I'll mention some issues (and
|some criticism) based on this version (s-nail packaged by OpenBSD):
That is very kind. I wouldn't be too strict for now however,
there are tasks which mutt(1) can do so much better, especially
regarding interactive dealing with attachments. But we will be
happy if you come more and more often, for sure!
|& version
|Version v14.8.3
Unfortunately pretty out of date, but doesn't matter regarding the
following.
|& features
|Features: MIME,LOCALES,MULTIBYTE CHARSETS,TERMINAL CHARSET,ICONV,NETWORK,
|S/MIME,SSL/TLS,SMTP,POP3,IMAP,NETRC,AGENT,IDNA,IMAP-SEARCH,REGEX,EDITLINE,
|HISTORY,SPAMFILTER,DOCSTRINGS,QUOTE-FOLD,HTML-FILTER,COLOUR
|
|1st
|----
|Using NCL, non-ascii characters are printed on screen as you type but
|not as wide characters. To reproduce it:
|
|$ export LC_CTYPE=en_US.UTF-8
|$ nail
|& set line-editor-disable
|& echo 10€
|10€
|& unset line-editor-disable
|& echo 10€
|10
|
|In the further processing the non-ascii characters (the one I echoed
|after the 10 is an euro sing) are ignored.
Well i'm using german via UTF-8 on FreeBSD/Apple/Linux/UnixWare
since the beginning and it just works pretty well?
The problem with the old NCL (Nail-Command-Line) is that it
doesn't backspace over wide characters because terminals don't do
that in the mode we use, even though they correctly create the
necessary font symbols and advance the cursor over them when
typing the character in question.
Note that the function to implement the necessary functionality
(wcwidth(3)) in a user program isn't part of ISO C but requires
POSIX (X/Open Portability Guide Issue 4 ("XPG4")).
|But I guess it'll be more desirable to take advantage of readline (bash)
|or editline (obsd ksh) as other command line applications do. Using,
|for example, ftp, lftp, bc I'm able to edit the line using vi or emacs
|mode. I see editline support included in the features list but when I
|disable NCL, line editing capabilities are lost.
I don't understand what you mean? If you compile it your own it
should be possible to use editline(3)?
S-nail v14.9 will bring the heavily improved, new MLE
(Mailx-Line-Editor) which supports wide glyphs, and detachs buffer
handling from the actual terminal buffer, so that lines of any
length (2 gigabytes) can be used. It will support
context-sensitive key bindings.
On the long run i think i'll remove support for any external line
editor, because we'll support the well-known standard bindings
out of the box and users can create whatever binding they want.
The MLE is a good one, except that tabulator expansion doesn't
create a selection list but, well, expands.
We don't honour any editline or readline configuration, though.
|2nd
|-------
|It took me the whole Sunday to figure out why s-nail ignored my
|~/.netrc. And the netrc command showed me some a not very helpful
|message:
|
|& netrc
|Interpolate what file?
The -d and/or -v command line switches very often (and
increasingly) show context information shall something go wrong.
You would have seen
Errors occurred while parsing "/home/steffen/.netrc"
then. Granted this is not very helpful.
|It came out that s-nail doesn't recognize comments (prefixed by #). I'd
|assumed they are accepted netrc syntax since fetchmail, lftp, ftp, msmtp
|and other network applications I use haven't ever complained about them.
Not that i know, it is definetely not portable, i looked around
Unix manuals once i've implemented the parser, which itself was
loosely based upon NetBSD's ftp. But indeed it seems fetchmail
supports comments, so i will add support for them and update the
"The .netrc file" manual section accordingly. Thanks for that!
|3rd
|------
|What about ~/.mailcap? I know that it's just a Unix thing and not an
|internet standard but, do you have wishes Microsoft users will ever use
|s-nail? :-)
Mailcap support will be in v14.9. I like it.
In v14.9 there will be no special subprocess which handles
external viewers etc. in order to support capability-restrictions
in the main program. We may support turning off all MIME part
viewers with a single variable (in equal spirit to
*line-editor-disable*, *colour-disable*, *termcap-disable*, etc.).
I think our v14.9 MIME support will only support "copiousoutput"
automatically, and i'll add a new command which will honour other
entries, too. In v15 we will have the possibility to access
specific MIME parts directly.
This is backward-incompatible behaviour, but anything else doesn't
make any real sense.
|4th
|---
|No offence but a command line version of Thunderbird is a counter sense.
|In my opinion, built in POP, IMAP, SMTP support is too ambitious and not
|the unix way, you already have tools like fetchmail or msmtp. Besides,
|why to force the whole thing towards the IMAP fashion? I still use mbox
|format and download all email to /var/mail/$USER using POP3. I never
|use IMAP; by no way I leave my messages on the server more than
|necessary (including gmail ones). Today, anyone may consider me a freak
|for doing things in this way, but, honestly, why "normal" people should
|ever think about using s-nail :-). So, since I store email in *my*
|machine, why should it affect the way I organize and archive my messages
|how much configured accounts I have or from which one I send or receive?
|Another consideration related: at least "at home" my identity is my name
|not my address or my s-nail configured account, the "showto" option
|should take in care *only* my full name.
I have problems to parse this. The network layer will be
rewritten completely for v15, and will hopefully be smarter
regarding connection resets a.k.a. automatic reconnects etc.
further on. Of course i want more protocols, especially news, but
optional so that users have the choice to reduce functionality as
necessary. I don't want to use anything else but BSD mail, just
a bit improved.
*showto* is a standardized option -- what do you mean exactly?
|I wish you don't take my criticism wrong and my opinion be useful for
|you.
No, sure. I'll add .netrc comments for v14.9, and i will disable
any non-copiousoutput MIME handlers except when a user uses a yet
to-be-invented command. Thanks!
Ciao!
--steffen
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
__________________________________
[email protected]
