[v.7.8.6] Vertical Edge Settings no longer works with Split Lines (Ctrl-I)

Ekopalypse

@guy038 but works only as long as you don’t restart npp, correct?

guy038

Hi, @matthew-au, @michael-Vincent, @ekopalypse, @alan-kilborn and All,

@ekopalypse, Ah yes ! As soon as I restarted Notepad++, it simply showed the two edge lines that I had previously set ( 30 and 60 )

However, remember that, by default, if no vertical setting or several vertical settings are set, then the CTRL + I feature splits lines, roughly, to the windows text width !

Cheers,

guy038

guy038

Hello, @matthew-au, @michael-Vincent, @ekopalypse, @alan-kilborn and All,

The last N++ v7.8.6 version now supports the new Vertical Multi-Edge lines feature. Unfortunately, as a consequence, this definitively breaks the native Split Lines feature ( Ctrl + I )

A work-around has been found but needs to choose one column number only and tick once on the Background mode option ! But this prevent you from easily using multiple vertical lines, which is a pity :-(

So, I imagined a regex S/R, that exactly simulates the N++ Split Lines feature ;-))

Just one constraint : If your text contains some tabulation chars, you must run, first, the Edit > BLank Operations > TAB to Space option, in order to change any tab character with the appropriate number of space chars. Indeed, the regex S/R assumes that each character displayed takes the place of exactly one character. !

The generic regex S/R, for any splitting column C is :

SEARCH (?-s)^(?=.{C})(.{1,C-3}\x20|.{C-1})\K

REPLACE \r\n ( or \n if Unix files )

So, let’s suppose that you want to split text, at column C = 80. In that case, the regex S/R must be changed as below :

SEARCH (?-s)^(?=.{80})(.{1,77}\x20|.{79})\K
REPLACE \r\n ( or \n if Unix files )
Tick the Wrap around option
Select the Regular expression search mode
CLick on Replace All button, exclusively ( Do not use the Replace button ! )

After numerous tests, I verified that the split texts are strictly identical :

Whatever the Split Lines option ( Ctrl + I ) or the Regex S/R is used
Whatever the In selection option is set or not, in the Replace dialog
Whatever the Line or Background mode is used, in Settings > Preferences... > Editing > Vertical Edge Settings
Whatever the View > Word wrap option is set or not
Whatever the View > Show Symbol > Show All Characters option is set or not
Whatever the current font used is a MonoSpace or a Proportional font, in the Style Configurator...

In case of a proportional font, do not trust the visual vertical edge line, but rely on the real column, indicated in Settings > Preferences... > Editing > Vertical Edge Settings ! BTW, the Line mode is generally recommended for monospace fonts and the Background mode should be preferred for proportional fonts !

As a test, we’ll simply use the License.txt file and split its contents at column 80 :

First of all, make sure that the single number 80 is shown in Settings > Preferences... > Editing > Vertical Edge Settings
Copy the License.txt file in two new tabs ( new 1 and new 2 )
In the new 1 file :
- Ctrl + A
- Ctrl + I ( Split Lines option )
In the new 2 file :
- Open the Replace dialog ( Ctrl + H )
  - SEARCH (?-s)^(?=.{80})(.{1,77}\x20|.{79})\K
  - REPLACE \r\n ( or \n if Unix files )
  - Tick the Wrap around option
  - Select the Regular expression search mode
  - Click on Replace All button, exclusively ( Do not use the Replace button ! )
Now, compare the two tabs with, for instance, the Compare plugin or with an external compare tool => The two tabs should be strictly identical ;-))

Remark : Of course, this regex S/R supposed that the splitting vertical line was at position 80. So, adapt the generic regex, above, according to the real column needed !

Best Regards,

guy038

Alan Kilborn

Seems to be relevant to this current discussion: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/7814

Alan Kilborn

@guy038

Any reason for the capturing group usage?:

guy038

Hi, @alan-kilborn and All,

You’re perfectly right about it : No need of a capturing group for that purpose ! So, the generic search regex can be changed as below :

SEARCH (?-s)^(?=.{C})(?:.{1,C-3}\x20|.{C-1})\K

And the corresponding search regex for C = 80 is :

SEARCH (?-s)^(?=.{80})(?:.{1,77}\x20|.{79})\K

Indeed, although the maximum of characters, caught in group 1, not exceeds, either, C-2 or C-1 chars, the fact of using a non-capturing group should speed up the replacement process, in case of huge files !

Cheers,

guy038

Patrick Sheppard

Not sure this is worth a new thread … I used the following NppExec / Scintilla script to set the vertical edge column to the current column (super useful in my usage). It is now broken. Any recommendations for how to fix is appreciated. I did try what I thought was the obvious update and it didn’t work…

