Several Column Selection Mode Indenting bugs

[knn]

In COLUMN edit mode...

• ...when I stand before the first column and mark a few rows and press <TAB> then the last row won't indent
• ...when I press <BACKSPACE> then the rows won't unindent
• ...when I type a few letters then the letters will get inserted correctly while a following <TAB> gets inserted at the BEGINNING of the row, and not there where the cursor is (= after the last typed letter)

Also HippoEdit 1.48 crashed completely (= vanished from 1 second to the other without any crash message) when I marked indented tabs (in colum selection mode) and pressed <BACKSPACE> (= to delete these tabs). I was not able to reproduce that behavior but I wanted to report it anyway.

[alex]

Hi knn,

when I stand before the first column and mark a few rows and press <TAB> then the last row won't indent

it is a bug. I have recreated it. Will be fixed in new beta.

when I press <BACKSPACE> then the rows won't unindent

not really a bug. <BACKSPACE> does not do unindent, for this use Shift+Tab (command unindent). Backspace is used to back delete typed text in multiple selection, and it is limited to not go outside of it. But I will check, and maybe will extend it to delete previous chars, when user already have null-width selection. But not unindent. But this can be complex.. because this can destroy block (for example you have on one line tab and on next one 4 spaces instead of tab)

when I type a few letters then the letters will get inserted correctly while a following <TAB> gets inserted at the BEGINNING of the row, and not there where the cursor is (= after the last typed letter)

here is also not a bug. Because TAB by default mapped to do indent (as a shortcut), and indenting is always done for complete selection and started from selection beginning. I can try to determine, if user is in multi edit mode and do tab insertion instead of indent in this case, but I do not promise this. If effort will be not big.

All mentioned I will try to put in new 1.49 beta. But as I said earliest end of the next week.

About the crash, I have also tried and was not able to reproduce. If you can, please send me instruction and crash dump. I will fix this ASAP.

Best regards,
Alex.

[knn]

not really a bug. <BACKSPACE> does not do unindent, for this use Shift+Tab (command unindent). Backspace is used to back delete typed text in multiple selection

Hmm, but isn't <ERASE> for deleting text and <BACKSPACE> is for backspacing?

here is also not a bug. Because TAB by default mapped to do indent (as a shortcut), and indenting is always done for complete selection and started from selection beginning.

It should depend on where the cursor is located. So when I mark/select from bottom right to top left (= cursor is at the beginning of the selection) then it should insert the tab at beginning.

But when I mark/select from top left to bottom right (= the cursor is right) then it should insert the tabs there.

About the crash, I have also tried and was not able to reproduce. If you can, please send me instruction and crash dump. I will fix this ASAP.

This was the only crash I encountered. Hell knows what caused it.

Since it's so seldom I would rather like fixing the QuickSearch input field that vanishes sometimes, if you find time.

[alex]

Hmm, but isn't <ERASE> for deleting text and <BACKSPACE> is for backspacing?

And how this conflicts with my sentence I wrote. <BACKSPACE> is not equal to <UNINDENT>.

It should depend on where the cursor is located. So when I mark/select from bottom right to top left (= cursor is at the beginning of the selection) then it should insert the tab at beginning.
But when I mark/select from top left to bottom right (= the cursor is right) then it should insert the tabs there.

Do not think so. For me this will lead to confusion. In multi edit mode, chars are always appended to the end of selection.
Do you have an example of such implementation?

Since it's so seldom I would rather like fixing the QuickSearch input field that vanishes sometimes, if you find time.

What do you mean? Which HE version you are using?

[knn]

And how this conflicts with my sentence I wrote. <BACKSPACE> is not equal to <UNINDENT>.

<backspace> erases what one just typed. Thus if you typed <tab> then <backspace> untabs.

Do not think so. For me this will lead to confusion. In multi edit mode, chars are always appended to the end of selection.

I think the confusion is created because when I columnselect 0 rows and then type something then HE inserts what I type (= correct behavior) but ADDITIONALLY selects the text that I type (= unnecessary behaviour). If it would just stay a 0-column-selected line then it would work as I suggested, i.e. it would insert the tab at the position the cursor is. This is also the behavior of Ultraedit.

What do you mean? Which HE version you are using?

I am using 1.48 and QuickSearch is buggy. It simply disappears. Now, the QuickSearch itself still works (= I type something and it finds it and highlites it), but the input field itself is gone.




But here is another bug when columnselecting:

I merely wanted to column select a block and here is what happened.

Here are tabs in the text involved



Here are no tabs in the text:

[alex]

<backspace> erases what one just typed. Thus if you typed <tab> then <backspace> untabs.

If tabs expanded to spaces, then only last space will be deleted. So you are wrong here.

I think the confusion is created because when I columnselect 0 rows and then type something then HE inserts what I type (= correct behavior) but ADDITIONALLY selects the text that I type (= unnecessary behaviour). If it would just stay a 0-column-selected line then it would work as I suggested, i.e. it would insert the tab at the position the cursor is. This is also the behavior of Ultraedit.

The selection is added to mark area of the text which are in multi edit mode currently. This is actual design and I am not planning to change this soon. With current behavior my concerns are correct.
Same way of selection can be found in EmEditor.
If I will go further in development of muti selection and multi edit mode, probably I will change the logic. UltraEdit is not a good example of the usability, from my point of  view. If you want to see good implementation of multi edit mode check Sublime Text.

I am using 1.48 and QuickSearch is buggy. It simply disappears. Now, the QuickSearch itself still works (= I type something and it finds it and highlites it), but the input field itself is gone.

Please provide reproducible example.

I merely wanted to column select a block and here is what happened.
Here are tabs in the text involved

You have used non-monospaced font. Block selection is not fully supported in this mode.

[knn]

If tabs expanded to spaces, then only last space will be deleted. So you are wrong here.

I don't expand tabs to spaces.

When I press <tab> then <backspace> untabs. This is normal behaviour in HippoEdit. I see no reason why it should be different when I made a zero-column-selection.

Please provide reproducible example.

I can't. The quicksearch input field disappears regularly but I haven't found a reproducible reason yet.

You have used non-monospaced font. Block selection is not fully supported in this mode.

My examples _are_ monospaced of course.

[alex]

I don't expand tabs to spaces.
When I press <tab> then <backspace> untabs. This is normal behaviour in HippoEdit. I see no reason why it should be different when I made a zero-column-selection.

This depends on Tools->Options->Formatting->Tabs and Spaces setting

My examples _are_ monospaced of course.

No. The font you have used has probably size of space less then size of other chars. In monospaced font all glyphs, for all styles (bold, italic) should have same width.

[knn]

This depends on Tools->Options->Formatting->Tabs and Spaces setting

I have "use as typed".

And when I press <tab> and then <backspace> then the <tab> gets deleted.

I see no reason why HippoEdit behaves differently (= doesn't delete the tab) when I made a zero-column-selection.