There is an "oddity", and I am trying to find out the correct behaviour:

Set your editor options to:
Tabs to spaces: NO
smart tabs: NO
tabs indent block:NO
show special chars: Yes
alt-key sets column mode: yes

have a text like [------- is *one* tab]

abcdefghij
--------1234
mnopqrstuv

Now hold the alt key and use the mouse to select a column of one char. Starting in front of the "b", ending after the "n"

In this case there is no block highlight in the middle line (1234), but in other cases there will be (select "gh", "st").

Pressing ctrl-x will cut "b", "1", "d"

The block should have gone through the tab, but then half of the tab would be selected. Besides the optical issues, on pressing ctrl-x, which char(s) of the middle line should be cut?
Or should the block highlight the "1" ? IMHO not.

Thanks
Martin

The 1 is wrong. I don't know, if copying spaces, one tab or nothing is good here. I vote for the tab.

The block should have gone through the tab, but then half of the tab would be selected. Besides the optical issues, on pressing ctrl-x, which char(s) of the middle line should be cut? Or should the block highlight the "1" ? IMHO not.

Mattias

In case of copy, I would go for the tab.
I probably would go for the tab in case of "cut"-ing => However cutting the tab would mean that the line changes more than expected.

Options are:
if a tab is partly selected (only possible if column mode / selection in the other lines is always handle as currently): [in order of my preference]

1) copy or cut the tab => in case of cut, the tab will go from the line
2) treat the tab as shared between the line and selection, therefore copy even on "cut"/ctrl-x
=> clipboard will contain the tab, but the tab also remains in the line
3) copy or cut empty => leave the tab in the line
4) copy or cut spaces => leave the tab in the line
5) convert to spaces (not good, since the user has not selected "tab to spaces")
copies selected spaces / leaves remaining spaces

-------
2 further things:

a) in the above scenario, the selection may not always be drawn (or sometimes be draw over to big an area).
this does not need a bug report at current (or if so, put a note on). I am working on block-selection markup code, and will fix this part.

- I *may* at the same time pick up the actual "what gets copied/cut" bug too. If not, I'll report it later

b) Another block highlighting issue (may be correct as it is?) As you can move the cursor through the tab, it can be positioned anywhere inside the tab. If you start a selection (shift cursor right/left) from a position in the middle of the tab, nothing is highlighted in first. Only if you select enough to include the end of the tab, then the whole tab will be highlighted.

This is probably because while inside the tab, you only move the physical caret. The logical caret does not move. I am not sure, if:
- this is considered an issue?
- is worth fixing?

Martin

In case of copy, I would go for the tab. I probably would go for the tab in case of "cut"-ing => However cutting the tab would mean that the line changes more than expected.

Or less than expected, if _not_ cutting the tab. It's a border case, where both can make sense.

I think, you should do the easiest to implement, because whatever you do someone will have a different opinion.

Bordercase too. Keep it simple stupid.

Mattias