Hide Fold Lines

Alan Kilborn

I’d suppose that this is a side-effect of a “simplification” I made to Notepad++ code, that allows Scintilla to handle the green separator line that appears when lines are hidden with View (menu) > Hide Lines.

Unfortunately (for a few reasons), Scintilla doesn’t fully differentiate arbitrarily-hidden-lines from lines-not-shown-due-to-folding.

Are there any known ways to exhibit this behavior that a normal user would get into?

Definition of normal user : Someone that is not hacking Scintilla with calls to its functions using NppExec, PythonScript, ExtSettings…

Details on the change I made are here:

I can confirm this issue with Npp v8.5.1. The previous version v8.5 was not affected.

This tracks, as my change was integrated into 8.5.1.

Michael Vincent

@dinkumoil said in Hide Fold Lines:

@EvilEpicPanda @EvilEpicPanda and all
I can confirm this issue with Npp v8.5.1. The previous version v8.5 was not affected.

Notepad++ 8.5.1 changed the way the fold lines are handled now using the Scintilla element SC_ELEMENT_HIDDEN_LINE instead of a marker.

I use PythonScript (latest 3.0 version works, the default 2.0 will not) to change:

editor.setElementColour(ELEMENT.HIDDEN_LINE, hidden_line_color)

Not sure NppExec can handle this as you need to set the alpha value as well and running NppExec for me returns a negative number making me think it’s signed and may not recognize the alpha value.

Cheers.

dinkumoil

@Alan-Kilborn @Michael-Vincent

Thank you for your clarifications.

So, the new command sequence in NppExec would be:

// Turn off folding lines
sci_sendmsg SCI_SETFOLDFLAGS SC_FOLDFLAG_NONE

// Set alpha channel of hidden line color to fully transparent
sci_sendmsg SCI_GETELEMENTCOLOUR SC_ELEMENT_HIDDEN_LINE
set local $(NewColor) ~ $(MSG_RESULT) & 0x00FFFFFF
sci_sendmsg SCI_SETELEMENTCOLOUR SC_ELEMENT_HIDDEN_LINE $(NewColor)

to turn off folding lines and

// Turn on folding lines
sci_sendmsg SCI_SETFOLDFLAGS SC_FOLDFLAG_LINEAFTER_CONTRACTED

// Set alpha channel of hidden line color to fully opaque
sci_sendmsg SCI_GETELEMENTCOLOUR SC_ELEMENT_HIDDEN_LINE
set local $(NewColor) ~ $(MSG_RESULT) | 0xFF000000
sci_sendmsg SCI_SETELEMENTCOLOUR SC_ELEMENT_HIDDEN_LINE $(NewColor)

to turn them on.

I have to integrate this sequence (including a Npp version query to support older versions) into my ExtSettings plugins. Since I’m up to start a new job I guess this will take some time.

But I still don’t understand why this change was necessary or why it improved the code. Before we had one thing to turn off/on and now we have two of them. Why do we need a folding line and a hidden line, seemingly drawn onto each other? If we would have the hidden line only it would be clear, but this way …

Alan Kilborn

@dinkumoil said in Hide Fold Lines:

But I still don’t understand why this change was necessary or why it improved the code.

In earlier Scintilla there was no SC_ELEMENT_HIDDEN_LINE so, for N++ to show a horizontal line across the viewport to indicate that lines were hidden, N++ had to dedicate a marker to it, and manage that marker as part of the hidden lines logic.

When SC_ELEMENT_HIDDEN_LINE was added, this functionality could be offboarded to Scintilla. The N++ code got simpler, and a marker was freed up for possible other purposes.

Unless there are downsides to this for normal users (have to wait and see), then asking the “hackers” (of which I am a proud one) to take a few extra steps in their hacking is not a big deal. Of course, if I’d have known this would cause the hackers any problems at all, I might have considered not suggesting/doing the change.

dinkumoil

@Alan-Kilborn

Thank you again for the additional info.

@Alan-Kilborn said:

Unfortunately (for a few reasons), Scintilla doesn’t fully differentiate arbitrarily-hidden-lines from lines-not-shown-due-to-folding.

Do you know more about these “few reasons”? Respectively, do you think it is worth the effort to file a bug report at Scintilla’s bug tracker to convince Neil Hodgson that it would be better to fully differentiate between lines for folded code and lines for hidden code? Currently both kind of lines are drawn when code is folded but the folding line alone would be sufficient.

