Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Bugs-1247835 ] Incorrect tab position
|
From: SourceForge.net <no...@so...> - 2005-08-11 17:36:32
|
Bugs item #1247835, was opened at 2005-07-30 06:25 Message generated for change (Comment added) made by vincentdarley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1247835&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 18. [text] Group: current: 8.5a3 >Status: Open >Resolution: Accepted Priority: 5 Submitted By: Chengye Mao (chengyemao) Assigned to: Vince Darley (vincentdarley) Summary: Incorrect tab position Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Vince Darley (vincentdarley) Date: 2005-08-11 17:36 Message: 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. ---------------------------------------------------------------------- Comment By: Kevin B KENNY (kennykb) Date: 2005-08-11 15:18 Message: 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? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-08-11 02:20 Message: 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. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-08-09 09:46 Message: Logged In: NO Added some documentation, as per last comment. ---------------------------------------------------------------------- Comment By: Chengye Mao (chengyemao) Date: 2005-08-01 17:36 Message: 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. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2005-08-01 07:30 Message: 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). ---------------------------------------------------------------------- Comment By: Jim Ingham (wolfsuit) Date: 2005-07-31 01:46 Message: 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... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1247835&group_id=12997 |