Select by columns?

Thomas Schulz

Ah, I found the “Edit | Column Mode…” entry that shows the required short cut as a tip!
I just have to add the “Alt” key for selecting in columns…

Scott Sumner

Thomas,

Your own solution can be unwieldy if you have a lot of lines to deal with. Thus I would suggest two alternatives.

The first is to use a regular expression Replace:
Find what box: (?-s)^.{20}(.*)$
Replace with box: \1
Search Mode: Regular expression
After setting that up, be at the top of your intended file and press the Replace All button.
All of the undesired text is now gone.

The second alternative is to use the Begin/End Select feature with column mode:
Have the cursor in column 1 at the top of your intended file.
Start the “Begin/End Select” command via the Edit menu.
Go to the next to last line in your file, put the cursor in column 21.
Enter column mode by pressing Shift+Alt+DownArrow. This moves your cursor to the last line.
Stop the Begin/End Select (item is currently checked) via the Edit menu.
All of your undesired text is now highlighted, awaiting your delete command.

guy038

Hello Scott and All,

Oh, I didn’t know that the Begin/End Select feature works, also, with a Column Mode/rectangular selection !

After some tests, I don’t even think that the Alt + Shift + Down arrow is necessary. So, the general method, of using the Begin/End Select feature, seems to be :

Left mouse click at the beginning of the wanted selection
Select the Begin/End Select command ( The menu option is automatically checked )
Go to the location where the wanted selection must stop
Move the cursor to that second and final location, with :
- A left click to set the future normal selection
- A hit on the ALT key and a left click, simultaneously, to set the future column mode selection
Select, again, the Begin/End Select command ( The menu option is automatically unchecked ), to generate the appropriate selection

Best Regards,

guy038

Scott Sumner

guy038,

You are exactly right with the mouse operation–I like it! I’m so used to entering column mode with Shift+Alt+(cursor-move) that I neglected to remember the mouse and its possible elegance for the solution to the original problem here, in conjunction with Begin/End Select.

As a side note (#1), were you aware that column mode also works in the “Search Results” window? Unfortunately, I think there is a bug with it in the SR window: If the last line you are trying to column-select is shorter than the lines above, you will be limited to the length of the last line for your whole block! Note that this comment is made only considering Alt+mouse selection of columnar text; with keyboard Shift+Alt+cursor things are really odd in the SR window!

As side note (#2), and maybe getting really off track now!, I find it really interesting that I can Alt+Click in the main editor window to put the cursor/caret BEYOND a line’s current ending point (normally N++ disallows cursoring beyond the current end-of-line). I know that there is a Scintilla command I can execute to free the cursor so that it can normally move beyond end-of-line (which I like being able to do!), but I’ve found it causes some strange behavior sometimes (semi-random indenting, random extra line insertion) when Enter is pressed to goto/create the next line, so I quit using that Scintilla extension.

Now, on to what I really wanted to say, a question of my own (let’s call it #3): I notice with the regex solution I proposed to the original problem, N++ works differently than other editors I’ve used, and I’d like to understand why and if there is a way to have N++ work more like I’m used to. Originally I was going to propose to Search for ^.{20} and Replace with nothing. In other editors (PSPad, MultiEdit) this works as intended to chop the first 20 characters off each line’s beginning, moving to the next line after each chop. In N++, however, I notice that it will chop the first 20, and then keep chopping 20 off the current line, as long as the current line is still >= 20 characters long. I found that I had to propose a more complicated regex search/repl expression than I wanted to to make it work to solve the original problem. It seems like the other editors are more “line-oriented” when it comes to regex processing, but I’m not sure how to explain what I mean by that. Please help me understand this behavior a little better.

guy038

Hello Scott,

About point #1 :

I don’t think that I ever used the rectangular selection in the Search Results panel ( or, may be, without realizing that I did it ! ) Despite of the small bug when the last line is shorter than others, it can be intersesting sometimes :-)

BTW, did you notice that you can just copy the found lines, without their line numbers ( Line xxx: ), since the N++ v6.7.9 ?

So, when your search, displays some lines, from several files, and that you click, either :

On the title of a specific Search "....." (xx hits in yy files)
On an absolute pathname of a specific file
On a previous selection of some lines, even on two or more files
On a specific line

Then, after right clicking, in the search results window, on the option Copy, you get, accordingly, in the clipboard :

All the lines found, in the current Search "....." (xx hits in yy files)
All the lines, found in that specific file
All the lines, of the selection ( + 1 or, when you select lines, end with Shift + Left arrow, to copy the exact number )
That specific line

without the leading text Line xxx:

The nice thing is that if you make a [ rectangular ] selection and that you press, first, on CTRL + C ( instead of the right click on the copy option ), you’ll simply get, in the clipboard, a “hard” copy of the selection, which will include the leading line numbers, of the search results panel :-)

About point #2 :

Scott, you’re talking about the Virtual space capability of Scintilla. See further information, from the link below :

http://www.scintilla.org/ScintillaDoc.html#MultipleSelectionAndVirtualSpace

The function call used is SCI_SETVIRTUALSPACEOPTIONS (int Virtual Space), of number_id 2596

The argument can take values 0 to 3. The Scintilla documentation speaks of the two bit flags SCVS_RECTANGULARSELECTION=1 and SCVS_USERACCESSIBLE=2, which can be set independently.

Except for the value 0, which means NO virtual space at all, you could test the other cases. To do so :

Open the shortcuts.xml file, with an OTHER editor
Add the text below, in the macros section :

<Macro name=“VIRTUEL Space, after End of Line, Activated” Ctrl=“no” Alt=“yes” Shift=“no” Key=“32”>
<Action type=“0” message=“2596” wParam=“3” lParam=“0” sParam=“” />
</Macro>
<Macro name=“VIRTUEL Space, after End of Line, Desactivated” Ctrl=“no” Alt=“yes” Shift=“yes” Key=“32”>
<Action type=“0” message=“2596” wParam=“0” lParam=“0” sParam=“” />
</Macro>
Save it and restart N++

You may test the values 1 and 2, changing wParam, in the first macro :-)