EvilEpicPanda

@dinkumoil said in Hide Fold Lines:

@Alan-Kilborn @Michael-Vincent

Thank you for your clarifications.

So, the new command sequence in NppExec would be:
// Turn off folding lines
sci_sendmsg SCI_SETFOLDFLAGS SC_FOLDFLAG_NONE

// Set alpha channel of hidden line color to fully transparent
sci_sendmsg SCI_GETELEMENTCOLOUR SC_ELEMENT_HIDDEN_LINE
set local $(NewColor) ~ $(MSG_RESULT) & 0x00FFFFFF
sci_sendmsg SCI_SETELEMENTCOLOUR SC_ELEMENT_HIDDEN_LINE $(NewColor)
to turn off folding lines and
// Turn on folding lines
sci_sendmsg SCI_SETFOLDFLAGS SC_FOLDFLAG_LINEAFTER_CONTRACTED

// Set alpha channel of hidden line color to fully opaque
sci_sendmsg SCI_GETELEMENTCOLOUR SC_ELEMENT_HIDDEN_LINE
set local $(NewColor) ~ $(MSG_RESULT) | 0xFF000000
sci_sendmsg SCI_SETELEMENTCOLOUR SC_ELEMENT_HIDDEN_LINE $(NewColor)
to turn them on.

I have to integrate this sequence (including a Npp version query to support older versions) into my ExtSettings plugins. Since I’m up to start a new job I guess this will take some time.

But I still don’t understand why this change was necessary or why it improved the code. Before we had one thing to turn off/on and now we have two of them. Why do we need a folding line and a hidden line, seemingly drawn onto each other? If we would have the hidden line only it would be clear, but this way …

Works beautifully, thanks!

Alan Kilborn

@dinkumoil said in Hide Fold Lines:

Unfortunately (for a few reasons), Scintilla doesn’t fully differentiate arbitrarily-hidden-lines from lines-not-shown-due-to-folding.

Do you know more about these “few reasons”?

What I meant with that phrasing was that I’ve attempted in the past to work with hidden lines (as Notepad++ defines the term…arbitrarily hidden lines via Alt+h, not lines hidden as part of folding) with scripts and, because Scintilla doesn’t strictly differentiate the two types, I found it not reasonably possible to complete my scripting efforts. I gave up (not a pleasant feeling).

But, really, no, I don’t know why Scintilla chose this particular implementation (that’s what I think you are asking about).

do you think it is worth the effort to file a bug report at Scintilla’s bug tracker to convince Neil Hodgson that it would be better to fully differentiate between lines for folded code and lines for hidden code?

Perhaps. In the past, on other issues, I’ve seen a lot of pushback and denial and “not a bug to me; I have no interest in working on” kind of statements from Scintilla behaviors that are fairly obvious bugs in my view.

This one wouldn’t be a bug per se, but more of a feature request? (I’ve observed that Scintilla is rather cranky about the labeling of issues; if you call a feature request a bug, the developers get upset and focus on that rather than the specific issue).

dinkumoil

@Alan-Kilborn said in Hide Fold Lines:

In the past, on other issues, I’ve seen a lot of pushback and denial and “not a bug to me; I have no interest in working on” kind of statements from Scintilla behaviors that are fairly obvious bugs in my view.

I’ve observed that Scintilla is rather cranky about the labeling of issues; if you call a feature request a bug, the developers get upset and focus on that rather than the specific issue

Thank you for these insights. Tracks with my own experience.

Dave Bleja

@Alan-Kilborn

Well, there are also users stuck in the middle, like me. I guess I’m not a “normal” user, since I too was using ExtSettings to hide those lines. But neither am I a “hacker” (surely installing a plugin and unchecking a single checkbox in it does not qualify me as one).

These folding lines mess up my workspace and are a deal-breaker for me. Previously the solution was very simple (install ExtSettings, uncheck a checkbox), but now it seems to have become more complicated. I read through this thread, kinda understood some of what you guys were talking about, and tried installing NppExec and following the provided instructions to re-hide these lines. But it didn’t work. I must have done something wrong, but with my modest technical understanding, I couldn’t figure out what.

So I’ve uninstalled the latest NP++ and have gone back to 8.4.7, which was the last version I was using. I’ll be stuck on 8.4.7 until there’s a straightforward way of removing these lines again.

