Change default scope for "find usages" in PyCharm - python

Somehow my PyCharm's "Find Usages" scope gets changed and now it only searches in "Scratches and Consoles".
It used to be that when I typed ⌘B, PyCharm would go to the definition or usages of the object.
But now I get this popup that says usages are out of scope 'Scratches and Consoles', and I have to press ⌥⌘F7 to get to search in project files.
I tried clicking on the settings wrench and changing the scope but it does not persist.

There are a number of undocumented rules to this that can only be verified by trying it out:
If you have 2 PyCharm windows open (meaning 2 different projects simultaneously open in 2 different windows) you can only have 1 settings dialog (Ctrl + Alt + Shift + F7 or ⌥⌘F7 on Mac) open simultaneously. Meaning if you change the setting in one window while the dialog is open in the other, the same setting is changed in both windows.
If you only have the above mentioned settings dialog open in 1 window, the setting can be selected differently for both windows.
Now to the question,
If you close your current window the last find setting you chose will be saved, and it will persist when you later reopen that window/project and be used for searches. But there is one exception to this, if your last setting before closing the window was a saved costum scope then when you reopen the window the search setting will have reverted to default.
Here comes 1 important subtlety, after reopening the window if you try "Find usages" (Alt + F7 or ⌥⌘F7) the search will indeed use that last setting before you closed the window (you can see it in the search title window). But if you again press (Ctrl + Alt + Shift + F7 or ⌥⌘F7 on Mac) or the cog in the find settings, the setting you'll be shown is most times the default (sometimes not, but this behavior is not clearly consistent).
Meaning, it's not always consistent what setting is first shown in the below dialog after you reopen the IDE.
The problem you are describing should not be an issue. If you close the window the setting should persist. If you try opening the setting again most times you'll be offered with the default (after reopening the window) or your last choice if you changed it after opening the window.
There is, however, no way to change the default (this is probably to protect inexperienced users from configuring an IDE default search setting that would be difficult to revert). Meaning the first time you open the IDE if the setting doesn't revert to default automatically you'll have to set it manually but just that once.
(In these cases invalidating caches is frequently a good choice, if the cache becomes stale you can start having inexplicable results in search.)

Related

How to disable keyboard shortcut Alt+F4, in PyQt5? [duplicate]

Ctrl+Escape is a global Windows shortcut for opening main system menu. But I would like my Qt application to use this shortcut without triggering Windows main menu. I know it is probably a bad idea to override system shortcuts in general, but I would like to use this shortcut is a very limited use case.
This usecase is as follows. I have a popup window containing several rows or items. This window is opened by Ctrl+Tab and while the user holds Ctrl and keep pressing Tab, the current rows are cycled through. When the user releases Ctrl, the current row is used for some operation... But sometimes it happens that user presses Ctrl+Tab and then realizes he does not want to continue. He usually presses Escape while still holding Ctrl. And then it triggers Windows system menu and normal user gets confused, choleric user get angry... which is a bad thing. In other words I would like to be able to close the popup window when user presses Ctrl+Escape. How to do that? It is even possible?
If I write the code using this shortcut like any other short, it does not work and it always triggers Windows main menu.
As I understand it, Qt will typically not receive the key event if the underlying window system has intercepted it. For example even QtCreator cannot override system-wide shortcuts.
This question is almost a duplicate of: C++/Qt Global Hotkeys
While that question is asking specifically to capture shortcuts in a hidden/background application, I think the basic concept is the same -- capture shortcuts before the window system processes them.
From that answer, UGlobalHotkey seems pretty good, and the How to use System-Wide Hotkeys in your Qt application blog post could be useful for your limited-use case (but read the comments on that blog post about fixing the example).
Also found:
https://github.com/mitei/qglobalshortcut
https://github.com/Skycoder42/QHotkey (looks like a more detailed version of above)

Why do control keys and arrow keys not work in pycharm?