::NPXEdgeColumSetToCurrent
NPP_CONSOLE ?
SCI_SENDMSG SCI_SETEDGECOLUMN $(CURRENT_COLUMN)

Michael Vincent

@Patrick-Sheppard said in [v.7.8.6] Vertical Edge Settings no longer works with Split Lines (Ctrl-I):

It is now broken

What version of Notepad++ - please post your debug info (menu ? => Debug Info…). I’ll assume you’re using the new 7.8.6 version as that is an easy fix. As of N++ 7.8.6, the vertical edge mode changed to multiedge by default so you can add multiple edges. You can try:

SCI_SENDMSG SCI_GETEDGEMODE
================ READY ================
ECHO $(MSG_RESULT)
1

to verify. I’m assuming you’ll get back “3” as in EDGE_MULTILINE. You can modify your script to be:

::NPXEdgeColumSetToCurrent
NPP_CONSOLE ?
SCI_SENDMSG SCI_SETEDGEMODE EDGE_LINE
SCI_SENDMSG SCI_SETEDGECOLUMN $(CURRENT_COLUMN)

Cheers.

Patrick Sheppard

Thanks, Michael.

I had downgraded to 7.8.5 because of this issue and was reluctant to jump back up, but I just did and your modification works a charm.

Appreciated.

guy038

Hello, @matthew-au, @i-neuw, @michael-Vincent, @ekopalypse, @alan-kilborn, @peterjones, @terry-r and All,

I revisited my previous posts of that discussion about the new Vertical Multi-Edge lines feature !

First, when I said :

A work-around has been found but needs to choose one column number only and tick once on the Background mode option !

I want to insist that the fact of ticking on the Background mode option, then unticking it, is needed to update the sole edge boundary value, displayed ! Even with the last 7.9.0 N++ version, this step is necessary !

Now, I did some additional tests, on, both, the final version of my regex and the native Split Lines N++ feature ( Ctrl + I ), using the license.txt file !

Using my regex S/R method, to split the lines, we get the same result :
- Whatever the Line or Background mode is used, in Settings > Preferences... > Editing > Vertical Edge Settings
- Whatever the View > Word wrap option is set or not
- Whatever the View > Show Symbol > Show All Characters option is set or not
- Whatever the current font used is a MonoSpaced or a Proportional font, in the Style Configurator...

provided that you previously ran the Edit > BLank Operations > TAB to Space option if your file contains some TAB characters !

Using the native Edit > Line Operations > Split Lines feature, we get the same result
- Whatever the Line or Background mode is used, in Settings > Preferences... > Editing > Vertical Edge Settings
- Whatever the View > Word wrap option is set or not

But, unlike what I said in my first post, the results of the Ctrl + I feature are totally different depending on whether :

The View > Show Symbol > Show All Characters option is set or not
The current font used is a Monospaced or a Proportional font, in the Style Configurator...

So, regarding my previous argumentation, my regex method and the native Split Lines N++ feature give the same results ONLY IF :

A monospaced font is currently used
The EOL symbol ( CRLF ) is not displayed
The column number is superior to a minimum of about 15 for normal text. When I say “normal”, I refer, for instance, to the license.txt text, from line 28 GNU GENERAL PUBLIC LICENSE Version 2, June 1991 till the end of file !

Note also that, with these hypotheses, the splitting operation of a selection of lines with, both, the regex S/R and the native Split Lines feature gives the same text contents !

IMPORTANT : My regex S/R is built in order to exactly replace the native Split Lines N++ feature, with the hypotheses above. But, of course, you may decide to not follow this rule and use, instead, a more simple search regex as, for instance :

SEARCH (?-s)^.{75,}?\K\x20+

REPLACE \r\n

which would split lines, roughly, after 80 characters

Best Regards,

guy038

Michael Alden

Posting this in case it’s useful to anyone else. I worked around this issue using this plugin: dail8859/LuaScript: Notepad++ plugin for Lua scripting capabilities. Specifically, I added this code to my Lua startup script.

-- Lua function for Scintilla colors
local function RGB(red, green, blue)
    return red | green << 8 | blue << 16
end

-- Teal color value same as default used in Notepad++
local COLOR_TEAL = RGB(128, 255, 255)

-- Set line mode to EDGE_Line at 80 characters with teal color
npp.SendEditor(SCI_SETEDGEMODE, EDGE_LINE)
npp.SendEditor(SCI_SETEDGECOLUMN, 80)
npp.SendEditor(SCI_SETEDGECOLOUR, COLOR_TEAL)

