Bug: Lister can't show long lines containing tab character

[jdmarch]

Lister often hides the ends of lines containing tabs. There are 3 ways that Lister might have implemented the display of such lines:

1. (preferred) For the purpose of calculating display widths, Lister would treat the tab as if it were an appropriate number of spaces, and would wrap at the specified column. It does not now do this.

or
2. (acceptable) As it does now, Lister would count the tab as a single character when calculating where to wrap lines, but when this made a line longer than specified, it would permit the display to be scrolled to the right to see the end of the line. Now, Lister apparently will not scroll the display any further to the right than it would if the tabs were all normal characters. As a result, ends of lines are often hidden.

or
3. (nice extra option) Lister could implement a toggle to display the tab character as a user-specified (single width) symbol.

Thanks,
Jonathan

[ghisler(Author)]

1. (preferred) For the purpose of calculating display widths, Lister would treat the tab as if it were an appropriate number of spaces, and would wrap at the specified column. It does not now do this.

Lister would have to read the entire file and count the tabs for all lines - this would be much too slow for big files.

However, you can set a smaller tab width by changing the wincmd.ini, section [Lister], see the help file for details.

[jdmarch]

Lister would have to read the entire file and count the tabs for all lines - this would be much too slow for big files.

I assume that you mean "count the extra spaces caused by tabs", since the actual count of tabs would not tell you how long the displayed lines will be (only provide an upper bound). But why would you need this information for the entire file rather than only for the text currently on the screen? Certainly not for the display of the current text itself. Nor to calibrate the horizontal scroll bar, because you already place a limit of 256 characters on the display width. So seemingly only to calibrate the vertical scroll bar, but this could be based on the line number in the file rather than on the line number in the display of the entire file. And already it seems that you can't predict the line number in the display of the entire file because to do so you would have to analyze exactly where each line wrapped between words, for trhe entire file! Am I missing something?

[Added later: actually I have learned from another post of yours that you don't count lines in the entire file, so you must use byte position for the vertical scroll bar, so there's really no obvious reason to count tabs in the entire file.]

you can set a smaller tab width...

Thanks for the tip.
Jonathan

[Hacker]

jdmarch,

BTW: You have my support. The tabs causing text to be off-screen can be annoying.

Thanks
Roman