I use MobaXterm to control linux server remotely from my windows desktop. I use Linux and pycharm 2019.3 in the linux server for nearly one whole year. During the past year I can not use control keys in pycharm. To be specific, when I press arrow left, endless number 4 will be inserted in pycharm until I type a normal character from a to z. Similary, when I press arrow right, up, and down, endless 6, 8, and 2 will be inserted. Furthermore, when I press insert, delete,home, end, page up, and page down, endless number 0,.,7,1,9, and 3 will be inserted into pycharm editor area until I press backspace or a normal character.
I tried to upgrade my pycharm from 2019.3 to 2020.2, but the same issue still exist.
I can not delete any thing, I have to use backspace to replace delete, it is awful。
I have been suffering the problem for one year. Please help me!
-----update------
I also found that when I disable the number lock, I can still type normal number using numeric keypad. Very weird.
-----update2-----
I found when I open the pycharm and just press control keys, everything goes well. But once I press a normal character (like a-z), this will trigger the issue, after that, control keys will not work normally.
-----update3-----
I uninstalled pycharm completely, and install it again. the issue still exist.
I restored default setting, the issue still exist.
-----update4----- This issue is related to: https://youtrack.jetbrains.com/issue/IDEA-150932
and
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206345169-Scrolling-with-keys-on-numeric-keypad-with-num-lock-off?input_string=Using%20Numeric%20Keypad%20Arrow%20Keys%20in%20CLion
-----update5----- This issue only exist in pycharm. Everything works correctly outside pycharm.
I know why! How to fix PyCharm keyboard keymap numpad left, right, up & down Ctrl BUGs
PyCharm latest version 2021.2 and many previous versions have 3 types of bugs in Keymap usually with larger keyboards with numpads on the right. (There are more bugs/Trojans in plug-in specific keymaps, that may already use or have conflicting uses of key+mouse+key combinations.)
First to fix the bug (eg missing numpad "left" arrow), open pycharm:
(optional) Update pycharm+its plug-ins and restart.
(optional) Running out of disk space? Delete ONLY the older backup PyCharmCE??? directories that do not match your
[ Help --> About --> Version ] value. Those configuration directories under Linux are ~/.cache/JetBrains/. Obviously do not delete the current PyCharmCE??? version. Windows has a similar set, I think. The bug here is the .cache/JetBrains directories are HUGE, and pycharm update fails to delete the oldest versions 3 versions back!
Go to the editors main Keymap: Ctrl+Alt+s --> Keymap --> Editor Actions and find the keystrokes that offend you, in my case "up" "down" "left" and "right" which are PyChuggyBuggeyWuggy dead unresponsive keys on the numpad.
Strange you will find "up" "down" "left" and "right" already coded into that list. All you do is add the keystroke of interest for each, even if it already looks good, IT IS NOT!
Each action in the Keymap list can have one or more keystrokes. Do not delete the existing keystroke, you will be adding your new one.
Double click on the chosen key in that very long Keymap list eg "left" --> "Add keyboard shortcut" (Confusingly it already says "Left" ignore that, it means non-numpad left, it is a bug).
JUST PRESS YOUR OWN LEFT arrow key (on the numpad) on the keyboard. then press OK. A new left appears, it looks the same but is not ... BUG!
Press Apply --> OK. It just added ANOTHER Left. That is actually a different Left! (That is a BUG and it should say "numpad left"). Test your changes.
For ANY other keystroke or mouse+key combo you can do the same thing, pycharm
may not record the "name" of the action correctly, but it will remember the combo for correct use against each list under: Ctrl+Alt+s --> Keymap --> Editor Actions
MAJOR BUG2 PyCharm SECURITY FLAW. Pycharm repeadedly phones home along with PlugIn violating security at least 160 times a day! Not
asking your permission. The atom editor and sublime do the same, do
not tolerate that, BLOCK THEM with the firewall.
MAJOR BUG3 PyCharm SECURITY FLAW. Plugins have the ability to intercept any and every keystroke and use the Keymap.
Many of the plug-ins are "builtin" and others are optional. They can be updated with fake versions that are trojan horses that capture
keystrokes. I do not see any way of verifying plug-ins, but I do see them violating security and phoning home information without your permission.

Multiple conemu windows - how to differentiate?

