Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Bugs-1247835 ] tabs: wordprocessor vs tabular interpretation
|
From: SourceForge.net <no...@so...> - 2005-08-12 15:09:59
|
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: None Priority: 5 Submitted By: Chengye Mao (chengyemao) Assigned to: Vince Darley (vincentdarley) Summary: tabs: wordprocessor vs tabular interpretation 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-12 15:09 Message: 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! ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2005-08-12 13:39 Message: 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) ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2005-08-12 13:24 Message: Logged In: YES user_id=32170 attached test script. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2005-08-12 13:23 Message: 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. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2005-08-11 21:15 Message: 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. ---------------------------------------------------------------------- Comment By: Chengye Mao (chengyemao) Date: 2005-08-11 19:04 Message: 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. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2005-08-11 18:34 Message: 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} ---------------------------------------------------------------------- Comment By: Chengye Mao (chengyemao) Date: 2005-08-11 18:04 Message: 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. ---------------------------------------------------------------------- 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 |