I've installed the WebStorm 2016.2 editor. I opened one file, and now whenever I make any changes the window for that file the editor cycles through the following states:
When I modify the file a dialog with "Updating index" shows (with no cancel or other controls) running for about half a minute
Then there is a progress bar at the bottom of the editor, "Indexing", which goes to completion, taking about another half minute
After this any click on the file will repeat this cycle
I've tried invalidating the cache, restarting the editor, and also reverting any changes to the file, none of which makes a difference.
It turns out that I had accidentally excluded the file i was editing from the Webstorm project. When I undid that exclusion the problem went away.
I can only presume that Webstorm was detecting that the file hadn't been indexed, and therefore ran the indexer, but the exclusion meant it wasn't indexing the file. Thus the next time the file was touched it tried to run it again.
Related
I'm running WebStorm and have two panels open - one for CSS, one for SASS. What I want is, once I modify the SASS file, the CSS file should update immediately. However, it takes about 10 seconds for this to happen. This is just a visual update however - if I refresh my browser I can see that the page has changed to reflect the modified CSS. The issue is that the CSS file does not seem to update itself quick enough, unless I close and reopen, or wait about 10 seconds.
I've tried to create a custom file watcher that watches for changes in the CSS file, and run a AutoHotKey script, which sends the keystrokes CTRL+ALT+Y. This is the keyboard shortcut to 'reload from disk'. This doesn't work either.
Is there any way to actually get the CSS file to update immediately on external changes? I have the "Synchronize External Changes" checked as well.
I often use various hotkeys to navigate files in a codebase using Visual Studio 2019:
ctrl+, lets me type a filename, and hitting enter opens that file
I have ctrl+a mapped to toggle between .cpp and .h files
I use ctrl+] to "go to definition", etc...
I also often use a split frame: my "workspace" consists of two views of files, side by side, and each has its own list of open tabs.
The behavior I would like to force is, if I use a shortcut to open a new file (or really attempt to open a file by any means...), it should open that file in the current frame.
In fact, that IS the behavior if either A. the current frame already has the target file in an open tab, or B. neither frame has the target file open in a tab.
But when the other frame has the target file in a tab, VS switches focus to the other frame and selects that tab.
This makes it very difficult to keep one frame open as a reference, and the other as an active development buffer, as VS keeps shuffling them from under me.
So I have not changed any settings in my code blocks editor and yet this appears I am new to the code blocks editor and if anyone could explain how this could popup so I can fix it and I have heard people will disable code completion to fix this but I never had the problem with it on so
I have tried disabling code completion this did fix the problem but it normally wouldn't do this with code completion on and I don't want it off
Open Code Blocks settings screen
Click "Editor..."
On the left, choose "Code compliation"
Choose "C/C++ Parser"
Make sure the checkmark on "Use one parser for the whole workspace" is checked
Then after saving the changes restart your Code Blocks IDE and make project save it. After that your issue is resolved.
None of the solutions mentioned above helped me!
I found myself solution, try whether it works for you not!
settings -> Editor -> scroll down (left options) -> Code Completion -> C/C++ parser -> Use one parser per project Check this option -> Maximum allowed parsers keep it less mine worked when i keep it to 2
It seems that rebooting the program has fixed this problem... Also I uninstalled the Library finder which I had opened once by accident then closed the program not saving and changes to anything which then restored library finder and apparently fixed the issue...
This worked for me:
Create two C/C++ files. Build and run them. Go to the C/C++ file you've built first and try to write something. Now, your issue should be fixed.
There's a youtube video explaining this trick. You can watch this if you face any difficulty: https://www.youtube.com/watch?v=sduqmX_VXB8
It's very simple. Save the file declaring which type it is. If C++, save it as whatever.cpp and it's gonna work.
Your file name should start with lower case alphabet.
We have to simply do one thing i.e. stop the code completion.
Goto "Settings" menu --> "Editor" --> "General Settings" (Left Pallet) --> "Editor settings" tab --> uncheck the "Code completion" checkbox..
Save the setting and you are good to go.. now u will never get that pop-up again..
Sometimes in Visual Studio 2017, when opening a code-behind file, the page is empty.
If I close all the tabs, and reopen the same file from the Solution Explorer, the code will display.
Is there something about the way the project file is being saved, when tabs are left open, that might be causing this blank screen? Is there a way to close all tabs automatically when VS is about to shut down? Or a way to tell VS not to even bother to remember which files were open?
I'm using JetBrains Webstorm IDE and set it up to run my Protractor tests from inside, and all the command line output shows nicely in the test runner, but the browser window pops up over everything and I find it extremely distracting. Is there a way to stop it from showing? Or forcing it to stay minimized?
This applies to Karma - but maybe you can do the same thing in Protractor.
My horrible hack for this is to launch Firefox with -with-tab instead of -no-remote and set the Firefox tab loading behaviour by using the info at http://www.techsupportalert.com/content/how-stop-firefox-stealing-window-focus.htm - basically by setting browser.tabs.loadDivertedInBackground to true.
This prevents the window stealing focus when you load a new tab. You end up with a lot of tabs though.