Karmaflute
Member
I use another editor which has a great feature where it will populate the find box with your current selection. So I can, for example, copy what I want to replace with, Ctr-F, paste the replacement text, and I'm good to go.
It would also be nice if you condense both the Find and Replace dialogs. A convenient checkbox next to the replace edit box would be sufficient. The options between Find and Replace are nearly identical.
simon
PN Developer
Hi, I'm not sure which version you're using but PN should already automatically populate the find text. There are a few cases where it doesn't:
The find and replace dialog box are already the same dialog, the mode just switches which controls you have to contend with.
Karmaflute
Member
Yes, in this case it was the whole line (I was replacing comment blocks that were too short with longer ones). Is there a reason this isn't allowed?
Also, the benefit of having the Find/Replace portions of the dialog merged is that it will require only one hotkey (Ctrl-F in my case) to bring up the dialog for either find or replace. I think it would be convenient to merge the two with a simple checkbox next to the replace field to toggle it on/off.
Using the Find hotkey would of course have this checkbox off by default.
This solution requires less mouse clicking and one less hotkey for a common repetitive task.
jumpfroggy
Member
Hey Karma. I prefer the current behavior over a method that would auto-fill the find box when you have a line (or lines) selected. Most of the time when I select a few lines and hit replace, I'm really wanting to replace within that selection. In that case, auto-filling the box is the wrong thing to do. I realize that it may be different for you, I only know for myself that it works better that way most of the time (say 90% for me).
I'm mulling over the merged find & replace dialogs. Right now they're not too different, so I could see the replace dialog being the only one. However, I would never want a checkbox to enable/disable the replace features of the dialog. Right now you can hit one hotkey for the find window, another hotkey for the replace; that's simple & quick. If you had a checkbox, now you have a to hit a hotkey, see if it's checked or not, then hit another hotkey for the checkbox (or click w/ mouse), then hit another hotkey or click to focus on the field to type in your phrase. It would cause a lot of work, and you could just leave the replace features enabled all the time.
But I'm also confused by the way you suggest merging the dialogs. So you only have one dialog with a checkbox to enable/disable the replace features. You still have two hotkeys, one that shows the dialog with the replace features enabled by default, another where they're disabled. How is this any different from right now with two dialgs & two hotkeys? I'm just curious.
Karmaflute
Member
If Find and Replace were merged then I would only need one hotkey to bring up the window. Yes, it's one click to go to Replace and one click to uncheck the checkbox for my idea, but the two search methods are nearly identical. Just merge them instead of making another tab. Find and Replace are virtually the same features.
jumpfroggy
Member
It's true that the find and replace windows are very similar. I could conceivably see combining them. But to rely on a checkbox is not great. If the two dialogs can be merged into one, what's the point of having a checkbox at all? Just ignore the second box, and ignore the other buttons. Have an enable/disable checkbox would be redundant, and a mouse click is more expensive (UI-wise) than a keyboard shortcut.
I am curious what a merged dialog would look like, and if there'd be any changes.
simon
PN Developer
Another option would be to have a Find Next button that just does find next, and a replace button that does replace. All of the controls would then always be visible, and depending on what you clicked you would find or replace.
The complications are that there are some options that are only applicable for replace, and these clutter and confuse the interface in the case of find.
Karmaflute
Member
You could just disable or hide the additional options. I just think it's superfluous to have two sections for what are virtually the same thing.
Would it be possible to at least alter the behavior for find/replace fill the find box when a whole line is selected? This feature has failed for me several times because of this inconsistency.
Thanks.
jumpfroggy
Member
> Without an enable/disable checkbox how can you replace a block of text with "nothing"?
Just leave the "Replace With" blank? That's how I usually do it. Shouldn't need an enable/disable box for this.
> Another option would be to have a Find Next button that just does find next, and a replace button that does replace. All of the controls would then always be visible, and depending on what you clicked you would find or replace.
Essentially, you could just use the Replace dialog as is since it contains all this already.
> The complications are that there are some options that are only applicable for replace, and these clutter and confuse the interface in the case of find.
I looked at both dialogs, the only things I can tell that changes is the "Search within" options. For the find dialog, you have "Current Document" and "All open documents". For the replace dialog, you have "Current Document" and "In Selection". I'm not sure when "Current Project" is enabled, don't use those.
But another thing here is that those options are always visible, just sometimes disabled. So there's no less "clutter". I think PN may be able to be smart enough to deal with strange requests, like a "find next" with "in selection" (just find the next match within the current selection? Or ignore the selection and just do a "current document"?
I think it's worth combining, they're almost completely visually identical. Plus the thing that convinced me is that OpenOffice does this already... hit Control+F and a Find & Replace dialog comes up. I think as long as we have the keyboard accelerators for the "Find next" and "Replace" (all) buttons, there's no downside to combining them. It's not a huge deal if it stays separate, but it would just be a little less redundant.
> Would it be possible to at least alter the behavior for find/replace fill the find box when a whole line is selected? This feature has failed for me several times because of this inconsistency.
I'm not sure how this would change. Right now it's: if one or less lines are selected, auto-fill it in the box. If nothing is selected, auto-fill the current word. If more than one line is selected, use that as the "Within Selection" option and use whatever the last "Find what" value was. I don't think we want to auto-fill multiple lines (since that's really a regex thing, and would be confusing to have it be auto-filled), and it's definitely helpful when selecting a piece of the current document. Is there another way this could be fixed?
I'd rather change the current behavior so that it auto-fills if you've selected, but does *not* auto fill if nothing is selected. That always throws me off. I hate hitting control+f and getting auto-filled whatever word the cursor happens to be on.
Karmaflute
Member
Quote >> 'jumpfroggy' : "I'd rather change the current behavior so that it auto-fills if you've selected, but does *not* auto fill if nothing is selected. That always throws me off. I hate hitting control+f and getting auto-filled whatever word the cursor happens to be on."
Having the find/replace box remember the last action is a luxury. The fact that it's automatically highlighted makes it each to just type something new and have it replace the contents. What advantage would it be other than aesthetics to have it be blank by default if nothing is selected?
jumpfroggy
Member
>> Quote >> 'jumpfroggy' : "I'd rather change the current behavior so that it auto-fills if you've selected, but does *not* auto fill if nothing is selected. That always throws me off. I hate hitting control+f and getting auto-filled whatever word the cursor happens to be on."
> Having the find/replace box remember the last action is a luxury. The fact that it's automatically highlighted makes it each to just type something new and have it replace the contents. What advantage would it be other than aesthetics to have it be blank by default if nothing is selected?
I was unclear before:
-if nothing is selected, simply show the last-used search phrase
-if <=1 line is selected, use the selected text as the search phrase
-if >1 lines are selected, show the last-used search phrase and check "in selection"
The only difference is #1... right now if nothing is selected, it auto-fills whatever word is under the cursor. I think it would be more useful if it simply left the last-used search phrase in place for this case.
jumpfroggy
Member
@Nux
I agree that it works in those cases (when the cursor is not on text), but what I was proposing is that PN should never replace your "search for" text unless you've got something highlighted. It's too tricky to remember that you may or may not have to reposition the cursor before you hit Control+F. It's a very subtle quirk, but one that I feel would be better if it were changed.
jumpfroggy
Member
I guess this comes down to preference. In the current system, you can easily put the cursor on a word, hit find, and get the current word already filled out. However, the downside is that if you previously searched for a word and want to search again, hitting find will often replace the previous word and you have to make sure you manually select your previous search.
In my suggestion, you'd have to double click on a word (or select it with keyboard) then hit find to do a "quick" search. The downside is that it's an extra click or few key presses for the quick search. The upside is that when you hit control+F without selecting something, you always know that you're going to have the previous search filled out.
I'm all about saving keystrokes (believe me), so normally I'd go with the current operation. However, I've run into a lot of situations where the unpredictability of the current mode removes any convenience it might hold. I realize this is a personal preference, and probably something that should be polled before any change is considered.
Polls polls polls! (Sorry simon, had to :)). Thanks for the feedback Nux.
PS. What did this mean? "Plus you can use upper search functions." Thanks.
PS. What did this mean? "Plus you can use upper search functions." Thanks.
I meant the search toolbar. I'm not sure if it's on by default, as I don't remember when did I last install PN from scratch ;-).
I could live through "select word with a keyboard", but not with a mouse click. Having said that - someone suggested that if he selects text he wants to search in selected text... So, probably polls it is ;-).
jumpfroggy
Member
Yeah. Things like this make me wish for a firefox-like "about:config", for all those little prefs that don't warrant a real checkbox in teh options, but would still be nice to have. Options like this are so tiny (a one line IF THEN change), so it wouldn't contribute to code bloat, but are so nit-picky and specific that it'd be hard to even name the pref. For later, I guess.
simon
PN Developer
Yeah. Things like this make me wish for a firefox-like "about:config", for all those little prefs that don't warrant a real checkbox in teh options
Yeah, me too :)
In all seriousness, I would like to do something like this so that people can tweak where necessary and the interface can remain simple. This ties in with discussions on the mailing list where I've been experimenting with options storage, err, options.
I'd like to be able to do this:
jumpfroggy
Member
This could tie into the other discussion about storing items in XML vs. JSON vs. the registry. It could be a new section in the Options, "Advanced" where it would just be a list of settings and a generic way to change their values. That way it would be storage-agnostic (don't care if it's xml/json/ini/etc). It'd be nice if it had a little substring search box at the top, but that wouldn't even be necessary at first since there wouldn't be may options to start.
You must log in to post.
