Recent

Author Topic: "Find" could be made better very easily.  (Read 7648 times)

Spoonhorse

  • Jr. Member
  • **
  • Posts: 56
"Find" could be made better very easily.
« on: June 16, 2021, 11:14:14 pm »
When I press Ctrl+F and put in a search string, I expect the editor to find the next matching string and it does. But then when I press Ctrl+F again I expect it to look for the next matching string and not the one it just found. Yes, I can get the result I actually want by pressing F3 instead but why frustrate people like that? We've already learned what Ctrl+F means, why make it do something slightly different that no-one will ever want it to do? No-one ever wants to search for the same string in the same place while they still have it highlighted just to check that it's still there, and yet this is what has been implemented.

dbannon

  • Hero Member
  • *****
  • Posts: 1532
    • tomboy-ng, a rewrite of the classic Tomboy
Re: "Find" could be made better very easily.
« Reply #1 on: June 17, 2021, 02:11:52 am »
Ctrl-F starts the search process, F3 continues it.  If you keep starting it, you should expect it to keep starting.

I don't know of any application that uses Ctrl-F in the way you think it should work.

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7384
  • Debugger - SynEdit - and more
    • wiki
Re: "Find" could be made better very easily.
« Reply #2 on: June 17, 2021, 03:30:59 am »
There are a few details that make this less easy(desirable) than you think.

First lets see, if I understand you correctly.

If I press Ctrl-F the 2nd time (while the found term is still selected), there are 2 things that happen.
1) The dialog opens again
2) The dialog goes to "selection only"

You probably dislike both. But what irritates you is probably mostly (2).
If only the dialog would open again. And if you could then just press enter, and if that would then find the next match (instead of the current highlighted one), well then you could just press enter, and find what you want.

But of course, if there is a selection, then the user may want that selection to be searched.
At the time of ctrl-f the IDE can not know the users intent.

Example:
- I search for a very long (multi word match).
   Maybe a regular expression like: writeln.*;
- Now that block is selected
- I want to find something in that block.
  The IDE may fill in the search term, with the entire selected block.
  But the IDE does not know, if I am going to replace the search term with something else.
  So - since a block is selected - the IDE should switch to search "selection only".

And this is exactly what the IDE does.

So up to this point, everything is actually useful (useful, for some usecases).


The "strange" thing that happens is something else. And it does not matter, if or if not the selected block came from a previous search, or was set by the user directly.

If I select any amount of text, that does not extend over the line bounds, then this text will be the new search term. That also is correct and useful. And it can be disabled in the options (but that will not help here)

