Tk Source Code

Platform Windows XP/SV2

Tab positions of a Text widget is incorrect in Tk85a3.

Try the following:

text .t
.t config -tab {0.5i 1.0i 1.5i 2.0i 2.5i 3.0i 3.5i 4.0i 4.5i}
pack .t

Type into the text widget the following text line:

This is a line of text for testing tabs.  It seems that tab 
position of a text widget in Tk 85 is not correct.

An inserted tab will make multiple spaces in almost any 
position in the above text line even after its specified 
position.

The correct behavior is: a tab may make mutiple spaces 
if it is inserted before the specified tab position.  If it is 
inserted after its specified position, it should only make 
one space. The first tab only add one space after 0.5i 
and the second tab only add one space after 1.0i, and 
so on so forth.

This bug may make text tab displays incompatible to 
previous Tk text wigets, i.e., 8.4 and below. Any text file 
that uses tabs in formating and saved by a previous 
Tcl/Tk may be display incorrectly in Tk 853a.

data_type - 362997

IP - Comment Removed: 130.88.1.31

allow_comments - 1

data_type - 212997

Logged In: YES 
user_id=32170

tip#256 implementation, tests, etc committed to cvs head.

File Deleted - 146139:

File Added - 147573: tabs85.patch

Logged In: YES 
user_id=32170

Added patch with docs, tests.

File Deleted - 145399:

File Deleted - 145400:

File Deleted - 145891: 



File Added - 146139: tab85.patch

Logged In: YES 
user_id=32170

New implementation, for the '-tabstyle' version.
Surprisingly, requires several times more code to add the
new option everywhere.

File Added - 145891: 256.tip

Logged In: YES 
user_id=32170

Attached TIP, since Donal seems to be absent for the moment.

Logged In: YES 
user_id=32170

TIP submitted.

Logged In: YES 
user_id=32170

Donal: the problem you cite has been fixed in Tk 8.5 for a
long time. You typically just do:

set charWidth [font measure [$w cget -font] "a"]
$w configure -tabs [list [expr {4 * $charWidth}] left]]

for example.

Agreed that a TIP is needed, although I would hope it can be
fasttracked!

Logged In: YES 
user_id=79902

This feature requires TIPping.

On the plus side, we might be able to nail the problem with
the difference between empty and non-empty -tabs options (no
combination of tab settings could duplicate the empty -tabs
option, making it impossible to set the editor-like tab
width to anything other than 8 standard-sized characters)

File Added - 145400: tabtest.tcl

Logged In: YES 
user_id=32170

attached test script.

File Added - 145399: tab85.patch

Logged In: YES 
user_id=32170

Attached a patch to fix the problem, adding an optional
first keyword to -tabs of 'tabular' or 'wordprocessor',
where 'tabular' is the default.

I'm wondering if 'indexed' might be a better word than
'tabular' in this context, since the key feature is that the
n'th tab is indexed against the n'th tab stop.

Logged In: YES 
user_id=72656

The tabs issue was raised many times before, and that Vince
was changing it with the text widget enhancements was no
surprise to maintainers.  In general, I think the new 8.5
behavior is better (wordprocessor), but if we want to keep
the old behavior, I think the idea of an option first
keyword to adjust behavior seems best.

Logged In: YES 
user_id=191079

This will work too. But additional coding is required for the -
tabs configuration.  Adding a new option seems a simple 
solution.

Logged In: YES 
user_id=32170

Certainly the goal would be to have backwards compatibility
the default (so don't rush to make big changes to your
code!).  I'm just wondering whether it's possible to avoid a
global option and instead allow the actual '-tabs' option to
define the behaviour. This would have the added benefit of
allowing the mixing of tab-style throughout a single text
widget.

For example we could simply add two possible keywords to the
list of -tabs values, to allow switching:

.text configure -tabs {1i 2i}
.text configure -tabs {wordprocessor 1i 2i}

Logged In: YES 
user_id=191079

I am editing my Tk text widget document to be compatible to 
the Tk85, which is no fun at all.   It will be great if the old tab 
position scheme will remains.    

Can we keep the old tab option syntax and use a new tab 
scheme option for this new tab position feature?  For 
example, add a tab scheme option -tabscheme 

$text config -tabscheme wordprocessor

to indicate the new scheme. A {} string indicates the old 
scheme.

That will make all existing code compatible and a user may 
choose a specific tab feature when it is needed.

Logged In: YES 
user_id=32170

Having examined the code very carefully, and the example
given above. I finally understand:

(a) Tk 8.4 had the 'table like' tab stop behaviour, where
there was a direct connection between the n'th tab character
in a line and the n'th tab stop that was defined.

(b) This table-like tab stop behaviour was not documented in
any clear fashion.

(c) Tk 8.4 also had a number of bugs in the treatment of tab
stops (some of those it still has).  In particular, there
were a number of such bugs apparent when one used the text
widget as a text-editor. Since I use the text widget
primarily as a text editor, those bugs were very apparent to
me, and since the "correct behaviour" was not well defined
in the documentation, I didn't even realise that
'table-like' behaviour was what was supposed to happen.

(d) In my various Tk-text-wdiget 8.5 TIPs, I fixed many text
widget bugs, including a number of tab-stop related ones.
This included a "fix" which makes Tk 8.5 perfect in its
treatment of tab stops as a text editor, but breaks the
(poorly documented) old table-like behaviour.

So, there was no TIP focusing on this because I thought I
was just fixing bugs (which, mostly, I was)!

I think the solution is for me to submit a new TIP adding
yet another configuration option to the text widget to
choose between 'table-like' tabs and 'editor-like' tabs.

Apologies for the confusion...

Any suggestions for the name/values of the new option?

Vince.

Logged In: YES 
user_id=99768

I agree with the last anonymous sender.

Lacking a table widget in the Core, I've a fair amount of
code that manages tables using tabs in the text widget.  The
existing semantics of tabs do (at least nearly) The Right
Thing; if a field is too long, subsequent fields are
displaced to the right only as far as necessary.  The
proposed change means that one overlength field makes a
total hash of the rest of the table row.

I'd be ok with this as an option, but not as the only
choice. Please put the 8.4 semantics back - or at least make
them available.

Where was the TIP for this?

Logged In: NO 

-tabs are often used to create multicolumn reports; for this
use case, the 8.4 behavior (as described above) is
preferable.  With the 8.5 scheme, if the text in one column
extends past the subsequent tab stop, the rest of the row
becomes completely misaligned.

Logged In: NO 

Added some documentation, as per last comment.

Logged In: YES 
user_id=191079

I did not know that the tab behaviors of previoius Tk text 
wigets are incorrect.  Hope your description of the tab's 
behavior will be incorperated into the Tk help manual.  It is 
much easier to be understood and verified.

Logged In: YES 
user_id=32170

You're misunderstanding the documentation. A given \\tab
character isn't associated with one particular 'stop' that
it owns, and therefore checks whether it falls before or
after that stop.  Each \\tab character simply advances to
the next tab stop that lies after its position.

There were bugs in Tk 8.4's tab handling (see other bug
reports), so 8.5 does in fact have different behaviour, but
those differences are not with respect to the above example
as such (they may influence the result from the above
example, but that's a coincidence).

I you disagree, please attach a demonstration script to this
report with further detail (your report above has been
converted to pure text and contains no tabs).

Logged In: YES 
user_id=169107

Dunno why this was assigned to me, the text widget is definitely not my 
forte, and this is not OSX specific...