>it seems that if i use mh-format coloring in my mhshow marker
>line, that the color gets reset at the end of the marker line
>whether i include a resetterm sequence or not. i see that scan.curses
>explicitly provides resetterm, so now i'm wondering if what
>i'm seeing with mhshow markers is a bug
>>They are similar, but there is a small advantage to using the
>>scan.highlighted format: you can have a shared format file owned by root
>>with abstract names-- scan-color-cur, scan-color-unseen--and users can
>>customize the colors as they wish without having to maintain their own
>>scan format
ken wrote:
> >to be honest, i didn't remember that i could use mh-format to apply
> >the color directly, and since i was already colorizing headers using
> >sed, i just expanded that.
>
> Hey, that's fine. Just wanted to understand if it isn't useful to people.
>
> >i think i'd also want
ken wrote:
> [32m[ part - text/plain - ][m
> >>opposed to just doing it directly in the format engine? 1.6 supports
> >>retrieving some terminal parameter strings directly from terminfo(5),
> >>like the codes to set foreground and background color. If it's not
> >
> >If it does, etc/sc
>to be honest, i didn't remember that i could use mh-format to apply
>the color directly, and since i was already colorizing headers using
>sed, i just expanded that.
Hey, that's fine. Just wanted to understand if it isn't useful to people.
>i think i'd also want a unique syntax
>anyway, since s
>They are similar, but there is a small advantage to using the
>scan.highlighted format: you can have a shared format file owned by root
>with abstract names-- scan-color-cur, scan-color-unseen--and users can
>customize the colors as they wish without having to maintain their own
>scan format ;-)
ken wrote:
> Thanks for the work; it looks good! Unfortunately, since we're in a
> feature freeze for 1.6 I don't think it can go in there.
yup, that's fine.
> Is there a reason you did colorization in your wrapper script, as
> opposed to just doing it directly in the format engine? 1.6 sup
Ahh, I see. The two files might reference one another?
They are similar, but there is a small advantage to using the scan.highlighted
format: you can have a shared format file owned by root with abstract names--
scan-color-cur, scan-color-unseen--and users can customize the colors as they
wish wit
>>opposed to just doing it directly in the format engine? 1.6 supports
>>retrieving some terminal parameter strings directly from terminfo(5),
>>like the codes to set foreground and background color. If it's not
>
>If it does, etc/scan.highlighted should maybe be updated then?
>I was not aware of
>opposed to just doing it directly in the format engine? 1.6 supports
>retrieving some terminal parameter strings directly from terminfo(5),
>like the codes to set foreground and background color. If it's not
If it does, etc/scan.highlighted should maybe be updated then?
I was not aware of any t
>in the absence of any more comments, i've pushed this change (which
>makes all part separator lines configurable) to master. i've been
>using it for a week now, and it seems solid -- i've been testing quite
>a bit with various kinds of messages while writing some new wrapper
>scripts, so it's got
in the absence of any more comments, i've pushed this change (which
makes all part separator lines configurable) to master. i've been
using it for a week now, and it seems solid -- i've been testing quite
a bit with various kinds of messages while writing some new wrapper
scripts, so it's gotten s
ken wrote:
> I'm not fond of the idea of the new pseudo-component you created called
> "hidden". I know you can use it as a boolean, but defining it to a fixed
> string seems wrong to me.
>
> There is an existing function called %(unseen); I think it would be perfect
> for this. The way yo
ken wrote:
> >this issue was rather a big itch for me, so i had to scratch it. i
> >agree about "not 1.6", but i think i might have it, or something
> >close.
>
> I'm mostly okay with this, but there's one thing I'd like to see
> changed.
certainly. i expected to iterate.
>
> I'm not
>this issue was rather a big itch for me, so i had to scratch it. i
>agree about "not 1.6", but i think i might have it, or something
>close.
I'm mostly okay with this, but there's one thing I'd like to see
changed.
I'm not fond of the idea of the new pseudo-component you created called
"hidden"
ken wrote, responding to me:
> >it's unfortunate that the marker for non-displayed parts is
> >customizable, but for displayed parts it is not. looking at
> >the code, i see that that would be a bit of an untangle.
>
> Hrm. Let me meditate on that. Might not be so bad. The key is that
>
16 matches
Mail list logo