If text is selected then search settings are adapted to search selected text. (I don't think that can be disabled by any IDE option)

However, searching inside a selected block only makes sense, if the search term is not equal to the selected text.

Example:
- the user double clicks a word to select it
- the user hits ctrl F
- the dialog fills the search text with the selected word and goes to "only selection"
- the user does not change anything. Neither the search term, nor the "only selection"
The search is pointless.
But its a user error.
=> if the word was selected by the user before, then there is no sensible alternative action.
The settings the user confirmed for the search simple are pointless. But the user confirmed them.

In the case of the word having been selected by the user, when there was no previous search, it would be a very unpredictable action to ignore the settings that the user confirmed (however pointless they are). So the IDE must not go and search the next word outside the selection.

After all, the user may have just forgotten to change the search term. In that case the user may be glad to find the selection still as it was.


So your suggestion makes only "some sense" in a very specific case.
It would require state-keeping what the users last action was.

It would also risk irritating users who might not understand the pattern, and only be irritated because the search would sometimes adhere the settings and sometimes ignore them.

And, even if the last action was a search: The above case where the user forgot to change the search term => it could still apply.


So it is not easy at all. Others might find it irritating. And it would add complexity for no gain (changing one complaint for another is not a gain).


The only possible change that could be made, is to give users the option that the IDE does not adapt the search scope to "only selection".

Then you could hit ctrl-f and just hit return, and it would search to the next occurrence.

But it would still open the find dialog, and you still need to do an extra keypress.
So - I guess - it would not really help you either. So I don't think such an option is needed/helpful



Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7384
  • Debugger - SynEdit - and more
    • wiki
Re: "Find" could be made better very easily.
« Reply #3 on: June 17, 2021, 03:36:46 am »
Btw, have you got on editor (to which you are used) that behaves, as you said it should?

What editor is that?

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1580
  • Former Delphi 1-7, 10.2 user
Re: "Find" could be made better very easily.
« Reply #4 on: June 17, 2021, 07:22:04 am »
Btw, have you got on editor (to which you are used) that behaves, as you said it should?
What editor is that?

The two text editors I use most behave like this: vi (/) and Emacs (CTRL-S). Find a match with / or CTRL-S, and / or CTRL-S to find the next match.

On the other hand, I have no problem with the Lazarus IDE editor on macOS using CMD-F (find) and CMD-G (find again) which is consistent with other macOS GUI editors like TextEdit.
« Last Edit: June 17, 2021, 07:29:23 am by trev »
Lazarus 2.3 2021-08-10 FPC 3.3.1 r49223 macOS 10.14.6 Xcode 11.3.1
Lazarus 2.3 r65500 FPC 3.3.1 r49634 macOS 11.5.2 aarch64 Xcode 12.5.1
Lazarus 2.3 2021-08-11 FPC 3.2.2 FreeBSD 13.0 amd64 VMware VM
Lazarus 2.1 r61574 FPC 3.0.4 Ubuntu 20.04 Parallels VM
Lazarus 2.0.10 FPC 3.2.0 Win10 Parallels VM

dbannon

  • Hero Member
  • *****
  • Posts: 1532
    • tomboy-ng, a rewrite of the classic Tomboy
Re: "Find" could be made better very easily.
« Reply #5 on: June 17, 2021, 08:59:15 am »
The two text editors I use most behave like this: vi (/) and Emacs (CTRL-S). Find a match with / or CTRL-S, and / or CTRL-S to find the next match.

I cannot speak for emacs but vi /vim don't, IMHO, quite work like that.  You press /, enter a search term and then Enter.  If you want to search for the same term, you done then press /, you press 'n'.  Pressing / again prompts you for a new search term.  Mind you, I use vim not vi so just possible I am forgetting how vi worked ?

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1580
  • Former Delphi 1-7, 10.2 user
Re: "Find" could be made better very easily.
« Reply #6 on: June 17, 2021, 09:09:08 am »
[ You press /, enter a search term and then Enter.  If you want to search for the same term, you done then press /, you press 'n'.  Pressing / again prompts you for a new search term.  Mind you, I use vim not vi so just possible I am forgetting how vi worked ?

With vi, you just press / [enter] again nothing else (I've used it for the last 26 years, almost daily). Ok, I had omitted the [Enter]. Emacs just requires CTRL-S, no extra [Enter].
Lazarus 2.3 2021-08-10 FPC 3.3.1 r49223 macOS 10.14.6 Xcode 11.3.1
Lazarus 2.3 r65500 FPC 3.3.1 r49634 macOS 11.5.2 aarch64 Xcode 12.5.1
Lazarus 2.3 2021-08-11 FPC 3.2.2 FreeBSD 13.0 amd64 VMware VM
Lazarus 2.1 r61574 FPC 3.0.4 Ubuntu 20.04 Parallels VM
Lazarus 2.0.10 FPC 3.2.0 Win10 Parallels VM

dbannon

  • Hero Member
  • *****
  • Posts: 1532
    • tomboy-ng, a rewrite of the classic Tomboy
Re: "Find" could be made better very easily.
« Reply #7 on: June 17, 2021, 09:37:43 am »
Ah, I see the way you mean it.  The next search is triggered by the Enter rather than the '/' but maybe that is still comparable to what the OP wants. But I doubt the OP uses either vi or emacs .....

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng

Spoonhorse

  • Jr. Member
  • **
  • Posts: 56
Re: "Find" could be made better very easily.
« Reply #8 on: June 17, 2021, 10:33:19 am »
Hi, Martin, thanks for the explanation. I now understand why it's like that.

Ctrl+F is just second nature to me from Windows Notepad and the like. I've mainly only intermittently coded little useful algorithms until six months ago ... I'm using Lazarus because 25 years ago my dad had a copy of Delphi which I poked at ... there are still lots of things I don't know about the editor. Someone the other day was talking about making different words be highlighted in different colors for code refactoring and I though, my god, that's wonderful, they should put that on the startup screen in big letters next to Write Once Compile Anywhere ... but I still haven't looked through the documentation to find out how to do it.

Zvoni

  • Hero Member
  • *****
  • Posts: 677
Re: "Find" could be made better very easily.
« Reply #9 on: June 17, 2021, 10:52:21 am »
Ctrl-F starts the search process, F3 continues it.  If you keep starting it, you should expect it to keep starting.

I don't know of any application that uses Ctrl-F in the way you think it should work.

Davo

Nevermind that the majority of programs offering such a feature ("Search"/"Continue Search") pretty much all use the "CTRL+F/F3"-Combination (e.g. pretty much everything from Microsoft, Notepad++ and others)
From the Top of my head the first "popular" program not adhereing to it is Geany
One System to rule them all, One IDE to find them,
One Code to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
People call me crazy, because i'm jumping out of perfectly fine aircraft

Handoko

  • Hero Member
  • *****
  • Posts: 4327
  • My goal: build my own game engine using Lazarus
Re: "Find" could be made better very easily.
« Reply #10 on: June 17, 2021, 11:05:04 am »
... there are still lots of things I don't know about the editor.

Lazarus IDE is full of useful features. You should check these out:

Default keyboard shortcuts
https://wiki.lazarus.freepascal.org/Lazarus_IDE_Shortcuts

Editor features
https://wiki.lazarus.freepascal.org/New_IDE_features_since

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7384
  • Debugger - SynEdit - and more
    • wiki
Re: "Find" could be made better very easily.
« Reply #11 on: June 17, 2021, 11:07:34 am »
@trev
My emacs time is to far back...
"vi" is like opening the dialag, but not setting "search in selection only" and then hit enter.

@Spoonhorse

Ok, in Notepad the dialog opens every time. But Notepad does not have "find in selection". So if you press enter, it does what you want.


The IDE will remember, how you did set "selection only" if you change it.

- Select some text
- Open the find dialog
- unselect the "selection only"
- set to search "from cursor"
- Press "Find"

Now this is remembered.

Search a term.
Once the term is found and selected, press ctrl-F again
- the "selection only" should not be checked
Hit Enter, and it should find the next occurrence


I have not tested if that persists, when you restart the IDE.
But if not, that can be seen as a bug, and reported for fixing.

MarkMLl

  • Hero Member
  • *****
  • Posts: 3030
Re: "Find" could be made better very easily.
« Reply #12 on: June 17, 2021, 11:28:10 am »
I'm trying to think back... IIRC, Multi-Edit had a couple of settings which controlled (a) whether operations such as paste left the block selected (not really relevant, since the most useful think find can do is leave the found text selected) and (b) whether a find (or find-again etc.) worked from the start of a selected block or the end.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7384
  • Debugger - SynEdit - and more
    • wiki
Re: "Find" could be made better very easily.
« Reply #13 on: June 17, 2021, 11:30:56 am »
whether a find (or find-again etc.) worked from the start of a selected block or the end.

When "find" sets the selection, it will set the caret at the correct side of the selection, depending on it being a forward or backward search.
Only issue is, if you change direction.

MarkMLl

  • Hero Member
  • *****
  • Posts: 3030
Re: "Find" could be made better very easily.
« Reply #14 on: June 17, 2021, 11:51:57 am »
whether a find (or find-again etc.) worked from the start of a selected block or the end.

When "find" sets the selection, it will set the caret at the correct side of the selection, depending on it being a forward or backward search.
Only issue is, if you change direction.

I know. I'm just saying that the developers of that specific editor considered those settings worth implementing, and quietly speculating that one of them might fix OP's issue.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018