When scrolling, never shorten the length of tabs

[aaaxx]

Unintended consequence of implementing this is that now long files with dramatic differences in line lengths nudge left and right like crazy when scrolling.

Could you make the plugin never go below the previously calculated column widths – in other words, make the table only grow, never shrink.

I made you a dummy file from some data I had that made this pretty obvious.

[dail8859]

That file is incredibly helpful and will use it for testing.

I was aware of this side effect and in some cases like the one you provided show it being very distracting. I'll give it some thought to see if I can do as you suggest.

[Rolands71]

Hi
I have the same issue as aaaxx reported.
I use the Elastic Tab Plugin almost daily with large CSV files and this scrolling issue is really a problem.
I already searched for a solution, and just now stumbled upon this conversation.
I would really appreciate a work around or a solution for this issue.
I can also provide more sample files if needed.
I can also over to help testing .

Best regards
RS

[dail8859]

Thanks for your input as well.

I use the Elastic Tab Plugin almost daily with large CSV files and this scrolling issue is really a problem.

What do you define as "large"...as in file size? Number of rows? Number of columns?

I can also provide more sample files if needed.

The dummy file provided should be sufficient for any testing I do.

[Rolands71]

Hi dail8859

What do you define as "large"...as in file size? Number of rows? Number of columns?

this is totally different. The file size can be from 100kb to 20MB.
I have files with 8 columns, but many have over 20 up to 48 columns.

[dail8859]

@Rolands71

Thanks for the info. It is just nice for me to keep these kinds of numbers in mind when testing it.

[dail8859]

I've tried a couple ways of implementing this. Keeping the columns from shrinking isn't too hard. However, the difficulty comes when then editing the file. The way the algorithm works is that it tries to avoid parsing and measuring columns when possible.

So if the columns are stretched to a specific width (say because you scrolled way down, found a wide column, then scrolled back up) then edit that column, the implementation can either (a) all of a sudden shrink that column width to whatever the width is of the surrounding lines or (b) keep that width and never be able to shrink it back down when editing. The only way to get the (b) implementation to recalculate the width would be switch to another file then switch back.

I'm open to thoughts, or other ideas if anyone has them.

[Rolands71]

I only seldom edit CSV files in notepad.
I thought about boths possibilities. I think I can live with both solutions (a) and (b).
I'm not sure which solution is more convenient for editing files, I assume (a).

May I suggest a maybe different approach. (I'm not a programmer so may suggestion may be impossible).
Would it be possible that duplicate the first line with the Header of the CSV file, determine the max width for all columns, keep this max width, and show the header line always as first line?
Like the "freeze panes" feature in Excel ?
I know that this may create more /other issues, especially of the with Headerline is not the line with max width.
If this idea sounds crazy for you , please just ignore it.

[dail8859]

Would it be possible that duplicate the first line with the Header of the CSV file, determine the max width for all columns, keep this max width, and show the header line always as first line?

This is well beyond what I want to get into with the plugin :) Plus I have no idea how to do it within Noetepad++

[Rolands71]

ok, no problem, please forget my idee.
How will you proceed ? will you go for solution (a) or (b) ?
If I can help with testing , please let me know.

[dail8859]

Not completely sure yet. I want to play around with it some more and see how it works under different situations. The main "use-case" for this plugin is actually for aligning code rather than CSV files, so I want to make sure it still works fine in those cases, and try to do what I can for CSV files.

Before I do anything "permanent" I'll drop a test version here for anyone that wants to try it out.

[aaaxx]

Took me a while to figure out that by "editing" you meant the situation when the edited text ends up shorter than before.

I really can't decide. I can see arguments for both implementations. Although, the fact that the plugin recalculates widths when switching between tabs, so the potentially too-wide columns aren't necessarily permanent, makes me lean towards B.

By the way, why are the widths recalculated when switching tabs?

[dail8859]

By the way, why are the widths recalculated when switching tabs?

The tab widths are associated internally with the Scintilla editor rather than the document itself (each tab represents a different document). So when you switch tabs the editor needs to recompute the widths since the document has changed.

[SalviaSage]

Okay, so this plugin slows down opening large files, so you make it so it only works on like 3 screens of text instead of the whole file.

And then, when you do vertical scrolling, the code moves left and right rather unnaturally.

So... we just fixed a problem by introducing another one... Isn't there a better solution? :(

[dail8859]

@SalviaSage

So... we just fixed a problem by introducing another one...

The original intent wasn't to "introduce another one" as you suggest. This change actually fixed more than just the slow opening of large files.

Isn't there a better solution?

I don't know if there is or not...maybe you have a better solution? I've tried a few ways already to fix all the problems, but always run into cases where it breaks. If someone smarter than myself wants to attempt to fix all the issues, then I will gladly accept a pull request.