I've dug around in TFM and so on, and not spotted it. Of
course, it's entirely possible that it's there, but described
in words utterly unlike anything I can guess.
I used the HTML garbage simply because that's something that
a lot of people are likely to recognize. But there are various
other sorts of apps where one might like to do such a thing.
is simply a whitespace character that isn't treated as a space. Right?
Try inserting the character \xa0 instead of a space between the
two words you don't want broken apart onto separate lines.
| Don Porter, D.Sc. Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/mcsd/Staff/DPorter/ NIST |
That didn't work at all. The text doesn't break there, but
also there is no space visible on the screen. I can verify
that there is an A0 (0240) char there by running "od -cx" in
a window, cutting the text from the text widget, and pasting
it to the "od -cx" command. It clearly shows the A0 char
where I expected it. But the text widget shows the two
adjacent chars without a space between them.
The text widget's font is:
and as you might guess, I didn't type that; I copied it from
the wish program's window. The program has a font menu and a
routine to change the text widget's font, and that seems to
work ok. I hadn't done that; this is the default font that
my .Xdefaults file sets up.
This is on a SunOS 5.7 machine with tcl/tk 8.0.
> Try inserting the character \xa0 instead of a space between the
> two words you don't want broken apart onto separate lines.
Here's a little test script to demo how \xa0 fails:
text .t -wrap word
pack .t -fill both -expand 1
.t insert end "This line uses\xa0several a0\xa0chars to\xa0prevent wrapping.\n"
When I run this, the first and third \xa0 seem to work to prevent
wrapping. They both display as a space, and when I resize the
window to put the right margin inside "several" or "prevent",
the wrap occurs before "uses" and "to" respectively.
However, the "a0\xa0chars" screws up rather badly. First, it
doesn't display as "a0 chars". Where the " c" should be, there
is what looks like a subscript "1" or "l", with no space at all.
That is, it looks like "a0lchars" with the "l" hanging down below
the line. And when I resize to put the right border inside the
"hars" portion, it wraps just before the "h", putting the lowered
"l" at the end of the first line.
Again, this is on SunOS 5.7 with wish 8.0.
The problem is in the way \x... is interpreted in Tcl. After the \x,
all hexadecimal chars will be swallowed up until a non-hex is found, but
only the last two are used. This is kind of stupid, IMHO, since octal
backslash is limited to 3 (although one or two works as well, which can
be dangerously interp'd), and the unicode of Tcl8.1 is limited to 4.
You just have to be careful in how you want to do that.
Anyway, I prefer to use 8.1, and the \xa0 does work in the text widget,
but it can be safely written:
set a "a\u00a0b"
to get "a b" (visually), without having to worry about what follows
the escape sequence. Otherwise, you can pop it into octal as \240
(again, 3 max, so no misunderstandings).
** Jeffrey Hobbs jeff.hobbs @SPAM acm.org **
** I'm really just a Tcl-bot My opinions are MY opinions **
It's probably font dependant. What font are you using?
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Apparently that's not really what's going on. Jeff Hobbs sent me
some email explaining that \x soaks up all the hex chars that follow
it, and uses the last two. So "\xa0chars" is \xa0c "hars", not
\xa0 = "chars".
At the moment, this seems to be a brick wall. Is there any way
to make this work? Well, I suppose I could put it into a variable
with some recognizable bit of junk for the \xa0, and then to a
regsub to convert the junk into "\xa0". Maybe I'll try that.
It may help to note that this design was just borrowed from C which
defines hex escapes similarly. In C, not having a bound on escape
sequence lengths makes a lot of sense because objects could be
indefinitely large - and it was implementation dependent how large
certain datatypes could be. Tcl followed C's definition for hex
escapes because it wasn't clear at the time that it wasn't a good
idea. Now of course, it's quite obvious. (In fact, lint probably
reports that Tcl isn't checking for the potential overflow.) So this
should be fixed - and it's trivial to do so. There can't possibly be
any code that would break.
By the way, the "only the last two are used" is not set in stone.
That's also implementation dependent.
> Anyway, I prefer to use 8.1, and the \xa0 does work in the text widget,
> but it can be safely written:
> set a "a\u00a0b"
> to get "a b" (visually), without having to worry about what follows
> the escape sequence. Otherwise, you can pop it into octal as \240
> (again, 3 max, so no misunderstandings).
As I said, if you can't use the 8.1 \u00a0 notation, just convert
it to octal, which is also deterministic (\xa0 == \240) and works.
When you get this fixed (by whatever mechanism) you'll find that (in
at least one font!) non-breaking spaces work if you are viewing the
text, but *not* if you are editing it - the displayed position of the
insert mark does not correlate with where in the text any insertions
occur (when it is after the nbsp on the same line) and the space can
even sometimes appear to disappear! Though at least the internal data
structures for the text widget maintain their coherency.
I haven't had the forethought/courage to try variable width fonts or
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
Actually, one of the problems I've found with languages that emulate C
in such situations is they don't quite get it right. For example,
null-terminated strings without memcpy()-type functions, or a leading
zero making numbers into octal (where in C that only happens for
literals). This isn't just Tcl, tho.
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.