Hey, You can also check this https://hackr.io/tutorials/learn-c-plus-plus there are top listed tutorials recommended by the programming community.

Even if @Ekopalypse 's suggestions work for you, it seems like having a script to break up the file into year-size-chunks would be a sensible thing to do. I have no idea what the format for your file is, but I would think you could parse it with a Python script or something and break it into more manageable size pieces.

@Dov-Fuchs
The file you want to open in the browser must be saved as HTML
…this is important!!!

@Daniel-Moço

I can speak only for myself but I’m absolutely lost - I don’t understand what you are trying to do. Maybe you wanna post in your native language and with English translated text in the hope that one is out there who is able to understand what you are trying to achieve.
If you can provide a screenshot, which can be embedded using this syntax , it might be useful as well.

@Greg-Hendricks

This belongs in the Boycott Notepad++ section 😛

@Norbert-Wasser

This thread discusses what you are wanting to do: https://notepad-plus-plus.org/community/topic/16701/how-to-mark-lines-above-marked-lines

Thanks, opened issue - https://github.com/notepad-plus-plus/notepad-plus-plus/issues/5873 .

@廖红贵 said:

select 10 rows, when I input the following values: Initial Number = 1, Increase By = 1, Repeat = 10,

You selected 10 rows, and told to count up from 1, repeating each number 10x. So the first 10 rows were 1, like you told it to do. To see the 2, you would have to have more than 10 lines selected.

You should probably start with something simpler and easier to see, like 1,1,1, which will just count from 1 to N for the N lines you select:

:

@Paul-Flaherty

install WINE, install npp - done.
In addition, on linux there are already some packages are available like snap etc…

Hi, All,

Continuation of the previous post !

You certainly noticed that, in the 4 last cases of the previous post, the numbers are always moved back, right after the ABC DEF string, because digits, as bi-directional weak char, are considered as belonging to the last embedded directional range. So, how to force the numbers to stay, after the GHI JKL MNO PQR STU string, already written in the Right to Left direction ?

For such a task, and to compensate for the lack of the Isolates formating characters, we need to use one of the Implicit Directional Marks, below, which do work, too, with Notepad++ ;-))

-  LEFT-TO-RIGHT MARK LRM 200E -  RIGHT-TO-LEFT MARK RLM 200F -  ARABIC LETTER MARK ALM 061C

These characters are very light-weight formatting and act, simply, as a bidirectional strong char, with the L or R type

