>> I have always wished I could switch from using a monospace font to something
>> else, but to do so would wreak havoc on indenting. Particularly I am
>> referring to indenting created by mid-line tabs.
>> In the past I have been in programming communities wherein some people did
>> use alternate fonts (e.g. Geneva) and this did cause a lot of hassle.
>> Meanwhile, it is such an easy problem to solve - except of course that maybe
>> MetroWerks is using someone else's editor code.
>> My suggestion is that text positions be computed for non-monospace fonts in
>> a way that is interoperable with monospace fonts, which eliminates damaged
>> column alignment, at least 99% of the time.
>> The way to do this is to compute the text position independently for each
>> block of text which follows one or more tabs anywhere on a line. The trick
>> would be to simply compute the position AS IF it were for a monospace font.
>> This can be done by simply totalling the number of virtual monospace
>> characters on the line prior to the block of text in question, counting each
>> character as 1, and bumping forward to the next multiple of 4 each time a
>> tab is encountered in a forward scan. Then take that number and multiply it
>> by the "M" width in the current font to compute the x pixel position. Allow
>> the M width value to be specified as a customizable value, overriding the
>> actual M width in the current font.
>> This should allow communities of programmers to coexist peacefully in spite
>> of differing font preferences.
> I'm not sure this would work as effectively as you think, but I'll pass
> it on.
I think the effectivness of it will be statistical, and the optimum
effectiveness would be determined by the choice of "monospace character
width" for the given non-monospace font. I suggested using the "m" width,
but this is probably wrong. You really want the width of the average
chracter based on typical usage, which of course a slippery concept, but I
think a good average will work well. A little bit of playing around might
reveal a good simple rule such as a particularly weighted average of the "n"
width and the "m" width. Perhaps it is this weight (e.g. 40% meaning 40% of
the way from "n" to "m") which would be the most useful control to offer in
Basically you want to achieve interoperability both in going from monospace
to non-monospace and from non-monospace to monospace. If I am thinking
correctly, the two directions form a trade-off. If you chose a relatively
wide "monospace character width" in your non-monospace font, you will
increase the chances that a previously monospace document will come in
without a conflict. But then if you type a bit in non-monospace land and
put too many of those nice narrow characters BEFORE another tab, then going
back to monospace land will have problems, because those narrow characters
become wide and can no longer be placed prior to that next desired tab
position based on the metrics used in non-monospace land. Conversely if you
make the "monospace character width" too narrow, then problems occur when
importing from monospace land.
Allowing the "monospace character width" to be customizable in some fashion
will allow a given site to optimize based on their expected path. For
example a whole company may be making a transition from monospace to
nonmonospace and may not care so much about going the other direction, in
which case the "monospace character width" can be set wider to optimize that
direction of migration. Of course problems can still occur when going from
one non-monospace font to another, and the same issues apply in terms of
chosing the "monospace character width" (or whatever it should really be
called) effectively for both (or all of) the fonts involved.
In any case my suggestion would be that tabs remain explicit entities in the
document, so that the problems that arise will involve rendering only, not
Quote:> Do you know of any other editors that can currently do this?
I am not aware of any, but I use neither project builder nor Symantec C++
(does this still exist?) so I can not expand on David Dunham's comments