[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  Find should use selected location as starting point, not start/end
Find should use selected location as starting point, not start/end

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Posted by GreenReaper   (4 posts)  [Biography] bio
Date Fri 24 Apr 2015 04:48 AM (UTC)
Message
Right now, if I use Ctrl+F to find something, then use Ctrl+F to find it again, I only get to one instance of the search term (or two, if I change direction). It never gets to the middle because it starts at the start or the end every time.

The way it works in most text editing programs I'm familiar with is that the button is actually "Find Next" and starts from the current selection. (They tend to use a non-modal dialog to make it easier to do repeated searches, too.)

I appreciate that there is a "Find Again"; I just think that should be the default behaviour from the dialog as well.
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #1 on Fri 24 Apr 2015 04:56 AM (UTC)
Message
Well, it's not a bug because it is by design.

Another thing that is a bit different from a lot of text editors is that find doesn't wrap. It could be tedious, if your suggestion was implemented, to have to deselect any selection, and then do a find, if you want to search the entire buffer.

Does anyone else have a comment?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by GreenReaper   (4 posts)  [Biography] bio
Date Reply #2 on Fri 24 Apr 2015 05:19 AM (UTC)

Amended on Fri 24 Apr 2015 05:30 AM (UTC) by GreenReaper

Message
If it's by design, then the search dialog should be changed so that the "Direction" group is instead captioned "Search from" and it has "Bottom, going up" and "Top, going down", as this better communicates to the user what will happen. (However, the "Find Again" menu item is then mislabelled, because it doesn't do what the Find dialog does again - it seems to be "Find Next", regardless of selection.)

Overall, I think the design should be changed to search from selection. :-) But I agree that it would be nice to know what other users' expectations are.

Wrap would be nice, but the regular Windows Notepad doesn't offer it, so I wouldn't expect MUSHclient to. Notepad++ has a checkbox for it. Don't know how hard it is based on your internal design.

If it's easy to change Find to a non-modal on-top dialog as Notepad has, that'd also make it easier to clear any selection while the dialog is open (Notepad++ even makes the dialog semi-transparent if it loses focus, so you can see selections behind the dialog). I appreciate modal -> non-modal is not quite as simple as flicking a switch, though.
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Sat 25 Apr 2015 01:14 AM (UTC)
Message
I find those modeless dialog boxes intensely annoying, because they tend to get hidden behind other windows.

I'll see if it is possible to search from the selection, and make that an option, so the default behaviour will be unchanged.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Sat 25 Apr 2015 01:16 AM (UTC)
Message
Could I just ask though, why is this important?

Let's say you search for "foo" and find it. Later you search for "bar". Why do you want to start from where "foo" was? Especially if the search doesn't wrap? Surely you want to search everything for "bar" and not just where "foo" happened to be?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by GreenReaper   (4 posts)  [Biography] bio
Date Reply #5 on Sat 25 Apr 2015 06:42 AM (UTC)
Message
Nick Gammon said:

I find those modeless dialog boxes intensely annoying, because they tend to get hidden behind other windows.

That is why you make it a 'topmost' window, so it can't get lost. (In turn, this can make it get in the way of the text you're seeing - so Notepad++ makes it transparent when it loses focus - but this probably isn't such a big issue here as MUSHclient's Find dialog is smaller.)

Nick Gammon said:

Could I just ask though, why is this important?

Quite simply, Find does not work as it does in other applications, i.e. you can't open Find again (or keep it open and keep pressing the button) and find multiple instances of the *same* string. This violates user expectations, and may lead them to believe that there is only one instance of the string they were trying to find.

This is compounded by the fact that "Find Again" uses the Shift+Ctrl+F accelerator, and does not support the usual key in this situation for Windows applications, F3.