I do hope that NPP+ introduces a way to get rid of these lines (or at least to style them, so we can make them the same color as the background).

Alan Kilborn

@Dave-Bleja

… and tried installing NppExec and following the provided instructions to re-hide these lines

Dunno…without more detailed info from you than “it doesn’t work”, I don’t suppose anyone can help.

When I tried @dinkumoil 's sequence of NppExec commands for turning fold lines off (in his Mar 31, 2023, 4:13 PM posting above), it worked perfectly (tried it on N++ 8.5.3).

Dave Bleja

@Alan-Kilborn

My point is that the change you made has created problems for a “normal” user like me. You asked whether it would affect “normal” users, and I am answering that question for I am, for all intents and purposes, a “normal” user.

A repetitive electric-green line that cannot be changed no matter the color scheme is, at best, a design flaw, and I’m sure I’m not the only one bothered by it. This design flaw is not your fault, but the change you made has brought it to the surface, and has effectively broken what was a very simple workaround to fix it. I’m sure that with enough persistence, I could get this new NppExec workaround to work, but I’ve already lost too much time on this problem, which is why I ended up reverting to 8.4.7.

From the sounds of it, the change you made made good sense on paper, and added a theoretical improvement that may help down the track, by simplifying code and freeing a spare marker. Though unless that spare marker has been put to good use somewhere already, then from where I sit, the change you made has currently had a net negative effect.

I want to stress again that the design fault here is not of your making. But now that your change has exposed it, I wonder if you would consider having a go at addressing it (eg. by enabling that lines to be stylable, if not removable). If not, then I hope you’ll consider reverting your change for now, until a solution for this green line does eventually exist.

Alan Kilborn

@Dave-Bleja said in Hide Fold Lines:

My point is that the change you made has created problems for a “normal” user like me. You asked whether it would affect “normal” users, and I am answering that question for I am, for all intents and purposes, a “normal” user.

If you are “hacking” Notepad++ functionality by using ExtSettings or some NppExec commands or via scripting, you are NOT what I was defining as a “normal user”. Maybe I should have said “typical user”?

It still has not been shown that the change I made to the code affects the typical Notepad++ user.

Note: You said this first:

I guess I’m not a “normal” user, since I too was using ExtSettings to hide those lines.

Correct.

A repetitive electric-green line that cannot be changed no matter the color scheme is, at best, a design flaw.

This is a valid point, although not in the “fold lines” context, since the line when it appears during folding is not green (without some prior “hacking” having been done).

But try this:

select some range of lines
press Alt+h (or do View menu > Hide Lines)
see green line appear across the editing area where lines are hidden (and large green arrows appear in the margin area) --maybe let’s call this line the “lines are hidden here” line
change to various themes and/or dark mode
see that the line is ALWAYS green
go to Style Configurator to attempt to change this line’s color
fail because there is no way to do such configuration

And, if we change your statement such that it could be talking about the typical “fold line” or the “lines are hidden here” line, like so: A repetitive line that cannot be changed no matter the color scheme is, at best, a design flaw. Then I would agree in that context as well.

Summary:

What’s missing is a way for the typical user to configure:

on/off for the fold line that extends across the user’s view area when blocks are folded (and this, if it existed, probably makes your whole issue a non-issue)
the color of that fold line (obviously only meaningful when that line is configured to be on)
on/off for the “lines are hidden here” line that extends across the user’s view area when lines are hidden
the color of that “lines are hidden here” line (obviously only meaningful when that line is configured to be on)

(Of course, if the green line’s color can be changed, the next thing users will want will be for the green margin arrows’ color to be changeable…)

I think this more than covers what you mentioned:

…by enabling that lines to be stylable, if not removable

Reference images:

What typical user sees for the “fold line”:

What typical user sees for the “lines are hidden here” line:

Dave Bleja

@Alan-Kilborn
What I would like you to appreciate is that I was a typical user, and I’d happily become one again if given the chance. Unfortunately, typical users who do not want these distracting folding lines have had only two choices:

Realise that there’s no native way of getting rid of them. Tough luck.
Google the problem and learn that there’s a simple solution: install the simple plugin ExtSettings and click a checkbox. Problem solved (though by clicking a checkbox they are now, by Alan’s unbending blanket definition, classified as “hackers”).

But the change you introduced in 8.5.1 has changed the choices available. They are now:

