Ken wrote:
> So I was surprised that git did color as well, because it sure
> doesn't do that by default for me. Even though the man page
> says that --color=always is the default.
The man page is confusing. It's trying to say that --color
is the same as --color=always. It then says: "The def
>> my two reactions are: a) i didn't even know git did color,
>
>That's what got me started with all this. I find it
>incredibly helpful with git (diff and status, and it looks
>neat with log --graph). And after using color with scan
>for a few days, I wish I had enabled it a long time ago.
So I
If you use less or w3m as a pager, here's a cheap way to color
header fields. In mhl.headers:
; less and w3m reset text color and attributes at the end of each line:
From:decode,component=^[[1;31mFrom
Subject:decode,component=^[[1;36mSubject
^[ = ASCII ESC
David
___
Steve wrote:
> i'm willing to contrib a GTK+ color theme, if someone reminds me
> when this is working and there's a working example to crib from.
etc/scan.highlighted has been updated with a black background
on the colorized (cur and unseen) lines.
You'll need the latest code for the zputlit su
> On Wed, Nov 7 2012 at 2:40pm EST, Ken Hornstein wrote:
>
> Hm. If you don't care which hilight is first, I _think_ you can do it.
> Untested, but
>
> %(void(msg)%(void(modulo 2))%<(eq 0)...hilight on...%|...hilight off%>
>
> Hm, well, that only works assuming contiguous message
>has anyone given any thought to colorizing the background of alternate lines
>of scan output? i've only been skimming, but i think "the way it ended up"
>leaves that as not directly possible?
Hm. If you don't care which hilight is first, I _think_ you can do it.
Untested, but
%(void(msg)%
In the message dated: Tue, 06 Nov 2012 21:13:45 EST,
The pithy ruminations from Michael Richardson on
were:
=>
[SNIP!]
=>
=> To those who are thinking about colours, please remember to set both
=> foreground and background colors. YOU have no idea what my background
=> colour is. I
> To those who are thinking about colours, please remember to set both
> foreground and background colors. YOU have no idea what my background
> colour is. It's not always "white"
> (color-ls got this wrong for along time, vim still does)
it can be even worse...
in xterm, colors 0 through 1
Michael wrote:
> To those who are thinking about colours, please remember to set both
> foreground and background colors. YOU have no idea what my background
> colour is. It's not always "white"
> (color-ls got this wrong for along time, vim still does)
Good point. I'll add background color to
> "Paul" == Paul Fox writes:
Paul> david wrote:
>> git uses ANSI escape sequences for colors, too. It doesn't use
>> terminfo at all.
Paul> my two reactions are: a) i didn't even know git did color, and
Paul> b) why does anyone bother shipping a terminfo with more than
Paul wrote:
> my two reactions are: a) i didn't even know git did color,
That's what got me started with all this. I find it
incredibly helpful with git (diff and status, and it looks
neat with log --graph). And after using color with scan
for a few days, I wish I had enabled it a long time ago
david wrote:
> git uses ANSI escape sequences for colors, too. It doesn't
> use terminfo at all.
my two reactions are: a) i didn't even know git did color, and b)
why does anyone bother shipping a terminfo with more than one entry
these days? clearly we wouldn't miss it very badly.
on the oth
git uses ANSI escape sequences for colors, too. It doesn't
use terminfo at all.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
On 2012-11-05, at 18:23 PM, Ken Hornstein wrote:
> I _believe_ that if you turn color/hilighting on/off on every line, it
> should be okay, because each line is it's own write(2) call. But I put
> this under "you turn on color/hilighting, you should know how to deal
> when it breaks".
You can t
>The question isn't "if the comm link breaks", but "if you control-C or
>kill -9 the sucker because you just did this:
>
>[~] folder +linux-kernel
>linux-kernel+ has 185962 messages (5-205596); cur=203756.
>[~] scan
I _believe_ that if you turn color/hilighting on/off on every line, it
should be
Valdis wrote:
> The question isn't "if the comm link breaks", but "if you
> control-C or kill -9 the sucker
Thanks, that helps me understand. Though an atexit() handler
won't get a chance with kill -9.
David
___
Nmh-workers mailing list
Nmh-workers@n
On 5 November 2012 at 19:24, valdis.kletni...@vt.edu wrote:
> The question isn't "if the comm link breaks", but "if you control-C or
> kill -9 the sucker because you just did this:
>
> [~] folder +linux-kernel
> linux-kernel+ has 185962 messages (5-205596); cur=203756.
> [~] scan
>
I run /usr
On Sun, 04 Nov 2012 22:03:44 -0600, David Levine said:
> For my scenario of using an xterm to run scan on some other
> host, I don't want a purpose built formatter with an
> atexit() handler. If the comm link breaks, there is no way
> scan could reset my terminal.
The question isn't "if the comm
ken wrote:
> >I'm guessing inc(1) suffers from using scan's functions even though it
> >has no -clear itself.
>
> Actually, scan(1) reads termcap so it can get the terminal width
> (if TIOCGWINSZ fails or is not supported). inc(1) reads termcap
> because it wants to do the same thing that s
>I'm guessing inc(1) suffers from using scan's functions even though it
>has no -clear itself.
Actually, scan(1) reads termcap so it can get the terminal width
(if TIOCGWINSZ fails or is not supported). inc(1) reads termcap
because it wants to do the same thing that scan(1) does.
--Ken
Lyndon wrote:
> But you're still dealing with the issue of tracking the
> column counter. A binary string can contain printable
> characters
Not allowed to zputlit.
> 2) What happens to the terminal state when the program is
> interrupted in the midst of printing to the terminal? You are
> pot
On 2012-11-03, at 4:33 PM, Ralph Corderoy wrote:
> But it limits them to colour-setting terminfo entries. Surely the first
> step is to allow an arbitrary binary string through as it permits
> everything; the user can decide how to wangle what they want into the
> format file.
But you're still
Hi Lyndon,
> You can get the sequences out of terminfo without having to use the
> full blown curses interface. (tparm() if memory serves).
Agreed.
$ tput setb 3 | hd
1b 5b 34 36 6d|.[46m|
0005
$
> And by using terminfo, you make
On 2012-11-03, at 6:16 AM, Ralph Corderoy wrote:
> There is dircolors(1) to help set LS_COLORS for ls(1) to read, e.g.
> `dircolors --print-database', but I agree with disliking hard-coding
> ANSI escape sequences.
Hardcoding is silly ;-)
You can get the sequences out of terminfo without having
Here's my proposed addition, including an example
etc/scan.highlighted. Comments?
The fmt_compile.h diff doesn't show the trivial number changes
for all following tokens. And the Makefile.am, man page, and
test additions aren't shown here.
In fmt_scan.c, width is the parameter to scan -width, f
ralph wrote:
> Hi Paul,
>
> > why do scan and inc already link against termcap?
>
> $ ltrace -l /lib/libncurses.so.5 scan -clear last >/dev/null
> tgetent(0, 0x7fff5bd4348c, 2, 2, 0x414e40)
>
Hi Paul,
> why do scan and inc already link against termcap?
$ ltrace -l /lib/libncurses.so.5 scan -clear last >/dev/null
tgetent(0, 0x7fff5bd4348c, 2, 2, 0x414e40)
= 1
tgetflag(0x
ralph wrote:
> Hi Ken,
...
> > I just looked; ls, at least, hardcodes the ANSI sequence strings into
> > the code (hm, so does grep). I don't know if that's standard practice
> > or not; somehow doing that still sticks in my craw.
>
> There is dircolors(1) to help set LS_COLORS for ls(1) t
Hi Ken,
> for example, man outputs "bold" text by doing overstriking with ^H and
> less knows how to deal; I don't know if that was planned as much as it
> is an artifact of history.
man (nroff) gets bold by overstriking because moving the teletype's head
back and putting down more ink is the bes
On Fri, Nov 2, 2012 at 4:10 PM, Lyndon Nerenberg wrote:
>
> On 2012-11-02, at 1:51 PM, valdis.kletni...@vt.edu wrote:
>
> > There's some support for different styles on *types*
> > of lines (current, deleted, read/unread, selected), but you can't do "if
> it's from
> > my boss, make the 'from' fi
On Sat, Nov 3, 2012 at 12:14 AM, Lyndon Nerenberg wrote:
>> Pretty much every modern terminal (emulator) supports color, so more
>> power to those that want to do add color to scan output.
>
> But is it worth the added code complexity?
But that is not what the initial criticism was about, unless
On 2012-11-02, at 14:55 PM, Earl Hood wrote:
> Pretty much every modern terminal (emulator) supports color, so more
> power to those that want to do add color to scan output.
But is it worth the added code complexity? What's bugging me the most about
this proposal is that there is a solution b
>> So what do others think?
>
>That this functionality in a command line tool is silly. If you need a
>GUI, install exmh.
Well, I respectfully disagree. If we replace "cyan" with "bold"
or "underline", we're talking about functionality that has been
used with VT100-compatible terminals for a lon
On Fri, Nov 2, 2012 at 4:12 PM, Lyndon Nerenberg wrote:
>> But if someone else is motivated
>> to make nmh be able to look like modern "ls", "grep" and "vi" (vim)
>> then, I suggest, so be it.
>
> We should be silly because other people are silly? Now *that's* silly :-P
There is nothing silly ab
Oliver wrote:
> Multiplying maximum width by MB_CUR_MAX is one way to determine a
> suitable buffer size though that doesn't allow for escape seqences for
> colours. Is it too ugly to have the function allocate the buffer and
> rely on the caller to free it?
fmt_compile() does that, but not fmt_s
Ken Hornstein wrote:
> My thinking was to add an extra parameter to fmt_scan() that meant the buffer
> size available and limit the output based on both the number of characters
> and the total buffer size. This is easy enough to do, but I realize that
Multiplying maximum width by MB_CUR_MAX is o
On 2012-11-02, at 1:45 PM, ra...@hep.wisc.edu wrote:
> But if someone else is motivated
> to make nmh be able to look like modern "ls", "grep" and "vi" (vim)
> then, I suggest, so be it.
We should be silly because other people are silly? Now *that's* silly :-P
_
On 2012-11-02, at 1:51 PM, valdis.kletni...@vt.edu wrote:
> There's some support for different styles on *types*
> of lines (current, deleted, read/unread, selected), but you can't do "if it's
> from
> my boss, make the 'from' field of the scan output red".
Then this sounds like an exce
valdis.kletni...@vt.edu wrote:
> > That this functionality in a command line tool is silly. If you
> > need a GUI, install exmh.
>
> Ironically, exmh doesn't have a good way to do colorizing or
> highlighting of scan output *either*. There's some support for
> different styles on *types* o
On Fri, 02 Nov 2012 13:15:50 -0700, Lyndon Nerenberg said:
> That this functionality in a command line tool is silly. If you need a GUI,
> install exmh.
Ironically, exmh doesn't have a good way to do colorizing or highlighting of
scan output *either*. There's some support for different styles o
> > So what do others think?
>
> That this functionality in a command line tool is silly. If you need a GUI,
> install
> exmh.
*I* agree that colorization in a command line tool is silly, and thus
I would never spend time adding it. But if someone else is motivated
to make nmh be able to
> So what do others think?
That this functionality in a command line tool is silly. If you need a GUI,
install exmh.
--lyndon
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
On 2 November 2012 at 14:40, Ken Hornstein wrote:
> For me ... I'd prefer to not do the "display" sugar right now. I just
> don't like the idea of putting knowledge of JUST ANSI escape sequences
> directly into nmh; that seems wrong. Making it possible for users to
> use them, fine. Providing
>We already have \-processing, though output functions like putstr strip
>them.
Careful ... how that's implemented is a bit wonky.
Technically \-processing doesn't happen in the format code; it
happens in a function called new_fs() (sbr/fmt_new.c). Well,
new_fs() calls normalize(), but you get t
Hi,
David wrote
> While terminfo or something higher level, more generic, etc., would be
> nice, we're so close now to supporting ANSI escapes that I'd like to
> (and am going to :-) get them to work. It doesn't preclude adding
> something else, of course.
I'd worry implementation is rushing ahe
>Yes, you'll be able to do that with just the new zputlit
>support. The questions are whether we want to add the
>"display" sugar and/or the predefined escape values.
For me ... I'd prefer to not do the "display" sugar right now. I just
don't like the idea of putting knowledge of JUST ANSI escap
Ken wrote:
> >%(display cyan)%(zputlit)
>
> Hm. Could you do
>
> %(void(profile cyan))%(zputlit)
>
> instead?
Yes, you'll be able to do that with just the new zputlit
support. The questions are whether we want to add the
"display" sugar and/or the predefined escape values.
David
_
>%(display cyan)%(zputlit)
Hm. Could you do
%(void(profile cyan))%(zputlit)
instead?
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken wrote:
> - Can we just stick with the original idea of outputting escape characters?
>
> Well ... maybe. The problem is the limitation of the format language.
> For example, you can't have an argument to a function which contains
> a ')' character. Maybe that isn't a concern. We migh
>I was envisioning just one function, that takes the terminfo symbolic
>name of a capability and gives back the actual string.
Well ... it's not that simple. As I read it you need to parameterize
it with tparm(), which means you need to take multiple arguments.
This isn't so hard from the mh-form
Ken Hornstein writes:
> - Can we use curses? Short answer: no.
Check.
> - Can we use terminfo? Short answer: maybe.
> My gut feeling is that terminfo seems to be what people have converged
> to using. It's not apparant at first glance how you translate a terminfo
> capability to the ac
So I've been thinking about this overnight and looking at some things
this morning, and I'm not sure what the right answer is.
First off, let's start with Paul Fox's comment yesterday:
>the 1980's just called. they want their termcap file back.
Ouch. :-) Okay, I know that was all in good fun,
Ken wrote:
> Jerrad points out it's a zero-width operator ... maybe "zputstr"?
"zputlit"?
The (putlit) function outputs the exact contents of str
register without any changes such as duplicate space
removal or control character conversion.
David
> >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 sympathe
>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 viewpoi
>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
_
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 putti
>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
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 s
> > 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
>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
wit
David Levine 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 against the w
Paul wrote:
> i think my usual inclination for colorization is to
> post-process with sed. i haven't done it with scan
> output, but i do it with a couple of different mail
> perusing scripts i've written.
After trying it for a bit, I want it built into nmh.
I do too many different things with s
Ken wrote:
> My thinking was to add an extra parameter to fmt_scan() that meant
> the buffer size available and limit the output based on both the
> number of characters and the total buffer size.
Yup.
> My issue is straightforward and doesn't require any user-visible
> changes, but I am thinkin
>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
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 sh
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 I
67 matches
Mail list logo
