I encountered this character which first shows as 2 black boxes, then it
disappears completely when cursor is over it, then it again shows as 2
black boxes.
Might be again a bug in terminal interpreter, but this symbol has a very
low, 16-bit code point value. So I decided to report it here.
vim-7
> 1. are 1-wide
> 2. the *font itself* is too wide.
>
>
> So this problem has nothing to do with Vim.
>
>
> To check whether it is the case, use terminal emulator which does not support
> fallback fonts or does not do it by default. E.g. rxvt-unicode (AKA urxvt)
> has this property (make sure
I came across this symbol: U+1F44D THUMBS UP SIGN (👍)
In vim-7.4.778 it shows with width one or two, depending if the cursor is
to the left of it or not. So the text in this line "jumps" when cursor
moves over the symbol.
Attaching example: thumbs.txt
Yuri
--
--
You received this message from
In these Bourne shell statements in .sh file:
val=$((some_variable - 1))
val=$(some_function_or_command)
val=$(${SOME_VAR} arg1 arg2)
enclosing dollar sign and braces highlighted as red, even though this is a
valid shell syntax.
Yuri
--
--
You received this message from the "vim_dev" maillist
I have the UTF8 representation of this character: Ϊ́(ce 99 cc 88 cc 81)
It apparently consists of 3 Unicode codepoints: U+0399 U+0308 U+0301
This character shows in vim as 2 separate caret positions. But when cursor
is on the first position, the second one (an accent) completely disappears.
T
I have this text:
阿斯達abc
Человек
It's hex is here:
e9 98 bf e6 96 af e9 81 94 61 62 63 0a d0 a7 d0 |.abc|
0010 b5 d0 bb d0 be d0 b2 d0 b5 d0 ba 0a ||
Command:
$ vim +1 "+normal 3|"
wrongly places the cursor on the second (Mandarin) character.
I need to open the file at the particular line and column.
This command
$ vim '+call cursor($line,$column)' '$file'
does it, however it treats 'column' as byte offset, and not character offset,
which in case of utf-8 causes cursor to be placed to the left of that character
location.
Is there an
I look at some html file which is really in cp-1251 encoding.
Cyrillic characters are not shown properly, which is expected because vim can't
know the encoding.
However, when I copy-and-paste such text (Shift-Y p), it stores it in the
destination file as different byte array.
For example, bytes
> These two situations are both correct.
I think when people open a directory, they normally expect to see what is
inside, like 'ls' would show. It doesn't matter how this is implemented, but
the expected result is the list of what is inside, plus '..' item.
--
--
You received this message fr
Netrw shows the entry with the current directory name inside itself.
For example:
There are two directories /some/dir and /some/dir/other-dir
Command 'cd /some/dir && vim .' shows this:
../
I use vim on the light background, and the blue comment color has always
bothered me. The problem is that blue looks very much like black, and comments
overall look too much like the main text.
Recently I switched the comment to gray, and am much more happy about the code
look aesthetically. Al
Attached patch fixes the problem when vim fails to highlight comments between
rules in yacc source.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
Every once in a while, and for many months/years, I sometimes see this message
when I open a new file with ":new some-file".
Error detected while processing BufRead Auto commands for "*":
E19: Mark has invalid line number
Press ENTER or type command to continue
Pressing ENTER proceeds to the fil
> At least I know that Linux, its stability, and all it stands for, is
> assured with or
> without Mr. Torvalds. I'm sure that the world's biggest corporations
> feel equally
> as confident as I do which is why they stake their reputations on it
> 24/7, 365.
Don't be so sure. Every successful p
Beginning few months ago, vim behavior changed for this command: 'vim
/some/dir/'
It opens some directories with "Netrw", and it doesn't open some other
directories.
But it always prints in the bottom: "/some/dir/" Illegal file name.
Directories it opens successfully tend to be descendants of the
> So can you suggest a patch?
Sure, attaching patch.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subs
When lex/yacc are used to generate C++ compatible sources, these extensions are
used. However, vim syntax highlighter doesn't currently recognize them. I think
these extensions should be added.
As a reference, GNU automake recognizes them:
http://ftp.gnu.org/old-gnu/Manuals/automake-1.6.1/html_n
17 matches
Mail list logo
