This is something that's been bothering me for a while; I'd like to hear what others think.
In the Replace dialog, the "Replace All" section has a checkbox ("Close dialog"), and three buttons that control the scope of the search:
[In Selection] [In Session] [In Document]
"Selection" and "Document" are self-explanatory; "Session" replaces text in all currently-open files.
Why are the buttons in this order? Intuitively, I would expect them to be ordered in terms of increasing scope: selection, document, session. I don't see why the current order would be preferable---I've never even used the "In Session" button in actual work.
--Daniel
On Sun, 11 Jan 2009 02:51:27 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
This is something that's been bothering me for a while; I'd like to hear what others think.
In the Replace dialog, the "Replace All" section has a checkbox ("Close dialog"), and three buttons that control the scope of the search:
[In Selection] [In Session] [In Document]
"Selection" and "Document" are self-explanatory; "Session" replaces text in all currently-open files.
Why are the buttons in this order? Intuitively, I would expect them to be ordered in terms of increasing scope: selection, document, session. I don't see why the current order would be preferable---I've never even used the "In Session" button in actual work.
Good catch. I agree it should be in the order selection, document and then session. I don't remember when these buttons were added. In case I did so, I probably just didn' think about and just added them. In case of it was Nick, maybe he had a reason.
If there was no reason, I think we should change it as suggested by Daniel.
Regards, Enrico
On Sun, 11 Jan 2009 18:50:36 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
[In Selection] [In Session] [In Document]
"Selection" and "Document" are self-explanatory; "Session" replaces text in all currently-open files.
Why are the buttons in this order? Intuitively, I would expect them to be ordered in terms of increasing scope: selection, document, session. I don't see why the current order would be preferable---I've never even used the "In Session" button in actual work.
I did it like that because the Gnome HIG says the most commonly-used button should be on the right, and I assumed it was the document button. Then it seemed logical to put the session button near the document button.
Anyway, the selection button can also be used often, so we could change the order to:
[Session] [Document] [Selection]
This also makes sense in making the function with the biggest impact away from the commonly used position.
Good catch. I agree it should be in the order selection, document and then session. I don't remember when these buttons were added. In case I did so, I probably just didn' think about and just added them. In case of it was Nick, maybe he had a reason.
Regards, Nick
On Fri, 2009 Jan 16 17:04:36 +0000, Nick Treleaven wrote:
I did it like that because the Gnome HIG says the most commonly-used button should be on the right, and I assumed it was the document button. Then it seemed logical to put the session button near the document button.
But don't forget, the buttons appear only after you click the "Replace All" arrow, at the left edge of the dialog. Consider the distance that you need to move the mouse afterward to reach each button---shouldn't the more common case(s) require a shorter distance?
I see where you're coming from on the Gnome HIG, and that is a reasonable approach. But the "Replace All" arrow confounds the logic of that, IMO. If the most commonly used button is to be on the right, then I would suggest removing the arrow, and keeping that section of the dialog always visible, so that there is no need for the pointer to visit the left edge. (This would also make the dialog require one less click, and score UI brownie points by removing a modal element.)
Anyway, the selection button can also be used often, so we could change the order to:
[Session] [Document] [Selection]
This also makes sense in making the function with the biggest impact away from the commonly used position.
Aye, as well as having them in a sorted order. And for my part, replace-in-selection is a much more common operation than replace-in-document. When I'm editing a large source file, the latter tends to be a big/scary/rare deal; more typically I'll, say, rename a variable in a function with the former.
--Daniel
Daniel Richard G. schrieb:
But don't forget, the buttons appear only after you click the "Replace All" arrow, at the left edge of the dialog.
Something I never understood why...
Consider the distance that you need to move the mouse afterward to reach each button---shouldn't the more common case(s) require a shorter distance?
I see where you're coming from on the Gnome HIG, and that is a reasonable approach. But the "Replace All" arrow confounds the logic of that, IMO. If the most commonly used button is to be on the right, then I would suggest removing the arrow, and keeping that section of the dialog always visible, so that there is no need for the pointer to visit the left edge. (This would also make the dialog require one less click, and score UI brownie points by removing a modal element.)
I agree!
I think the arrow should be removed, I would however prefer that the scope of 'replace-all' be a persistent radio-button, and that there be only one button for replace-all -- that seems to be the way most software does it. Since that's a big change, though,just removing the show/hide arrow would be good -- I don't see what purpose it serves... /ˈmɪstər/ /ˈdʒɛnəsɪs/@/dʒi/ /meɪl/ /dɒt/ /kɒm/ Benjamin West
On Fri, Jan 16, 2009 at 10:58 AM, Daniel Richard G. skunk@iskunk.orgwrote:
On Fri, 2009 Jan 16 17:04:36 +0000, Nick Treleaven wrote:
I did it like that because the Gnome HIG says the most commonly-used button should be on the right, and I assumed it was the document button. Then it seemed logical to put the session button near the document button.
But don't forget, the buttons appear only after you click the "Replace All" arrow, at the left edge of the dialog. Consider the distance that you need to move the mouse afterward to reach each button---shouldn't the more common case(s) require a shorter distance?
I see where you're coming from on the Gnome HIG, and that is a reasonable approach. But the "Replace All" arrow confounds the logic of that, IMO. If the most commonly used button is to be on the right, then I would suggest removing the arrow, and keeping that section of the dialog always visible, so that there is no need for the pointer to visit the left edge. (This would also make the dialog require one less click, and score UI brownie points by removing a modal element.)
Anyway, the selection button can also be used often, so we could change the order to:
[Session] [Document] [Selection]
This also makes sense in making the function with the biggest impact away from the commonly used position.
Aye, as well as having them in a sorted order. And for my part, replace-in-selection is a much more common operation than replace-in-document. When I'm editing a large source file, the latter tends to be a big/scary/rare deal; more typically I'll, say, rename a variable in a function with the former.
--Daniel
-- NAME = Daniel Richard G. ## Remember, skunks _|/_ meef? EMAIL1 = skunk@iskunk.org ## don't smell bad--- (/o|o) / EMAIL2 = skunk@alum.mit.edu ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Ben West wrote:
I think the arrow should be removed,
<AOL>ME TOO!</AOL>
I would however prefer that the scope of 'replace-all' be a persistent radio-button, and that there be only one button for replace-all -- that seems to be the way most software does it.
No thanks. I'm constantly shifting between replace all in doc and replace in selection. I prefer having separate buttons, and it annoys me to have to unhide the buttons constantly (i.e. whenever I start Geany again).
On Sat, 2009 Jan 17 09:17:59 +1100, Ross McKay wrote:
I would however prefer that the scope of 'replace-all' be a persistent radio-button, and that there be only one button for replace-all -- that seems to be the way most software does it.
No thanks. I'm constantly shifting between replace all in doc and replace in selection. I prefer having separate buttons, and it annoys me to have to unhide the buttons constantly (i.e. whenever I start Geany again).
Agreed there. I would add that a radio-button selector interface would require more than one click or keystroke on average (sometimes one, sometimes two).
--Daniel
On Fri, 16 Jan 2009 12:58:10 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
On Fri, 2009 Jan 16 17:04:36 +0000, Nick Treleaven wrote:
I did it like that because the Gnome HIG says the most commonly-used button should be on the right, and I assumed it was the document button. Then it seemed logical to put the session button near the document button.
But don't forget, the buttons appear only after you click the "Replace All" arrow, at the left edge of the dialog. Consider the distance that you need to move the mouse afterward to reach each button---shouldn't the more common case(s) require a shorter distance?
I see where you're coming from on the Gnome HIG, and that is a reasonable approach. But the "Replace All" arrow confounds the logic of that, IMO. If the most commonly used button is to be on the right, then I would suggest removing the arrow, and keeping that section of the dialog always visible, so that there is no need for the pointer to
Wow, taking the other (rather quick appearing) replies in the thread into account, it seems this expander (technical term for the arrow as it expands a hidden area) is pretty unpopular. IIRC the intention in adding it was to not fear the user with a too complicated and too heavy loaded dialog, so hide by default less commonly options with the expander. But I'm not completely sure if it was this way, it's a long time ago :).
Anyway, the selection button can also be used often, so we could change the order to:
[Session] [Document] [Selection]
This also makes sense in making the function with the biggest impact away from the commonly used position.
Aye, as well as having them in a sorted order. And for my part,
Yup, sounds fine to me.
Regards, Enrico
On Sat, 17 Jan 2009 13:02:58 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 16 Jan 2009 12:58:10 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
On Fri, 2009 Jan 16 17:04:36 +0000, Nick Treleaven wrote:
I did it like that because the Gnome HIG says the most commonly-used button should be on the right, and I assumed it was the document button. Then it seemed logical to put the session button near the document button.
But don't forget, the buttons appear only after you click the "Replace All" arrow, at the left edge of the dialog. Consider the distance that
Actually you can click anywhere on the expander line.
you need to move the mouse afterward to reach each button---shouldn't the more common case(s) require a shorter distance?
After the first time, it stays open. Button order should be consistent everywhere.
I see where you're coming from on the Gnome HIG, and that is a reasonable approach. But the "Replace All" arrow confounds the logic of that, IMO. If the most commonly used button is to be on the right, then I would suggest removing the arrow, and keeping that section of the dialog always visible, so that there is no need for the pointer to
Wow, taking the other (rather quick appearing) replies in the thread into account, it seems this expander (technical term for the arrow as it expands a hidden area) is pretty unpopular. IIRC the intention in adding it was to not fear the user with a too complicated and too heavy loaded dialog, so hide by default less commonly options with the expander. But I'm not completely sure if it was this way, it's a long time ago :).
I could make Geany remember whether the expander is open when quitting.
Regards, Nick
On Mon, 19 Jan 2009 12:41:56 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
I see where you're coming from on the Gnome HIG, and that is a reasonable approach. But the "Replace All" arrow confounds the logic of that, IMO. If the most commonly used button is to be on the right, then I would suggest removing the arrow, and keeping that section of the dialog always visible, so that there is no need for the pointer to
Wow, taking the other (rather quick appearing) replies in the thread into account, it seems this expander (technical term for the arrow as it expands a hidden area) is pretty unpopular. IIRC the intention in adding it was to not fear the user with a too complicated and too heavy loaded dialog, so hide by default less commonly options with the expander. But I'm not completely sure if it was this way, it's a long time ago :).
I could make Geany remember whether the expander is open when quitting.
That would be the alternative to the suggested frame replacement for the expander with the bonus that by default the expander would be closed and so the dialog be a bit less height (remember Netbook users).
Regards, Enrico
On Mon, 2009 Jan 19 18:22:42 +0100, Enrico Tröger wrote:
I could make Geany remember whether the expander is open when quitting.
That would be the alternative to the suggested frame replacement for the expander with the bonus that by default the expander would be closed and so the dialog be a bit less height (remember Netbook users).
But the dialog doesn't grow in height when the arrow is opened---the widgets just get squeezed a little tighter vertically.
A persistent arrow could work, too, but... isn't that making things more complicated than they need to be? It simplifies the dialog visually when the user doesn't want to see the replace-all functionality, but then you still have that element of UI modality, and now a new config variable to keep track of it. Not to mention, the opened arrow/label doesn't associate itself with the buttons very well if the act of having opened it is not in recent memory. (In other words, if you see the dialog for the first time with the arrow already opened, the arrow label doesn't do a good job of actually labeling the set of buttons.)
--Daniel
On Mon, 19 Jan 2009 14:06:50 -0500 "Daniel Richard G." skunk@iSKUNK.ORG wrote:
I could make Geany remember whether the expander is open when quitting.
That would be the alternative to the suggested frame replacement for the expander with the bonus that by default the expander would be closed and so the dialog be a bit less height (remember Netbook users).
But the dialog doesn't grow in height when the arrow is opened---the widgets just get squeezed a little tighter vertically.
It does the first time.
A persistent arrow could work, too, but... isn't that making things more complicated than they need to be? It simplifies the dialog visually when the user doesn't want to see the replace-all functionality, but then you still have that element of UI modality, and now a new config variable to
Not sure why that's a problem (maybe my ignorance though ;-))
keep track of it. Not to mention, the opened arrow/label doesn't associate itself with the buttons very well if the act of having opened it is not in recent memory. (In other words, if you see the dialog for the first time with the arrow already opened, the arrow label doesn't do a good job of actually labeling the set of buttons.)
We could add a 'Replace all in:' label as well, maybe change the close dialog option to work for all buttons, not just replace all.
I don't mind if we remove the expander.
Regards, Nick
On Tue, 2009 Jan 20 12:44:52 +0000, Nick Treleaven wrote:
But the dialog doesn't grow in height when the arrow is opened---the widgets just get squeezed a little tighter vertically.
It does the first time.
Okay, I see what you mean. Still, it's only by a little bit....
A persistent arrow could work, too, but... isn't that making things more complicated than they need to be? It simplifies the dialog visually when the user doesn't want to see the replace-all functionality, but then you still have that element of UI modality, and now a new config variable to
Not sure why that's a problem (maybe my ignorance though ;-))
Just that, as the buttons are not a fixed part of the dialog, you can't always count on them being there, ready to click---not without the extra overhead of expanding the arrow. It's a small nicety to know that this dialog, that gets used so often and so rapidly at times, will always take the same form.
keep track of it. Not to mention, the opened arrow/label doesn't associate itself with the buttons very well if the act of having opened it is not in recent memory. (In other words, if you see the dialog for the first time with the arrow already opened, the arrow label doesn't do a good job of actually labeling the set of buttons.)
We could add a 'Replace all in:' label as well, maybe change the close dialog option to work for all buttons, not just replace all.
But that would change the basic behavior of the dialog, where it stays around until explicitly told otherwise (via the Close button or the checkbox). The Find dialog behaves this way, too, so there would be a consistency issue.
I think the checkbox and overall behavior are fine. As I mentioned before, NEdit does things the other way around, and I can recall feeling much more annoyance when the NEdit dialog goes away after one operation when I wanted several, than when the Geany dialog persists when I want only one op.
Ideally, I'd like to keep the checkbox/behavior, and gain the "Replace all in:" labeling convention---if there were a way to combine them without awkwardness.
I don't mind if we remove the expander.
I'm all for that ^_^
--Daniel
Daniel Richard G. wrote:
I think the checkbox and overall behavior are fine. As I mentioned before, NEdit does things the other way around, and I can recall feeling much more annoyance when the NEdit dialog goes away after one operation when I wanted several, than when the Geany dialog persists when I want only one op.
The point of closing the dialog after the first operation is to do every subsequent one using hotkeys.
I, for one, have set the search dialog to autoclose. After the first hit, I search further using ctrl+g, without that dialog blocking my view on the text.
On Wed, 21 Jan 2009 18:12:36 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
On Tue, 2009 Jan 20 12:44:52 +0000, Nick Treleaven wrote:
But the dialog doesn't grow in height when the arrow is opened---the widgets just get squeezed a little tighter vertically.
It does the first time.
Okay, I see what you mean. Still, it's only by a little bit....
A persistent arrow could work, too, but... isn't that making things more complicated than they need to be? It simplifies the dialog visually when the user doesn't want to see the replace-all functionality, but then you still have that element of UI modality, and now a new config variable to
Not sure why that's a problem (maybe my ignorance though ;-))
Just that, as the buttons are not a fixed part of the dialog, you can't always count on them being there, ready to click---not without the extra overhead of expanding the arrow. It's a small nicety to know
With Nick's suggestion to make the arrow state persistent, you only have to open the expander once, then it will 'stay' open as long as you won't delete your config.
keep track of it. Not to mention, the opened arrow/label doesn't associate itself with the buttons very well if the act of having opened it is not in recent memory. (In other words, if you see the dialog for the first time with the arrow already opened, the arrow label doesn't do a good job of actually labeling the set of buttons.)
We could add a 'Replace all in:' label as well, maybe change the close dialog option to work for all buttons, not just replace all.
But that would change the basic behavior of the dialog, where it stays around until explicitly told otherwise (via the Close button or the checkbox). The Find dialog behaves this way, too, so there would be a consistency issue.
Yes, I also wouldn't like to change the close dialog option. It's pretty fine as it is, IMO.
I don't mind if we remove the expander.
I'm all for that ^_^
Is a persistent expander really that bad? It would be pretty much like without it, you still see it but once opened (and not closed again) it will always be open, so it's more or less the same as when the expander was a frame. Plus we have the benefit that users who really don't want to see/use the replace all options, simply won't see it and so have a smaller dialog (as I mentioned before, there are Netbook users out there :D).
Just for the records: the original topic, the button order, has been changed by Nick today.
Regards, Enrico
Assuming we don't get rid of it entirely could we make the close option persistent as well?
On Fri, Jan 23, 2009 at 8:00 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 21 Jan 2009 18:12:36 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
On Tue, 2009 Jan 20 12:44:52 +0000, Nick Treleaven wrote:
But the dialog doesn't grow in height when the arrow is opened---the widgets just get squeezed a little tighter vertically.
It does the first time.
Okay, I see what you mean. Still, it's only by a little bit....
A persistent arrow could work, too, but... isn't that making things more complicated than they need to be? It simplifies the dialog visually when the user doesn't want to see the replace-all functionality, but then you still have that element of UI modality, and now a new config variable to
Not sure why that's a problem (maybe my ignorance though ;-))
Just that, as the buttons are not a fixed part of the dialog, you can't always count on them being there, ready to click---not without the extra overhead of expanding the arrow. It's a small nicety to know
With Nick's suggestion to make the arrow state persistent, you only have to open the expander once, then it will 'stay' open as long as you won't delete your config.
keep track of it. Not to mention, the opened arrow/label doesn't associate itself with the buttons very well if the act of having opened it is not in recent memory. (In other words, if you see the dialog for the first time with the arrow already opened, the arrow label doesn't do a good job of actually labeling the set of buttons.)
We could add a 'Replace all in:' label as well, maybe change the close dialog option to work for all buttons, not just replace all.
But that would change the basic behavior of the dialog, where it stays around until explicitly told otherwise (via the Close button or the checkbox). The Find dialog behaves this way, too, so there would be a consistency issue.
Yes, I also wouldn't like to change the close dialog option. It's pretty fine as it is, IMO.
I don't mind if we remove the expander.
I'm all for that ^_^
Is a persistent expander really that bad? It would be pretty much like without it, you still see it but once opened (and not closed again) it will always be open, so it's more or less the same as when the expander was a frame. Plus we have the benefit that users who really don't want to see/use the replace all options, simply won't see it and so have a smaller dialog (as I mentioned before, there are Netbook users out there :D).
Just for the records: the original topic, the button order, has been changed by Nick today.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, 23 Jan 2009 09:09:00 +1100, Gordon Wrigley gordon.wrigley@gmail.com wrote:
Assuming we don't get rid of it entirely could we make the close option persistent as well?
Even if the expander would be removed, this doesn't affect your request, does it? To me, these are two independent things.
After all, is this really necessary?
Regards, Enrico
Le Fri, 16 Jan 2009 17:04:36 +0000, Nick Treleaven nick.treleaven@btinternet.com a écrit :
On Sun, 11 Jan 2009 18:50:36 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
[In Selection] [In Session] [In Document]
"Selection" and "Document" are self-explanatory; "Session" replaces text in all currently-open files.
Why are the buttons in this order? Intuitively, I would expect them to be ordered in terms of increasing scope: selection, document, session. I don't see why the current order would be preferable---I've never even used the "In Session" button in actual work.
I did it like that because the Gnome HIG says the most commonly-used button should be on the right, and I assumed it was the document button. Then it seemed logical to put the session button near the document button.
Anyway, the selection button can also be used often, so we could change the order to:
[Session] [Document] [Selection]
This also makes sense in making the function with the biggest impact away from the commonly used position.
Good catch. I agree it should be in the order selection, document and then session. I don't remember when these buttons were added. In case I did so, I probably just didn' think about and just added them. In case of it was Nick, maybe he had a reason.
Regards, Nick
Some notes about the replace feature/interface:
-1- I think the arrow should go and these replace choices be visible from start -- does this serve any purpose?
-2- Which choice is the most common or useful one can probably be discussed for nights... so I propose the fasttest/default one to be the most secure one, i.e. "in selection" or "in scope" (-->).
-3- I would add a "replace all in current scope" function that I dream of for years already ;-) where 'scope' means closest nesting func, class, or whatever.
-4-This button and "in selection" should be invalid (greyed) whenever there is no 'scope' (module toplevel, meaning "in scope" = "in doc") or there is no selection.
-5- I would also add a "in project" choice to allow lexical evolution at project level. This would walk together with file/doc/module registering in project. (The latter would also allow straightforward project stage freezing/recording e.g into myProj-0.10-01_02_2009.tar).
-6- I'd love an '\i' code working in both the search & replace fields, that would mean 'indent' & match the user specified value for one level of indentation in preferences (that is n spaces or one tab).
-7- ?
denis
------ la vida e estranya
/ˈmɪstər/ /ˈdʒɛnəsɪs/@/dʒi/ /meɪl/ /dɒt/ /kɒm/ Benjamin West
On Sat, Jan 17, 2009 at 3:13 AM, spir denis.spir@free.fr wrote:
Le Fri, 16 Jan 2009 17:04:36 +0000, Nick Treleaven nick.treleaven@btinternet.com a écrit :
On Sun, 11 Jan 2009 18:50:36 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
[In Selection] [In Session] [In Document]
"Selection" and "Document" are self-explanatory; "Session" replaces text in all currently-open files.
Why are the buttons in this order? Intuitively, I would expect them to be ordered in terms of increasing scope: selection, document, session. I don't see why the current order would be preferable---I've never even used the "In Session" button in actual work.
I did it like that because the Gnome HIG says the most commonly-used button should be on the right, and I assumed it was the document button. Then it seemed logical to put the session button near the document button.
Anyway, the selection button can also be used often, so we could change the order to:
[Session] [Document] [Selection]
This also makes sense in making the function with the biggest impact away from the commonly used position.
Good catch. I agree it should be in the order selection, document and then session. I don't remember when these buttons were added. In case I did so, I probably just didn' think about and just added them. In case of it was Nick, maybe he had a reason.
Regards, Nick
Some notes about the replace feature/interface:
-1- I think the arrow should go and these replace choices be visible from start -- does this serve any purpose?
-2- Which choice is the most common or useful one can probably be discussed for nights... so I propose the fasttest/default one to be the most secure one, i.e. "in selection" or "in scope" (-->).
-3- I would add a "replace all in current scope" function that I dream of for years already ;-) where 'scope' means closest nesting func, class, or whatever.
I second this, EXcept that scoping seems to be broken in JavaScript. I can't seem to get geany to resolve that properly. In JS though, I get why it could be tough. I'll try to file a formal bug-report on it once I unburry myself from stuff that needs to be done.
-4-This button and "in selection" should be invalid (greyed) whenever there is no 'scope' (module toplevel, meaning "in scope" = "in doc") or there is no selection.
-5- I would also add a "in project" choice to allow lexical evolution at project level. This would walk together with file/doc/module registering in project. (The latter would also allow straightforward project stage freezing/recording e.g into myProj-0.10-01_02_2009.tar).
-6- I'd love an '\i' code working in both the search & replace fields, that would mean 'indent' & match the user specified value for one level of indentation in preferences (that is n spaces or one tab).
-7- ?
denis
la vida e estranya _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Sat, 17 Jan 2009 11:13:30 +0100, spir denis.spir@free.fr wrote:
Hey,
Some notes about the replace feature/interface:
-1- I think the arrow should go and these replace choices be visible from start -- does this serve any purpose?
I wrote this in another mail in this thread, one/the reason for the arrow was to simplify the dialog. But based on the feedback in this thread, we will remove it.
-3- I would add a "replace all in current scope" function that I dream of for years already ;-) where 'scope' means closest nesting func, class, or whatever.
Hmm, not sure. Could be done but adds yet another button, yet another thing you need to sort out when you do a quick search/replace. (this is not a 'no', just a 'I won't work on it')
-4-This button and "in selection" should be invalid (greyed) whenever there is no 'scope' (module toplevel, meaning "in scope" = "in doc") or there is no selection.
Yes, this is a good idea (at least for selection).
-5- I would also add a "in project" choice to allow lexical evolution at project level. This would walk together with file/doc/module registering in project. (The latter would also allow straightforward
We discussed this already a couple of times earlier, we don't want a discrete list of files per project. We have session support for projects which is really convenient and sufficient.
project stage freezing/recording e.g into myProj-0.10-01_02_2009.tar).
Uh, this is something a build system should do, not an IDE/Texteditor.
-6- I'd love an '\i' code working in both the search & replace fields, that would mean 'indent' & match the user specified value for one level of indentation in preferences (that is n spaces or one tab).
Use regular expressions like "^[ \t] .*" or something similar, I usually fail to construct untested regexps :).
Regards, Enrico
On Sat, 2009 Jan 17 16:33:11 +0100, Enrico Tröger wrote:
I wrote this in another mail in this thread, one/the reason for the arrow was to simplify the dialog. But based on the feedback in this thread, we will remove it.
Placing a "Replace All" GtkFrame around them might address potential user confusion... grouping the buttons together in the same way that the arrow currently does, but without hiding anything.
Alternately, just to toss in another idea, NEdit uses a label at the left such that the button labels complete a sentence. Something like
Replace all in: [Session] [Document] [Selection]
(Which would nicely eliminate the redundant "In" preposition on each of the buttons.)
-3- I would add a "replace all in current scope" function that I dream of for years already ;-) where 'scope' means closest nesting func, class, or whatever.
Hmm, not sure. Could be done but adds yet another button, yet another thing you need to sort out when you do a quick search/replace. (this is not a 'no', just a 'I won't work on it')
-4-This button and "in selection" should be invalid (greyed) whenever there is no 'scope' (module toplevel, meaning "in scope" = "in doc") or there is no selection.
Yes, this is a good idea (at least for selection).
Agree on greying out "In Selection" when there is no selection. "In Scope" sounds interesting, but I think it would be too complicated practically to be added alongside the other find/replace modes. My misgivings:
1. Would it work reliably/predictably, even in cases of complex C++ code and the like?
2. What, exactly, does "scope" mean? Body of the current function/method? (Would it include the signature line, so you can find/replace the formal parameters too?) What about just the current curly-brace block, which would also have a claim to the term "scope?" Or the current class? Would there be a preference to decide between these, or would it be something set by the language syntax driver?
-6- I'd love an '\i' code working in both the search & replace fields, that would mean 'indent' & match the user specified value for one level of indentation in preferences (that is n spaces or one tab).
Use regular expressions like "^[ \t] .*" or something similar, I usually fail to construct untested regexps :).
Yeah, for cases like this I'd do e.g. s/^(\s*)foobaz/\1barqux/. There might be some value to \i if you're changing indent levels, but Geany already has such an excellent keybinding for this (Tab or Shift-Tab with a selection) that I would say a new regex escape is not needed.
--Daniel
Le Sat, 17 Jan 2009 14:56:11 -0500, "Daniel Richard G." skunk@iSKUNK.ORG a écrit :
Placing a "Replace All" GtkFrame around them might address potential user confusion... grouping the buttons together in the same way that the arrow currently does, but without hiding anything.
Alternately, just to toss in another idea, NEdit uses a label at the left such that the button labels complete a sentence. Something like
Replace all in: [Session] [Document] [Selection]
(Which would nicely eliminate the redundant "In" preposition on each of the buttons.)
+++
-3- I would add a "replace all in current scope" function that I dream of for years already ;-) where 'scope' means closest nesting func, class, or whatever.
Hmm, not sure. Could be done but adds yet another button, yet another thing you need to sort out when you do a quick search/replace. (this is not a 'no', just a 'I won't work on it')
[...]
"In Scope" sounds interesting, but I think it would be too complicated practically to be added alongside the other find/replace modes. My misgivings:
Would it work reliably/predictably, even in cases of complex C++ code and the like?
What, exactly, does "scope" mean? Body of the current function/method? (Would it include the signature line, so you can find/replace the formal parameters too?)
Yes, I meant that. Precisely, as a formal parameter (name) is a local variable (name), I find practicle to be able to "replace all" in the scope of the name life. Namely (sic!) a namespace is imo the proper scope of a "replace all" feature in many cases, if not most. So that when writing "in scope" I rather meant "in the extent of the current code section that defines a namespace". What about just the current curly-brace block, which
would also have a claim to the term "scope?" Or the current class? Would there be a preference to decide between these, or would it be something set by the language syntax driver?
The note above basically excludes lower level code blocks such as loops or ifs. Anyway, this seems mostly useful for funcs/methods and it would apply on a whole class only when one points at a line at class top-level. An alternative may be to define this at per-language level inside language specific config files, so that there would be both a geany default and possible user preference.
--Daniel
------ la vida e estranya
On Sun, 18 Jan 2009 02:17:42 +0100, spir denis.spir@free.fr wrote:
-3- I would add a "replace all in current scope" function that I dream of for years already ;-) where 'scope' means closest nesting func, class, or whatever.
Hmm, not sure. Could be done but adds yet another button, yet another thing you need to sort out when you do a quick search/replace. (this is not a 'no', just a 'I won't work on it')
[...]
"In Scope" sounds interesting, but I think it would be too complicated practically to be added alongside the other find/replace modes. My misgivings:
- Would it work reliably/predictably, even in cases of complex C++
code and the like?
- What, exactly, does "scope" mean? Body of the current
function/method? (Would it include the signature line, so you can find/replace the formal parameters too?)
Yes, I meant that. Precisely, as a formal parameter (name) is a local variable (name), I find practicle to be able to "replace all" in the scope of the name life. Namely (sic!) a namespace is imo the proper scope of a "replace all" feature in many cases, if not most. So that when writing "in scope" I rather meant "in the extent of the current code section that defines a namespace". What about just the current curly-brace block, which
would also have a claim to the term "scope?" Or the current class? Would there be a preference to decide between these, or would it be something set by the language syntax driver?
The note above basically excludes lower level code blocks such as loops or ifs. Anyway, this seems mostly useful for funcs/methods and it would apply on a whole class only when one points at a line at class top-level. An alternative may be to define this at per-language level inside language specific config files, so that there would be both a geany default and possible user preference.
Hmm, first this is going a bit off-topic and far beyond the original request. I don't think we need this in the core of Geany, could be done as a plugin, maybe. But per filetype scope settings just for 'Replace All' sounds heavy to me, sorry.
Anyway, we already have some code to find the scope at the cursor position and the found scope is displayed in the statusbar. Anyway, it's known that this value is not always accurate and not that reliable. Especially for PHP files and maybe others.
Regards, Enrico
how about a Select Scope fucntion that allows you to select the current scope, and then you can do "In selection" /ˈmɪstər/ /ˈdʒɛnəsɪs/@/dʒi/ /meɪl/ /dɒt/ /kɒm/ Benjamin West
On Sun, Jan 18, 2009 at 4:50 AM, Enrico Tröger enrico.troeger@uvena.dewrote:
On Sun, 18 Jan 2009 02:17:42 +0100, spir denis.spir@free.fr wrote:
-3- I would add a "replace all in current scope" function that I dream of for years already ;-) where 'scope' means closest nesting func, class, or whatever.
Hmm, not sure. Could be done but adds yet another button, yet another thing you need to sort out when you do a quick search/replace. (this is not a 'no', just a 'I won't work on it')
[...]
"In Scope" sounds interesting, but I think it would be too complicated practically to be added alongside the other find/replace modes. My misgivings:
- Would it work reliably/predictably, even in cases of complex C++
code and the like?
- What, exactly, does "scope" mean? Body of the current
function/method? (Would it include the signature line, so you can find/replace the formal parameters too?)
Yes, I meant that. Precisely, as a formal parameter (name) is a local variable (name), I find practicle to be able to "replace all" in the scope of the name life. Namely (sic!) a namespace is imo the proper scope of a "replace all" feature in many cases, if not most. So that when writing "in scope" I rather meant "in the extent of the current code section that defines a namespace". What about just the current curly-brace block, which
would also have a claim to the term "scope?" Or the current class? Would there be a preference to decide between these, or would it be something set by the language syntax driver?
The note above basically excludes lower level code blocks such as loops or ifs. Anyway, this seems mostly useful for funcs/methods and it would apply on a whole class only when one points at a line at class top-level. An alternative may be to define this at per-language level inside language specific config files, so that there would be both a geany default and possible user preference.
Hmm, first this is going a bit off-topic and far beyond the original request. I don't think we need this in the core of Geany, could be done as a plugin, maybe. But per filetype scope settings just for 'Replace All' sounds heavy to me, sorry.
Anyway, we already have some code to find the scope at the cursor position and the found scope is displayed in the statusbar. Anyway, it's known that this value is not always accurate and not that reliable. Especially for PHP files and maybe others.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Sun, 18 Jan 2009 04:59:38 -0700, "Ben West" mrgenixus@gmail.com wrote:
how about a Select Scope fucntion that allows you to select the current scope, and then you can do "In selection"
Not sure whether I understand you correctly but how would that differ from selecting some text and then use 'In selection'?
Regards, Enrico
On Sun, 18 Jan 2009 04:59:38 -0700 "Ben West" mrgenixus@gmail.com wrote:
how about a Select Scope fucntion that allows you to select the current scope, and then you can do "In selection"
I sometimes use the GeanyLua 'Select block' function, then replace in selection. It looks backward for any bracket, then looks forward for a match, selecting in between.
Geany doesn't really know what the scope is for each filetype properly, but putting the cursor into the outermost bracket and selecting is good enough IMO.
Regards, Nick
On Sat, 17 Jan 2009 14:56:11 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
On Sat, 2009 Jan 17 16:33:11 +0100, Enrico Tröger wrote:
I wrote this in another mail in this thread, one/the reason for the arrow was to simplify the dialog. But based on the feedback in this thread, we will remove it.
Placing a "Replace All" GtkFrame around them might address potential user confusion... grouping the buttons together in the same way that the arrow currently does, but without hiding anything.
Alternately, just to toss in another idea, NEdit uses a label at the left such that the button labels complete a sentence. Something like
Replace all in: [Session] [Document] [Selection]
Great ideas!
Attached are mockups of both variants together with the necessary code changes (the patches are mainly for reference).
I basically like both variants but would prefer the one with the frame as it groups well the Replace All options together. The variant with the label eliminates the room for the 'Close dialog' checkbox so I commented it out on the screenshot and it looks a bit lost at all, IMO.
Regards, Enrico
On Sun, 2009 Jan 18 13:27:52 +0100, Enrico Tröger wrote:
Attached are mockups of both variants together with the necessary code changes (the patches are mainly for reference).
I basically like both variants but would prefer the one with the frame as it groups well the Replace All options together.
That one looks good. The only downside I can see is that the three buttons are no longer perfectly aligned with the four along the bottom :)
The variant with the label eliminates the room for the 'Close dialog' checkbox so I commented it out on the screenshot and it looks a bit lost at all, IMO.
Granted, as the button labels are shorter, everything could be squeezed tighter horizontally. I'm not sure how the checkbox might go in, however. If you put it back in on the left, it presses up against "Replace all in:", and the two could potentially be read as one phrase. On the right, and you pretty much fly in the face of the Gnome HIG.
For its part, NEdit does things the opposite way: a "Keep Dialog" checkbox. Any find/replace operation would be a single shot, unless that option is checked. So the option is grouped together with the other find/replace options, and not specifically associated with the replace-all buttons. (Not suggesting that Geany follow suit; only painting the rest of the picture of this other editor.)
By the way, don't forget the whole button-reordering dealie! If I read Nick correctly, the desire is to keep more-commonly-used operations to the right. And we also said that arranging the replace-all scopes in a sorted order made sense. Which would then imply an end result of session, document, selection.
--Daniel
On Sun, 18 Jan 2009 14:30:15 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
On Sun, 2009 Jan 18 13:27:52 +0100, Enrico Tröger wrote:
Attached are mockups of both variants together with the necessary code changes (the patches are mainly for reference).
I basically like both variants but would prefer the one with the frame as it groups well the Replace All options together.
That one looks good. The only downside I can see is that the three buttons are no longer perfectly aligned with the four along the bottom :)
This also wasn't the case before at least not for non-English locales and if so it was just by coincidence.
For its part, NEdit does things the opposite way: a "Keep Dialog" checkbox. Any find/replace operation would be a single shot, unless that option is checked. So the option is grouped together with the other find/replace options, and not specifically associated with the replace-all buttons. (Not suggesting that Geany follow suit; only painting the rest of the picture of this other editor.)
What? Another editor? No way, can't be believe that...
By the way, don't forget the whole button-reordering dealie! If I read
Haha.
Nick correctly, the desire is to keep more-commonly-used operations to the right. And we also said that arranging the replace-all scopes in a sorted order made sense. Which would then imply an end result of session, document, selection.
Yup.
Regards, Enrico
On Sat, 17 Jan 2009 16:33:11 +0100, Enrico Tröger enrico.troeger@uvena.de wrote:
-4-This button and "in selection" should be invalid (greyed) whenever there is no 'scope' (module toplevel, meaning "in scope" = "in doc") or there is no selection.
Yes, this is a good idea (at least for selection).
No, it's not. As the whole dialog is non-modal by design, making it possible to change text, change the selection, change documents while the dialog is open, it doesn't make sense to disable the Selection button even if there is no selection.
It didn't hurt people in the past few years, so it probably also won't in the future :).
Regards, Enrico
On Mon, 2009 Jan 26 19:45:24 +0100, Enrico Tröger wrote:
-4-This button and "in selection" should be invalid (greyed) whenever there is no 'scope' (module toplevel, meaning "in scope" = "in doc") or there is no selection.
Yes, this is a good idea (at least for selection).
No, it's not. As the whole dialog is non-modal by design, making it possible to change text, change the selection, change documents while the dialog is open, it doesn't make sense to disable the Selection button even if there is no selection.
Well, you'd dynamically update the status of the Selection button to reflect the existence/absence of a selection to operate on. The whole idea is, the button is greyed out at the times that its associated action is not sensible.
It didn't hurt people in the past few years, so it probably also won't in the future :).
Just wait till someone comes on here and posts "I pressed the 'In Selection' button when there wasn't a selection... and my computer ESPLODED!!!" ^_^
--Daniel
On Tue, 27 Jan 2009 12:47:34 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
On Mon, 2009 Jan 26 19:45:24 +0100, Enrico Tröger wrote:
-4-This button and "in selection" should be invalid (greyed) whenever there is no 'scope' (module toplevel, meaning "in scope" = "in doc") or there is no selection.
Yes, this is a good idea (at least for selection).
No, it's not. As the whole dialog is non-modal by design, making it possible to change text, change the selection, change documents while the dialog is open, it doesn't make sense to disable the Selection button even if there is no selection.
Well, you'd dynamically update the status of the Selection button to reflect the existence/absence of a selection to operate on. The whole idea is, the button is greyed out at the times that its associated action is not sensible.
Oh come on, then we could also add tons of other useless features just to bloat it up. I think users will notice that the 'in selection' action doesn't make any sense when there is no selection, users are not stupid (although some designers of a famous DE may think this sometimes...).
It didn't hurt people in the past few years, so it probably also won't in the future :).
Just wait till someone comes on here and posts "I pressed the 'In Selection' button when there wasn't a selection... and my computer ESPLODED!!!" ^_^
Hmm, if the user's computer is exploded, we are still safe because then he can't write to the list anymore assuming users have no friends and social contacts :).
Er, hrm, j/k.
Regards, Enrico
On Tue, 2009 Jan 27 19:11:39 +0100, Enrico Tröger wrote:
Well, you'd dynamically update the status of the Selection button to reflect the existence/absence of a selection to operate on. The whole idea is, the button is greyed out at the times that its associated action is not sensible.
Oh come on, then we could also add tons of other useless features just to bloat it up.
I think users will notice that the 'in selection' action doesn't make any sense when there is no selection, users are not stupid (although some designers of a famous DE may think this sometimes...).
It's no different than greying out a Web browser's "Stop" button when a site has finished loading. Sure, a user might already know that there is no selection, or that a site is already loaded, but the grey-out makes the current state more conspicuous---as well as that the associated operation is a no-op.
Is that feature bloat? Well... yeah, if your standard is xedit }:)
--Daniel
On Tue, 27 Jan 2009 14:49:49 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
On Tue, 2009 Jan 27 19:11:39 +0100, Enrico Tröger wrote:
Well, you'd dynamically update the status of the Selection button to reflect the existence/absence of a selection to operate on. The whole idea is, the button is greyed out at the times that its associated action is not sensible.
Oh come on, then we could also add tons of other useless features just to bloat it up.
I think users will notice that the 'in selection' action doesn't make any sense when there is no selection, users are not stupid (although some designers of a famous DE may think this sometimes...).
It's no different than greying out a Web browser's "Stop" button when a site has finished loading. Sure, a user might already know that there is no selection, or that a site is already loaded, but the grey-out makes the current state more conspicuous---as well as that the associated operation is a no-op.
Is that feature bloat? Well... yeah, if your standard is xedit }:)
Maybe not. But from the technically POV, you need to watch mouse events, then check in the event handler whether a selection exists or not and then notify the search/replace dialog. It's possible at all, no doubt and it's not difficult but it's just code which is not that necessary, IMHO.
Regards, Enrico