So, we get 4 more cases :

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> <LRM>123, 456 VWX YZA ABC DEF ‮GHI JKL MNO PQR STU‬ ‎123, 456 VWX YZA ( 47 chars ) ─► The "ABC DEF " string is written with the DEFAULT direction of the CURRENT embedding level (level 0), so with the "Left to Right" direction ─► The "GHI JKL MNO PQR STU" string, from right AFTER the <RLO> formating char, till the <PDF> formating char (level 1), is written in the "Right to Left" direction ─► The SPACE char, as a NEUTRAL char, is written in the CURRENT bi-directional direction, of level 0, so "Left to Right" ─► Finally, the INVISIBLE <LRM> mark, acting as a STRONG "Left to Right" character forces ALL remaining text, so the string "123, 456 VWX YZA", to be rewritten in the "Left to Right" direction ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> <LRM><RLO>123<PDF>, <LRM><RLO>456<PDF> VWX YZA ABC DEF ‮GHI JKL MNO PQR STU‬ ‎‮123‬, ‎‮456‬ VWX YZA ( 52 chars ) ─► The "ABC DEF " string is written with the DEFAULT direction of the CURRENT embedding level (level 0), so with the "Left to Right" direction ─► The "GHI JKL MNO PQR STU" string, from right AFTER the FIRST <RLO> formating char, till the FIRST <PDF> formating char (level 1), is written in the "Right to Left" direction ─► The SPACE char, as a NEUTRAL char, is written in the CURRENT bi-directional direction, of level 0, so "Left to Right" ─► The INVISIBLE <LRM> mark, acting as a STRONG "Left to Right" character forces the context string "123, ", with the WEAK bidirectional digits , to be rewritten in the "Left to Right" direction ─► But the "123" number, from right after the SECOND <RLO> formating char, till the SECOND <PDF> formating char (level 1) is written, in the "Right to Left" direction ─► Again, the INVISIBLE <LRM> mark, acting as a STRONG "Left to Right" character forces the string "456", with the WEAK bidirectional digits , to be rewritten in the "Left to Right" direction, so AFTER the "123, " string ─► But the "456" number, from right after the THIRD <RLO> formating char, till the THIRD <PDF> formating char (level 1) is written, in the "Right to Left" direction ─► Finally, the " VWX YZA" string, after the THIRD <PDF> formating char, is written with the DEFAULT direction (level 0), so in the "Left to Right" direction ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> <LRM><RLO>123, 456<PDF> VWX YZA ABC DEF ‮GHI JKL MNO PQR STU‬ ‎‮123, 456‬ VWX YZA ( 49 chars ) ─► The "ABC DEF " string is written with the DEFAULT direction of the CURRENT embedding level (level 0), so with the "Left to Right" direction ─► The "GHI JKL MNO PQR STU" string, from right AFTER the FIRST <RLO> formating char, till the FIRST <PDF> formating char (level 1), is written, in the "Right to Left" direction ─► The SPACE char, as a NEUTRAL char, is written in the CURRENT bi-directional direction, of level 0, so "Left to Right" ─► The INVISIBLE <LRM> mark, acting as a STRONG "Left to Right" character forces EACH remaining block of text, to be rewritten in the "Left to Right" direction ─► However, the "123, 456" string, from right AFTER the SECOND <RLO> formating char, till the SECOND <PDF> formating char (level 1) must be written, in the "Right to Left" direction ─► Finally, the " VWX YZA" string, after the SECOND <PDF> formating char, is written with the DEFAULT direction (level 0), so in the "Left to Right" direction ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> <LRM><RLO><LRO>123<PDF>, <LRO>456<PDF><LRM><PDF> VWX YZA ABC DEF ‮GHI JKL MNO PQR STU‬ ‎‮‭123‬, ‭456‬‎‬ VWX YZA ( 54 chars ) ─► The "ABC DEF " string is written with the DEFAULT direction of the CURRENT embedding level (level 0), so with the "Left to Right" direction ─► The "GHI JKL MNO PQR STU" string, from right AFTER the FIRST <RLO> formating char, till the FIRST <PDF> formating char (level 1), is written in the "Right to Left" direction ─► The SPACE char, as a NEUTRAL char, is written in the CURRENT bi-directional direction, of level 0, so "Left to Right" ─► The INVISIBLE <LRM> mark, acting as a STRONG "Left to Right" character, forces the context-numbers string to NOT depends on the FIRST <RLO>........<PDF> range ─► Then the "123, 456", right after the SECOND <RLO> formating char, till the FOURTH <PDF> formating char, is rewritten in the "Right to Left" direction (leval 1) ─► But the "123" number, from right after the FIRST <LRO> formating char, till the SECOND <PDF> formating char (level 1) is written, in the "Left to Right" direction (level 2) ─► The ", " string is written according to the CURRENT direction of the SECOND <RLO>........<PDF>range, starting at the SECOND <RLO> formating char, till the FOURTH (level 1), so in the "Right to Left" direction ─► The "456" number, from right after the SECOND <LRO> formating char, till the THIRD <PDF> formating char (level 2) is written, in the "Left to Right" direction (level 2) ─► The INVISIBLE <LRM> mark, acting as a STRONG "Left to Right" character, forces the " VWX YZA" string, to be written in the "Left to Right" direction (level 0) However, note that I did NOT understand WHY I had to locate the <LRM> mark BEFORE the LAST <PDF> formating char ( and NOT after ) to get the right behavior !

So, in short, starting with the 2 sample texts ABC DEF GHI JKL MNO PQR STU VWX YZA and ABC DEF GHI JKL MNO PQR STU 123, 456 VWX YZA, the syntaxes, below :

ABC DEF <RLO>GHI JKL MNO PQR STU VWX YZA ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> VWX YZA ABC DEF <RLO>GHI JKL<PDF> MNO <LRO>PQR STU<PDF> VWX YZA ABC DEF <RLO>GHI JKL <LRO>MNO PQR<PDF> STU<PDF> VWX YZA ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> 123, 456 VWX YZA ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> <RLO>123, 456<PDF> VWX YZA ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> <LRO>123, 456<PDF> VWX YZA ABC DEF <LRO><RLO>123<PDF>, <RLO>456<PDF><PDF> <RLO>GHI JKL MNO PQR STU<PDF> VWX YZA ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> <LRM>123, 456 VWX YZA ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> <LRM><RLO>123<PDF>, <LRM><RLO>456<PDF> VWX YZA ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> <LRM><RLO>123, 456<PDF> VWX YZA ABC DEF <RLO>GHI JKL MNO PQR STU<PDF> <LRM><RLO><LRO>123<PDF>, <LRO>456<PDF><LRM><PDF> VWX YZA