Realise that there’s no native way of getting rid of them. Tough luck.
Google the problem and learn that there’s a simple solution: install the simple plugin ExtSettings and click a checkbox. Problem solved (though by Alan’s unbending blanket definition they are now classified as “hackers”).
Google the problem and learn that there’s a complicated solution: install an intimidating-looking plugin called NppExec; enter a bunch of code you don’t understand into a console; then learn how to make it work not as a manually-entered console command, but as an automated script that runs invisibly at startup. None of this is rocket science, though it’s certainly a more daunting collection of hoops to jump through than the now-defunct simple solution above. But to those who don’t like it, Alan says ‘suck it up - you’re a hacker now’.

Since it now takes more time, effort, and know-how to remove these folding lines, it’s highly likely that there will be more typical users who don’t like these distracting lines but who grudgingly accept them because they don’t feel sufficiently confident to jump through the hoops necessary to remove them. Or who, like me, choose not to upgrade past 8.5.0 for the same reason (I know, I know - I don’t count because I’m a “hacker”)

Since the benefits of your change are so far only hypothetical (as I understand it, though I’m happy to be corrected), while the downsides are quite practical, I ask again: would you be prepared to revert the changes until a solution to the folding line problem is implemented, either by you or someone else (any one of the four missing features you outlined would go a long way to addressing this problem)?

