Are you using Flymake + Emacs + GHC Inferior Mode? When I have an Flymake Error raised with red background color in the editor - I can move the mouse over and get an yellow tooltip explaining the error. Unfortunatelly the tooltip disapperas approx. 10 seconds later.
How can I prevent this? My error messages are long and I need time to read :-)
Unless you are really attached to overlays, I find it much more convenient to have the error messages displayed in the echo area. To try out if you like this behavior, you can easily toggle it with M-x tooltip-mode. If you are the keyboard centric type, also see the discussions on EmacsWiki on how to display FlyMake errors without having to mouseover them:
http://www.emacswiki.org/emacs/FlyMake
Related
I updated my Android Studio recently to 4.0 and now when I type code incorrectly, and I mouse over the red squiggly line to see what it expects or suggests, the tooltip appears and disappears very quickly. I can't read it. In fact, it's even harder now to get the thing to show up, it's very precise where the mouse pointer is. I've restarted everything including my computer. I've changed the tooltip settings from 700 to 2000 with no change. Anyone else have this issue and know how to fix it?
Thanks all!
I found the answer via this link:
Android Studio , tooltip disappearing so fast
Basically, put a bunch of random letters in your filter for Logcat and it will stop the messages, the tooltip will stay up. When Logcat is running it's interrupting the tooltips now for some reason. I think this must be a bug.
Hi, does anyone know what is it on the left?
It is unfoldable, non-draggable, useless and empty area across entire code. It appears in every opened class. If you click on it, you'll set a breakpoint. You can not collapse it. I do not remember how or why I got this, but then I didn't find any key or menu or button combination to heal this bug.
THis is the last Android Studio 3.6.3. And the same was before upgrade.
Please help, it eats my space and nerves!
UPD Gutter icons look ok.
Maybe your gutter icons are messed up. Check via the settings or the context menu on the gutter (i.e. where the line numbers are).
After 2 months of terribly inconvenient work I finally found the cause. To turn it off do
View - Appearance - Exit Distraction Free mode.
Amazingly, but this big white indent was intended to not distract me (from what? nothing else has changed).
While my search for a Python debugger on Emacs remains unfulfilled, I am giving PyCharm CE a test drive.
Already on my second day I'm encountering a trivial but frustrating point. Is it possible to set the background to be pitch black in just one place?
A program written by programmers for programmers should certainly have included a feature such as "change the background for Docstrings, Comments, Keywords, ... the whole shebang" to black, but I don't see it.
I understand of course that some parts of the UI will stubbornly refuse to change, and I'm OK with that, just so long as the Python code itself appears on a pure black background.
The Twilight and Mokokai themes come close, but their backgrounds still leave ample "contrast room" that could be used by darkening the background color.
(How do we get from left to right... err.. I mean.. how do we get darker than we are.. um, wait... Isn't the version on the right so much easier on the eye.. but anyway, how can we do it?)
Update
The exact same problem and solution apply to Android Studio.
In File > Settings:
Go to Editor > Colors & Fonts > General
Choose the theme you want to modify (will likely need to Save As... your own as you can't modify the default color schemes.
Go to the Text > Default Text colors and change the background to black. The only ones that won't be affected are the syntax highlighters that define their own background (usually select/highlight/errors/etc.)
This is the popup I mean:
It happens to obscure the indicator margin for a couple of lines, making it impossible to drag the current statement indicator to those lines.
The "Debugging" toolbar has a button called "Show threads in source":
Turn it off to disable this pop-up, along with the messy-looking graphic underneath the current statement indicator:
(took me far too long to find this, and Googling didn't help, hence this answer... it doesn't help that this button cannot be found by searching for "thread"in the otherwise excellent Quick Launch search box)
I have an interesting (but frustraring) problem. I have an application which uses the full screen (this is meant to simulate a third-party fullscreen POS application).
My application displays a sequence of modeless dialog boxes on top of the full screen application. It shows one, hides it, then shows the next, hides it etc. After the 3rd show, the Windows taskbar appears about 1 second later. I can't figure out why.
I've stripped my code right back to see if its something I'm doing in my OnNcActivate handler (which I use to draw my skinned window) but I don't think it is as the problem appears to be timing related. I've tried running Spy++ as well as dumping messages in m WindowProc myself and I still can't see anything odd that would give me any clues.
There are some messages with ID 0x36e in my logs but I can't find out what they are supposed to be. I've checked various message ID lists and can't find them. They shouldn't be any message IDs of my own since WM_USER doesn't start until 0x400.
I know I could get around this problem by auto-hiding the taskbar but I can't ask our customers to configure their taskbars to auto-hide to get round my problem.
Any ideas why the taskbar would appear in relation to my modeless dialog boxes?
EDIT: I completely stripped out my self-drawn GUI code and I still have the same problem. I could be wrong but it would seem that when I call ShowWindow( SW_HIDE) first, Windows tries to activate "another Window" (as it says in MSDN). I think in this case its activating the taskbar rather than the POS application. If on the other hand I open my second window before calling ShowWindow( SW_HIDE ) on the second, then it seems to behave itself.
Cheers
Sparky
Following a long discussion I come to the conclusion that DestroyWindow was not the problem. I found in the end that displaying a dialog.. clicking on the POS, then clicking back on the dialog that sometimes the taskbar would appear. I have spent an entire week trying to find reasons for all of this but to no avail. I thought that assigning the POS window as the owner would solve the problem - it didn't. In the end the solution for my problem was to determine if the taskbar is obscured completely before showing my dialog. If it is, I hide the taskbar for the duration which my dialog is displayed (set its placement to SW_HIDE) and then set it to SW_SHOW when I close my dialog. The task bar doesn't pop up and annoy people anymore. Not a fantastic solution for other peoples' applications perhaps, but perfect for our customers.