9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: <markp@panix.com>
To: 9fans@cse.psu.edu
Subject: [9fans] the "disappearing text problem" (experiment results)
Date: Mon,  6 May 2002 20:25:02 -0400	[thread overview]
Message-ID: <200205070025.g470P2Q28586@panix1.panix.com> (raw)

well, I'm duly embarrassed. as soon as I sent my mails about the
"disappearing text problem" on the laptops I realized that I forgot to
mention a possibily significant local change... I almost sent a followup
mentioning it, but instead decided I'd wait 'til I had some results to
report just in case it turned out irrelevant.

it wasn't irrelevant. :)

the change: something about the interaction of my less than perfect
vision and the way those yellows display on the LCDs makes it difficult
to discern highlighted text from ordinary text in acme, so long ago I'd
changed the color definitions around /sys/src/cmd/acme/acme.c:846 to
taste. being too lazy to think of any saner color scheme for selected
text at the time, I'd done:

	textcols[HIGH] = display->black;
	textcols[HTEXT] = display->white;


so, I played around and found I could reliably make text seem to
"disappear" by b2ing a command (du -a) that makes an +Errors window with
enough output in it that you have to scroll the window to see all of it.
the output text that's drawn along with the +Errors window was visible,
but output text I saw by scrolling the window with the mouse wasn't.
just solid black blocks.

then I fiddled with the color definitions. it turns out that the text
that wasn't initially visible *is* drawn, but it's drawn in black,
regardless of textcols[HTEXT]. so when textcols[HIGH] is black too, it
looks like it's disappeared.

found that out by trying...

	textcols[HIGH] = allocimage(display, Rect(0,0,1,1(, screen->chan, 1, 0x884488); /* some garish grapey thing */
	textcols[HTEXT] = display->white;

.....and seeing that the du -a output that's visible as soon as the
+Errors window appears is white, but text that appears on scrolling
shows up black.

didn't do the equivalent experiment with rio or samterm, but since it's
the same behavior I expect it's the same deal. also didn't observe any
problems drawing unhighlighted text. (I did the 'cat /lib/words' test)

now all my highlighted text is black on a light light grey background,
which is nicer than white-on-black anyway...


---mp



             reply	other threads:[~2002-05-07  0:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-07  0:25 markp [this message]
2002-05-07  1:01 markp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200205070025.g470P2Q28586@panix1.panix.com \
    --to=markp@panix.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).