Couldn't figure this out. Just need to enter 1 emoji into a string and couldn't figure it out. Unicode is not working. Tried diagraph but didn't work either. Is there some trick to this in Vim? thx!
You do not need to install a plugin for this. All you need to do is enter the unicode value of the emoji. You can do that in insert mode with <C-v>. From :h i_ctrl-v_digit:
*i_CTRL-V_digit*
With CTRL-V the decimal, octal or hexadecimal value of a character can be
entered directly. This way you can enter any character, except a line break
(<NL>, value 10). There are five ways to enter the character value:
first char mode max nr of chars max value ~
(none) decimal 3 255
o or O octal 3 377 (255)
x or X hexadecimal 2 ff (255)
u hexadecimal 4 ffff (65535)
U hexadecimal 8 7fffffff (2147483647)
For example, if you want to enter this smiley-face, which has a unicode value of U+1F60A, you could simply type:
<C-v>U1F60A<esc>
or if you don't want to hit <esc>,
<C-v>U0001F60A
Just so you know, there's a good chance that it will not render properly in vim, depending on your font. If you are using gvim, you can change :se guifont=*, or in regular vim, changing your consoles font to make it render (assuming you pick a font that can render this particular emoji)
Another approach is to use abbreviations.
I added a few in my .vimrc file and now I just type :pushpin: for π, :bulb: for π‘, :bomb: for π£, etc...
" Emoji shortcuts
ab :white_check_mark: β
ab :warning: β
ab :bulb: π‘
ab :pushpin: π
ab :bomb: π£
ab :pill: π
ab :construction: π§
ab :pencil: π
ab :point_right: π
ab :book: π
ab :link: π
ab :wrench: π§
ab :info: π
ab :telephone: π
ab :email: π§
ab :computer: π»
There are a lot more of them on emojicopy.com or similar sites. I just picked a few I already used before.
While it is possible to <c-v>U1f60A<esc>, it's not practical if you're
responding to email / entering a comment in a web form. I'm not going to
memorize unicode emoji tables ππ«π for quick "Thanks π" comment.
Few other options for such use cases:
Type your usual smileys like :) and have a plugin replace it with the
unicode equivalent π. The plugin
emoji-ab does this for you.
Type codes like :boom:. Many markdown parsers will convert it to π₯ for
you. But if you're not using such a parser,
emoji-ab will also convert it for
you.
Use something like
gucharmap
(or one of the many online Unicode pickers) to copy and paste unicode
characters into vim.
Another way to access these emojies in many contexts including Vim is to use the character map dialog window:
On Mac, press Ctrl+Command+Space and select the character.
On Windows, press Windows+R and type the charmap.
You can use emoji-fzf pip package
First install fzf
sudo apt install fzf
then intall emoji-fzf
pip install emoji-fzf
now make sure you can run emoji-fzf
emoji-fzf --help
if you get "comand not found" error please see
pip installs packages successfully, but executables not found from command line
now add emoji-fzf to your .vimrc
" Use emoji-fzf and fzf to fuzzy-search for emoji, and insert the result
function! InsertEmoji(emoji)
let #a = system('cut -d " " -f 1 | emoji-fzf get', a:emoji)
normal! "agP
endfunction
command! -bang Emoj
\ call fzf#run({
\ 'source': 'emoji-fzf preview',
\ 'options': '--preview ''emoji-fzf get --name {1}''',
\ 'sink': function('InsertEmoji')
\ })
" Ctrl-e in normal and insert mode will open the emoji picker.
" Unfortunately doesn't bring you back to insert mode π
map <C-e> :Emoj<CR>
imap <C-e> <C-o><C-e>
restart your vim and press ctrl + e and search for your favourite emoji and press enter
Related
I am trying to see the contents of a Finnish text on vi. However, it replaces some letters with numbers. For example, <8a> stands for Γ€, etc.
I changed the character encoding to ISO8859-1, however still when viewing the file, it cannot show the umlaut letters. I also tried :set encoding=latin1 on vi, however it changes to different letters but not umlaut letters. Finally, I tried to replace those numbers with the original letters, but I am getting 'pattern not found' error. I am not sure whether I am doing the substitution correctly though: %s/<8a>/Γ€
Are there any more solution ideas?
vi screenshot
Try from command line:
vim -c "set encoding=utf8" -c "set fileencoding=utf8" -c "wq" filename
being filename the original file you need to open with right encoding.
I would like to register this:
a
b
So I typed : then let #c='a^Mb' and I tried also with \r and \n instead of ^M
When I type "cp vim do not consider this as a return to line but as chars.
Update:
I am running vim 7.4.52 on 3.16.0-38-generic #52~14.04.1-Ubuntu
:let #c="a\n\nb"
Seems to be working fine for me on vim7.4 on FreeBSD. (Double quotes instead of single quotes)
If it's not working, you might want to specify which platform and version of vim?
I have a default installation of vim on linux, on a system with a vt52 terminal emulator and unicode capability.
Everything has been working fine until today when I moved my vt52 terminfo file from the temporary local user directory to the permanent system directory ... at first it seemed fine, but all the sudden, when I try to execute a colon command by pressing enter (either CTRL-J, or the key itself == decimal 10), vim just flashes the screen but doesn't execute the command or leave command entry mode.
However, If I press CTRL-M to get a carriage return character (decimal 13), vim does accept the command.
I tried copying the file back to ~/.terminfo again, but it didn't fix the problem...
I thought this might be either a tty issue or a corrupted vimrc file, so...
first I tried deleting the .viminfo and .vimrc files, and doing a stty sane before starting vim but neither helps. I just noticed that enter doesn't work in insert mode either, but CTRL-M does.
Then I checked from the bash shell, using CTRL-V, that when I press CTRL-M, it shows ^M and when I press CTRL-J, it just enters and shows nothing. So -- to double check -- I did a stty raw and cat - | hexdumpx, and sure enough pressing enter returns only 0x0a, and pressing CTRL-M returns only 0x0d ; so the keyboard driver is returning the proper character in raw mode, and I retested in sane mode which apparently maps both of them to 0x0A.
The termcap file I re-compiled with tic, and copied to both ~/.terminfo/v/vt52u where it worked fine before -- and over to /usr/share/terminfo/v/vt52u.
But I don't see anything in the termcap file which could possibly cause the problem.
vt52u|vt52 with UTF-8:\
:am:eo:rs=\Ee\Eb0\Eco:is=\EE\Ee:\
:nl=^j:sr=\EI:bl=^g:ta=^i:\
:ho=\EH:cr=^m:le=\ED:nd=\EC:do=\EB:up=\EA:ta=^i:nw=^j^m:xn:\
:cm=\EY%+ %+ :it#8:co#75:li#24:\
:sc=\Ej:rc=\Ek:\
:vi=\Ef:ve=\Ee:\
:so=\Eb0\Ec3:se=\Eb0\Eco:mh=\Eb8\Eco:mr=\Ebo\Ec0:me=\Eb0\Eco:\
:cl=\EH\EJ:cb=\Eo:cd=\EJ:ce=\EK:\
:km:kb=^h:
EDIT:
I've isolated the problem by experiment 5 listed below, as being caused by something either in or missing from the above termcap file, or in the tic compiler's conversion of it to terminfo.
So -- what termcap entry is missing or which existing one is causing the problem?
---------------------- Additional experiments as I try to figure it out -------------------
1: doing a :set term in vim reveals term=vt52u .... which is correct. So VIM should be using the above termcap file, but I don't know from where (eg: cached version, or not -- or corrupted.) and :version only reveals +termcap which says vim should be using a tic compiled termcap file which is what I've been trying to give it.
2: I recompiled ncurses-5.9, and re-installed it to make absolutely sure no corrupt files exist. Nothing changed even with: ./configure --prefix=/usr --without-cxx --without-cxx-binding --without-ada --without-manpages --without-progs --without-tests --with-build-cc=gcc --with-shared --without-debug --without-profile --without-gpm --without-dlsym --without-sysmouse --enable-sigwinch --enable-hashmap --enable-scroll-hints --build=i686-linux --host=arm-linux-gnueabi --without-pthread --enable-widec --with-fallbacks=vt52u --disable-big-core --enable-termcap --enable-getcap-cache
3: doing a :set termcap shows more keys defined than the termcap file has, which is bad... termcap only defined one key ... and that one should be ^H not ^?, so VIM's value doesn't match, but the other termcap values all match, since ^[ is the same as escape \E in the termcap file. So, I have proof that vim is definitely loading the proper termcap file because t_so 's value is unique to the vt52u. So -- it's not a corrupt termcap.... :( weird.
t_kb <BS> ^? <DecMouse> ^[[
t_kd <Down> ^# <NetMouse> ^[}
t_sr=^[I t_bc=^[D t_le=^[D t_cd=^[J t_ce=^[K t_cl=^[H^[J
t_me=^[b0^[co t_mr=^[b0^[co t_ve=^[e t_vi=^[f t_nd=^[C t_se=^[b0^[c0
t_ZH=^[bo^[c0 t_ZR=^[b0^[co t_so=^b0^[c3 t_cm=^[Y%p1%' '%+%c%p2%' '%+%c
4: Recompiled vim 7.4, to remove all built in terminals, and to insure no corrupt files. Had no effect; did not fix default value of backspace key being wrong.
echo "Please Edit feature.h so that NO_BUILTIN_TERMCAPS is always #defined."
sleep 5
vim /src/feature.h
./configure --prefix=/usr/ --build=i686-linux --host=arm-linux-gnueabi --with-features=big --disable-darwin --disable-selinux --disable-xsmp --disable-xsmp-interact --disable-mzschemeinterp --disable-tclinterp --disable-netbeans --disable-sniff --disable-gui --disable-cscope --disable-workshop --enable-multibyte --disable-gtktest --disable-gpm --disable-sysmouse --disable-xim --enable-pythoninterp=dynamic --without-x --with-tlib=ncursesw vim_cv_toupper_broken="yes" vim_cv_terminfo="yes" vim_cv_tty_group="world" vim_cv_tty_mode="0620" vim_cv_getcwd_broken="yes" vim_cv_stat_ignores_slash="yes" vim_cv_memmove_handles_overlap="yes"
echo "Please Edit src/Makefile such that STRIP=arm-linux-gnueabi-strip"
sleep 5
vim src/Makefile
make
make install
5: In bash, I changed the terminal type to generic "export TERM=VT52" rather than the unicode version, with color support which I compiled with tic. ** THE NEWLINE PROBLEM WENT AWAY WITH THE SACRIFICE OF COLOR COMMANDS, AND OTHER FEATURES OF VT52U ** I need the features, but apparently something about the termcap file I listed above is defective.
This was an ugly bug to track down by trial and error...
Vim appears to require keydown to be defined, and if not defined it assumes a default value of ^# ; for an unknown reason, it then treats the enter key as if it were a key down, rather than newline. ^# is logically the value for character code 0, null; which is the only character that would be found in an empty string in "C" which vim is written in and appears to trigger the issue/feature/bug.
But in any event in the termcap shown in the opening post, the kd symbol is not defined; and that's what is causing the problem.
Within vim, the problem can be solved by setting the termcap keydown variable as the same escape sequence which would normally exit insert mode, and then do letter j (down):
:set t_kd=\Ej
The same default can always be added to the termcap entries, too;
Since this is an input escape sequence and not a terminal output escape sequence, it doesn't conflict with the VT52's "save cursor" escape sequence defined in the termcap; eg: The VT52 will never see it since Linux tty's when in line entry mode do not echo escape sequences that come from the keyboard back to the terminal's output.
If a terminal doesn't have true arrow keys -- defining the arrow keys as escaped versions of vim's h,j,k,and l keys might be a reasonably compatible solution as long as it doesn't conflict with other programs which might want to use those input escape sequences for other things. I don't use emacs and other popular programs which might want those escape sequences for something, so if anyone else knows which (if any) programs would have problems with that solution, a comment would be appropriate.
In ncurses 5.9,there appears to be a bug in the terminfo compiler, so that on many installations (eg: slackware 14), 'tic' will not be able to compile terminfo source files -- but only termcap source files. If you want the termcap source code for an arbitrary terminal, you can run "infocmp -C fooTerminalName > fooTerminalName.tcap" to have the system generate a termcap source file for you that can be edited and recompiled with tic successfully.
There is a text file like that
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
mail:x:8:12:mail:/var/spool/mail:/bin/false
ftp:x:14:11:ftp:/srv/ftp:/bin/false
http:x:33:33:http:/srv/http:/bin/false
How to replace in VI all characters in strings 2-4 from 2nd to 5th to 'X'?
UPD:
it's smth like: :2,4s//X/g
I guess I need a regular expression
UPD2: :2,4s/^\(.\)...\|^$/\1XXX/ | 2,4s/^$/ XXX/
Vim only
Try this command:
:2,4s/\%2c.../XXX/
Where:
2,4 is for in strings 2-4
\%2c... is for from 2nd to 5th
XXX is for to 'X'
Both Vim and Vi
As Vi doesn't have \%c, this command should be used instead:
:2,4s/^\(.\).../\1XXX/
Resources
:help :range
:help /ordinary-atom
the -w and -W options of vim have theoretically the following effect:
-w {scriptout} All the characters that you type are recorded in the file
"scriptout", until you exit Vim.
This is useful if you want to create
a script file to be used with "vim -s"
or ":source!". When the "scriptout"
file already exists, new characters
are appended. See also
|complex-repeat|. {scriptout} cannot
start with a digit. {not in Vi}
-W {scriptout} Like -w, but do not append, overwrite an existing file.
{not in Vi}
But when I do this, the {scriptout} file will always begin with a hexadecimal sequence like 80 fd 60 (sometimes it is 80 fd 62).
I am using gvimportable.exe 7.3 from portableapps.com. With the -u NONE switch, it does the same.
What is this βmagic numberβ for? Under Windows with gvim.exe I cannot replay my scriptout until I have removed those three leading bytesβ¦
It seems that this feature, which could be very useful, is poorly documented.
Thank you for your answers.
(This answer is probably fragmented significantly, it took me a while playing around - I wanted to find a solution too because it intrigued me - not just the bounty of 200 :P. It more or less shows my train of thought and experimentation.)
I can now reproduce it with gvim on Linux, which is /usr/bin/vim.gnome -g; running as vim -g does just the same.
Delving into the code: (futile in this case, but fun to do and to learn how to do)
I've looked through the source code and I can now explain it somewhat (but not usefully!); it gets the outfile FILE (src/globals.h:1004) set (src/main.h:2275); this is then written to in src/getchar.h:1501, in the updatescript method which is used by gotchars (line 1215) which is used by vgetorpeek, which is used by vgetc and vpeekc... (no, I don't know where this is going!) then these are used in a number of places.
Anyway, I suppose the key is somewhere in src/gui.c, but I don't know where at the moment! It's also possible that some key sequence is being "sent" (physically or virtually, I don't know), but seeing as the issue is the same across platforms it would seem more likely to be a Vim issue than otherwise.
Interesting situations leading to a probable explanation:
It's also worth while noting that if you automatically quit, gvim -u NONE -w scriptout -c quit (:quit after loading) or gvim -u NONE -w scriptout -c quit (instant :quit, never shows GUI), the file scriptout is left empty.
Additionally, if you open gvim and then close it using the X button, pressing no keys:
0000000: 80fd 6280 fd63 80fd 62 ..b..c..b
If you open gvim, click away, click back and use :q:
0000000: 80fd 6280 fd63 80fd 6280 fd2c 80fd 2e3a ..b..c..b..,...:
0000010: 710d q.
So I think it's the window events are internally translated into something else. 80 fd 62 is the open sequence and 80 fd 63 80 fd 62 is the close sequence.
I've found another way of triggering 80fd as well, which leads me to thing it's some sort of "user has access to the window"; by default with GNOME in Ubuntu, Ctrl+Alt+S does something with the window (can't remember what it's called; slides it all up into the title bar, app inside loses keyboard control etc.). gvim ... (you know the arguments!), i<Ctrl+Alt+S (contracted) Ctrl+Alt+S (expanded) >Esc Z Q produces this for me:
0000000: 80fd 6269 3c80 fd63 80fd 623e 1b5a 51 ..bi<..c..b>.ZQ
Summary: so there we have what I believe is the solution; gVim catches the window messages in some form and - whether it should or shouldn't - puts them in its scriptout. If you think it shouldn't (or would like to know why they're left in or if they're even meant to be or whether you should care at all), ask on the Vim list, I think.
My best guess is that this is a bug in the GUI code of gVim.
Using gVim 7.3, if I run gvim -u NONE -W scriptout then I see the problem, but if I run vim -u NONE -W scriptout then the unwanted bytes are not present.
I also tested Vim 7.2 from the shell in Linux, the version of Vim included in Snow Leopard (7.2), and the GUI and terminal versions of MacVim 7.2 (with mvim -W and /Applications/MacVim/Contents/MacOS/Vim -W, respectively) and they all worked correctly.
Someone has done the hard work for us in the vimgolf project, in particular this well-commented file: https://github.com/igrigorik/vimgolf/blob/master/lib/vimgolf/lib/vimgolf/keylog.rb
0x80 in escape sequence for special two-byte codes. In this case they represent gvim focus events. See here:
# If you use gvim, you'll get an entry in your keylog every time the
# window gains or loses focus. These "keystrokes" should not show and
# should not be counted.
"\xfd\x60" => nil, # 7.2 Focus Gained compat
"\xfd\x61" => nil, # Focus Gained (GVIM) (>7.4.1433)
"\xfd\x62" => nil, # Focus Gained (GVIM)
"\xfd\x63" => nil, # Focus Lost (GVIM)