I am using XCE for hours every day, grabbing tabular material from the web and converting it to XML. So I've been using the Find, Replace, and Global Replace functions a lot.
When Global Replace completes, a panel opens at the bottom of the window and says something about how many replacements were made.
Sometimes, this panel is already open and so the new message appears.
But usually I'm eager for screen real estate, so I close that panel after each change.
I close it a lot.
Based on how much effort I'm expending, I request that this message instead be put in the status line, where the similar messages from Replace All appear.
* * *
I know that you really have two tools here. And I know that you'll integrate them better when you can. But apart from that . . .
Here's what I do:
I copy a string from my text into a text editor (TextPad). I construct a regex search string based on that string. Then I construct a regex replacement.
Then I copy the regex search string into the Replace panel's Find: box and the regex replacement string into the Replace with: box.
Then I click "Find Next"
Then I choose Edit | Global Replace and click on OK in the resulting dialog.
(The dialog disappears. The Information panel appears above the Replace panel with a message about the number of changes made. I close that panel.)
All these steps might seem counter-intuitive (why not just go straight to Global Replace?), but it's the most efficient process to follow **if I've made a mistake.**
If I build the regex in the Global Replace dialog, then it's absolutely gone after I click on OK. I have not only to reconstruct the regex I've also got to fix the mistake without knowing what it was. And whatever it was, I obviously built it thinking it was correct, so I have to figure out whether the mistake was in the regex logic or in the typing.
Occasionally I find that unexpected spaces have been inserted before tabs in the source material, causing the regex to fail. A quick search for "[space][tab]" to be replaced with "[tab]" fixes that, but of course it wipes out the 70-character regex I've just built. That's another reason I build the regex elsewhere, so I can re-copy it.
I make almost all my changes using Global Replace, because if I've made a mistake in the replacement regex, a single Undo gets me back to where I started. If I use Replace All, then I must undo each change individually. And that takes way to much time.
I use the Replace panel because I can keep it on-screen and go back and forth between the main text and the Find: and Replace with: text boxes. You can't do that with the Global Replace.
I click on Find Next whether it succeeds or not, because that puts the contents of the Replace panel's boxes into Global Replace. If I've made a simple error (sometimes I put a range, say from 0-3, and the actual range is 0-4) and not every line that should have changed actually does change, then I edit the string in the Find: box and change the other lines.
If I edit that line in Global Replace, it's not captured so I would have to make the change a second time if it turns out that I made two errors in that search regex.
* * *
I'd like to have a different font for the Find: and Replace with: boxes than I use anywhere else -- it's maybe the only place I like to see a monospaced font, so that I can click into the right spot in a regex. And when I say "different" I mean that I absolutely don't want all my dialog boxes in all my applications to use that font.
Maybe 10 or 20 percent of all my regexes are longer than one line, though I've seen many (and written a few) that were many lines long. I suppose as the ultimate, I'd like to be able to resize the dialog box so that I could see the entire regex no matter how long it is. Failing that, I think I'd like to get the Find: and Replace with: boxes on separate lines so they could be longer.
* * *
I've thought about the Find: and Replace with: histories. At times I think, "There should be a checkbox in the Global Replace dialog that asks if I want to save this string." And I would probably check it every single time -- before I search, I think the string is perfect so I would want to save it. I really only want to discard the unsuccessful search/replace operations. (So "keep this one and throw away the one before" is really what is needed, I suppose :-)
Hope these thoughts and the report of how I work is helpful to you. Thanks for the program. It's really become an essential tool for me.
Roger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much Roger, I will do my best to address these issues. At least one of them (strings not being remembered correctly from global replace dialog) is a must-fix asap bug!
I am also aware of another find-related bug that is now fixed in the source: F3 does not work as expected because it simply fires the find next event (as opposed to calling the find/replace panel's find next method, which is now necessary).
I will try to set the font in the find/replace edit boxes to Courier or similar. This should be straightforward I hope. Thanks for the tip!
You're also absolutely right about the message pane: it pops up much too often and I will in future use the status bar instead. It's a real shame Esc menu shortcuts are no longer supported by the framework (why on earth I cannot imagine - I've spent a lot of time trying to get around this, so far without success). Alt+C is very much an emergency choice.
Finally I also think it will be important to remember at least 10 find strings, replace strings, command strings (the command pane is nearing completion in the source), and so on.
The registry may not be the best place for this so I'll look into this more closely.
Thanks again for your help!
Best,
Gerald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ten is a round number, but I find that to be too few in TextPad's search string memory -- if I've fiddled with the string at all each time, then I really only have the last 5 searches, and I may well have more changes than that to make on each file I'm working with.
Without wanting you to go into ridiculous numbers, I urge you to make this larger. I would probably opt for 20*, just thinking about how far back I actually do want to go -- usually just a day or two.
Btw, I don't know if there's a font that's sort of halfway between being proportional- and mono-spaced -- one that would provide plenty of room around the periods, commas, parentheses and narrow letters, but not squash the "w" and "m". If there is one, that may be a better choice than Courier, if only because it would allow for more characters to be displayed than Courier would (if I recall correctly, proportional fonts allow for 40 percent more content than monospaced fonts in the same space).
Thanks,
Roger
* Even though Textpad has a clip facility, where I could save regexes, I don't use that. I think it would be as much work to look through all my unsorted past search and replace strings and figure out which one would be closest to the current action and then grab and modify it as it would be to start from scratch. If I really use such an operation over time, I end up making it into a macro.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's a good point. I really don't like arbitrary restrictions like 4, 10, etc (though restricted stacks make sense in some places). I'm all for the 0, 1, infinity rule. One way to handle this would be to store these strings separately (say, in the user's home directory). Then anyone could go in and manage them themselves. Who knows, I could use XML to hold the fields...
As for the size of the edit boxes, I need to look into a resizable dialog with multiline fields that _does_ remember strings that were rejected by the regex engine.
I will take a good look at this: I'm really sorry to be forcing you to take so many unnecessary steps right now!
My development time is squeezed quite badly right now, but I will try to get 1.0.9.3 out (with command pane and some improvements to find/replace) asap.
Best,
Gerald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please don't take my workaround list as a complaint! :-)
I'm very happy with the program and very optimistic about the future. You've done wonders and I don't regard these UI things to be bugs, but instead just artifacts of how things have developed. And given enough time and input, I expect they'll disappear as you keep refining things.
Roger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From TextPad's sometimes idiosyncratic search-and-replace, I'm not unaccustomed to beginning the operation with a CTRL-HOME, move the cursor to the top of the file action. Then after the operation, I'm at the top of the file.
So XCE's behavor isn't too problematic for me when it positions the cursor at the top of the file after a Global Replace.
However, without any bookmarks, this makes it harder to get back to the spot where I was working and to continue editing the file from that point.
Therefore, I would request changing the procedure so that the cursor is repositioned wherever it was when the Global Replace action was iniitiated (or to the beginning of the content of the parent element, or whatever nearby location makes the most sense).
This is what I've come to expect from other editors and seems to me to follow the principle of least surprise for a new user.
* * *
An additional issue here is when I am working with a largish file with, say, many branches off some level, which I've collapsed as I work through them. If I do a global replace, of course I expect all instances in the collapsed elements to be changed as well. But I'm not prepared for them to be unfolded, and I sometimes have a heckuva time finding where I was working because my visual cue of "the first unfolded element after a long string of folded elements" has disappeared.
Thanks. Hope these notes help you.
Roger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for this. This is a bug in my view: the program should attempt to find the previous spot in the file by remembering line and column (if replacements have affected the line this will be inaccurate, but the application should try).
Please do feel free to log issues like this as bugs: in that way, it's easier for me to prioritise the work as others waiting for bug fixes see I'm not ignoring their bugs :-)
(The same is true of the global replace that doesn't remember the string if the regex couldn't compile for example.)
Best,
Gerald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using XCE for hours every day, grabbing tabular material from the web and converting it to XML. So I've been using the Find, Replace, and Global Replace functions a lot.
When Global Replace completes, a panel opens at the bottom of the window and says something about how many replacements were made.
Sometimes, this panel is already open and so the new message appears.
But usually I'm eager for screen real estate, so I close that panel after each change.
I close it a lot.
Based on how much effort I'm expending, I request that this message instead be put in the status line, where the similar messages from Replace All appear.
* * *
I know that you really have two tools here. And I know that you'll integrate them better when you can. But apart from that . . .
Here's what I do:
I copy a string from my text into a text editor (TextPad). I construct a regex search string based on that string. Then I construct a regex replacement.
Then I copy the regex search string into the Replace panel's Find: box and the regex replacement string into the Replace with: box.
Then I click "Find Next"
Then I choose Edit | Global Replace and click on OK in the resulting dialog.
(The dialog disappears. The Information panel appears above the Replace panel with a message about the number of changes made. I close that panel.)
All these steps might seem counter-intuitive (why not just go straight to Global Replace?), but it's the most efficient process to follow **if I've made a mistake.**
If I build the regex in the Global Replace dialog, then it's absolutely gone after I click on OK. I have not only to reconstruct the regex I've also got to fix the mistake without knowing what it was. And whatever it was, I obviously built it thinking it was correct, so I have to figure out whether the mistake was in the regex logic or in the typing.
Occasionally I find that unexpected spaces have been inserted before tabs in the source material, causing the regex to fail. A quick search for "[space][tab]" to be replaced with "[tab]" fixes that, but of course it wipes out the 70-character regex I've just built. That's another reason I build the regex elsewhere, so I can re-copy it.
I make almost all my changes using Global Replace, because if I've made a mistake in the replacement regex, a single Undo gets me back to where I started. If I use Replace All, then I must undo each change individually. And that takes way to much time.
I use the Replace panel because I can keep it on-screen and go back and forth between the main text and the Find: and Replace with: text boxes. You can't do that with the Global Replace.
I click on Find Next whether it succeeds or not, because that puts the contents of the Replace panel's boxes into Global Replace. If I've made a simple error (sometimes I put a range, say from 0-3, and the actual range is 0-4) and not every line that should have changed actually does change, then I edit the string in the Find: box and change the other lines.
If I edit that line in Global Replace, it's not captured so I would have to make the change a second time if it turns out that I made two errors in that search regex.
* * *
I'd like to have a different font for the Find: and Replace with: boxes than I use anywhere else -- it's maybe the only place I like to see a monospaced font, so that I can click into the right spot in a regex. And when I say "different" I mean that I absolutely don't want all my dialog boxes in all my applications to use that font.
Maybe 10 or 20 percent of all my regexes are longer than one line, though I've seen many (and written a few) that were many lines long. I suppose as the ultimate, I'd like to be able to resize the dialog box so that I could see the entire regex no matter how long it is. Failing that, I think I'd like to get the Find: and Replace with: boxes on separate lines so they could be longer.
* * *
I've thought about the Find: and Replace with: histories. At times I think, "There should be a checkbox in the Global Replace dialog that asks if I want to save this string." And I would probably check it every single time -- before I search, I think the string is perfect so I would want to save it. I really only want to discard the unsuccessful search/replace operations. (So "keep this one and throw away the one before" is really what is needed, I suppose :-)
Hope these thoughts and the report of how I work is helpful to you. Thanks for the program. It's really become an essential tool for me.
Roger
Thank you very much Roger, I will do my best to address these issues. At least one of them (strings not being remembered correctly from global replace dialog) is a must-fix asap bug!
I am also aware of another find-related bug that is now fixed in the source: F3 does not work as expected because it simply fires the find next event (as opposed to calling the find/replace panel's find next method, which is now necessary).
I will try to set the font in the find/replace edit boxes to Courier or similar. This should be straightforward I hope. Thanks for the tip!
You're also absolutely right about the message pane: it pops up much too often and I will in future use the status bar instead. It's a real shame Esc menu shortcuts are no longer supported by the framework (why on earth I cannot imagine - I've spent a lot of time trying to get around this, so far without success). Alt+C is very much an emergency choice.
Finally I also think it will be important to remember at least 10 find strings, replace strings, command strings (the command pane is nearing completion in the source), and so on.
The registry may not be the best place for this so I'll look into this more closely.
Thanks again for your help!
Best,
Gerald
Ten is a round number, but I find that to be too few in TextPad's search string memory -- if I've fiddled with the string at all each time, then I really only have the last 5 searches, and I may well have more changes than that to make on each file I'm working with.
Without wanting you to go into ridiculous numbers, I urge you to make this larger. I would probably opt for 20*, just thinking about how far back I actually do want to go -- usually just a day or two.
Btw, I don't know if there's a font that's sort of halfway between being proportional- and mono-spaced -- one that would provide plenty of room around the periods, commas, parentheses and narrow letters, but not squash the "w" and "m". If there is one, that may be a better choice than Courier, if only because it would allow for more characters to be displayed than Courier would (if I recall correctly, proportional fonts allow for 40 percent more content than monospaced fonts in the same space).
Thanks,
Roger
* Even though Textpad has a clip facility, where I could save regexes, I don't use that. I think it would be as much work to look through all my unsorted past search and replace strings and figure out which one would be closest to the current action and then grab and modify it as it would be to start from scratch. If I really use such an operation over time, I end up making it into a macro.
That's a good point. I really don't like arbitrary restrictions like 4, 10, etc (though restricted stacks make sense in some places). I'm all for the 0, 1, infinity rule. One way to handle this would be to store these strings separately (say, in the user's home directory). Then anyone could go in and manage them themselves. Who knows, I could use XML to hold the fields...
As for the size of the edit boxes, I need to look into a resizable dialog with multiline fields that _does_ remember strings that were rejected by the regex engine.
I will take a good look at this: I'm really sorry to be forcing you to take so many unnecessary steps right now!
My development time is squeezed quite badly right now, but I will try to get 1.0.9.3 out (with command pane and some improvements to find/replace) asap.
Best,
Gerald
Please don't take my workaround list as a complaint! :-)
I'm very happy with the program and very optimistic about the future. You've done wonders and I don't regard these UI things to be bugs, but instead just artifacts of how things have developed. And given enough time and input, I expect they'll disappear as you keep refining things.
Roger
From TextPad's sometimes idiosyncratic search-and-replace, I'm not unaccustomed to beginning the operation with a CTRL-HOME, move the cursor to the top of the file action. Then after the operation, I'm at the top of the file.
So XCE's behavor isn't too problematic for me when it positions the cursor at the top of the file after a Global Replace.
However, without any bookmarks, this makes it harder to get back to the spot where I was working and to continue editing the file from that point.
Therefore, I would request changing the procedure so that the cursor is repositioned wherever it was when the Global Replace action was iniitiated (or to the beginning of the content of the parent element, or whatever nearby location makes the most sense).
This is what I've come to expect from other editors and seems to me to follow the principle of least surprise for a new user.
* * *
An additional issue here is when I am working with a largish file with, say, many branches off some level, which I've collapsed as I work through them. If I do a global replace, of course I expect all instances in the collapsed elements to be changed as well. But I'm not prepared for them to be unfolded, and I sometimes have a heckuva time finding where I was working because my visual cue of "the first unfolded element after a long string of folded elements" has disappeared.
Thanks. Hope these notes help you.
Roger
Thanks for this. This is a bug in my view: the program should attempt to find the previous spot in the file by remembering line and column (if replacements have affected the line this will be inaccurate, but the application should try).
Please do feel free to log issues like this as bugs: in that way, it's easier for me to prioritise the work as others waiting for bug fixes see I'm not ignoring their bugs :-)
(The same is true of the global replace that doesn't remember the string if the regex couldn't compile for example.)
Best,
Gerald
This is partially fixed as of 1.0.9.3 (Windows version out today) - apologies for the areas that aren't done yet.
Best,
Gerald