Select by columns?

  • Hi,

    I have sometimes text from application logs. The lines are starting with a time stamp. To remove irritating information I’d like to remove the first twenty characters of each line. So I’m searching for the possibility to select by columns.
    Does anyone know on how to select by columns?
    Is there maybe a short cut for this too?

    Thank you in advance!

  • 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…

  • 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.

  • 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,

    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.

  • 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 :

    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 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="" />

    • 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 :




  • 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.

  • 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.

  • 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!

  • 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



    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

  • 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!

  • @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!

Log in to reply