About point #3

There a logical explanation about the odd N++'s behaviour, for the search/replacement :

SEARCH ^.{n}
REPLACE Empty

When you perform a search ONLY, once the n first characters, of a line, are selected, the cursor is on column n+1. Obviously, to get a second match, due to the anchor ^, the regex engine must go forward, first, till an other beginning of line => You do get, successively, a string, of n characters long, located, at beginning of lines

Right. Now, when you perform a replacement, the situation is completely different ! Indeed, when the n characters, at the beginning of a line are deleted, as the replace field is empty, the cursor is STILL located at the beginning of that line !

Therefore, the regex engine selects the following n characters, in the same line, delete them and so on… till the current line contains less than n characters. This time, as the syntax .{n} can’t be satisfied, the regex engine normally matches the n first characters, from the next line ! Et voilà

It just like if you would have followed the steps, below :

Search for the regex ^.{n}
Manually, delete these n selected characters
Search again for the regex ^.{n}
Manually, delete the n other selected characters

and so on…

The alternative search/replacement, that correctly work , are :

SEARCH (?-s)^.{n}(.*)
REPLACE \1

SEARCH (?-s)^.{n}(.)?
REPLACE \1

SEARCH (?-s)^.{1,n}(.*)
REPLACE \1

SEARCH (?-s)^.{1,n}(.)?
REPLACE \1

Why are these regexes OK ? It’s just because, for a complete match, the regex engine must, also, match the remainder of the current line or one character, after the n characters, which are to be deleted. Obviously, in both cases, the cursor location, AFTER rewriting the group 1, is NOT at beginning of the current line. So, the regex engine needs to skip to the beginning of the next line, for an other match !

NOTES :

The (?-s) modifier ensure that the dot matches standard characters, ONLY, whatever the state of the .matches newline option

The first two S/R are equivalent but DON’T change the lines of less than n characters

The last two S/R are equivalent and delete ALL characters between columns 1 and n , included, on any line

REMARK :

Luckily, the two opposite S/R, below, works fine :

SEARCH .{n}$
REPLACE Empty

SEARCH .{1,n}$
REPLACE Empty

Again, when the last n characters of a line are deleted, the cursor is located between the last character of this line and a End of Line character. Then, the only way to match, again, the regex .{n}$, for instance, is to skip to the n characters of a next line, which contains, at least, n characters !

To test these different regexes and observe the results of replacement, just type the text, below, in a new tab and replace the variable n by the value 5, for instance :

Cheers,

guy038

Scott Sumner

I think the point I was trying to make about point #2 is that an Alt+click on a line after the official line ending allows the cursor to be moved beyond the actual line ending, without having the Scintilla virtual space stuff enabled. A neat trick for someone that doesn’t want the free-cursoring behavior all the time, but only occasionally. Otherwise, your information about the virtual spacing was solid for those that aren’t aware.

Scott Sumner

I totally understand what you are saying about point #3 and the regexs, but I’m still confused about the logic other editors use. You didn’t comment on that, and while the information you did provide is good, I still don’t know what to think about how the non-N++ editors do it. Maybe if you include ^ or $ in your regex in those editors’ replace functions, all you get is a one-chance-per-existing-line match capability? Perhaps N++ gives one more flexibility, but after years of using an editor that is different, I am finding it difficult to untrain my way of thinking about it.

Scott Sumner

I’ll call an end to the point #3 discussion, as I think speculating about the behavior of other editors really isn’t what this community forum is about. Sorry about getting too far off the Notepad++ track there!

guy038

Hi Scott,

Concerning point #3 of my previous post, I did some tests with some other code/text editors. For six of them, which could handle regular expressions ( even basic ones ! ), I, always, did the same simple S/R :

SEARCH ^...

REPLACE Empty

I distinguished three different behaviours :

The editors Notepad++, SCiTE, and SynWrite replace all sequences of 3 characters in each line, with both, the Replace function and the Replace All function
The editors Notepad2, EditPad and gVim replace all sequences of 3 characters in each line, with the Replace function BUT, change the first three characters, in each line, ONLY, if the Replace All function is used
The editor PSPad replace the first three characters, in each line, ONLY, with both, the Replace function and the Replace All function

After reflection, I think that the second behaviour ( Notepad2, EditPad or gVim ) would be the best, as the Replace and Replace All results, with the obvious search syntax ^..., are different, although both logical

Cheers,

guy038

P.S. :

For instance, with the gVim editor :

The command :s/^...//cg acts as Notepad++ and delete every block of three characters, in the same line, before moving to the next line

The command :%s/^...//g acts like EditPad, Notepad2 or PSPad and delete, ONLY, the first three characters of each line

Scott Sumner

guy038,

Nice diligence on the regex issue. Good information. I think I’ve got to go with favoring the first group of editors that behave the same way with Replace and RepaceAll. For myself, often I do a regex search and replace and hit Replace for the first few matches (confirming to myself that I’ve got the regex correct), then switch to ReplaceAll to finish out the file. I’d be very disappointed to have Replace and ReplaceAll work differently in this situation!

Freon Sandoz

@guy038 Good one! It’s a bit confusing, and it took me a few tries to get it right, but for selecting a column of data in 17,000 lines it was the only way to go!