editor design:should tab near screen-right be constrained

[lovelyshell]

I am designing a text editor, and now i have a question how to paint tab-key(namely '\t') when it's near the right edge of terminal screen.

If the COLUMNS of terminal is aligned on 'tabstop', nothing to worry. But if someone drags its terminal to a strange width like 81 while tabstop = 8, then he types tab when the cursor on column 81(column number count from 1), how should my editor paint this tab for him?

I found both vim and emacs move the cursor to the next screen line and then forward it by 7 columns, just like you pressed space bar 8 times.
I am emulating such behavior in my editor, but i found it introduce complexity to programming. If the complexity is worth it, that's ok, but this behavior seems not important.

I want to constraint such tab within the right edge of screen, namely, just move cursor to the beginning of next screen line. I don't know whether it will confuse the editor users.

Would you give me some suggestion?

[iansjack]

If your lines are wrapping then they should behave as if they were a single line (i.e. the way they behave in the editors you tested). The other option is not to word wrap but to scroll the screen (or just the line) horizontally; but, again, a tab should behave normally (i.e. move to the next multiple of your tab width).

If you do otherwise you will get inconsistent behaviour when deleting part of the line, when resizing the window, or when altering the tab width.

But, in the end, it's a matter of what you find most natural.

[lovelyshell]

If you do otherwise you will get inconsistent behaviour when deleting part of the line, when resizing the window, or when altering the tab width.

I can't very well understand this sentence. Could you explain it in detail? Just one of the three cases above is enough . How about taking 'resizing window' as exmaple?

[iansjack]

I think the penultimate sentence of your OP sums it up: "I don't know whether it will confuse the editor users."

If your editor's behaviour differs from other standard editors, what do you suppose the answer to that question is?

Is there a reason why you want this non-intuitive behaviour (other than to make the programming easier - which I'm not convinced it does)?

[lovelyshell]

I think the penultimate sentence of your OP sums it up: "I don't know whether it will confuse the editor users."

If your editor's behaviour differs from other standard editors, what do you suppose the answer to that question is?

Is there a reason why you want this non-intuitive behaviour (other than to make the programming easier - which I'm not convinced it does)?

The other reason is, I think this behavior might not be important. I seldom typed a tab across line in daily programming, neither did I found some else.
I want to know how many people in the world need such broken-and-wrapped tab or often see it, so I wrote this post.

The only occasion I see is when I opened a source file wrote by another, and the column limit in his code style is longer than my terminal. But the first thing I did is to drag my terminal to adjust it.
A tab hitting the right edge of terminal will lose its layout meaning and whatever paint design can not save it.
As you said , breaking and wrapping it is a natural way. However, constraining it within current line is less natural but still reasonable, for I remember(not very clearly, it's a post on stackexchange) tab was not allowed to enter new line in very early age(seems also in XTERM today), may be for it got its meaning from tabulator.

If the behavior is really not important at all, I prefer the latter design.
Just like the cursor behavior difference between vim and emacs: when you click the screen area corresponding to a tab, emacs moves cursor to the first cell of tab area while vim moves to the last.

[simeonz]

I don't know whether it will confuse the editor users.

Tab stops are the positions at which the cursor moves after writing the tab character. They don't have to be regularly spaced. In fact, a more sophisticated text editor could make them user configurable. But it would be rather rude if those positions changed automatically. Why? Because of the way tabs work. They don't exactly move you from one visual slot to another, like a spreadsheet application would move you between cells. If you insert tab, it moves the cursor to the next stop after the current cursor position. If you write some more characters and the cursor passes a tab stop, pressing tab moves you to the tab stop following it. Thus, by changing the positions of tab stops, you could make certain character strings spill past certain tab ranges, and that would shift the whole tab stop sequence of the line. As you can understand, that botches the vertical layout the text had.

Now, whether or not tabs should be used with wrap around, or is it better to use spaces, is a different topic. And whether supporting tabs properly is relevant in a given situation is yet another topic.

[eekee]

I just tested Acme (Plan 9). It aligns tabs visually, not according to logical line. As to how it would be in practice, I'm not sure. I hate wide text and refuse to code with people who use it! (I don't refuse as such, but I do really hate it.) I think if you use tabs in wide text, you're opening the way for horrible confusion whatever you do. What's 'wide'? Well, my eyes aren't too happy with 80 columns on mobile devices, and I appreciate being allowed (hah!) to have 2 or 3 columns without straining my eyes on my 23". (I generally find fixed-format text sucks all round, tabs or not, "plain" or not.) Whichever solution you choose for your editor, wide text with tabs will suck. I guess the way vim and emacs do it sucks slightly less than the way acme does it, there's slightly less potential for confusion.

[linguofreak]

One possible option would be for the editor not to use any part of the terminal within a tab width of the right edge. So if you have a tab width of 4 columns, and a terminal width of 83 columns, the editor would only use the right 80 columns, and fill the last 3 columns with a different background color to indicate that they are unused. If the terminal is widened to 84 columns, or shrunk to 80 columns, then the entire width would be used.