I noticed that Emojis like 😀 are not displayed in gvim on my system but they are in terminal vim if that is used in an xterm or konsole. And yes I tried many guifonts capable of displaying them (noto mono, noto color emoji, hack). I also noticed that vim in gnome-terminal doesn't display them either (although using the same fonts in it as in the other terminals). In fact I haven't found a single gnome(?) or gtk(?) application that displays them - not even when I use a gnome X-session. On the other hand no kde app has problems with them. Searching the web I got the impression that, e.g. gnome-terminal should have been able to display emojis for quite some time now. As I use a rolling distribution (openSuse tumbleweed) my software should be pretty recent. So what am I missing? Is there a specific package I need to handle emojis in gtk?
Update
I created test user on my system with default settings. To my big surprise if I log on to the X-system as that user emojis are displayed just fine in gvim. So it must be a configuration issue. Then I went back and logged into my normal account, used su testuser and then opened gvim. I could still see the emojis. I don't want to reset my configuration as I put a lot of effort to have the system behave the way I like it to. But I am at a loss in finding the responsible setting. Any ideas?
Finally, I found the culprit and wanted to share my insight here so that others with similar problems know where to look. In ~/.config/fontconfig/ there were three files I did not put there myself. I guess they were leftovers from some configuration tool. Using a rolling release distribution there are probably many orphaned files in my ~/.config directory. Anyway, after deleting those files and logging out and back on I can now see emojis in gvim etc.
Im using vim inside a gnome-Terminal to edit a Python Program. Im also using a tiling Window manager calles awesome-wm.
Inside my Python program im plotting some data to a matplotlib graph (when executed that opens another window). When i want to test my Program i use the following comand to run the Program from inside of vim.
:!python3 %
when the Program runs it prints three messages to the shell and opens a matplotlib window to plot the data.
Sometimes i can only see the messed up linebreaks and have to scroll up to see the messages.
My question now is why is the formating inside the console messed up an how do i fix it?
My guess would be that the Terminal Window does not notice that it is beeing resized when the plot window is beeing opend, but i dont know how to refresh the terminal in that case.
using :!clear; python3 % does not help.
Thanks in advance.
(Well, it isn't a direct solution to your problem, but here it goes.)
Most terminal don't handle reflow in resize properly. There is no right ways to do it so most don't attempt to pull all the tricks in the book to make this better. After all, for classic floating window manger, resizing isn't something you do very often. LibVTE/Gnome-terminal isn't designed for tiling WMs and has not been patched over the years to make it better.
Urxvt is probably the most common terminal for AwesomeWM (the default is xterm because it is much more commonly installed by default). It has more advanced features like tabs and transparency you expect from modern terminals. Note that some of them (tabs) are disabled by default.
Sometime using software like tmux can be used to mitigate some of the limitations of any given terminal, but it comes with limitations of its own.
I have situation that I'm calling mplayer every x minutes from xulrunner application and it always gets focus and comes on top, in front of other windows. But I need it to be behind xulrunner which has transparent box in which video should be visible.
Is there some way to force new process (mplayer) to be behind oldier process (xulrunner) and not to get autofocus on it?
Is it a Linux window manager level or there's some property in xulrunner or mplayer? (I'm using Fedora 18 with Openbox)
A solution can be achieved using devilspie. This tool allows you to customize many properties of application's windows including their focus, decoration, placement, and geometry. There is a handy frontend for it called gdevilspie, though there are no rpms available so it must be installed from source.
You can set devilsiie to match on all mplayer windows and set their action to "below" which will place them below all normal windows. Unfortunately this will apply to all invocations of mplayer, so this solution may be annoying if you use mplayer under other circumstances.
In Ubuntu, for example, you can use Super-M to invert the screen colors (requires desktop effects, see [1]). Other OSes have similar abilities, although I'm not really concerned with anything other than Linux.
Which API should I look into if I want to write a simple program that, when run, inverts the screen colors?
The language that I use the API from doesn't particularly matter to me. I am familiar enough with C/C++/Bash/Perl/Python that I can hack this up in whatever language has the easiest access to this API. Working on Ubuntu is required, working on other similar *nixes is not terribly important.
[1] https://help.ubuntu.com/community/KeyboardShortcuts#Desktop%20Effects%20enabled%20shortcuts
You could use xcalib to do what you want.
For example, a simple bash script to invert the screen colors would look like this:
#!/bin/bash
xcalib -invert -alter
Here are scripts and instructions for shifting colors using compton: https://github.com/vn971/linux-color-inversion
xrandr-invert-colors worked out of the box for me.
xcalib does not work for me using xorg and a tiling window manager, with an external display and gives me the following error: "Unable to get a display calibration".
Credit to Imat.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Background
I'm building an application where it detects what documents you're using from the file system. To do this it must access the AXDocument attribute of the active window. MacVim provides this. Running Vim in the Terminal wouldn't provide this.
I've just put out a survey to ask what editor coders who are interested in my app use. A significant number of the folk using Vim used it directly from the command line.
Why not use a GUI Vim?
Why do some people prefer to run Vim this way versus a GUI implementation like MacVim?
What advantages does this offer? As I understand it, you can send files to MacVim from the command line just as easily as command line Vim.
These reasons may be different for each specific developer but my guess would be:
vim is pretty much vim on any platform. GUI implementations can
vary.
Familiarity - being familiar with vim does not nessecarily mean
being familar with vim wrapped ina
GUI - espectially given #1.
"Elite Complex" ;-)
No definite avantages to the users over cli vim.
One might not have access to a gui (think ssh) or simply force of habit.
Although I don't use any feature exclusive to the GUI version (never touch the mouse while editing) I find GVIM more pleasing to the eye for fonts rendering and color management. So the only reason to use the cli version is not having access to a graphic environment (like when accessing a remote machine via ssh). Using GVIM also allows reuse of the terminal it was called from without having to use screen.
being able to run vim under screen provides
reliability: it will stay alive if X or the terminal app crashes. not sure how applicable this is to the Mac.
the option to multiplex sessions within terminal tabs. I actually end up rarely using terminal tabs because of this. It's possible (albeit a bit confusing) to set up heirarchical screen sessions and move branches of them around. screen is super awesome. This also provides an additional layer of text buffering in which you can search by regexp — this is useful if you spawn a shell command that is pages long and you're looking for a particular word in there.
the ability to connect to an existing session from another computer or reconnect after a network outage
and friends
in addition to making it possible to use screen, the console vim provides better shell integration. Although it's possible to run shell commands from within gvim (again, I'm not sure how this applies to the Mac, I'm a linux guy), there are limitations. I rarely use a gui vim so I'm not sure about the exact limits. For example, ANSI color codes are removed. I find this annoying because I tend to interact with SCM that way, for example running :!git diff --cached to check the changes in the index before committing. It makes for a somewhat quicker and more satisfying (mmm, diffy!) read if it's colourized.
I used to feel that gvim was a big improvement for viewing diffs, but I've changed the background colour of my terminal to a dark non-black shade, and set
:highlight DiffAdd ctermbg=Black
:highlight DiffChange ctermbg=Black
:highlight DiffDelete ctermbg=Black
:highlight DiffText cterm=Bold ctermbg=None
The result of this is that in diff mode, differing text shows up with a black background, and unchanged text is coloured with the terminal background colour. For side-by-side diffs, this works wonderfully, since you can tell immediately based on the other side whether a given line is a change or add; for non-side-by-side you will be able to see an unchanged part in a changed line.
This means that you can leave syntax colouring on and still be able to see diffs. Again, you do need to be able to set the background colour of the terminal to a unique, dark, non-black shade. This facility is available in the terminal emulators that I use (yakuake/konsole and roxterm) and many others.^[?Mac^M"mya)^O^Op
This also assumes that you're using a colourscheme meant for use with a dark background colour; I use a modified delek.
Although I haven't tried this, there is also the option to run console vim in 256-colour mode on terminals which support that mode — which I believe includes most or all modern ones. This can serve to make much of the subtlety of GUI colorschemes available to console vim.^["mp
I also like it that it lives in the place where it was started, and starts up quick. So if I'm navigating around in the shell, as per my wont, I can edit a file without interrupting that flow or having to farm that operation out to a different piece of conceptual real estate. Having less things to keep track of is a big plus. Being able to background it is helpful, too, for example if I need to grab the contents of an unexported shell variable via xclip. If I'd spawned a GUI window instead I might have some trouble remembering where that shell was, or might have already closed it.
My main reason for using a gui vim at all is that it makes somewhat more sense as something spawned from a gui app, eg a browser. In practice I never do this, and I suspect that it's fairly equivalent to just have a new terminal window pop up with a new console vim in it. Though there is likely some (window manager) window management functionality that is exclusive to gui implementations. This is pretty similar to the use case you're discussing.
gvim is actually just a basic terminal emulator with vim running in it, and some menus and toolbar buttons up the top.
So if you have a good, full-featured terminal emulator already, you may as well use that instead, since you'll be using the same type of terminal window that you are familiar with across all your terminal sessions.
Another benefit is that it makes it easy to switch to a shell inside vim and then switch out seamlessly.
On Windows I prefer gvim. On Linux it's vim inside gnome-terminal, which is nice and configurable thankyou.
To avoid (or at least minimize) the use of the mouse.
some gvim variations can't handle
some of my hotkeys
some spawn separate window when i try
to compile program
sometimes they simply can't use fonts
like fixed or terminus correctly
(think about "terminus bold" - some
gvim variations simply stretch
"terminus normal" instead of
rendering with the separate font)
cli generally works faster than gui,
especially if running in real
textmode console (not possible on a
mac though)
there are almost no benefits in using
GUI version, and i'd loose ability to
run in screen, ssh, to suspend
process with ctrl+z, and many more.
The main reason I use the command line is that I spend most of my day in a terminal already, and my use of vim reflects this. I do not open up vim for a long while just editing different files then opening others without closing it; I usually open a file or two do a few edits then do some command line tasks, maybe change a directory, and open up vim somewhere else. When using the a gui there is substantial lag when opening the editor. This wouldn't bother me if I opened it once and left it open but I tend to not work that way. So the command line works better for my workflow. Furthermore since there is no real benefit feature-wise of the GUI over the command line and vise-versa, I've always just stuck with the command line since it suited me better.
vim is way more performant with huge files (100-500MB .csv or .xml files in my case).
gvim beats vim hands-down when used to compare files (gvimdiff): setting the font (want more content on the screen?), dragging the window split line (want to see more of one file rather than the other) etc.
Other than that, I haven't seen other mayor differences and use gvim except when working with large files because I find it more handy in a graphical environment (gnome).
Speed of rendering
proper shell integration with
suspend (C-z),
alternate terminal,
uniform copy/paste
nicer quickfix integration (all external programs run inside your terminal, instead of popup windows... )
network agnostic: can run over ssh
using GNU screen, can detach/attach session over internet;
To the sometimes mentioned 'downside':
mouse support is up to par with :se mouse +=a; this enables selection, window border dragging with the mouse, even over GNU screen over ssh
Pair coding via vim + gnu screen is the selling point for me. I work in screen/vim all day, it allows people to remote into my screen session and we can both edit files fluidly. It's so hot right now.
As a big vim user myself, although I know about GUI vims, I don't use them just out of habit.
I've been using vi since 1990, switched to vim a few years ago but still call it through an alias (alias vi=vim).
For me its just habit. vim works well as it is. Perhaps the gui offers more and I should explore it, but vim works just the way I expect it to and want it to.