So, every time Notepad++ starts it resets the column marker. This has the same affect as if one were to toggle the “Background mode” setting.

Alan Kilborn

@Michael-Alden

Thanks for your contribution.
It is a Lua variation on @Michael-Vincent 's original NppExec solution.
There hasn’t been a Pythonscript implementation, so I’ll add that now:

editor.setEdgeMode(1)
editor.setEdgeColumn(80)

Michael Vincent

@Alan-Kilborn said in [v.7.8.6] Vertical Edge Settings no longer works with Split Lines (Ctrl-I):

Pythonscript implementation

And of course “PerlScript”:

    editor->setEdgeMode( $SC_EDGEMODE{EDGE_LINE} );
    editor->setEdgeColumn(80);

Cheers.

Alan Kilborn

Cross-linking: https://community.notepad-plus-plus.org/topic/20581/restore-right-margin-word-wrap-as-in-7-8-5

dinkumoil

@Matthew-Au @rd4gh @Alan-Kilborn @Michael-Vincent and all

Since this is the older thread I will drop my two cents here.

Notepad++ v7.8.6 introduced support for drawing multiple vertical lines (also called “edges”) inside of an editor window. But this new feature is not simply an extension of the old well-known single-edge-line feature, instead it is a completely new edge mode that replaced the old one. Unfortunately this broke the ability to word-wrap a document’s content at such an edge line (using the standard keyboard shortcut Ctrl+I).

In the following I provide some scripts for the NppExec plugin to get back the old single-edge-line feature and being able to control it. Additionally I provide a fixed implementation of the related “word-wrap at single-edge-line” feature. That’s because I became aware that Notepad++'s internal implementation of this feature has two bugs:

If the font size of the line numbers margin is set to a different value than the font size for documents, the “word-wrap at single-edge-line” code calculates a wrong wrapping position. This position has to be provided in pixels. To calculate this pixel value, a Scintilla function has to be called that calculates the width in pixels of a provided string from a provided text style. It seems like Notepad++'s internal code erroneously takes the text style of the line numbers margin font when calling this Scintilla function.
To generate the template string for the pixel calculation mentioned above, it is necessary to query the set column number of the single-edge-line. Since column numbers in Scintilla are 0-based, the retrieved result has to be incremented by 1 to get the required length of the template string. It seems Notepad++'s internal code doesn’t do that because when word-wrapping a line that has a word boundary exactly at the single-edge-line it wraps this line at the beginning of that word instead at its end.

Here are the scripts. Most of them could be assigned to a keyboard shortcut using Shortcut Mapper.

Initialize Single-Edge-Line Mode

::SetSingleEdgeLine
npp_console keep
sci_sendmsg SCI_SETEDGECOLUMN 80
sci_sendmsg SCI_SETEDGEMODE EDGE_LINE

This script is intended to be used as a NppExec startup-script. It sets the single-edge-line column to column 80 and activates single-edge-line mode. It is able to override a multiple-edge-line or background-color-edge mode set in Notepad++ preferences dialog.

Change Single-Edge-Line Column

::ConfigSingleEdgeLine
npp_console keep
sci_sendmsg SCI_GETEDGECOLUMN
inputbox "Input edge column" : "Edge column" : $(MSG_RESULT)
sci_sendmsg SCI_SETEDGECOLUMN $(INPUT)
sci_sendmsg SCI_SETEDGEMODE EDGE_LINE

This script opens an input box where users can change the single-edge-line column. The current column is shown as default value. When the user closes the box, the provided value is set as the new column and single-edge-line mode is activated.

Turn on Single-Edge-Line Mode

::SingleEdgeLineOn
npp_console keep
sci_sendmsg SCI_SETEDGEMODE EDGE_LINE

This script activates single-edge-line mode with its current settings.

Turn on Multiple-Edge-Line Mode

::MultipleEdgeLinesOn
npp_console keep
sci_sendmsg SCI_SETEDGEMODE EDGE_MULTILINE

This script activates multiple-edge-line mode with its current settings.

Turn on Backgound-Color-Edge Mode

::BackgroundEdgeOn
npp_console keep
sci_sendmsg SCI_SETEDGEMODE EDGE_BACKGROUND

This script activates background-color-edge mode with its current settings.

Turn all Edges off

::EdgesOff
npp_console keep
sci_sendmsg SCI_SETEDGEMODE EDGE_NONE

This script deactivates all edges.

Word-Wrap Selected Text at Single-Edge-Line

::WrapSelectedLinesAtEdge
npp_console keep

set local $(EdgeModeSingleLine) ~ EDGE_LINE
sci_sendmsg SCI_GETEDGEMODE

