I today tried tabbar-mode, both version 2.0.1 obtainable via the marmelade elpa repository, and version 2.0 from dholms github repository. When tabbar-mode is activated, keystrokes are lagging noticably (I'd say >1s).
I'm using emacs-24 as long running daemon, with cedet, gnus, erc active, with 2-3 clients showing ~7 Frames. The OS is linux, the windowmanager awesome.
Can you provide any hints what might be responsible, where to look?
It's actually pretty simple; tabbar uses three icons to the left of the tabbar; glancing over the code I noticed that it meddles with transparency issues -- that raised a red flag.
Setting
(setq tabbar-use-images nil)
before activating tabbar-mode replaces the icons with text - voila, everything is smooth again.
Related
I've installed latest Fedora-36 + Gnome-42 distro and got some strange issue with keyboard layouts.
Somehow VSCode and gnome conflicting and (i guess!) i get frequently overridden keyboard layout.
FYTK how my keyboard layout looks like after some work:
Idk if this is ok for keyboard layout to look this way, but i still have an issue of periodic hard VS Code freezes.
Also, sometimes, i get a problem of static keyboard layout, that even after manual switching (by hotkeys) to another, my layout continue to be the same. To fix this i need to do a lot of tries of win+space (my hotkey) and after 20-40 repeats it comes back to normal.
Interesting fact: it does not depends on time. I could go afk for some time and nothing changes.
Without VSCode everything seems to work fine.
System:
Fedora: 5.17.14-300.fc36.x86_64
Gnome: 42.2
VSCode: code-1.68.1-1655263151.el7.x86_64.rpm
Before writing question i've tried to install different verisons of VSCode, like insiders 1.69 or flatpak one. Nothing changes.
VS Code freezing was a nvidia issue. Keyboard layout stopped to be static after driver fix.
I guess overriding was just my imagination.
Where did my VSCode indent guides go?
As best as I can recall, indent guides were working as advertised in VSCode 1.17.2 on my MacBook Pro (macOS Sierra 10.12.6 (16G29)) a few hours ago. Now, with no change to any settings and without closing/reopening the editor, I notice that they're no longer rendering. I checked multiple file formats and none of them work.
I checked editor.renderIndentGuides. It's defaulted to true, and isn't being forced to false anywhere, confirmed by noting that vscode.workspace.getConfiguration("editor")["renderIndentGuides"] evaluates to true).
One minor oddity I noticed was that the settings editor itself was correctly showing indent guides until I restarted VSCode and now it's broken too.
After noticing the problem, I briefly installed the Guides extension to see if it would make things any better. It worked, but I found its appearance slightly too in-your-face and didn't need any of the special bits (in which case the Guides README recommends not to use it) so I removed it, after which guides are again not rendering. If nothing else works, I'll reinstall Guides and see if I can tweak it to suit, but I'd rather just have VSCode work as intended.
I narrowed the problem down slightly to the MBP's built-in retina display. When I run on a non-retina external screen, I see the guides. However, even there, I noticed that playing with indentation level settings causes the guides to break up a little and I have to close and reopen the file to restore order.
I figured out the proximate cause. Setting the font too small (< 12pt) produces aliasing on thin (presumably 1-pixel) lines.
A non-retina external screen exhibits similar behaviour, though it requires smaller fonts. Also, while both screens have trouble with rulers, only the retina screen loses the guides.
So like other Agda enthusiasts, with the release of the new version of Agda, I quickly cabal-force-installed the latest and greatest. However, after compiling and setting-up agda-mode (the new one), my emacs is giving me some strange settings.
I no longer have an include dirs menu when I attempt to customize agda, I've circumvented this by using the program args menu and adding --include-dir=<stuff>. However, the colour scheme is bothersome. In a literate agda file, everything outside of \begin{code} and \end{code} is coloured salmon-red and I want it to be black as was in older versions.
I've played around with the highlight settings, but just could not get this to change. Any advice would be most appreciated!
Thank-you!
Edit : the removal of the include-dirs is no error, the change log under the emacs section mentions this and more.
I had been using Eclipse 3.x for a few years and while I had a few issues w.r.t. its stability and performance, I never had any particular annoyance with the UI itself...
Now that the new and shiny Eclipse 4.2 is out of the oven, it feels more stable and somewhat snappier, but I instantly felt a dislike for some details of its UI:
I find the "curved" look of the main toolbar distracting and it seems to me that it does not mix well with any other element in my desktop. It could just be a color issue, but the toolbar is prevalent enough to merit a specific mention.
The default colors do not work well with the TFT/TN displays of the laptop and both desktop computers that I am using. The various gradients seem completely washed out, the tab separators are practically invisible and the toolbar curve looks totally weird.
It's also almost impossible to tell which view is active - Eclipse 3.x used a unique blue color for the active tab header. Juno uses a color-reversal in all inactive tabs, which probably sounds more visible, but in my opinion that effect is lost because the active tab is still in a shade of gray which is lost in the overall gray-ness of the new UI...
So, how do I get back to a more reasonable look and feel? Is there somewhere a theming option that would help?
PS.1: I use Eclipse/GTK on Linux...
PS.2: What happened to all the colors in Juno, anyway?
PS.3: Can we keep the new splash screen, though? That one, I like...
Apparently, the Eclipse developers were kind enough to leave us an easy way out:
From the Window menu, select Preferences.
Expand the General category in the Preferences dialog tree.
Click on the Appearance sub-category.
On the left side of the window, a Theme drop-down menu will appear - click on it.
Select Classic in the Theme drop-down menu.
Most important: you need to restart Eclipse after that, even though no hint to that effect appears.
This setting is mentioned in several blog posts, which for some reason I could not find until I started using terms such as "awful" and "ugly" in Google. It seems that I was not the only one to find the new theme unbearable...
There is another way documented here.
This goes a lot further than the switch to classic theme and makes it look like 3.x.
The problem with the Juno L & F is that its great on monitors with 1600x1050. But my work PC has 2 screens that are 1280x1-24. Not so great!
I found a way to make Juno look like Indigo: I know there are new fancy themes around but I'm not willing to spend time on it.
My solution is just to copy the Indigo css_prefs files into Juno directory
.metadata/.plugins/org.eclipse.core.runtime/.settings
The file you have to look for are
org.eclipse.e4.ui.css.swt.theme.prefs and org.eclipse.wst.css.ui.prefs
If you don't have them you can download from my blog http://www.venturin.net/2013/04/04/eclipse-juno-looks-ugly-in-linux-mint-14-nadia/
To restore traditional style tabs on more recent versions of Eclipse, edit e4_classic_winxp.css and change swt-simple: false; to swt-simple: true; (this assumes you are using the default Classic theme).
On Eclipse Kepler this file is located in:
eclipse\plugins\org.eclipse.platform_4.3.2.v20140221-1700\css
On Eclipse Mars this file is located in:
eclipse\plugins\org.eclipse.ui.themes_1.1.0.v20150511-0913\css
(load "~/.elisp/nxhtml/autostart.el")
(setq mumamo-chunk-coloring 'no-chunks-colored)
I currently have the above in my .emacs and the chunk coloring is still showing up. I have also tried disabling it through customize-option and then setting the state to "no chunk coloring" in mumamo-chunk-coloring. I'm using the latest emacs23 from cvs and have the most recent nxhtml release.
What is the correct way to disable the coloring of different major modes?
Bug. I forgot to add this possibility back when implementing chunks in chunks.
I have just corrected this in 1.88 (which is yet in beta).
Note that in the new version you will use a number for mumamo-chunk-coloring. Set this to 1 to avoid coloring main mode chunks etc.
BTW: Just happened to see this. If you want bugs to be corrected it is normally much better to report them in nXhtml bug database on Launchpad.