I am new at the list. Sorry for direct (and perhaps stupid)
question.
Does anyone can compile vmh from nmh-1.4-RC2? Form me it gives a
lot of errors.
I read at list archive that in nmh there is something like vmh.
This what I need, ncurses interface to nmh, but it is not a part
of debian nhm pack
Joel Uckelman writes:
> > > So, I have some thoughts in this direction, but I'm wondering: what do
> > > you want out of repl in terms of better MIME handling?
> >
> > All the "text" parts turned into UTF-8 and quoted would be a good start.
> > I can then trim down in vi as normal.
>
> Yes, ple
Ken Hornstein writes:
> >*Please, no!* Conversion from any charset to utf-8 is possible, but
> >conversion back, according to user preferences, is not. People
> >start to use funny characters like non-breakable space and so on.
>
> Unfortunately, we don't have unlimited development resources.
>
Ken Hornstein writes:
> There is a good chunk of code inside of nmh that assumes ASCII (in
> terms of "what is a space", "what is a newline", and other things).
> [..]
> internal representation UTF-8.
What do you mean by "internal representation"? Conversion from
any to utf-8, processing by t
Joel Uckelman writes:
> Thus spake Oliver Kiddle:
> >
> > The limitations occur where e-mails use characters that can't be
> > displayed in the current locale but we can't do anything about that.
> >
> How likely is it that a message containing characters undisplayable in
> the user's locale wi
Ralph Corderoy writes:
> Hi Aleksander,
>
> > For English-speaking countries UTF-8, in majority, means ASCII, they
> > can see no difference.
>
> I don't think that's the case. Even North Americans, who have $ in
> ASCII, still find ` ' " " and ... cropping up, especially when services
> automa
Lyndon Nerenberg writes:
> >> But restrict the entire nmh to utf-8 charset would cripple system.
>
> How so, specifically? Plan9 has run a native UTF8-only mail environment
> for ages (with a very MH-like mailstore, as well), and it's far from
> crippled.
This a tiny difference between "ent
Ken Hornstein writes:
> > Couple of years ago emacs switch to "internal" coding in utf-8. I
> > had to stop using emacs and mh-e.
>
> See, this is what I'm missing - why, exactly? I assume the problem was not
> just philsophical.
Neither politycal, nor religious =:-) Purely practical.
Imagine
Ralph Corderoy writes:
> Hi,
>
> I still use mail(1) for sending one-line emails or in pipes.
More imporant (for me) is the possibility to send only file(s) as
attachements.
echo Enclosed | nail -a some.file some...@somewhere.net
Similar functionality has mutt, switch -a. I can't do it via
In the .mh_profile some entries specifies programs like:
Editor: vim-mail
moreproc: less
postproc: /usr/lib/mh/post
Some of those programs require options or parameters but
apparently this is not accepted.
I need moreproc to be "less -force" but show (nmh-1.3) refuses
this.
Workaround is to ma
Joel Uckelman writes:
> My wife pointed out to me today that for the past seven years (!) since
> the Linux distribution we use switched to UTF-8, when she sends messages
> containing non-ASCII characters [..] and that nmh is
> producing messages which lack any headers indicating that the contents
Ralph Corderoy writes:
> Hi max,
>
> > Why not set in .mh_profile
> > automimeproc: 1
>
> I like to look over the mime'd draft before sending to check I got the
> directives right.
Well, it seems that both approaches can coexists if buildmimeproc
would do nothing in case of already MIMEfied mes
Ken Hornstein writes:
> >I need moreproc to be "less -force" but show (nmh-1.3) refuses
> >this.
>
> Yeah, I guess what happens there is mhl (or whatever) is trying to
> exec("less -force"). Which as you've noted doesn't work.
>
> Other people have complained about this as well. But in this ca
Ken Hornstein writes:
> >Well, it seems that both approaches can coexists if buildmimeproc
> >would do nothing in case of already MIMEfied message. Instead of
> >error reporting.
>
> There is one caution here ... if you have a line that begins with a "#"
> that is NOT an mhbuild directive then yo
Ken Hornstein writes:
> >It is possible to keep almost unchanged state with addition of
> >one more clause to mhbuild like pair #off #on which marks the
> >region where ^# is not interpreted as directive.
>
> But to me it seems dumb that # characters can't be in the
> beginning of a line, and h
Ken Hornstein writes:
> I've been grappling with to do when we have issues with character set
> conversion.
Unfortunately, I have a lot of experience and troubles with character
set conversion.
> Specifically, I have two issues:
>
> - What to do if the character set is unsupported.
> Should
Ken Hornstein writes:
> >Unfortunately, I have a lot of experience and troubles with character
> >set conversion.
>
> Well, if you just bit the bullet and switched to UTF-8, you wouldn't have
> all of these problems! :-)
It is not that simple. Utf-8 solves couple of problems but creates some
ne
17 matches
Mail list logo
