[92] in bug-owl
multi-col characters patch
daemon@ATHENA.MIT.EDU (Jeremy Daniel)
Tue Sep 24 19:09:53 2002
To: bug-owl@MIT.EDU
From: Jeremy Daniel <jdaniel@MIT.EDU>
Date: 24 Sep 2002 19:09:46 -0400
Message-ID: <sked6r356it.fsf@multics.mit.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
--=-=-=
This patch is in responce to my earlier message of bug-owl[0046]
(attached below). The complexity it adds is unfortunate, but I've
been unable to discover another way to work around the bug.
Essentially the reasoning is this: Curses sems to have no function
that will tell me whether a single character will print as multiple
columns. The only thing to do then is print it and check the location
of the cursor (the man pages also mention wcurs_inch but it didn't
look any more useful).
Therefore, in order to make certain not to overflow onto the next line
we have to print one character at a time, and each time check our
position with getyx(). If we do overflow we move back to the first
column, skip the rest of that line, then continue on with printing the
next line. Skipping the rest of the line has some complexity since
the normal course of action for long lines is to overrun the end of
line and we therefore leave out those newlines so their proper
locations have to be infered from the window width.
The only remaining issue then is if a multicolumn character starts on
the last column. It would then overflow onto the first column of the
next line. This patch does not blank it (although that might be
wise), but allows the next write to write over it. I can think of no
work around for this except perhaps we should adopt a syntax like
emacs's '$' to mark that one can scroll right, making sure the last
character on each line is indeed single column.
Please let me know your thoughts on this . . .
-----
/mit/jdaniel/project/owl/build-cvs/patches/multicol_chars.patch
-----
Index: fmtext.c
===================================================================
RCS file: /mit/ktools/src/owl/repository/owl/fmtext.c,v
retrieving revision 1.6
diff -u -r1.6 fmtext.c
--- fmtext.c 2002/09/16 22:13:41 1.6
+++ fmtext.c 2002/09/24 19:20:52
@@ -341,12 +341,16 @@
void owl_fmtext_curs_waddstr(owl_fmtext *f, WINDOW *w) {
char *tmpbuff;
- int position, trans1, trans2, len, lastsame;
+ int position, trans1, trans2, len, lastsame, y, oldy, x, wincols, newlinepos;
+ char ch_as_str[2];
tmpbuff=owl_malloc(f->textlen+10);
position=0;
len=f->textlen;
+ getmaxyx(w, y, wincols);
+
+ newlinepos=position;
while (position<=len) {
/* find the last char with the current format and color */
trans1=owl_util_find_trans(f->fmbuff+position, len-position);
@@ -377,13 +381,34 @@
wattron(w, COLOR_PAIR(f->colorbuff[position]));
}
}
-
- /* add the text */
- strncpy(tmpbuff, f->textbuff + position, lastsame-position+1);
- tmpbuff[lastsame-position+1]='\0';
- waddstr(w, tmpbuff);
- position=lastsame+1;
+ /* Add the text one character at a time checking position each
+ time. Create a single character string for printing it since
+ waddch seems to draw some high bit characters in reverse video
+ */
+ getyx(w, oldy, x);
+ ch_as_str[1] = '\0';
+ while (position<=lastsame) {
+ ch_as_str[0] = *(f->textbuff + position);
+ /* don't print the terminal null */
+ if (ch_as_str[0])
+ waddstr(w, ch_as_str);
+ getyx(w, y, x);
+ /* if we ran over skip to the next newline
+ OR where we _should have_ overrun the current line
+ */
+ if (y != oldy) {
+ oldy=y;
+ /* make sure we're starting the next line at the first column */
+ wmove(w, y, 0);
+ while ((*(f->textbuff + position) != '\n') &&
+ (position < newlinepos+wincols))
+ position++;
+ newlinepos=position;
+ }
+ position++;
+ }
+
}
owl_free(tmpbuff);
}
--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline
Subject: weird artifacts
Message-Id: <bug-owl:46@unknown-discuss-server>
X-Discuss-Garbage: [0046] daemon@ATHENA.MIT.EDU (Jeremy Daniel) bug-owl 06/30/02 01:10 (75 lines)
To: bug-owl@MIT.EDU
From: Jeremy Daniel <jdaniel@MIT.EDU>
Date: 30 Jun 2002 01:10:15 -0400
X-Discuss-Message-ID: <skeofdt8i88.fsf@multics.mit.edu>
Lines: 68
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
The main problem here involves characters in the message which take up
more than one column the way you're printing them. In particular the
following examples contain the characters '^_' and '^A'. Here are the
symptoms I am seeing.
-D H. J. Lu -DISCUSS ^_GCC 88777: Re: optimization/7145: g++ -
O jsmthng -jsmthng
The particular problem here is the 'O' in the left column of the
second line. It's actually the next character from the previous line,
printing when it should not. Owl's counter of what to print is thrown
off one by the '^_'.
-D H. J. Lu -DISCUSS ^_GCC 88777: Re: optimization/7145: g++ -
D foobar -foobar
Once I delete the message it appears normal, but if I undelete it it
returns how it was. I think the " D" is overwriting the character.
If I change the screen width it continues to be always the next
character off the screen which will appear in the first column.
Here's an example of making it very narrow and how many lines such an
artifact can throw off. Notice how it doesn't fix itself until you
get to the first visible '\n' on the page.
-D H. J. Lu -DISCUSS ^_GCC
8 foobar -foobar
yikes, larger-than-I-want credit c
a but I guess more than half of it i
D bazquux
{ bazquux
( not yet. tomorrow
-> daemon -sipb-auto .sipbmp3 (
Playback completed successfully.
No ID3 tag found
Filename: g/Gin Blossoms/Gin Blossoms
----------------
Here's a very different but also weird example:
olc.matiss -olc .new_question {test} (From: OLC Service~New "test" question from user mitchb [0].~^A^A^A^A^A^A^A^
DA^A^A^A^A^A^A OWL ADMIN Message sent to foobar bazqux
This particular one only happens at rather wide screen widths or when
scrolled to the right. I think the problem here is that $owl::body
never got initialized to '\0'. So when my default format function
appended it something weird must have happened. I counted and there
appear to be 160 or so '^A' characters in the body of this message.
-----------
I hope you find these descriptions useful enough to debug. For
reference I am using $TERM=screen on a screen from gnu inside PuTTY,
but I'm thinking that shouldn't make such a difference, especially for
the failure to initialize $body one.
--
Jer
------------------------------------------------------------------
Tulgey Wood - tulgeywood@attbi.com Cell Phone: 617-429-8573 /
4 Farragut Ave (617-629-3983) jdaniel-phone@mit.edu
Somerville, MA 02144-1709 AIM: jdanielmit
Zephyr athena users over the web: http://webzephyr.mit.edu/
--=-=-=
--
Jer
------------------------------------------------------------------
Tulgey Wood - tulgeywood@attbi.com Cell Phone: 617-429-8573 /
4 Farragut Ave (617-629-3983) jdaniel-phone@mit.edu
Somerville, MA 02144-1709 AIM: jdanielmit
Zephyr athena users over the web: http://webzephyr.mit.edu/
--=-=-=--
