Hazardous blank operations operate on whole file when no selected text, need to evolve safer approach
-
-
@PeterJones I was wondering if anyone used the whole document blank operations much, and it seems that for some the answer is yes. However, to claim that everyone that used blank operations before v8.6.2 intentionally runs them on the whole document seems excessive. Behavior that defaults to reformatting the the whole document is the type of thing that causes the need for code versioning rather than preventing it. I’m having trouble imagining examples of indented code where you would want muscle memory to reformat the whole document. In particular, the operations “Trim Leading Space” and “Trim Leading and Trailing Space” and “Trim both and EOL to Space” would remove indentation for the whole document. Are there more cases where you want to remove indentation of code in the whole document than there are cases where you want to preserve indentation everywhere except the selected lines? Would you give some examples of using Blank Operations on the whole document that are so common they are muscle memory for you?
-
@Stefan-Ozminski said in Hazardous blank operations operate on whole file when no selected text, need to evolve safer approach:
However, to claim that everyone that used blank operations before v8.6.2 intentionally runs them on the whole document seems excessive
It was based on a mis-remembering. Since you said, “I see that in 8.6.2 the feature to run Blank Operations on selected text has been added,”, I made the (reasonable) conclusion (and my memory didn’t disagree, because I rarely want to do those conversions on anything less than the entire document) that before 8.6.2, they didn’t work on selected text – and if it didn’t work on selections at all, then obviously all users of the Blank operations before that feature existed would expect it to work on the whole document when nothing is selected, because that’s the only behavior it had ever evidenced before.
But now that I go back and check (with v8.5.8), they do work on selected text even before 8.6.2. So assuming that the old discussion you linked was right in that they didn’t work on selection in 8.1.9.3, then the feature was added since then. Checking the Change history, I see it was added in 8.4.9, so blank-ops-on-selection has been there for a year now.
This means that my statement was off in time a bit, so slightly reduces the number of people who are used to an unmodified version of that command working on the whole file. So I will ammend my statement to, “Anyone who used that feature before 8.4.9 – which includes me – has come to expect that Blank Operations will work on the whole file if nothing is selected.” And since I assume that a significant portion of the userbase of Notepad++ has been using Notepad++ for more than a year, any change to the default behavior of the feature would confuse/annoy that portion of the userbase.
Behavior that defaults to reformatting the the whole document is the type of thing that causes the need for code versioning rather than preventing it.
???
I was saying that version control would eliminate lost data, because if you’ve got good version control history, you can always go back to where you were, even when you’ve gone beyond the undo buffer for your current application. (Did you think I was saying that somehow version control would eliminate the need to do Blank Operations? That’s not what I intended to say.)
In particular, the operations “Trim Leading Space” and “Trim Leading and Trailing Space” and “Trim both and EOL to Space”
But those aren’t the only Blank Operations. And, in fact, the post you referened was talking about “Tab to Space”, so that’s the Blank Operation that was primarily in my mind for this conversation.
Would you give some examples of using Blank Operations on the whole document that are so common they are muscle memory for you?
Using the phrase “muscle memory” was an exaggeration to bring home the point. I don’t do it often enough that it’s truly muscle memory – but I do use it often enough that it would annoy me to have to do an extra command (select all) before doing it on the whole file. And honestly, even though it wasn’t for me, I am quite confident that there are people who use the Blank Operations more than I do, and would be to the level of muscle-memory (and probably even assigned a shortcut).
When I do trim spaces or convert leading tabs/spaces, it is for the whole file, the vast majority of the time. For example, when I open a source file copied from a colleague, and the colleague has the coding style of tab characters for indentation, one of the first things I do is convert tabs to spaces. It would be rather pointless to me in such a circumstance to convert tabs-to-spaces on only part of the file. And that’s not uncommon in my job.
-
Tabs to spaces or spaces to Tabs on code copied from a colleague is a very good example of where a Blank Operation would commonly be used on the whole document. It would probably be much safer to have those operations default to operating on the whole document, but I also imagine there are examples where performing that operation on the whole document would seriously damage the formatting of the data. In the case of Tabs to spaces, the muscle memory would be for Alt-E, Alt-B, down arrow five times, Enter? It does not seem likely. Visual memory for Edit -> Blank Operations -> TAB to Space seems much more likely. Visualizing the menu change I am suggesting, it seems like it would be more helpful to the user, if selected text is required, that the Blank Operations menu were dimmed (probably not disabled, because it would probably prevent disabled submenu items from showing) when no text is selected. Then the user is cued that selected text is required without opening the Blank Operations menu. I would like to see “Convert Case to” dimmed when no text is selected as an improvement made at the same time. Frankly, to prevent my mistakes (increasing with age), and those of my colleagues, I would rather retrain my menu operation memory and require Ctrl-A to select all than leave the default to modify the whole document.
@PeterJones said in Hazardous blank operations operate on whole file when no selected text, need to evolve safer approach:
I was saying that version control would eliminate lost data
Clearly this is another exaggeration. In particular, the scenario I imagine happening to many people more than once with the current default operation is that someone would accidentally reformat the whole document while focusing on a specific section of code not realizing what happened, and then make more modifications to that specific section of code, and test multiple times, and possibly to other sections of code where the formatting change would not be noticed (i.e. comments or help text), then when they try to revert back to code that is properly formatted, they lose the work they most recently did. And then one might argue that they did not properly modularize their code into separate files, and I counter with the point that it is only valid for certain languages.
Also in regard to version control, which I do not deny is a good thing to have, I bet it is used by a minority of NPP users, and especially not helpful to people that work on a variety of servers and workstations. Those are reasons I recommend a safer approach, even at the cost of pushing people to make their whole document TAB to Space operations more efficient by assigning a Shortcut (e.g. Alt + Ctrl + Shift + T) to Main Menu “TAB to Space” in Shortcut Mapper, and then train themselves to type Ctrl-A, Alt + Ctrl + Shift + T.
I have been conscientiously coding, and dealing with other people coding and document editing for over 35 years. I don’t make these suggestions and explanations without serious thought to the short and long term consequences and the type of work that must go into building changes into the NPP program. On the other hand, years of experience is not the same as methodically analyzing a large number of people making mistakes editing documents, So, I ask questions and don’t claim to know with certainty the best approach with the best balance between improvement and the cost of change. Consequently, I consider this forum and your feedback important to the process.
-
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.
