It looks like someone harvested email addresses from the list and I'm
getting a LOT of spam containing my original subject line. Anyone
else see this too?
Sigh
--
Kevin
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Hi,
I tried adding some raw ANSI escape sequences to a scan
format to colorize the cur and unseen messages, and they
sort of work. I get the desired effects, but scan loses
track of how many characters are actually displayed so there
are some annoyances. They should be easy to fix.
But before
Kevin wrote:
It looks like someone harvested email addresses from the list and I'm
getting a LOT of spam containing my original subject line. Anyone
else see this too?
I haven't seen this. I'm not on exmh-users.
David
___
Nmh-workers mailing
david wrote:
Hi,
I tried adding some raw ANSI escape sequences to a scan
format to colorize the cur and unseen messages, and they
sort of work. I get the desired effects, but scan loses
track of how many characters are actually displayed so there
are some annoyances. They should
I tried adding some raw ANSI escape sequences to a scan
format to colorize the cur and unseen messages, and they
sort of work. I get the desired effects, but scan loses
track of how many characters are actually displayed so there
are some annoyances. They should be easy to fix.
I don't have a
David Levine levin...@acm.org writes:
Ken wrote:
My issue is straightforward and doesn't require any user-visible
changes, but I am thinking your issue might. I am wondering if
you've thought about how you'd make this work; maybe a format escape
that says, Don't count these characters
I was thinking of looking for ANSI sequences and not counting
them. But I don't know if that could get into trouble with
multibyte characters. mbtowc() is too much of a mystery to me.
Well, this is where things get funky.
In the particular case of UTF-8, the only magical bytes are ones
with
That format escape would avoid the issue.
+1 for a don't count this format escape. I don't think scan should be
assuming anything about what the terminal might take to be an escape
sequence. They're not that well standardized.
Specifically supporting the terminal types xterm and
Ken wrote:
But it occurs to me that we shouldn't actually do any of this for a
don't count this format escape, because that stuff should live
outside of the normal string handling routines in fmt_scan(). Also,
I'm with Tom that I'm not so crazy about putting knowledge of ANSI
escape
Will do. Any suggestions on what to call the escape function?
It sounds like a zero-width operator, though that's rather long.
What about hide?
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
david wrote:
Ken wrote:
But it occurs to me that we shouldn't actually do any of this for a
don't count this format escape, because that stuff should live
outside of the normal string handling routines in fmt_scan(). Also,
I'm with Tom that I'm not so crazy about putting
Will do. Any suggestions on what to call the escape function?
esc was might first thought but it might be confusing to
talk about/describe in the man page. fmtesc? invisible?
Jerrad points out it's a zero-width operator ... maybe zputstr?
--Ken
___
shouldn't this be done with more generic controls, that map to
(uncounted) terminfo/ncurses/whatever's-used-now strings? i.e.,
controls for specifically changing red/blue/bold/etc? feels a little
late to be embedding specific vt100 CSI codes into scan formats.
I'm sympathetic to this viewpoint
shouldn't this be done with more generic controls, that map to
(uncounted) terminfo/ncurses/whatever's-used-now strings? i.e.,
controls for specifically changing red/blue/bold/etc? feels a little
late to be embedding specific vt100 CSI codes into scan formats.
I'm sympathetic to
14 matches
Mail list logo
