I hope I can explain my specific annoyance clearly enough:
Quite some time ago, IntelliJ introduced a feature in the run console to parse the content of the output and would try to print a nice tree structure on the left. However, its default behavior of jumping to the error was very annoying. To illustrate my point:
When it starts normally, the full console output is available in the right panel. However, when things happen, or, in my case of gradle run, when I simply stop it, IntelliJ would jump to the specific block of output only with the error:
Note, in the second screenshot, that there is no scroll bar on the right side of the right panel, and thus I cannot scroll up to view the actual run logs. I have to click the left panel's top element in the tree to be able to view all logs.
The locking to a specific block of output is nice to have, but I am happy without it too, as before it was introduced. But the default jumping to that block is annoying and irritating. Almost in all cases I started and ended a run like this, I have to click the left panel to view the whole log -- this "Build cancelled" error block is of no use at all. And when it's jumping to an actual exception, majority of the time I'd need to look around its context for the cause, which requires me to re-orient myself in the log flow where the block was at. This is very counter productive for me.
I have been assuming IntelliJ should provide an option to either not jump to the error by default (leaving the full log available in the right panel), or to disable the whole console output parsing as a whole.
I have not been able to locate a setting for either of this. Does anyone know if that's possible?
We are working to fix that. Please vote and follow https://youtrack.jetbrains.com/issue/IDEA-241844
Related
I am using IntelliJ Idea for developing scala and Java programs. I am also a screen reader user.
One of the most useful features that IDEs provide is code linting and displaying error and warnings in your code, along with descriptions. I understand if you are a sighted user, you can just hover your mouse over an erroneous line of code and you get a tooltip with the description.
I haven't been able to figure out how to access this description as a screen reader users. So far, to review errors/warnings I would just build the program and look at the command line output, however this is pretty inefficient compared to just hovering over line of code.
Could someone share a better way of reviewing errors/warnings in IntelliJ using a screen reader? Ideally how to access the error tooltip, or how to access a better UI for reviewing them instead of looking at raw command line output.
I'm not sure about warnings however errors can be accessed in two ways:
Firstly when the caret is moved into a line with error the error text is written into the status bar - the problem with this approach is that for JAB applications screen readers are generally unable to find it, so in case of NVDA object navigation has to be used.
The second way requires your caret to be exactly at the point with error - generally it would be set in the proper place if you've navigated to the line with F2. After that you need to press CTRL+f1 - focus moves to the unnamed pane and the error text is its first descendant so once again you need to employ object navigation. I haven't found any reasonable way to access error texts with JAWS sadly.
Importantly, make sure to turn on screen reader support:
settings (ctrl + alt + S) > appearance and behaviour > Appearance > Support screen readers (requires restart)
Then when your caret is on an error/warning, you can press ctrl + F1 and a dialogue will pop up with the description. Press escape to close it.
If you want to make sure the caret is on an error/warning, use F2 to jump to next error/warning.
As noted by lukaszgo1 in his answer, the description is also printed to status bar, but NVDA cant find it using its normal command, because JAB GUI applications are lacklustre in their implementation of accessibility, however if you want to access the status bar of IntelliJ to read the description you can use an NVDA addon which I developed, that adds a command for reading IntelliJ status bar and fixes list items not being labelled properly.
I actually forgot I asked this until I got an answer recently.
Thanks to lukaszgo1 for his answer.
I´d like to know how can I stop execution in smalltalk. I entered an infinite loop and don´t want to loose the code that´s written. I tried using pause button but doesn´t seem to be right.
Normally, even if you are unable to stop execution, you should be able to get the code changes you made back from the .changes file. If you can restart the image, there is a 'recover lost changes' menu entry. Always first make a backup copy of the changes and image files before trying this. (In Pharo/Squeak. Other smalltalk have similar possibilities)
it depends on the dialect and possibly keyboard settings.
try CMD-. or CTRL-., which works in most dialects.
This will probably sound like a minor issue, but it's completely messing up my workflow:
I have a microservice that I restart frequently to refresh changes. I start in Debug mode, and use the curvy arrow in the upper left of the Debug tool window to stop/start the process.
In the Debug window, there are 2 tabs, Debugger and Console. For weeks, I've kept this on Console, and I can see the service run through startup, and I know when to start hitting endpoints. All of a sudden, whenever I start up, it switches to the Debugger tab, which means I have to manually switch back.
No documentation on this, and didn't find anything with a Google search. Does anyone have something to try?
Thank you
Update:
I start with the focus on Console (the right tab) and it switches to Debugger (the left tab). There is a "Focus on startup" in the context menu for Console, but it has no effect.
I'm not sure this is exactly what you're looking for. If it's not, could you please add some screenshots to the question which might better illustrate the problem? But if it is, here is what I found:
In the Debug tool window you have tabs like Output and Variables, which are probably the tabs you are talking about. You can right click any of these tabs and select Focus On Startup. You probably have this option selected for the wrong tab. So try selecting it for the Output tab.
You can toggle the Focus On Startup behavior for other tabs in the Debug tool window too.
I edited this question, as now it seems it's not a coding issue. Might be something with IDE or something else.
I am using Flash Develop 4.5.2 right now.
I added a small check in the class, to test equality. But it's showing strange result.
A 1 min video on Youtube about the problem => http://youtu.be/wHXs7nwyhow
![The flow jumps without getting any of the if-block][1]
[1]: http://i.stack.imgur.com/aD3YM.png
Might be some special characters issue. So, pasted it on notepad, and saved it back as ".as", but still that part is skipped by debugger. No matter, whatever i write there. ( See video )
Vishwas
Seems like a bug. I checked OFF "Omit trace actions" in Flash IDE ( So as to receive the trace statements in the trace window now ). And it's working fine now. ( It seems like Flash Develop debugger, tries ignoring those pieces of code, that are related with trace() in such case.
I've got a problem with an Ext.List:
You press a button on the main menu and are shown the list. Everything on it works fine and it let's you choose, where to go deeper inside the app. No problems so far.
But if you then go back to the main menu by pressing a "back"-button and reenter the page, that shows this Ext.List, it doesn't work anymore: you can't select an entry of the list.
The "back"-button removes the list, if you return to the main menu this way:
setTimeout(function(){page.removeAll();},100);
What's my mistake? Do you know a better method than "page.removeAll()" that really kills this Ext.List to let it then be completely recreated when I choose to see it in my main menu?
Thanks in advance, you guys have the best tips and tricks.
It's hard to tell without seeing your code but I suspect that there is a javascript error somewhere in the program flow that you described. If you display the javascript console in either Chrome or Firefox it should show the error.
Depending upon how the function that creates the list is defined it would normally recreate the list upon page/function entry and there should be no need to 'kill' the list explicitly.