Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ctrl+f defaults to the browser search #7525

Closed
akosyakov opened this issue Apr 8, 2020 · 21 comments
Closed

ctrl+f defaults to the browser search #7525

akosyakov opened this issue Apr 8, 2020 · 21 comments
Assignees
Labels
bug bugs found in the application core issues related to the core of the application keybindings issues related to keybindings

Comments

@akosyakov
Copy link
Member

Description

Reproduction Steps

  • open SIW view
  • press ctrl+f to retrigger search
  • native browser search is shown
  • search is not retriggered

OS and Theia version:

Diagnostics:

@akosyakov akosyakov added bug bugs found in the application search in workspace issues related to the search-in-workspace labels Apr 8, 2020
@kittaakos
Copy link
Contributor

  • native browser search is shown

FYI: previously we throw an exception: #7474

@akosyakov akosyakov self-assigned this Apr 8, 2020
@kittaakos
Copy link
Contributor

Related conversation: #7481 (comment)

@kittaakos
Copy link
Contributor

Linked issue: #7346

@akosyakov
Copy link
Member Author

@kittaakos you are right about #7346

I'm still not sure about falling back to the native search.

@akosyakov akosyakov changed the title ctrl+f does not trigger search anymore in the SIW ctrl+f defaults to the browser search Apr 8, 2020
@akosyakov akosyakov added core issues related to the core of the application keybindings issues related to keybindings and removed search in workspace issues related to the search-in-workspace labels Apr 8, 2020
@kittaakos
Copy link
Contributor

We have to re-introduce a NOOP core.find then.

@akosyakov
Copy link
Member Author

What about core.replace? We used to prevent it as well.

@kittaakos
Copy link
Contributor

What about core.replace?

Yes. Obviously, it belongs here.

We used to prevent it as well.

"prevent" 😄 yes.


I think Select All, Find, and Replace should be generalized all over the application; the active widget should handle it if it can, otherwise we have to fall-back to the default NOOP. Most likely that's a bigger task.

@akosyakov
Copy link
Member Author

akosyakov commented Apr 8, 2020

I think Select All, Find, and Replace should be generalized all over the application; the active widget should handle it if it can, otherwise we have to fall-back to the default NOOP

Strangely the same issue present in VS Code, try with the terminal for instance:

  • if you use a find keybinding then it shows find widget in the terminal
  • but if you use Edit -> Find it does nothing.

I don't think that's nice though.

@akosyakov
Copy link
Member Author

akosyakov commented Apr 8, 2020

Actually before it was working like in VS Code: if you have an opened editor which is not focused, Find and Replace will still applied to this editor. It does not work only in the case if a widget, e.g. terminal, has own command. I think we should align again with it.

@kittaakos
Copy link
Contributor

I think we should align again with it.

I don't like the idea because then we have to handle monaco commands differently, one command (find, replace) would require an editor, it does not necessarily have to have the focus. Other commands, such as select all, undo would require a focused editor.

But please go ahead if you think it is better.

@akosyakov
Copy link
Member Author

I don't like the idea because then we have to handle monaco commands differently, one command (find, replace) would require an editor, it does not necessarily have to have the focus. Other commands, such as select all, undo would require a focused editor.

I afraid that it will be surprising to users, since it used to work like that in Theia for other commands except undo, redo, select all and work like that in VS Code.

@kittaakos
Copy link
Contributor

since it used to work like that in Theia

But it threw an error.

@lmcbout
Copy link
Contributor

lmcbout commented Apr 8, 2020

Side effect of "Select All" for the "Problem" view. When using the cmd+a to selct all, it also select all line ranges in the open editor.
SelectAll

@akosyakov
Copy link
Member Author

But it threw an error.

yes, this thing we can fix by no-op core find/replace handlers which are always enabled, since we have reverse handlers Monaco and terminal extensions will win

@akosyakov
Copy link
Member Author

@lmcbout please file a separate issue. The problems view should have Select All command similar to the debug console.

@akosyakov
Copy link
Member Author

akosyakov commented Apr 8, 2020

@kittaakos I'm trying to figure out where do we check when closures and preconditions of Monaco commands/actions with the new approach. We used to do it via MonacEditor.isActionSupported. Do we completely ignore them now?

@kittaakos
Copy link
Contributor

@akosyakov
Copy link
Member Author

For the built-in Monaco commands, yes.

Why is it better? Don't we ignore internal Monaco logic, i.e. we call a command when Monaco does not expect it. Should not we evaluate them instead in isEnabled callback?

@kittaakos
Copy link
Contributor

kittaakos commented Apr 8, 2020

Why is it better?

Otherwise, you never execute anything from VS Code's coreCommands.

Update: fixed the module name, added link.

@akosyakov
Copy link
Member Author

Otherwise, you never execute anything from VS Code's coreCommand.

You mean for undo, redo, select all? I thought Monaco does the same what our core command doing for such cases, i.e. document.execCommand? For other I don't think they are enabled always, it should depend on when closure as before.

@akosyakov
Copy link
Member Author

I wonder also why do we need ElectronUndoHandler and other handlers? If it is based on Chromium and calls at the end document.execCommand. VS Code does not seem to do it.

akosyakov added a commit that referenced this issue Apr 8, 2020
akosyakov added a commit that referenced this issue Apr 9, 2020
akosyakov added a commit that referenced this issue Apr 9, 2020
akosyakov added a commit that referenced this issue Apr 9, 2020
akosyakov added a commit that referenced this issue Apr 9, 2020
akosyakov added a commit that referenced this issue Apr 9, 2020
akosyakov added a commit that referenced this issue Apr 9, 2020
akosyakov added a commit that referenced this issue Apr 14, 2020
akosyakov added a commit that referenced this issue Apr 14, 2020
akosyakov added a commit that referenced this issue Apr 14, 2020
akosyakov added a commit that referenced this issue Apr 14, 2020
akosyakov added a commit that referenced this issue Apr 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug bugs found in the application core issues related to the core of the application keybindings issues related to keybindings
Projects
None yet
Development

No branches or pull requests

3 participants