Windows 8.1 , ConEmu 170316 [32] {Preview}
I have multiple Conemu instances running, where each instance equals one "workspace".
I would like to be able to switch to this workspaces with autohotkey or pywinauto. However they require a criterion for selecting the right window, and usually I employ a combination of window title and or window class type.
Is there any setting in conemu that can help me achieve this criterion identifiation for window selection? If there isn't, I will have to write the PID down somewhere when I start the conem windows, then read it to bring up the right window at window activation time.
I can say only about pywinauto. When you call app = Application().start('ConEmu64.exe') pywinauto already remembers process PID and every new WindowSpecification object assumes this PID. Of course, it's true only if you're controlling start of ConEmu (or any other app). More details can be found in the Getting Started Guide.
Method app.connect(title="some unique tab name") will also remember the PID in app object. But if there are few instances with the same title, you need to disambiguate it using found_index=0 criterion, for example. Or right click on the tab and choose "Rename tab..." context menu item which changes the window title.
I took a short look at ConEmu. Toolbars and tabs are visible even to Spy++. So the most of actions can be automated. Just not sure about console inside a tab. If you want to type some commands, it's much better to use standard Python module subprocess because GUI automation for console programs looks very very strange. ;)
As per faq (ty Maximus) - see option 1:
1) Use -title “Window name” switch to explicitly set window title of new ConEmu instance. The example below starts new ConEmu window with title My server and ssh to your.server.com inside. Does not matter if you run another tab, or several tabs from task, the ConEmu window title remains My server. So you may rely on the title for selecting the window with class name VirtualConsoleClass.
Option 2 is also valid. I'd have to (1) create a config, and (2) hardcode the hashed id in ahk / pywinauto. Just using the window title name seems the right thing to do in my case, the app id setup seems overkill
2) Windows 7 introduced AppUserModelID. ConEmu uses executable path name and some switches (like -config, -loadcfgfile, -quake) to create a hash to form AppID, which you may see in the About / SysInfo. Current version shows 1d5372066082f23b41ba6aa278e56e9d::163. The trailing ::163 depicts ConEmu internal protocol version which may (and most probably would) be changed in the future. The hash itself is expected to be unchanged. You may query the ID from running ConEmu process using Windows API function GetApplicationUserModelId.
Thank you Maximus!

PyCharm won't accept code completion on enter

since yesterday PyCharm 2016.3 won't accept selected lines from the list of code completion:
If I hit enter, a new line will be set into the editor rather than the selected line of the popup window. Is there any setting for this behaviour? Until now I couldn't find anything.
I noticed on a few occasions the GUI going somehow off-rails, including in ways similar to the one described. I couldn't determine a pattern in the occurences. Just closing and re-opening the project didn't always help.
What worked pretty reliably for me in the end was exiting PyCharm (giving it ample time to finish), making sure no related java processes remains active (running on Linux, in some cases I had to manually kill such processes when it became clear they're not going away by themselves) and then re-starting the IDE.
I found the current keymap for code completion by chance. This is set via:
Settings > Keymap > Code > Completion > Basic

Control position of new Veusz window

This question is about Veusz, a python-based plotting program. Not about usage, but about where to start hacking to fix a particular problem... This is on Windows.
Currently, when the program is launched it starts non-maximized, even if it was maximized last time it was closed. I can modify the shortcut to always start maximized but new windows opened within the app are always non-maximized.
Although it doesn't remember its maximized state, it does remember the size of last non-maximized window. As a workaround, I tried positioning the program top-left and resizing it as if it were maximized. However, when I open new windows from this one, they are offset from the top-left corner by the height of the "window bar". The offset does not cascade though; that is, opening a new window from an offset one results in a window in the same position.
I've been pawing through the program's files looking for somewhere window position might be saved or a default might be set. Not seeing anything, though. This is a Qt app so perhaps it's not Veusz-specific but I'm inclined to think it is. Spyder, for instance is Qt-based but I don't see this problem with it.
Does the community have any suggestions regarding changing this behavior? I don't understand the setup routine well enough yet. The source is on Github if you're feeling that helpful.
The relevant code is here in functions closeEvent (for saving state) and setupWindowGeometry (for loading state).
https://github.com/jeremysanders/veusz/blob/master/veusz/windows/mainwindow.py
Veusz needs to save the state of the window, as well as the geometry. Maybe doing something like this http://doc.qt.io/qt-4.8/restoring-geometry.html

Categories