UVviewsoft forums

Command from SynWrite "Fill block" - is still needed? Synwrite has not it (command dont work).

Alexey wrote:Command from SynWrite "Fill block" - is still needed? Synwrite has not it (command dont work).

The way it was supposed to work:
1. Make a selection (most useful with column selection)
2. Call "Fill Block", presents dialog
3. In dialog, enter either a single character, or a string of characters, press enter
4. Selection is filled with the entered text.

This is a command I use infrequently. It is very nice when needed, but not needed that often. Not high priority.

Alexey wrote:Fixed in CudaExt https://github.com/kvichans/cuda_ext/issues/67
Pls "install from Github", repo https://github.com/kvichans/cuda_ext
and test 2 cmds.

Scroll to Top, Scroll to Bottom. These work. BUT, the current line is scrolled to the line second-from-top, second-from-bottom, instead of being scrolled to actual top/bottom screen line. Perhaps this is an error in calculating the screen top/bottom line, or perhaps this is intended as some might consider this desirable? If it is intended, please make an option so that user can have it scroll to very top/bottom screen line. Thanks!

qwerky
About filling of selection. What result you want if
- column selection have two rows with length eq 3,
- in dlg you enter "12".

Variants:
- "121" "121" - each row is filled as new.
- "121" "212" - continued

Alexey wrote:Added in CudaExt:
https://github.com/kvichans/cuda_ext/issues/68
Pls test

Scroll Left, Scroll Right. These work. BUT, the cursor is left behind, so it is off-screen. If cursor is in column 1, and Scroll Right is applied, screen moves right 30? columns, but cursor is still in column 1--cursor should move right same amount (to column 31), so that cursor will still be in exactly same position on screen.

Also, can the number of columns be set?

This is very good. Thank you for it. What I had been thinking: In SynWrite there was Scroll Left/Right, similar to these commands, but scrolled one column at a time (perhaps it was adjustable, don't remember). But there was also Page Left/Right, which paged the screen left/right by a large amount, similar to the width of the screen--perhaps this was the one that was adjustable, or both were adjustable?

So, four commands: Scroll Left, Scroll Right, Page Left, Page Right.

But, at least these two are a big help, especially if they could be adjusted.

kvichans wrote:qwerky
About filling of selection. What result you want if
- column selection have two rows with length eq 3,
- in dlg you enter "12".

Variants:
- "121" "121" - each row is filled as new.
- "121" "212" - continued

Very good question. I definitely feel it should be the first option above--each line filled as new. What do you think?

In all honesty, I think I almost always use the command with a single character, so for example select a column block and fill with "space", in order to clear the block without the surrounding text moving.

qwerky
Use "Install from Github..." to update plugin cuda_ext.

1. Test new command "CudaExt: Fill selection by string".
Note: the command skip a selection with EOL inside.

2. Commands "Scroll current line to screen top/bottom" now have options for user.json.

Hi Andrey,
Thanks all the excellent commands in cudaext!

kvichans wrote:qwerky
Use "Install from Github..." to update plugin cuda_ext.

1. Test new command "CudaExt: Fill selection by string".
Note: the command skip a selection with EOL inside.

This command seems to work fine. As discussed, the inserted string is started fresh with each line--this seems correct to me; does anyone else feel the inserted string should wrap with each line?
Note: the command works only with column selection blocks, not stream (normal) selection. That's fine with me; does anyone else need it to work with stream selection blocks?

2. Commands "Scroll current line to screen top/bottom" now have options for user.json.

Code: Select all

"cuda_ext_vert_indent":0, 
"cuda_ext_horz_scroll_size":30,

Tested both these options in user.json, and they work correctly; i.e. they correctly control the vertical indent, and the horizontal scroll size, respectively.
Issue: horizontal scroll still leaves the cursor in its original column, which causes cursor to be off-screen; it should change the cursor column by the same amount as the configured scroll size, so that the cursor remains in the same relative position on the screen (cursor is always visible).

qwerky wrote:Issue: horizontal scroll still leaves the cursor in its original column, which causes cursor to be off-screen; it should change the cursor column by the same amount as the configured scroll size, so that the cursor remains in the same relative position on the screen (cursor is always visible).

I dont agree.
1. Result of new scroll-commands is same (need be same) as clicking on horz-scrollbar (only shift size is diff).
2. There is problem to set caret to save "relative position": not all columns are available.

kvichans wrote:

qwerky wrote:Issue: horizontal scroll still leaves the cursor in its original column, which causes cursor to be off-screen; it should change the cursor column by the same amount as the configured scroll size, so that the cursor remains in the same relative position on the screen (cursor is always visible).

I dont agree.
1. Result of new scroll-commands is same (need be same) as clicking on horz-scrollbar (only shift size is diff).

You are right that column position does not change when horizontal scrollbar is used, which is done with the mouse. Why do you think that the keyboard scroll commands should do the same?

Think about vertical scroll: when vertical scrollbar is used via mouse, cursor position does not change; it remains on the same line, even if off screen--same as horizontal. But when vertical keyboard scroll commands are used, the cursor does not (and I think should not) leave the screen. So, scrolling up/down one line at a time, the cursor remains on the same text line, until that line reaches the top/bottom of screen, after which continued scrolling causes the cursor to change line, in order to remain on screen.

Now think about horizontal scroll with width set to one, so that each scroll command causes the text to scroll left/right by one column. What should happen (in my opinion) should mirror the vertical action: the cursor should remain in the same column until that column reaches the edge of the screen, after which it should change column in order to remain on screen. The same is true with a larger horizontal offset, say for example the default 30 columns: if the new position still has the current column on-screen, then the cursor should still be in the current column, but if the current column has moved off screen, then the cursor should be adjusted to remain on-screen. Sorry if I wasn't clear that I only want the cursor to change column when it moves off screen, not when it remains on screen.

So the effect should, I think, should be the same for both vertical and horizontal: when using the mouse/scrollbar, the cursor does not change line/column, but when using the keyboard/hotkeys, the cursor is forced to remain on-screen.

2. There is problem to set caret to save "relative position": not all columns are available.

Ah, perhaps here is where the misunderstanding occurs. I always use "allow cursor past end of line" so that the cursor can move anywhere freely. If you don't use that option, then you don't want your cursor to move past end of line when scrolling occurs. So perhaps when that option is turned off, so that the cursor is not allowed past end of line, the cursor should adjust to remain on-screen, until the end of line is reached, after which it should remain stationary even if off screen; but when that option is turned on, so that the cursor is allowed past end of line, then it is always kept on-screen? Is that more agreeable?