A user is unlikely to succeed in finding multiple instances of a string in the display buffer unless they first find the Find Again menu item - which is not the Edit menu, where it usually is (this makes sense for MUSHclient, since you actually "edit" worlds, but it's unusual and so represents an additional usability barrier).

In this case I knew that there were multiple instances of the string to be searched, so I investigated and filed this report to improve MUSHclient to meet user expectations. This might be done by searching from the current selection, if there is one; by by keeping the Find dialog open to make such repeated searches easier; and by supporting the standard F3 accelerator for repeated searches.

The reason that Find dialogs have a "direction" is that they implicitly search relative to the current selection, and not just from the top or bottom of the buffer. If there is no selection it might be reasonable to start from the top (if searching down) or the bottom (if searching up), but that is not the expected case when text is already selected. Another reasonable starting point might be the top or bottom of the text currently displayed, given that this is "down" or "up" from the user's current perspective. For text editors, the starting point for searches is the place where text is to be entered (which would also be the current selection), but that is always the bottom in MUSHclient, so that behaviour is not as useful.
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #6 on Sat 25 Apr 2015 08:41 PM (UTC)
Message
I acknowledge that there have been times when I have switched from other editors and my own Find Again has confused me momentarily. A simple fix you can make is to re-purpose F3:


AcceleratorTo('F3', 'DoCommand ("FindAgain")', sendto.script)


Do that in a script (eg. on World Open) and then F3 does the usual "Find again". Maybe make Ctrl+G do the same thing to be compatible with Macs, Linux, etc.

In fact you could make your favourite accelerator changes in a plugin, and just have that automatically load in all worlds (there is a global option for that). There is an example here:

Template:faq=39 Please read the MUSHclient FAQ - point 39.



But you are talking here about "find again" not being the accelerator you expect, rather than the problem of searching for "foo", finding it, then switching to searching for "bar" and wanting the search to start from "foo", which could erroneously suggest to you that "bar" is not in the output buffer, when it is, but before "foo"
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Sun 26 Apr 2015 12:09 AM (UTC)
Message
I should point out that in the current implementation, "find next" does not find the next "from the selection" it finds the next "from the last found point". They aren't necessarily the same.

You might find "foo" then change the selection to something else entirely (eg. by double-clicking a word) but if you do a "find again" it finds the next "foo" after the first one, not after where the new selection is.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by GreenReaper   (4 posts)  [Biography] bio
Date Reply #8 on Mon 27 Apr 2015 10:55 AM (UTC)
Message
Thank you; I have installed this plugin and I think it will help me personally. It's true that MUSHclient's "Find Again" does not work in the way that "Find Next" does elsewhere, but it'd still work for what I commonly want to do, i.e. search through the buffer for the names of particular people or items until I find what I'm looking for.

I still think it should be considered for a Windows default, as it is a common accelerator, while Ctrl+Shift+F is usually something like "find in files/all sources". Maybe there could be a default compatibility plugin for each platform?

As for not finding things when starting from a selection, the simplest solution is to make find wrap. You already know when it reaches the end/start, so you could instead make it go to the start/end when it reaches that point, as you do now when starting a new find. You'd just need to determine where to start (the current selection; failing that, the top/bottom of either the screen or the document), and stop the search there if you get all the way around. (Conceptually, you're searching a copy of the document starting from the selection point with the bit before it tacked onto the end.)
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #9 on Mon 27 Apr 2015 08:32 PM (UTC)
Message
Quote:

I still think it should be considered for a Windows default, as it is a common accelerator, while Ctrl+Shift+F is usually something like "find in files/all sources".


When I first wrote the client I allowed for a lot of macro keys: F2/F3/F4 etc. for common functions. Too late, I realized that maybe I should have reserved F3 for "find again". It was too late because that would break for users who had mapped F3 to come useful thing (like "open bag") and become used to it.

It is hard to get something like this perfect, and keep everyone happy. I find modal dialog boxes annoying at times, and also modeless ones. It can be annoying if it doesn't wrap, and annoying if it does. For example, I search for "foo", find it once, twice, three times, until I notice that the third "find" is the first one again, wrapped.

I should point out also the "recall" feature, that is another way of finding for a certain word. That filters the output window into a secondary text window, which is useful, for example, to just find everything a particular person said to you.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

19,537 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]