if $(MSG_RESULT) != $(EdgeModeSingleLine) then
  set local $(LinePixelWidth) = 0
  goto :DoWrap
endif
  
sci_sendmsg SCI_GETEDGECOLUMN
set local $(LineCharWidth) ~ $(MSG_RESULT) + 1

set local $(TemplateStr) = W
set local $(Cnt) = 2

:ForLoopStart
  if $(Cnt) > $(LineCharWidth) goto :ForLoopEnd
  set local $(TemplateStr) = $(TemplateStr)W
  set local $(Cnt) ~ $(Cnt) + 1
goto :ForLoopStart

:ForLoopEnd
sci_sendmsg SCI_TEXTWIDTH STYLE_DEFAULT "$(TemplateStr)"
set local $(LinePixelWidth) = $(MSG_RESULT)

:DoWrap
sci_sendmsg SCI_TARGETFROMSELECTION
sci_sendmsg SCI_LINESSPLIT $(LinePixelWidth)

This script provides a fixed version of the “word-wrap at single-edge-line” feature. As the original one, it word-wraps at the right edit window border if edge mode is not set to single line. This script could be assigned to the Ctrl+I keyboard shortcut in order to replace the buggy built-in version of Notepad++.

guy038

Hello, @dinkumoil and All,

Very interesting insight and solutions about the new multiple vertical edges and word-wrapping at a specific position …and, incidentally, some good and short examples of the NppExec scripting language ;-))

One question :

When trying to find out a regex emulation of the Ctrl + I feature, some months ago, I realized that some mandatory conditions were needed to get the expected behaviour. Refer to the middle part of this post

So, did you verify the behaviour of your last ::WrapSelectedLinesAtEdge script in these three cases :
A proportional font is used instead of the monospaced one ?
The EOL symbol is displayed, with the View > Show Symbol > Show End of Line or View > Show Symbol > Show All Characters options
The current file contains some tabulation characters, as the number of pixels used by a TAB char is generally different from the space character !

Indeed, the Ctrl + I behaviour, with a single edge, seemed broken when one of these cases occur !

Best Regards,

guy038

dinkumoil

@guy038

Of course, I had not tested the behaviour of my WrapSelectedLinesAtEdge script in conjunction with a proportional font before you asked me because it makes no sense. ;-) Besides that, I’m sure it will not work .

After testing I can say: I got the expected results.

When using a proportional font, the edge line is still drawn as a straight vertical line and when moving the cursor up and down along this line, the Col : field of the status bar shows different values in every single line, depending on the crrent line’s content - obiously because the font is proportional and the characters have different widths. And when running my script, Scintilla does the word-wrap at totally wrong positions.

An edge line simply makes no sense when using proportional fonts, thus my script makes no sense as well in this case. That’s the reason why I have not tested it and why I don’t care that it doesn’t work. :-)

BTW: When I activated the proportional font in style configurator, Notepad++ immediately turned off the single-edge-line.

Alan Kilborn

@dinkumoil said in [v.7.8.6] Vertical Edge Settings no longer works with Split Lines (Ctrl-I):

If the font size of the line numbers margin is set to a different value than the font size for documents

In experimenting with this, I think I discovered a hidden “feature”.
It has been asked before how to get increased vertical spacing between lines in a document (visually only, of course).
This seems to be another method:

Go into Style Configurator and set the Font size of the Line number margin to a large number, e.g. 28:

The effect:

Imgur

OK, the line numbers are really large, but you could always turn them off (in which case the vertical spacing remains, even after restart of N++).

Note: Regarding @dinkumoil 's comment, my new technique could really cause line-splitting with Ctrl+i to yield some wrong/undesired results!!

Michael Vincent

@Alan-Kilborn said in [v.7.8.6] Vertical Edge Settings no longer works with Split Lines (Ctrl-I):

It has been asked before how to get increased vertical spacing between lines in a document (visually only, of course).

Can you just use SCI_SETEXTRAASCENT and SCI_SETEXTRADESCENT?

In NppExec:

SCI_SENDMSG SCI_SETEXTRADESCENT 2

I actually use the value of 1 in my startup script.

Cheers.

Alan Kilborn

@Michael-Vincent said in [v.7.8.6] Vertical Edge Settings no longer works with Split Lines (Ctrl-I):

Can you just use SCI_SETEXTRAASCENT and SCI_SETEXTRADESCENT?

Well, yes… I was just showing another way of doing it, and an interesting way at that. :-)

And of course, there’s a leap to using NppExec (or the other usual suspect: PythonScript) that some people are unable/afraid to take.