Notepad++ v8.2.1 Release
-
@mathlete2 said in Notepad++ v8.2.1 Release:
Out of curiosity, I looked at the Auto-completion documentation, and it looks like it’s inaccurate:
It was accurate until that feature was changed. Now it’s being updated. The documentation sometimes lags a few weeks behind new releases, because that gives me a chance to go through the release notes and make sure everything relevant has been updated (because I am the primary documentation maintainer, but not one of the developers, so I don’t get foreknowledge of new features).
Also, when there are a lot of back-to-back NPP releases (like recently), the usermanual sometimes only gets released after a few releases, rather than after every release. It depends on how fast I am, and how often the website owner feels like doing a new release, or I ping him.
If you’re ever curious what changes have been implemented in the docs since the last release of the website, go to the github project for npp-user-manual.org. There, you can see that auto-completion page has been updated to mention the behavior change in v8.2.1.
After checking the github, if you ever feel that there’s a deficiency in the user manual that hasn’t been addressed, feel free to create an issue and submit a PR.
Perhaps there’s a bug in the update process?
No, the two biggest problems are that I’m not prescient, and I am not paid enough by the Community to make maintaining the user manual my full-time job.
-
@mathlete2 said in Notepad++ v8.2.1 Release:
Perhaps we weren’t clear about what “default behaviour” we were referring to.
Nope, it was 100% clear to me.
I read the release notes when I update.
And I realize that, for the good of the software, sometimes default behavior changes. -
@PeterJones ok, thanks for confirming this, and for the additional insight WRT the documentation process. Given that the new defaults are in fact intentional, I think I need to revisit Alan’s response:
@alan-kilborn said in Notepad++ v8.2.1 Release:
I believe the “default behavior” described was considered a bug, so changing it was a bug fix.
Generally speaking, if a feature is functioning as designed, undesired results are not necessarily bugs. Strictly speaking, bugs are unintended results; while unintended results are almost always undesired, undesired results are not necessarily unintentional - in many cases, they are entirely intentional.
Think of it this way: if a feature already has settings that can avoid certain results, changing the installation defaults of said features is never the solution; when a user reports such issues, the solution is for the user to change the settings, not for the company to change the defaults in the next version (especially if the feature has already been in use by the majority of end users for a significant period of time). So, if a feature doesn’t have such options yet, why would implementing them through feature requests (such as #4799 referenced above) be done in a way that changes the default installation settings?
Of course, some undesired results are in fact unintentional - #8389 and #10915 (which actually appear to be identical) seem like good examples of this. In this case, the issues seem to stem from the fact that the Auto-Complete (AC) menu displays the current text as an option, even when that’s the only option in the menu. I highly doubt that this was intentional - it doesn’t make sense to select an AC option that doesn’t add any new characters.
However, giving users the option of changing the AC key(s) only provides a potential workaround, not a proper solution. In fact, it won’t even be viable for all users; all the option does is allow users to shift the problem to a different key - one that also has dual functionality. Sure, users are much less likely to want to use Tab instead of Enter at the end of a line, but the ones that do will run into the same problem as before.
-
Actually, I had to get use to NPP’s way of doing it prior (enter key) rather than tab. The nice thing about the change is that it’s something you notice right away that it was changed, but as Alan has pointed out, reading the release notes should have taken care of the surprise factor. I noticed it right away, when my completion didn’t work, then I remembered the release notes, which when glancing at them originally, I didn’t understand what the change meant, until I saw it in action, then realized the behavior I was used to in other editors was back. So Ieft it at the tab, and had I understood what the release notes were referring to, I wouldn’t have been surprised at all.
I don’t know about others, but I read the release notes of everything, whether I understand the changes noted or not, like Firefox, Thunderbird and Windows updates. I may not understand everything they’re referring to, but at least I browse them to see what has changed. I was peeved by the recent Firefox change to the default color scheme I’d been using to default to dark mode, but after using it for awhile, my eyes were more thankful. The only change I’ve ever really complained about was the change in Tbird’s handling of saving files when in a newsgroup. It used to work, now it crashes the software, and I read them the riot act. :) Failure versus new behavior is totally different. RTFM or RTRN (in this case) helps to at least see what’s coming. :)
Lee
-
@Lycan-Thrope I see where you’re coming from, and I may well be in the minority in terms of users who were frustrated by NP++'s original use of ENTER. However, FWIW, the release notes only say that an option was added; there’s nothing to suggest that the default setting of this option actually changes the behaviour from previous releases, and that’s the crux of the whole issue. In fact, even if I follow @peterjones’s suggestion and read the updated auto-completion page, I see two excerpts pertaining to the default behaviour that point to a bug in the current installers:
You accept the suggestion by typing the Enter or Tab key, and the word is completed within your buffer as if you’d typed it all out
This is actually identical to the currently-published doc, so it may have just been an inadvertent oversight by the doc team. However, the other one clearly references changes in the 8.2.1 release:
hitting Tab or Enter key or double-clicking on the choice will select one (though in NPP v8.2.1 and newer, the Tab/Enter is configurable)
The good news is that both of these excerpts are consistent with one another: they both clearly indicate that, by default, both Tab and Enter should insert the active AC selection (i.e. in the Preferences window’s new Auto-Completion options, both TAB and ENTER are checked by default), and that users now have the option to disable one of the keys if they wish.
The bad news is that this is not how quite how the new option referenced in the release notes was actually implemented: when you update to 8.2.1 from a previous version (or install 8.2.1 directly to a system that has never had NP++ installed previously), ENTER is unchecked by default. In fact, if you then manually configure the options to match the documented default, then do an uninstall of NP++, you are asked if you want to keep your custom settings. If you select “yes”, then re-install NP++, the change is remembered.
All things considered, it looks like the developers intended to maintain the default AC keys for the sake of consistency, but inadvertently submitted the incorrect configuration when they implemented the new option.
-
You accept the suggestion by typing the Enter or Tab key, and the word is completed within your buffer as if you’d typed it all out
This is actually identical to the currently-published doc, so it may have just been an inadvertent oversight by the doc team. However, the other one clearly references changes in the 8.2.1 release:
That’s a generic introduction which applies to all versions. There isn’t an English language conjunction which means “one or the other, but that doesn’t necessarily mean that both will work at the same time, depending on version or settings”
hitting Tab or Enter key or double-clicking on the choice will select one (though in NPP v8.2.1 and newer, the Tab/Enter is configurable)
The good news is that both of these excerpts are consistent with one another:
IMO, they are.
they both clearly indicate that, by default, both Tab and Enter should insert the active AC selection (i.e. in the Preferences window’s new Auto-Completion options, both TAB and ENTER are checked by default), and that users now have the option to disable one of the keys if they wish.
IMO, they both clearly indicate that one or the other key is possible to work, but the second paragraph goes on to clarify that which of those keys is enabled will be affected by settings. It says nothing about the default setting.
I will have to make it more clear, because the documentation is meant to follow the actual behavior of Notepad++, and if you cannot understand the actual behavior of Notepad++ through my documents, it means I haven’t been clear enough.
The bad news is that this is not how quite how the new option referenced in the release notes was actually implemented: when you update to 8.2.1 from a previous version (or install 8.2.1 directly to a system that has never had NP++ installed previously), ENTER is unchecked by default. In fact, if you then manually configure the options to match the documented default, then do an uninstall of NP++, you are asked if you want to keep your custom settings. If you select “yes”, then re-install NP++, the change is remembered.
That’s because that option didn’t exist prior to 8.2.1, so there was no setting for it. When 8.2.1 installs, it adds the config bit for that setting, to whatever value the developer thought was appropriate – in this case, TAB enabled and ENTER disabled.
All things considered, it looks like the developers intended to maintain the default AC keys for the sake of consistency, but inadvertently submitted the incorrect configuration when they implemented the new option.
That is an incorrect assessment. You quibble over my phrasing in the manual, but I am not a developer, so any discrepancy between my phrasing and the actual behavior is a failing on my part to write the documentation in a way that you understand. Based on all statements by the developer, this was implemented exactly the way it was intended.
-
I am in the process of updating the phrasing again. Currently, I plan on the introductory paragraph including the sentence:
You accept the suggestion by typing the completion key (see “Automatic completion”, below), and the word is completed within your buffer as if you’d typed it all out.
… and the detailed paragraph saying:
You can use arrow keys (or the mouse) to navigate through the entries in the popup; hitting the completion key or double-clicking on the choice will select that choice and enter it as if you had just typed the whole word; hitting the
Esckey will exit the auto-completion popup without choosing one of the suggestions. (As of v8.2.1, the default completion key isTab, though you can use preferences to set whether it only acceptsTab, only acceptsEnter, or accepts either as a valid completion key. In v8.2 and earlier, both keys would be accepted as the completion key, without a configuration option to affect it.) -
M Michael Vincent referenced this topic on
-
@mathlete2 ,
I see your point, also, and as Peter has explained, he will phrase the situation different, and the issue that in that a previous update, it just worked for both, without exclusion of the other. I read the documentation as either or, as I seldom see things being explained that are inclusive of both options, and didn’t realize that it would allow both as that seems to me to be redundant action of overworked keys as it is. :) However, point taken…and have a good day. :)Lee
-
Out of curiosity, I looked at the Auto-completion documentation, and it looks like it’s inaccurate:
Notepad++ project is not like the ones in Microsoft or in Apple: all the maintainers are volunteers so our resources are much more restricted. It’s unfair to blame Notepad++ document not accurate. But even under such condition, I ensure you that Notepad++ User Manual Project updates extremely frequently. @PeterJones synchronizes the user manual on every release. On the current state of User Manual, he has done an awesome job.
OTOH, I saw several complains about Auto-completion “regression”, I admit that the “default settings” should be kept while adding the option. The decision was done in the current change because for some users it’s a bug. I should know that we cannot make everyone happy. So if no one thinks it’s not convenient, the default settings will be
ENTER&TABboth enabled in the next release - people who think typing ENTER twice to have one new line is a bug can disableENTERin the option. -
-
@donho said in Notepad++ v8.2.1 Release:
It’s unfair to blame Notepad++ document not accurate
To clarify, I wasn’t trying to blame the doc team (not in a guilt-trip sort of manner, anyway). I was just pointing out a (presumably inadvertent) discrepancy between the doc and the current behaviour. In fact, I was doing my best to establish that the discrepancy needed to be sorted out on the dev side, not the doc side.
-
@peterjones said in Notepad++ v8.2.1 Release:
It says nothing about the default setting (…) the documentation is meant to follow the actual behavior of Notepad++
In this case, there are specific workflows/keystrokes documented. In general, such descriptions implicitly describe a default behaviour (even if the term “default” isn’t explicitly used).
-
@mathlete2 said in Notepad++ v8.2.1 Release:
@peterjones said in Notepad++ v8.2.1 Release:
It says nothing about the default setting (…) the documentation is meant to follow the actual behavior of Notepad++
In this case,
Why are you still fighting this semantic argument?
I have already agreed that some users, including you, were confused by my wording, and I have already been working on updating the documentation to make it clearer to all readers, and now to include the fact that versions after 8.3 will go back to defaulting to Enter + Tab both consumed during auto-completion popup.
-
@donho said in Notepad++ v8.2.1 Release:
The decision was done in the current change because for some users it’s a bug.
Well, it was certainly an annoyance for some (many?) users, but as I’ve said before, not all annoyances are “bugs”. Even the annoyed users were acknowledging that the feature was technically working as expected - note that the feature request just wanted more options to work with, not new default settings.
Incidentally, ICYMI from one of my previous comments, there does seem to be an actual bug in the AC menus: exact matches to the current text (which don’t add any new characters when selected) are included as an option. If these options are being included intentionally, and are actually useful in some scenarios, it would be good to offer an option to exclude them.
-
@peterjones said in Notepad++ v8.2.1 Release:
Why are you still fighting this semantic argument?
I wasn’t, I was explaining why I was using a term that wasn’t explicitly used in the doc. You didn’t seem to understand why I was using the term “default” (which made sense because the doc excerpts that I was referencing didn’t use it), so I gave an explanation of why it was still an appropriate term to use in this context.
-
T Terry R referenced this topic on
-
T Terry R referenced this topic on
-
P PeterJones locked this topic on
