So I'm using the VSCode VIM plugin with easymotion enabled and my leader key set to space. To trigges easymotion, I use the default way of hitting the leader key twice. So to use easymotion I would need to hit space twice and then follow with a motion to tell it in which direction I want to move.
Most of the time this workst fine. But very regularly, I hit space once and then VSCode VIM won't register my next space tap, but only the one after that. It's super annoying when you are in flow while editing and I just spent half an hour trying go replicate it reliably without success.
The first thing I'd like to know is if anyone else is experiencing this? And the second thing of course is how to solve it. It would be enough to know what is causing this most likely even, right now I kind of feel like I'm going crazy.
I am aware that 3 months have passed, maybe you haven't solved or this reply my help other.
I have a Macbook Air M1, I had the same problem I was going crazy, I solved thanks to a guy on reddit...
So you should go into System Preferences -> Keyboard -> [Click the text tab] -> at the right there are 3 checkbox you should uncheck the last one "Add full stop with double space"
"press the restart button to restart Visiual Studio Code and enable the setting."
Now Im going to preface this by saying that this is quite possibly the most annoying thing I have ever experienced in my years computing.
I'm new to VS Code and as such I am knee deep in my settings.json a lot of the time. Especially moreso when Ive just installed a new extension and it comes with loads of parameters, alnd all sorts of goodies - sort of like I did today when I got home from work.
I open settings.json. I add a comment line indicating a new section for my new extension's myriad of settings I half understand, and move any auto-generated config settings from the bottom to the freshly minted position. I start typing, the widget pops up letting me know about all 70+ settings I can fiddle with as much as I please.
I hit tab on the first entry, it goes down. Tab again, "true" goes down.
"A setting has changed that requires a restart to take effect"
OKAY no problem VS code. Quick restart, back to my config.
I start typing the extension again, I get 200ms in or however long it takes for that widgit to appear, and
"A setting has changed that requires a restart to take effect"
I watch the text in my editor contort as the settings are unloaded and reloaded and unloaded again.
I got the first 4 characters of the extension name typed out before this lovely notification reappears.
Now,
when this happens a few times its a little irritating.
BUT THIS IS CONSTANT .Every. Single. Line. I try to add. Each and every setting. Sometimes 2 or 3 times before I actually get the string down, never-mind its value.
I don't know what to do, I am legitimately going to rip my hair out. This is by far easily up there with one of the most frustrating things I have ever been forced to endure. It is relentless.
I dont know what else to do. Ive tried all I can think of.
I just want to learn and use my new extension.
Please for the love of anything help me.
Please.
After mild frustration with the difficulty to make top-level "plain old folders" within Eclipse for visual-organization purposes, I discovered that the thing I'm after is called a "working set". Hooray! But they don't seem to be rename-able, by any of the apparent avenues (right-clicking on it or using the Configure Working Sets window).
Is that just the way things are, since no one should be so lazy as to refuse making a new working set with the right name and transferring everything over? Or am I missing something obvious?
I also have a more minor question whose answer I already think I know. Can I tell a specific working set not to change its icon to have the "red X" when one of its children has an error? Nothing in the preferences under Debugging suggests to me the ability to turn off the automatic icon-changing. It's a useful feature, but I have a few simple practice projects with very basic errors, and I don't need the visual reminder to "fix" them, especially if they're in my "Practice" working set, whose icon I'd prefer not to change.
To rename a Working Set, you need to get to the dialogue of selecting a Working Set (click on the white down arrow at the top right of the package explorer > Configure Working Sets..), focus on your Working Set and click the "Edit" button. There, you can change the Working Set's name, as well as what's actually included in the Working Set.
There is no way (that I know of) to change the icon display to avoid showing the errors marker.
This one's new to me.
I downloaded and installed the VB.Net version 3.5 updates, and got some complaints about my printer drivers, which I ignored. My system auto-rebooted without asking, and then came up with am "Active Desktop Recovery" background screen (everything still works normally). So when I tried to "restore my active desktop" ( a button on the background screen) it claims a script error.
Okay, fine, I wasn't using the active desktop anyhow, so I decided to turn it off. Go to the Display Properties window, and WTF! The Desktop tab is gone!
Anybody know the fix for this, or even a workaround??
Sounds like malware, perhaps trying to hide whatever changes it made to your desktop and prevent you from undoing them. Give your favourite anti-malware a go.
Afterwards, to restore the tab and fix the recover button thingie there's a few MSKBs: 929200 and 929200.
Set the decimal value to 0 under the value DeskHtmlVersion in key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Desktop\SafeMode\Components.
I am using Windows, and I have two monitors.
Some applications will always start on my primary monitor, no matter where they were when I closed them.
Others will always start on the secondary monitor, no matter where they were when I closed them.
Is there a registry setting buried somewhere, which I can manipulate to control which monitor applications launch into by default?
#rp: I have Ultramon, and I agree that it is indispensable, to the point that Microsoft should buy it and incorporate it into their OS. But as you said, it doesn't let you control the default monitor a program launches into.
Here's what I've found. If you want an app to open on your secondary monitor by default do the following:
1. Open the application.
2. Re-size the window so that it is not maximized or minimized.
3. Move the window to the monitor you want it to open on by default.
4. Close the application. Do not re-size prior to closing.
5. Open the application.
It should open on the monitor you just moved it to and closed it on.
6. Maximize the window.
The application will now open on this monitor by default. If you want to change it to another monitor, just follow steps 1-6 again.
Correctly written Windows apps that want to save their location from run to run will save the results of GetWindowPlacement() before shutting down, then use SetWindowPlacement() on startup to restore their position.
Frequently, apps will store the results of GetWindowPlacement() in the registry as a REG_BINARY for easy use.
The WINDOWPLACEMENTroute has many advantages over other methods:
Handles the case where the screen resolution changed since the last run: SetWindowPlacement() will automatically ensure that the window is not entirely offscreen
Saves the state (minimized/maximized) but also saves the restored (normal) size and position
Handles desktop metrics correctly, compensating for the taskbar position, etc. (i.e. uses "workspace coordinates" instead of "screen coordinates" -- techniques that rely on saving screen coordinates may suffer from the "walking windows" problem where a window will always appear a little lower each time if the user has a toolbar at the top of the screen).
Finally, programs that handle window restoration properly will take into account the nCmdShow parameter passed in from the shell. This parameter is set in the shortcut that launches the application (Normal, Minimized, Maximize):
if(nCmdShow != SW_SHOWNORMAL)
placement.showCmd = nCmdShow; //allow shortcut to override
For non-Win32 applications, it's important to be sure that the method you're using to save/restore window position eventually uses the same underlying call, otherwise (like Java Swing's setBounds()/getBounds() problem) you'll end up writing a lot of extra code to re-implement functionality that's already there in the WINDOWPLACEMENT functions.
It's not exactly the answer to this question but I dealt with this problem with the Shift + Win + [left,right] arrow keys shortcut. You can move the currently active window to another monitor with it.
Get UltraMon. Quickly.
http://realtimesoft.com/ultramon/
It doesn't let you specify what monitor an app starts on, but it lets you move an app to the another monitor, and keep its aspect ratio intact, with one mouse click. It is a very handy utility.
Most programs will start where you last left them. So if you have two monitors at work, but only one at home, it's possible to start you laptop at home and not see the apps running on the other monitor (which now isn't there). UltrMon also lets you move those orphan apps back to the main screen quickly and easily.
I'm fairly sure the primary monitor is the default. If the app was coded decently, when it's closed, it'll remember where it was last at and will reopen there, but -- as you've noticed -- it isn't a default behavior.
EDIT: The way I usually do it is to have the location stored in the app's settings. On load, if there is no value for them, it defaults to the center of the screen. On closing of the form, it records its position. That way, whenever it opens, it's where it was last. I don't know of a simple way to tell it to launch onto the second monitor the first time automatically, however.
-- Kevin Fairchild
Important note: If you remember the position of your application and shutdown and then start up again at that position, keep in mind that the user's monitor configuration may have changed while your application was closed.
Laptop users, for example, frequently change their display configuration. When docked there may be a 2nd monitor that disappears when undocked. If the user closes an application that was running on the 2nd monitor and the re-opens the application when the monitor is disconnected, restoring the window to the previous coordinates will leave it completely off-screen.
To figure out how big the display really is, check out GetSystemMetrics.
So I had this issue with Adobe Reader 9.0. Somehow the program forgot to open on my right monitor and was consistently opening on my left monitor. Most programs allow you to drag it over, maximize the screen, and then close it out and it will remember. Well, with Adobe, I had to drag it over and then close it before maximizing it, in order for Windows to remember which screen to open it in next time. Once you set it to the correct monitor, then you can maximize it. I think this is stupid, since almost all windows programs remember it automatically without try to rig a way for XP to remember.
So I agree there are some apps that you can configured to open on one screen by maximizing or right clicking and moving/sizing screen, then close and reopen. However, there are others that will only open on the main screen.
What I've done to resolve: set the monitor you prefer stubborn apps to open on, as monitor 1 and the your other monitor as 2, then change your monitor 2 to be the primary - so your desktop settings and start bar remain. Hope this helps.
Do not hold me to this but I am pretty sure it depends on the application it self. I know many always open on the main monitor, some will reopen to the same monitor they were previously run in, and some you can set. I know for example I have shortcuts to open command windows to particular directories, and each has an option in their properties to the location to open the window in. While Outlook just remembers and opens in the last screen it was open in. Then other apps open in what ever window the current focus is in.
So I am not sure there is a way to tell every program where to open. Hope that helps some.
I've noticed that if I put a shortcut on my desktop on one screen the launched application may appear on that screen (if that app doesn't reposition itself).
This also applies to running things from Windows Explorer - if Explorer is on one screen the launched application will pick that monitor to use.
Again - I think this is when the launching application specifies the default (windows managed) position. Most applications seem to override this default behavior in some way.
A simple window created like so will do this:
hWnd = CreateWindow(windowClass, windowTitle, WS_VISIBLE | WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, SW_SHOW, CW_USEDEFAULT, 0, NULL, NULL, hInst, NULL);
Right click the shortcut and select properties.
Make sure you are on the "Shortcut" Tab.
Select the RUN drop down box and change it to Maximized.
This may assist in launching the program in full screen on the primary monitor.