PS - I see now that the folding lines are not green by default, but are the same as the default text (which in your screenshot is black, though in my case is near-white #DEDEDE). I stand corrected, though obviously this remains a glaring design flaw either way. Default text needs to be a high-contrast color that draws attention to itself, jumping out of the background for noticeability and legibility. Whereas the job of a folding line is not to draw the eye to itself (since it itself contains no content of inherent value; every such line is identical - no individual line needs to be ‘read’), but rather to the content it demarcates, so a more subtle color for this line would be the more natural design choice. So using the same color for two elements with such contrary purposes isn’t a great idea.

Alan Kilborn

@Dave-Bleja

Since the benefits of your change are so far only hypothetical…

Not to me, as I take advantage of the freed-up marker (again, in a “hacking N++ context”). And apparently not to the author of Notepad++, who agreed with and accepted my change (on the basis, I’m sure, of offloading functionality from Notepad++ to Scintilla).

would you be prepared to revert the changes until a solution to the folding line problem is implemented

I have no interested in doing so.

As Notepad++ accepts user contributed changes, you could attempt to do so.

But probably by far the better path would be to expend effort to implement some/all of the suggested new settings I proposed in my previous posting.

I suppose an alternative approach you could take is to plead your case to @dinkumoil to change his ExtSettings plugin such that the very simple approach of ticking a checkbox again achieves your goal. If the plugin didn’t exist to provide the checkbox, users would just “grudgingly accept” the fold indication lines, and there’d be nothing to talk about here.

… a glaring design flaw either way. Default text needs to be a high-contrast color that draws attention to itself, jumping out of the background for noticeability and legibility. Whereas the job of a folding line is not to draw the eye to itself (since it itself contains no content of inherent value; every such line is identical - no individual line needs to be ‘read’), but rather to the content it demarcates, so a more subtle color for this line would be the more natural design choice. So using the same color for two elements with such contrary purposes isn’t a great idea.

Well-stated.

wonkawilly

I am getting black lines in n++ 853 portable and I think that as a feature not as an issue: in fact I like the rows because they separate folded sections of the same file allowing to spot them easily as if they where margins or just separators.

Look at the following screenshots for example: for me it is a very good thing.
But maybe an option to disable them if some users don’t want them maybe would be also appreciated as the possibility to style them with custom colors and lines type. But I love them, in principle.

Victorel Petrovich

@Alan-Kilborn said in Hide Fold Lines:

If the plugin didn’t exist to provide the checkbox, users would just “grudgingly accept” the fold indication lines, and there’d be nothing to talk about here.

Not necessarily … there are other editors out there that are able to hide those same annoying lines.

@Dave-Bleja and whoever might benefit:

Luckily, it’s not hard to finish up dinkumoil’s hack above with NppExec. I have just found and followed
https://community.notepad-plus-plus.org/topic/16484/how-can-i-hide-the-horizontal-lines-that-appear-when-i-fold-a-block/12?_=1690089965676,
with the obvious replacement of the specific commands to run.
For 1st step, the option in that “(menu) Plugins -> NppExec” is called “Execute NppExec Script … (F6)”. Then in “Advanced options” of that NppExec plugin there is indeed a place where you can select the created script to run at startup.

Victorel Petrovich

@Alan-Kilborn said in Hide Fold Lines:

Summary:
What’s missing is a way for the typical user to configure:

on/off for the fold line that extends across the user’s view area when blocks are folded (and this, if it existed, probably makes your whole issue a non-issue)
the color of that fold line (obviously only meaningful when that line is configured to be on)
on/off for the “lines are hidden here” line that extends across the user’s view area when lines are hidden
the color of that “lines are hidden here” line (obviously only meaningful when that line is configured to be on)

I totally agree, FWIW, and just want to suggest that as a built-in solution (rather than via pluggins), easier to implement than GUI, a configuration file with a list of parameters to set like:

ShowFoldLine=1; # other value possible : 0

Which will include such extra settings that don’t have (yet or never will) a GUI entry somewhere in Settings.
I’ve seen it work in Geany edior, which in particular does have the option this way to hide those folding lines (and some other things I used).

Alan Kilborn

@Victorel-Petrovich said in Hide Fold Lines:

just want to suggest that

If you read the FAQ you’ll learn that suggestions don’t go here.

a configuration file with a list of parameters to set like:
ShowFoldLine=1; # other value possible : 0

Which will include such extra settings that don’t have (yet or never will) a GUI entry somewhere in Settings.

There is already something a bit like this in Notepad++, with either the presence / absence of a specially named zero-length file (e.g. doLocalConfig.xml or enableSelectFgColor.xml ) controlling things, or special tags in a file like config.xml (e.g. regexBackward4PowerUser tag) that have no UI-controlling component and must be hand-edited if used.

I’ve seen it work in Geany edior, which in particular does have the option this way to hide those folding lines (and some other things I used).

I think the Scintilla demo editor, SciTE, controls things in a similar manner.

Victorel Petrovich

@Alan-Kilborn said in Hide Fold Lines:

If you read the FAQ you’ll learn that suggestions don’t go here.

Sure, but it was an informal one… and you broke that “rule” yourself when writing that list of suggestions.

the presence / absence of a specially named zero-length file (e.g. doLocalConfig.xml or enableSelectFgColor.xml ) controlling things, or special tags in a file like config.xml (e.g. regexBackward4PowerUser tag) that have no UI-controlling component and must be hand-edited if used.

The latter would be better than the former (imagine dozens of files in that folder for such little style settings ! ).

Yep, SciTE and textadept and SublimeText and many other editors.

PeterJones

@Victorel-Petrovich said in Hide Fold Lines:

@Alan-Kilborn said in Hide Fold Lines:

If you read the FAQ you’ll learn that suggestions don’t go here.

Sure, but it was an informal one… and you broke that “rule” yourself when writing that list of suggestions.

I wish people would understand that when Alan or myself or any of the other regulars point someone to that FAQ, it isn’t supposed to mean “discussion done”. It means that we are trying to inform them or remind them that no matter how much we discuss a potential new feature in the Community, it will not be considered for implementation until a feature is raised in the issue tracker. I guess I need to rework the introduction to that FAQ to make that more obvious.

the presence / absence of a specially named zero-length file (e.g. doLocalConfig.xml or enableSelectFgColor.xml ) controlling things, or special tags in a file like config.xml (e.g. regexBackward4PowerUser tag) that have no UI-controlling component and must be hand-edited if used.

Yep, SciTE and textadept and SublimeText and many other editors.

And Notepad++.

The latter would be better than the former (imagine dozens of files in that folder for such little style settings ! ).

both are used in Notepad++ currently: the ones that Alan mentioned for file-based triggers, and “hidden” config.xml preferences for advanced users like the ones for backward regex searches, find/replace history length, and the commandLineInterpreter setting which allows picking cmd.exe vs powershell.exe vs <insert favorite alternate CLI for Windows here>

(doLocalConfig.xml cannot be done via the config.xml file, because the result of the logic it triggers determines where Notepad++ searches for config.xml, which would be a rather catch-22 situation. But I don’t see any reason why enableSelectFgColor.xml and nppLogNulContentCorruptionIssue.xml and v852NoNeedShortcutsBackup.xml and even asNotepad.xml couldn’t have been implemented as hidden settings all in config.xml.)