Hide Fold Lines

Dave Bleja

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

PeterJones

@PeterJones said in Hide Fold Lines:

I guess I need to rework the introduction to that FAQ to make that more obvious

It now says,

Being directed to this FAQ does not mean “end of discussion”. It is solely to inform you of these facts for the first time, or to remind you of them if you’ve previously seen them. You are allowed and even encouraged to discuss new features ideas or potential bugs found in the Community, as long as you understand that a discussion in this Community Forum is not the same as making an official Feature Request or Bug Report.

Victorel Petrovich

@PeterJones said in Hide Fold Lines:

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.

OK Peter, but to me he sounded rather blunt / rejecting, saying suggestions don’t go here. He could have said " hey, as said in FAQ, don’t hope for things to get done just by suggesting here" , or something like that.
So, he got what he asked for, so to speak. Not that I’m upset, and hope he understood too and move on.

In fact, if you think about it, what I suggested there could not really be made into an issue on github, because it was only a sort of tip that is only relevant in case he (or other developer) was going to implement any of HIS suggestions in that list about lines.

So, yeah, it was a “suggestion” (in the general sense of the word) but not an independent feature request. More like a comment one the way he (or others) could implement those features… After submitting a proper issue on github. Not here. ;) :)

Victorel Petrovich

@dinkumoil said in Hide Fold Lines:

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 …

Of course they should not be drawn onto each other.
But, as a user, I can see why it’s good to have them both: sometimes you want to hide the fold lines, and not the non-fold lines.

For example, if the code is deeply nested and indented, and you fold some of the fold-points, then the long fold-lines distract from the hierarchical structure. ( I like the alternative markers you show in your picture above )

But not so with some arbitrary fragment of the file that you choose to hide - there the line marker is rather welcome, IMO.