Notepad++ v8.2.1 Release
-
I don’t wish to discourage anyone but considering the number of issues being fixed or retriggered, should I be using latest versions or just stay on old version like before the x64 transition?
-
@winswgmbh said in Notepad++ v8.2.1 Release:
considering the number of issues being fixed or retriggered
What is this quantity you are talking about?
I am using 8.2.1 for days now; no apparent problems.
just stay on old version like before the x64 transition?
That is something you have to answer for yourself.
-
@alan-kilborn Ok. Quantity is the issues people report here since v 6.9.5. I am following up the community hence the question. I neither mean the things are not fixed(yes they are fixed) nor intend to disrespect the developer if that is what is concluded from my comment however most of the times I prefer “stability” over trying new features and updates. I am using this program for basic notepad tasks and code reading, nothing too complex and I prefer it as my default one always.
-
@winswgmbh
if you use Notepad++ as a replacement for Notepad without doing fancy things, you can always update.
I have never had any issues, since I too use Notepad++ in a similar way. -
I had the same experience as Stefan, until I decided to involve myself in creating a UDL for my community’s language. I even had a screwed up install with my x64 being installed in the x32 directory on windows, etc, and the program always worked for the simple things I did, bar none. So if you don’t want the latest and greatest, don’t upgrade, but don’t be afraid to upgrade for your modest needs. Things like the recent testing of files 2GB in size will not affect your usage and if it does, the testers will most likely find it before it becomes a release. Other than the broken update program a few version ago, I’ve not had one problem with the NPP that I didn’t create myself with my language creation. :)
Lee
-
@Stefan-Pendl and @Lycan-Thrope Thank you so much for clearing my doubts and hesitation to upgrade.
-
@lycan-thrope
I do use some UDLs for data files of a software I am maintaining and also never had any issues.
It is the same for all kinds of software, an update or upgrade always has the risk to break something, this is why software vendors offer test releases.
If you like to make sure your use-case works, use the portable release for testing it. -
It seems v8.2.1 is quite stable.
The auto-updater has been triggered for this release. -
Hi @peterjones
During the auto complete, the suggested words are listed in drop down. However, mouse click or keyboard navigation and selection using Enter key is not working. So, I had to downgrade to v8.2 to keep that auto-complete and keyboard navigation working. -
election using Enter key is not working.
Per the v8.2.1 release notes, above: "3. Add an option for inserting auto-completion selection to fix hitting twice ENTER to go to next line. "
Did you try using that option, or using the alternate TAB instead of ENTER to select it? Because in my experiments earlier, I didn’t just have the pulldown, it worked 100% for me.
-
P PeterJones referenced this topic on
-
It shouldn’t change the default value of ENTER to TAB for auto-complete. I was very confused when it stopped working using the enter key. Only after going to the changelogs and then to options to switch it back from tab to enter it’s working fine again.
-
D donho unpinned this topic on
-
@dobatymo said in Notepad++ v8.2.1 Release:
It shouldn’t change the default value of ENTER to TAB for auto-complete.
Agreed. In general, adding options for alternative workflows is great, but changing default behaviours is a poor implementation strategy - the changes are very frustrating for long-time users, and often come across as regressions at first glance.
As a recent (non-NP++) example: Microsoft revamped the context menu in Windows 11 in an attempt to make certain selections easier to find. In doing so, they appeared to eliminate many of the commonly-used options, but what they actually did was just move them to a sub-menu. For many (most?) long-time Windows users, this was a highly disruptive change - one that was made worse by the method of reverting back to the old style.
In general, the only scenario where it makes sense to have new options and such toggled/implemented by default is if the user is new to the product - such users have no workflows ingrained into them yet, so there isn’t anything to disrupt. So, installations from full installers are likely safe for implementing the new workflows by default, but upgrades should never change current workflows.
That being said, some users (like myself) do fresh installations on new machines surprisingly often (in my case, on VMs used for testing). I already have a system in place for “importing” my preferred configurations post-installation (in fact, the configuration files are updated every time my VMs are powered up), but during the installation process, it would be nice to be prompted for the location of the various configuration files that ultimately get copied over.
-
@mathlete2 said in Notepad++ v8.2.1 Release:
It shouldn’t change the default value of ENTER to TAB for auto-complete.
Agreed. In general, adding options for alternative workflows is great, but changing default behaviours…
I believe the “default behavior” described was considered a bug, so changing it was a bug fix. Keeping the old behavior was nicely made into an option setting with the fix, to give those familiar with the feature a path to return to what they’ve gotten used to.
-
@alan-kilborn said in Notepad++ v8.2.1 Release:
I believe the “default behavior” described was considered a bug
Perhaps we weren’t clear about what “default behaviour” we were referring to. In this case, we were referring to the result of “pressing Enter while the auto-complete menu is open”:
In all previous releases, the default behaviour was to insert whichever selection was highlighted. With the update, the default behaviour completely ignores the menu. Unless the user is aware of the new options (and their default settings), this new default behaviour comes across as a (significant) regression.
Out of curiosity, I looked at the Auto-completion documentation, and it looks like it’s inaccurate:
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 suggests that TAB and ENTER should both be checked by default, but that is not the case after an update; only TAB is checked in this scenario, which is why “Enter” wasn’t working for us at first. Perhaps there’s a bug in the update process?
-
@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.