produce the corresponding results, below :

( 36 chars ) ABC DEF ‮GHI JKL MNO PQR STU VWX YZA ( 37 chars ) ABC DEF ‮GHI JKL MNO PQR STU‬ VWX YZA ( 39 chars ) ABC DEF ‮GHI JKL‬ MNO ‭PQR STU‬ VWX YZA ( 39 chars ) ABC DEF ‮GHI JKL ‭MNO PQR‬ STU‬ VWX YZA ( 46 chars ) ABC DEF ‮GHI JKL MNO PQR STU‬ 123, 456 VWX YZA ( 48 chars ) ABC DEF ‮GHI JKL MNO PQR STU‬ ‮123, 456‬ VWX YZA ( 48 chars ) ABC DEF ‮GHI JKL MNO PQR STU‬ ‭123, 456‬ VWX YZA ( 52 chars ) ABC DEF ‭‮123‬, ‮456‬‬ ‮GHI JKL MNO PQR STU‬ VWX YZA ( 47 chars ) ABC DEF ‮GHI JKL MNO PQR STU‬ ‎123, 456 VWX YZA ( 52 chars ) ABC DEF ‮GHI JKL MNO PQR STU‬ ‎‮123‬, ‎‮456‬ VWX YZA ( 49 chars ) ABC DEF ‮GHI JKL MNO PQR STU‬ ‎‮123, 456‬ VWX YZA ( 54 chars ) ABC DEF ‮GHI JKL MNO PQR STU‬ ‎‮‭123‬, ‭456‬‎‬ VWX YZA

As you may verify, by yourself, the 4 first and the 8 last results, of the last table, have, seemingly, the same width. This proves that, in all cases, the Unicode formating characters are zero-width chars ;-))

Best Regards,

guy038

P.S. :

Some of my explanations may be confusing, approximate or false. It is quite natural because this is a complex area !!

@Ldxrunner said:

Can I use notepad++ to copy and paste?

Yes.

Is notepad ++ encrypted ?

That’s a rather strange question. I can see two obvious interpretations:

If you mean “is the binary executable notepad++.exe encrypted”: No, the binary executable is not encrypted per se, just compiled, like other applications that run on Windows.

If you mean “does Notepad++ encrypt the text files or source code I edit and save”: Not natively. However, the NppCrypt plugin exists to facilitate encryption of your edited text.

@Alan-Robbo How little is needed for complete happiness)))

@Mr-Zed said:

This site converted

If you want help with the site’s Markdown language, see this excerpt from my boilerplate:

This forum is formatted using Markdown, with a help link buried on the little grey ? in the COMPOSE window/pane when writing your post. For more about how to use Markdown in this forum, please see @Scott-Sumner’s post in the “how to markdown code on this forum” topic, and my updates near the end. It is very important that you use these formatting tips – using single backtick marks around small snippets, and using code-quoting for pasting multiple lines from your example data files – because otherwise, the forum will change normal quotes ("") to curly “smart” quotes (“”), will change hyphens to dashes, will sometimes hide asterisks (or if your text is c:\folder\*.txt, it will show up as c:\folder*.txt, missing the backslash). If you want to clearly communicate your text data to us, you need to properly format it. That topic also explains how to embed images by uploading them to a public server like imgur.com, and embedding them using the syntax 

+1 for “the “vertical” option but keeping the tabs horizontal”

Currently the tabs’ text is pretty unreadable being vertical as well!

I found it filed :
Vertical Tab option with Horizontal Title - enhancement
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/4661

An alternative is suggested using the Document List Panel, which works well.

@Peter-Åkerström Have a nice swim))

Thank you adrecool-68. Good to know.

Or maybe try what I’ve come to remember as the “ninja” plugin; see here.

@tech_newb: Welcome to the Notepad++ Community.

Is this in fact a bug or can someone see something I am doing incorrectly

I cannot replicate your described behavior:

The highlighting continues beyond that row for me in v7.7 64-bit.

There might be something with your particular version.

If you go to ? > Debug Info, you can click on the “Copy debug info into clipboard” shown in my image, and directly paste the debug-info text into your reply. Or you can do a screenshot, upload to a service like imgur, and use syntax  to embed the image (making sure to have the direct img URL, not the imgur “display page” which includes html to display the image with all their formatting and internal/external links).