Hazardous blank operations operate on whole file when no selected text, need to evolve safer approach
-
I’m going to do a rare thing here and disagree (mildly) with Peter.
IMO it would be best if commands such as the ones discussed acted only upon selected text and did not default to the entire file if no selection is active. Mainly it is a “safety” concern, as was brought up. It really isn’t that hard to adapt to that behavior, after a few uses.
For myself, for the commands that always act on the entire file, I have a script that replaces their functionality, that acts only upon selected text.
-
Back to the original objection to this suggested change and the number of people that have intentionally run Blank Operations on the whole document: Elsewhere in the forum it has been explained that in older versions, a technique to reformat a section of code was to copy code to a new document, reformat and then copy and paste over the original section. I remember doing this in the past because selection in the old days did not work as I expected. Being the type that is reluctant to change the formatting of code unnecessarily, I don’t remember ever running Blank Operations on a whole document, and I have been using Notepad++ for over 10 years. I wonder if people that have used whole document blank operations intentionally did it because that was how they found the program worked, or because they thought it was the way it should work and that no caution built into the program was warranted.
@PeterJones, do you disagree that whole document blank operations that can easily affect code that is out of sight in a long document warrants some kind of caution built into the program? One of the things I like about the Replace dialog is that if you click Replace All, you get a highly visible status message in the bottom of the dialog showing the number of replacements. I consider that status message a caution. I could have suggested a pop-up dialog showing the number of lines affected by the whole document operation (Blank Operation), but that requires statistics gathered during the operation, of which I have seen no evidence. A popup dialog after the fact seems less consistent with the way the program works for other operations, and “Change Case to” is a precedent for selecting text before the operation rather than popping up a dialog after the fact. If the program already counts blank operations and lines changed, I would recommend that those stats be displayed in the status bar, if no dialog box is displayed and no selected text precaution is built into the program. What do you think?
-
My biggest objection is that Notepad++ users come out of the woodwork to complain loudly whenever a change is made that interrupts or drastically changes their workflow.
This happened when I finally lobbied successfully for Don to enable .bak files by default – for the same noble goal of protecting data – and even though it was as simple as a once-and-done preference setting to turn them back off, the Forum and GH Issues were almost immediately swamped with complaints about it, to the point that Don had to turn that back off in the next version.
And when Don made the call that the tab-right-click menu was getting too long, and moved the “move/clone to other view/new instance” commands from the main right-click to a submenu, there were a lot of complaints .
Maybe it really would be for the best for the Blank Operations and other such commands to not work on everything by default. Until your message, I don’t think I’d ever seen anyone complain about data loss or wasted time due to accidentally running a Blank-Operation on the whole document instead of the selection (and given the number of other data loss complaints over the years, that makes me think that it’s a rather more rare form of data loss or wasted time). But to some extent and due to the weight of historical behavior of the application, there will be a lot of psychological inertia in the long-term userbase to make the change from one command to two for every time they want to make that change across the whole file.
I will stop arguing against it. But, as a compromise to people like me who don’t want the added command before doing the Blank Operation, I think I might add a comment to the feature request that it would be a good idea if this protection be enabled by default, but have a preference setting (either in the GUI or one of the “hidden super-user controls”) that allows people to turn off the protection, if they feel confident in their ability to not be affected by this potential data loss/corruption.
-
I’m sort of in the habit of selecting all before sorting an entire file, as well, because (as I’ve talked about before) you can obtain an incorrect sort of the entire file if you don’t select-all first. I’m bringing this up because, after a few times of doing it, it isn’t hard for it to become rote.
-
Do any text editors have the concept of persistent selections? At present when you do an operation it removes the selection(s).
If persistent selections were available the person could set up one or more selections, declare that they are persistent, and to then do a series of operations on the selected text.
I have usually dealt with the issue in Notepad++ by copy/pasting a selection to a new tab, which leaves the selection in place, doing my series of operations in the new new, and cut/paste the results back, which overwrites the selection, and close the extra tab. I could use cut/paste in the first part but like to see the original text in place before I overwrite it with the results from the extra tab. I use cut/paste in the second part to clear out the extra tab meaning
Ctrl+Wsilently disposes of it.I use a graphics editor that uses persistent selections. I can set up rectangles, other shapes, or select via a variety of filters. Operations that normally affect the entire image only do their stuff within the selections, which remain in place. That editor has
Selectionsas one of its main menu items. The Selections menu drop down has Select All, Select None (which removes the selections), Invert (which reverses what is selected vs what is not. You set up a selection around something and Invert means the formerly selected area is protected from changes and operations affect everything else). The concept of invert seems like it would be useful in a text editor as a way to protect sections of text from changes. Though I have never used the feature the editor allows for saving selections to disk and then loading them. -
I have seen replies from at least two people (counting you) that object to requiring selected text for Blank Operations, and both expressed concern that the introduction would provoke a lot of complaints. Your last comment is the most helpful in understanding the short term cost of such a change and since I have heard from two active and involved users with experience and practice very different from mine, I am inclined to promote a less obtrusive mechanism that can be added without provoking so many complaints.
Given that the spirit of my request is “precaution against unintended whole document change” with Blank Operations, I think a dialog box with a descriptive warning, OK button, Cancel button and a checkbox associated with a stored setting would be sufficient, if not as consistent with NPP as making Blank Operations dependent on selected text like “Change Case to”. The dialog box would only be invoked if a Blank Operation is invoked without selected text. The checkbox would be to allow whole document change with no further prompts. So, people with an established practice of whole document Blank Operations could get back into the flow by checking the checkbox one time. I have not decided whether I think a second setting of “Require selected text for Blank Operations” should be added, with some way to set it as a default for all users during installation, but I think it should be considered. I can imagine a lead developer or IT department wanting to enforce the setting of “Require selected text for Blank Operations” on all computer where they install Notepad++. The trouble is, I feel like I am asking for something with double or triple the work if I ask for a stored setting and especially if I ask for a new popup dialog box.
I would think a new dialog box might be an opportunity to provide the user information about the somewhat recently added feature of Selected Text support in Blank Operations, but I can’t think of similar dialog boxes in Notepad++ that would be a precedent and more importantly, a template.
-
@Stefan-Ozminski There is a similar concept for search/replace. If you have 1024 or more characters selected at the time you bring up the search/replace dialog box then it silently enables
☑ In selection. The 1024 is configurable viaPreferences / Searching.I personally don’t like unusual pop-ups that then retain the choice. It interrupts the workflow as I then need to figure out what the box means and often it’s not clear at all if I can later change my mind and exactly how to do that. Later when I have time to research the consequences of my choice I often discover that it’s difficult to find where that particular configuration is buried.
I may be ok with a pop-up that also included a radio button of
- Don’t remember this choice.
- Save my choice for this Notepad++ session.
- Save my choice in Notepad++'s preferences.
About this choice (which links to the exact place in the npp manual)
The last part with the link is important to me as I’d then save the URL in my Notepad++ notes along with comments to myself about why I made the choice, etc. with minimum disruption to the workflow.
-
@mkupper Speaking of having settings in a new popup and in Settings -> Preferences, rather than have a new popup be the new precedent to add precaution for Blank Operations, I suspect it would be easier to have a new menu item type be the new precedent. All items in the Edit menu are currently verbs or actions that copy text, paste text, select text, find text or change text. New menu items in-line with the current Blank Operations menu items would be easier to find and much more visible. However, the new menu items I have in mind would set a precedent in that they would toggle a setting that does not fit in neatly in Settings -> Preferences. Currently, the Encoding menu and the Language menu have a radio button to show which item is currently selected, so showing a menu item in in a menu is not new for N++, but saved setting shown and changed in a menu would be a new precedent. I have attached an image showing a mock up of the menu additions.
If a new version of N++ rolls out with the new menu items, the default would be “Require Selected Text for Operation”, and if no text is selected in the document, the blank operation items above would be greyed out. When an established user navigates to Blank Operations and clicks on “Allow unselected operation”, the blank operation items above would be enabled, and the user would not need to navigate anywhere else (like Select All). Each time one of the settings is selected, the setting would be saved in the settings file and the radio button would move to the selected item. This Edit menu based precaution does not avoid creating a new saved setting in the settings file, but it does avoid creating a new popup dialog. The “Allow unselected” item is not named exactly the way I would like (Allow unselected whole document operation), but in a quick mock up, it was what I could fit in the space available. If the colors in the lower part of the menu are off, forgive me. I’m red-green color blind and quite bad at matching colors and rarely sure if the eyedropper is doing what I want. I was tempted to name the help item “Open new Blank Operations help page”, but eventually the Blank Operations behavior would not be new anymore. -
@Stefan-Ozminski Notepad++ already has some “settings” that are accessed via the menus and not Preferences.
View / Show SymbolsandView / Zoomare examples. Thus your idea has merit. -
@mkupper I’m relieved this request would not set a precedent by having menu items that modify/save settings in the configuration file. Given the menu items you pointed out as an example I think the most unusual thing needed to make this last approach work would be to leave the menu open when “Require selected text for operation” or “Allow operation without selected text” is clicked, which is a menu behavior that I think would be necessary to minimize the annoyance (to some established users) of making “Require selected text for operation” the default in a new version of N++. The main reason I suggest two menu items with a selection bullet (is there an established name for the selection symbol in the Encoding menu?) is that the “Allow operation without selected text” provides a place to put wording that spells out the alternative to “Require selected text for operation”. I still have not conceived of satisfactory wording for the “allow” setting that would fit in the menu. I would not be opposed to “Require selected text for operation” being the only menu item for the setting and having a Check Mark in front of it like View -> Show Symbols. If leaving the menu open interferes with having the upper blank operations become enabled or disabled, I wonder if it would be possible to allow the menu to close and then programmatically re-open it.
-
@Stefan-Ozminski said in Hazardous blank operations operate on whole file when no selected text, need to evolve safer approach:
think the most unusual thing needed to make this last approach work would be to leave the menu open when “Require selected text for operation” or “Allow operation without selected text” is clicked
Hmm, that is a good point and I’d need think about if it’s possible without a lot of code within Notepad++. One of the things Windows offers to all applications is the availability to define menus. The part where the user can pull down a menu, select sub-menus, etc. is handled by Windows. When a menu option is selected Windows closes the menu, parent menu, etc. and then tells the application that someone has selected a menu item and which one it was. Menus and sub-menus are handled as separate “windows” that are layered on top of the application.
It’s possible for applications to to define what they call window message handlers. Custom window message handlers for the menu “windows” are not very common meaning there will be few good examples to use, particularly for something unusual such as keeping a holding a menu open while flags get enabled/disabled.
