My alacritty config file is in ~/.config/alacritty/alacritty.yml with the following font settings:
# Font configuration
font:
[...]
# Point size
size: 10.0
All other font configuration options are commented out. I verified that alacritty is indeed reading this config file using the -vvv flag.
However, whenever I open a new terminal window the font seems to be selected at random. Below a picture of two windows opened one right after the other.
This problem is now reported as an issue at the alacritty repository. In general alacritty seems to have many issues with font sizes across different systems.
However, in trying to identify the cause I found that with the -vv flag alacritty always starts the terminal with a font size exactly the double of that in the config file.
So for now it is possible to work around this issue by setting up the font size at half of the desired in the config file. For instance, to obtain a font size of 14:
# Font configuration
font:
[...]
# Point size
size: 7.0
And then start alacritty with the -vv flag:
$ alacritty -vv
Possible workaround is to use -o flag when running alacritty and set font.size to desired value. Can be done through .bash_aliases or your WM config to make it faster to use.
Example:
alacritty -o font.size=8
Btw. I couldn't reproduce random font selection but I had problem with setting custom font size through alacritty config file.
Related
I'm trying to use gsettings to change some of my Gedit settings (Ubuntu 20.04), but my changes seem to be ignored by Gedit. For example, when I change the tab width through
gsettings set org.gnome.gedit.preferences.editor tabs-size 4
my new tab width does show up in
gsettings list-recursively | grep gedit
but when I open anything in Gedit, it's still using the default tab width of 8.
In this example case this isn't much of a problem, as I can change the tab width from the Gedit GUI as well, but other settings, such as right margin position, don't seem to be in the Gedit Preferences menu.
When I tried to sudo the gsettings command I got this error:
(process:4742): dconf-WARNING **: 08:03:40.804: failed to commit changes to dconf: Error spawning command line “dbus-launch --autolaunch=0d66e8250a634e9d8ee4675ca3d977fa --binary-syntax --close-stderr”: Child process exited with code 1
So what would be the correct way to use gsettings here?
Alright, after a good bit of additional searching I found this:
https://askubuntu.com/questions/491217/how-change-gedit-preferences-in-xfce-xubuntu#491296
So apparently (at least part of) my problem is that I'm using the Xfce desktop (I'm usually working over a VNC connection). I'm not sure exactly why/how this causes Gedit to ignore settings changed through gsettings, but installing dconf-editor and changing Gedit's settings there did the trick for me.
I am a user of a HPC system. I now would like to install a new version of gnuplot under my directory /home/username. I succeeded in installing, but now the default terminal type is qt. I now want to change it to x11. The command set terminal x11 is not working, the error messages are:
Expected X11 driver:
/home/app/gnuplot-5.0.6/libexec/gnuplot/5.0/gnuplot_x11 Exec failed: No
such file or directory See 'help x11' for more details
This is weird as I installed the gnuplot in
/home/username/app/gnuplot-5.0.6/
and there is a gnuplot_x11 in
/home/username/app/gnuplot-5.0.6/libexec/gnuplot/5.0/gnuplot_x11
Is there a way to tell gnuplot that it searches in the wrong path? And is there a way to set the x11 terminal as the default one?
Thank you very much!
Update:
I can set --with-qt=no, now the default becomes wxt. Now I can use set terminal x11:
gnuplot> set terminal x11
Terminal type set to 'x11'
Options are ' nopersist enhanced'
I am not quite understand why.
You can change the directory in which gnuplot looks for the gnuplot_x11 driver by setting the GNUPLOT_DRIVER_DIR environment variable. From help x11:
The gnuplot outboard driver, gnuplot_x11, is searched in a default
place chosen when the program is compiled. You can override that by
defining the environment variable GNUPLOT_DRIVER_DIR to point to a
different location.
I need to use a symbol font called Moon Fonts TTF in the PDF output from GNUplot. GNUplot finds it with no problem in the Aqua terminal.
I've tried:
set fontpath "/Users/house/Library/Fonts/MoonPhases.ttf"
and other add font suggestions from the gnuplot help pages with no luck.
I have also tried a series of .ttf, .otf, postscript and unicode-mapped fonts with some support from a typography expert, with no luck at all: pdfcairo, postscript or epscairo cannot seem to find it.
GNUplot's 'show fontpath' gives:
system fontpath is "/System/Library/Fonts" "/Library/Fonts" "/Users/house/Library/Fonts"
and the fonts are there in one of those paths. I also tried placing them directly in GN's working directory.
If anyone has suggestions about how to make this work it would be much appreciated.
OSX Snow Leopard
GNUplot 4.6.1
I have gnuplot installed via MacPorts. The folder /opt/local/etc/fonts contains the file fonts.conf. In there you'll find a section "Font directory list". However, even though ~/Library/Fonts is part of the gnuplot fontlist variable by default (and therefore aquaterm is able to use them), it is not listed in here (and therefore pdfcairo can't use them).
A quick fix is to create the following symbolic link:
cd ${HOME}
ln -s Library/Fonts .fonts
Then your pdfcairo output should pick up the fonts that are installed at the user level on your Mac.
I have tested this with gnuplot 4.6 on Mavericks (10.9.5), and it seems to work fine.
In Ubuntu 10.04 (as a Virtual Machine), I open gVim from command line but every time I switch from terminal to vim and back I see the following warning:
** (gvim:13790): CRITICAL **: murrine_style_draw_box: assertion 'height >= -1' failed
Why do I get this warning and how do I get rid of it?
The installation (via software center) is pretty much unmodified, except the addition of ~/.vimrc:
source $VIMRUNTIME/mswin.vim
behave mswin
set hls
It's a bug in the theme package(s). Resolution here: https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/538499/comments/24
Modify the entry in /usr/share/themes/YOUR THEME IN USE/gtk-2.0/gtkrc from GtkRange::trough-under-steppers = 0 to GtkRange::trough-under-steppers = 1
HTH
I am running a standard installation of OpenSuse 42.3. I ssh to the Opensuse machine via my MacOS computer. When I use vim to view files in the terminal window the syntax highlighting is pleasant to look at. I also have a Docker image of a stock installation of OpenSuse 42.3 installed on my OpenSuse machine. If I boot up the container and open a python file with vim within the container, the syntax highlighting looks different. I did a diff on the contents of the /usr/share/vim/vim74/syntax/python.vim, and there were no differences between the syntax file that is being used on the OpenSuse host and the OpenSuse container.
Below on the left is what I see when I ssh from my Mac to the OpenSuse machine and open a python file. On the right is what I see when I start the docker container ( still in the same terminal window that I started for the image on the left).
Shouldn't the display on the terminal window of the syntax highlighted file be the same if the vim syntax files are the same?
The highlighting in the terminal can depend on the number of available colors. Some colorschemes have separate branches of color definitions depending on how many are available. You can check for yourself via
:set t_Co?
You probably get 256 for TERM=xterm-256color and only 16 for TERM=xterm.
Though you can just force :set t_Co=256 and reload your colorscheme, it's better to fix the root cause, i.e. the wrong TERM value.