On Sat, Jan 24, 2009 at 4:48 AM, Gautam Iyer <gi1...@stanford.edu> wrote:
> On Fri, Jan 23, 2009 at 09:37:24PM +0000, Charles Acknin wrote:
>
>> Gautam, could you please be more specific with "highlight the
>> selection" and how this works? I'm fairly new to the codebase and
>> although not the biggest I've seen out there, it'd help a lot if you
>> could point me directly to the parts of interest that you think are
>> appropriate for the task.
>
> Look in screen.c:4116 (you might have to read a lot of the code before /
> after to follow). Basically each character on screen is stored in two
> arrays -- one for the character PVTS(r,p).text, and one for a bit mask
> of the attributes PVTS(r,p).rend.
>
> Input from a child process is parsed by mrxvt (according to VT100
> specifications), and the data is put into these two arrays. When the
> user selects some text, the corresponding characters in PVTS(r,p).rend
> get bit number Rs_Blink set. When the text is drawn it will be
> highlighted as blinking text.
Thanks for the hints. I'm playing with mrxvt in a debugger to get a
feeling of how this beast works. As far as I understand,
PVTS(r,p)->drawn_text is the array of raw characters displayed on the
screen, and PVTS(r,p)->drawn_rend the corresponding array of
attributes that dictates how each character is rendered on screen
(bold, underlined, color, etc). So it is always true that
len(PVTS(r,p)->drawn_rend) == len(PVTS(r,p)->drawn_text) such as if we
have "foo" displayed on the screen with "oo" in bold, then
PVTS(r,p)->drawn_text == { 'f', 'o', 'o' } and PVTS(r,p)->drawn_rend
== { normal, bold, bold }. Please correct me if I'm wrong so far.
I'm still trying to figure out why when changing PVTS(r,p)->drawn_rend
or PVTS(r,p)->drawn_text in the debugger the modifications are not
reflected on the screen, which makes me thing I must have missed
something. Ideas? And also, what's a good place where this
modification (of parsing and setting the highlight attribute in rend)
should be done? I guess it should happen just before spitting out the
bytes to the user.
> What you should do is add a byte to PVTS(r,p).rend. This will give 8
> extra bits of information (at the expense of a little more memory use).
> One of these bits should be for the user selection -- selected text
> should have it's own attribute, and not reuse the blink attribute. The
> others can be used for user defined patterns. (It would be nice to
> reserve at least one such bit for URL's, and incorporate some way for
> the user to open them easily.)
Why exactly should we add a byte to PVTS(r,p).rend? It seems to me
that we're already able to represent 256 different combinations per
character, don't we have some bits left here for the highlighting?
Put differently, is mrxvt already using the whole attribute spectrum?
On Sat, Jan 24, 2009 at 5:05 AM, Gautam Iyer <gi1...@stanford.edu> wrote:
> You would of course have to add code that matches regexps against the
> scrollback buffer every time text on screen changes (and accordingly
> update the attributes above). This should be done in a somewhat smart
> way -- if a program is spewing 100's of lines of crap per second, then
> we shouldn't hog CPU by needlessly matching patterns. The user wont see
> this text, until he scrolls up, so we should only match when needed.
>
> We should do some sort of delayed matching -- only the text on screen is
> matched, and only close just before screen refreshes. This doesn't
> always correspond to output from the child, since mrxvt does some
> caching. If the child is spewing a lot of data, then mrvxt delays the
> refresh until the child stops making noise.
Good point, I think I'll take care of this in a second step, that
sounds like (necessary) optimization.
> If you think this will be more ellaborate than a small patch, then let
> me know and I can give you SVN access. You will however have to take a
> blood oath saying you will conform to the mrxvt coding guidelines before
> committing anything.
Thanks for the offer, I think it's not a huge piece of work but I
wouldn't surprised if I were underestimating the scale of the task.
Let's see how it goes.
Charles
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Materm-devel mailing list
Materm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/materm-devel
mrxvt home page: http://materm.sourceforge.net
