On Fri, 15 Mar 2024 at 17:59, Christian Brabandt wrote:
>
>
> On Fr, 15 Mär 2024, A. Wik wrote:
>
> > I have:
> > colorscheme blue
> > set background=dark
> > hi Error guifg=darkgrey guibg=lightred gui=underline
> > \ctermfg=darkgrey ctermbg=lightred
> > in my .vimrc
> >
> > No
On Fr, 15 Mär 2024, A. Wik wrote:
> I have:
> colorscheme blue
> set background=dark
> hi Error guifg=darkgrey guibg=lightred gui=underline
> \ctermfg=darkgrey ctermbg=lightred
> in my .vimrc
>
> Normally, errors are highlighted in lightred foreground on lightred
> backgroun
Hi all,
I have:
colorscheme blue
set background=dark
hi Error guifg=darkgrey guibg=lightred gui=underline
\ctermfg=darkgrey ctermbg=lightred
in my .vimrc
Normally, errors are highlighted in lightred foreground on lightred
background, which is, of course, unreadable. Hence the
Hello,
Hoping an active Vim developer team member can help.
For gVim win32 64-bit nightly builds:
I am suddenly seeing a syntax highlighting issue with blocks in .cmd and
.bat files. I think it may be from an update that occurred between
02-03-2024 and 02-11-2024.
I am seeing several right
Hi,
I have been using vim a lot for programming bash and quite often
syntax highlighting shows some strange behavior when C-like for loops
and/or subshells are involved.
Please see the small image attached.
It seems to me that in the image the first two examples are fine, but
the third one
Is there a Vim script syntax highlighting file that can handle
statements split across multiple lines? For example, consider the
following:
syn region tmuxUninterpolatedString start=+'+ skip=+\\$+ ...
I would like to split this across multiple lines, to it looks something
like this:
On 09.04.21 22:07, 'J S' via vim_use wrote:
https://vim.fandom.com/wiki/Different_syntax_highlighting_within_regions_of_a_file
>
At the above link, there is a solution that sort of works. It's really quite
frustrating > because it will work one minute then not the next and so on. I
can't
On Friday, April 9, 2021 at 4:10:33 PM UTC-4 joesc...@yahoo.com wrote:
> Forgot to mention in the original post.
>
> I am testing this wtih VIM 7.4
>
Why not try updating to something recent? 8.2 is current.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! T
Forgot to mention in the original post.
I am testing this wtih VIM 7.4
--
--
You received this message from the "vim_use" 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 be
Check out this URL:
https://vim.fandom.com/wiki/Different_syntax_highlighting_within_regions_of_a_file
My overarching goal is to be able to write a shell script (bash) with embedded
code in other languages (Perl, AWK, sed, Python, Expect, whatever) and have the
main script syntax highlighted as
On 2021-02-15, Matthew Pritchard wrote:
> Hello I am wondering what is the color code for the different colors vim
> displays. I am also assuming that these colors can be customized. How do I
> do this?
I'd recommend to start with:
:help coloring
In particular, some conventional names are l
On Mon, Feb 15, 2021 at 03:13:52PM -0800, Matthew Pritchard wrote:
> Hello I am wondering what is the color code for the different colors vim
> displays. I am also assuming that these colors can be customized. How do I
> do this?
you can open a colorscheme in vim and see how colors are defined. th
On 02/15 03:13, Matthew Pritchard wrote:
> Hello I am wondering what is the color code for the different colors vim
> displays. I am also assuming that these colors can be customized. How do I
> do this?
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Ty
Hello I am wondering what is the color code for the different colors vim
displays. I am also assuming that these colors can be customized. How do I
do this?
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For mor
Dominique wrote:
> Tony Mechelynck wrote:
>
> > On Tue, Jan 19, 2021 at 9:53 AM Softwafe Engineer
> > wrote:
> > >
> > > Hello. Any plans about improving of syntax highlighting? I've tried
> > > treesitter in neovim and it's pretty
Hi,
On Tue, Jan 19, 2021 at 4:04 AM Dominique Pellé
wrote:
> Tony Mechelynck wrote:
>
> > On Tue, Jan 19, 2021 at 9:53 AM Softwafe Engineer
> wrote:
> > >
> > > Hello. Any plans about improving of syntax highlighting? I've tried
> treesitter in neovim
Tony Mechelynck wrote:
> On Tue, Jan 19, 2021 at 9:53 AM Softwafe Engineer
> wrote:
> >
> > Hello. Any plans about improving of syntax highlighting? I've tried
> > treesitter in neovim and it's pretty cool. In other hand vim's regexp
> > solution i
On Tue, Jan 19, 2021 at 9:53 AM Softwafe Engineer wrote:
>
> Hello. Any plans about improving of syntax highlighting? I've tried
> treesitter in neovim and it's pretty cool. In other hand vim's regexp
> solution is not best I suppose.
>
> Thanks
IMHO, the Vim
Hello. Any plans about improving of syntax highlighting? I've tried
treesitter in neovim and it's pretty cool. In other hand vim's regexp
solution is not best I suppose.
Thanks
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your rep
On Mo, 30 Nov 2020, Mathieu Roux wrote:
> OK you're right, the problem was syntastic.
>
> I can disable with
>
> :SyntasticToggleMode
>
>
> What can i type in .vimrc to disable syntastic automatically?
Put
let g:loaded_syntastic_plugin = 1
into your .vimrc
Or, disable this system plugin
I have so less time... so many things to do...
Syntastic reproach me when i write
L = [ 1,2,3 ] in python
instead of
L=[1,2,3]
On lun., 2020-11-30 at 09:46 -0800, rwmit...@gmail.com wrote:
> If you're not going to use Syntastic, why not un-install it?
>
> Have you considered le
If you're not going to use Syntastic, why not un-install it?
Have you considered learning what Synstatic is trying to show you, could
make you a better programmer.
On Monday, November 30, 2020 at 10:55:27 AM UTC-5 mth...@gmail.com wrote:
> Hello,
>
> OK you're right, the problem was syntastic.
Hello,
OK you're right, the problem was syntastic.
I can disable with
:SyntasticToggleMode
What can i type in .vimrc to disable syntastic automatically?
Thanks,
Mathieu
On sam., 2020-11-14 at 12:08 +0100, Christian Brabandt wrote:
> On Fr, 13 Nov 2020, Mathieu Roux wrote:
>
> > Hello,
>
On Fr, 13 Nov 2020, Mathieu Roux wrote:
> Hello,
>
> In fact, i have just installed all my stuff on a new computer.
>
> I did not installed consciently syntastic or vim-airline, but maybe i
> use it and i don't know.
>
> Bellow is my :scriptnames.
Well, according to your :scriptnames output,
Hello,
In fact, i have just installed all my stuff on a new computer.
I did not installed consciently syntastic or vim-airline, but maybe i
use it and i don't know.
Bellow is my :scriptnames.
Do you want one screenshot of my vim's window?
1: /usr/share/vim/vimrc
On Mo, 09 Nov 2020, Mathieu Roux wrote:
> nothing like that...
>
> i customized my .vimrc:
>
> syntax on
> syntax enable
> let filetype_py = "python"
> au FileType python nmap œ :w:!clear ; python3.9 "%"
> au FileType python imap œ :w:!clear ; python3.9 "%"
>
> When i execute my program with
, Christian Brabandt wrote:
> On Mo, 09 Nov 2020, Mathieu Roux wrote:
>
> > Hello everybody,
> >
> > I have re-installed my computer recently with kubuntu.
> > Now, when i use vim (python program with syntax highlighting), it
> > appears "S>" in the margin
On Mo, 09 Nov 2020, Mathieu Roux wrote:
> Hello everybody,
>
> I have re-installed my computer recently with kubuntu.
> Now, when i use vim (python program with syntax highlighting), it
> appears "S>" in the margin of my text (on the left).
>
> I just don&#
Hello everybody,
I have re-installed my computer recently with kubuntu.
Now, when i use vim (python program with syntax highlighting), it
appears "S>" in the margin of my text (on the left).
I just don't know why some lines are marked "S>" and some other lines
a
uot;syn sync fromstart". Am I missing
> something else in the syn-sync setup?
As stated above, the syntax highlighting is not updated to reflect the
changed text even with "syn sync fromstart". So this definitely looks
like a bug. Should I open a ticket in the issue tracker?
Tom
--
> If there are multi-line patterns, the sync mechanism needs to take care
> of any syntax items where more state becomes invalid. The extreme
> version is to use "syn sync fromstart". See ":help syn-sync".
My syn-sync setup does include "syn sync fromstart". Am I missing
something else in the sy
> the docs state (:help syn-multi-line) that syntax highlighting with
> multi-line patterns "mostly works as expected". I am not sure if this
> "mostly" includes automatic highlighting change of a multi-line syntax
> group when it's modified. Espec
On Sat, Dec 28, 2019 at 12:32 AM Tom M <7to...@gmail.com> wrote:
> Hi,
>
> the docs state (:help syn-multi-line) that syntax highlighting with
> multi-line patterns "mostly works as expected". I am not sure if this
> "mostly" includes automatic highlight
Hi,
the docs state (:help syn-multi-line) that syntax highlighting with
multi-line patterns "mostly works as expected". I am not sure if this
"mostly" includes automatic highlighting change of a multi-line syntax
group when it's modified. Especially as soon as the patter
On Saturday, December 14, 2019 at 6:18:14 AM UTC-6, Bram Moolenaar wrote:
>
>
> > I now understand those two other two entries. If I would have looked at
> > them for a few more seconds. :-) Wish I would have gotten this in before
> > 8.2. At any rate, this should be good to go in. What's the p
> I now understand those two other two entries. If I would have looked at
> them for a few more seconds. :-) Wish I would have gotten this in before
> 8.2. At any rate, this should be good to go in. What's the preferred method
> to submit a patch (if even required for such a simple change)?
You
n Fri, Dec 13, 2019 at 2:04 AM Christian Brabandt
wrote:
>
> On Do, 12 Dez 2019, DJ Lucas wrote:
>
> > I really don't understand vim syntax highlighting at all. This works,
> but I wanted to run it by somebody who actually does. I blatantly stole the
> additional regex
On Do, 12 Dez 2019, DJ Lucas wrote:
> I really don't understand vim syntax highlighting at all. This works, but I
> wanted to run it by somebody who actually does. I blatantly stole the
> additional regex from bindzone.vim, but I've no idea what the
> contains=@reolvIPC
I really don't understand vim syntax highlighting at all. This works, but I
wanted to run it by somebody who actually does. I blatantly stole the
additional regex from bindzone.vim, but I've no idea what the
contains=@reolvIPCluster bit does in the original or whether I broke
an
On 2019-05-24, Tony Mechelynck wrote:
> On Fri, May 24, 2019 at 1:52 PM 'J S' via vim_use
> wrote:
> [...]
> > Note: I tried contacting the listed author/maintainer (Charles
> > Campbell) via email first (before posting this), but the mail
> > bounced. It looks like the sh.vim file hasn't been up
On Fri, May 24, 2019 at 1:52 PM 'J S' via vim_use
wrote:
[...]
> Note: I tried contacting the listed author/maintainer (Charles Campbell) via
> email first (before posting this), but the mail bounced. It looks like the
> sh.vim file hasn't been updated since 2014.
Dr. Chip's adress is listed i
--
You received this message from the "vim_use" 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
ok, though isn't it more important to prune unnecessary content?
:-|
On 2019/05/21 13:17, 'J S' via vim
bash allows (yes, it is a "bashism") syntax like:
$ echo ${var:9:5}
To mean extract a substring of the variable, starting at position 9 and of
length 5.
But is also allows the offset (and then length, too, but ignore that for now)
to benegative. But, alas, as noted in "man bash", if the offset i
nal character of the last line of a paragraph,
which it shouldn't.
I'd like to restrict the matching to just the plain text in the mail
body, more specifically to all but the last line of a paragraph
(where paragraphs are separated by an empty line).
This sounds like syntax highlighting
* 'Andy Wokula' via vim_use (vim_use@googlegroups.com) wrote:
> syn regionmineRed start=+\[+ skip=+\\[\\\]]+ end=+]+ oneline
> contains=mineRed
That's it. Although I do not understand much, but I get it done.
Thank you very much,
--
Gua Chung Lim
"UNIX is basically a simple operati
x27;t know much about vim syntax highlighting.
I copied these commands from somewhere else (mostly help.vim).
And I then modified it to suit my needs.
Any input would be highly appreciated. Thanks,
" add a contains argument:
syn clear
syn region mineRed start=+\[+ skip=+\|
last one (]) is still white.
The relevant lines of mine.vim are as followings.
% grep mineRed ~/.vim/syntax/mine.vim
syn region mineRed start=+\[+ skip=+\|\\'+ end=+\]+ oneline
hi def link mineRed SpecialChar
Actually I don't know much about vim syntax highlighting.
> the vim syntax coloring works on the extensive md-set, where other
> characters can be used as formatting tag. using this extensive set
> brings more formatting options as well.
should have RTFM completely, the backticks are explained on the
daringfireball.
just found the ~~ as striketrough mar
> Vim help doesn't explain the syntax of every kind of file you might
> edit with it. IIUC, by putting text between grave accents in Markdown
> `like this` you make it appear in monospace: for instance in Github
> comments about Vim problems, this marks inline stuff that would be
> typed literally
n Mon, Oct 01, 2018 at 05:39:46PM +0200, Bram Moolenaar wrote:
>
> > Have you tried changing the value for 'redrawtime'? The syntax
> > highlighting may just be too slow.
>
> I put
>
> set redrawtime=1
>
> in my vimrc, but it had no effect.
>
&g
ue for 'redrawtime'? The syntax
> highlighting may just be too slow.
I put
set redrawtime=1
in my vimrc, but it had no effect.
The file in question is of limited length, only 36 lines and 995 words.
Therefore I suspected that the correct coloring being in sync shouldn't
e the problem.
>
> I hope anyone can give me a clue to make syntax coloring work for the
> entire file!
Have you tried changing the value for 'redrawtime'? The syntax
highlighting may just be too slow.
--
hundred-and-one symptoms of being an internet addict:
126. You brag to
On Mon, Oct 1, 2018 at 11:40 AM meine wrote:
>
> Hi,
>
> I use vim a lot with regular markdown --
> see: daringfireball.net/projects/markdown
>
> in several files syntax coloring suddenly stops, and I can't find why.
> this happens with files while typing, as well as in files while editing
> after
Hi,
I use vim a lot with regular markdown --
see: daringfireball.net/projects/markdown
in several files syntax coloring suddenly stops, and I can't find why.
this happens with files while typing, as well as in files while editing
afterwards.
for example some markdown pieces of text:
[text](http
May not be related to your problem, BUT you also need to tell vim that
you are
using bash, as it shares syntax with 'sh'.
In my ~/.vimrc, I have
let g:is_bash=1
let b:is_bash=1
kamaraju kusumanchi wrote:
On Sun, Jul 29, 2018 at 7:37 AM, John Little wrote:
With the vim 8.1.0224 from g
On Sun, Jul 29, 2018 at 7:37 AM, John Little wrote:
> With the vim 8.1.0224 from git, I see the problem.
Thanks for your help.
> The maintainer of sh.vim has fixed quoting problems in his latest version,
> 179, at http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH and indeed
> version 17
With the vim 8.1.0224 from git, I see the problem. (BTW, the colours depend
totally upon the colour scheme being used, so characterizing the problem by the
colours seen isn't very useful. Maybe using the default scheme, starting vim
with --clean -N could be.)
The problem causes the syntax colo
On Sat, Jul 28, 2018 at 3:00 PM, tooth pik wrote:
> my vim is newer than yours, so i'll wager my syntax/sh.vim is newer too
>
> anyway, that exact command renders just fine in my vim (8.1.223)
>
My /usr/share/vim/vim80/syntax/sh.vim is
" Last Change: Sep 22, 2016
" Version:
my vim is newer than yours, so i'll wager my syntax/sh.vim is newer too
anyway, that exact command renders just fine in my vim (8.1.223)
On Sat, Jul 28, 2018 at 10:13 AM, kamaraju kusumanchi
wrote:
> The following shell script is not highlighted correctly.
>
> . % cat foo.sh
> #!/usr/bin/bash
>
The following shell script is not highlighted correctly.
. % cat foo.sh
#!/usr/bin/bash
UPSTREAM=${1:-'@{u}'}
Please find the screenshot at https://pasteboard.co/HwyXxZU.png .
As you can see in the screenshot, the first and second left curly
braces are blue and yellow while the third and fourth
On Tue, Mar 20, 2018 at 1:48 PM, BPJ wrote:
> As the subject says: when I do `:bufdo e` in gvim syntax highlighting is
> turned off in the reloaded buffers. Why? and more importantly: what can I
> do so that syntax is left on/turned on in all reloaded buffers? The only
> fix I kn
As the subject says: when I do `:bufdo e` in gvim syntax
highlighting is turned off in the reloaded buffers. Why? and more
importantly: what can I do so that syntax is left on/turned on in
all reloaded buffers? The only fix I know of ATM is to do `:e`
for each individual buffer, but the idea
On 20/02/2018 16:10, Charles E Campbell wrote:
Lifepillar wrote:
Suppose that @, @@, and @@@ are three operators and that @ is not in
iskeyword. Besides, the operators may not necessarily be surrounded
by spaces or alphanumeric characters: for example, one may encounter
@( at the begin of the li
Lifepillar wrote:
> Suppose that @, @@, and @@@ are three operators and that @ is not in
> iskeyword. Besides, the operators may not necessarily be surrounded
> by spaces or alphanumeric characters: for example, one may encounter
> @( at the begin of the line (as in this line).
>
> How would you de
Suppose that @, @@, and @@@ are three operators and that @ is not in
iskeyword. Besides, the operators may not necessarily be surrounded
by spaces or alphanumeric characters: for example, one may encounter
@( at the begin of the line (as in this line).
How would you define syntax rules to highlig
One more addendum:
In the external file, I changed the line:
highlight NONASCII ctermbg=13
to:
highlight NONASCII ctermbg=13 guibg=Magenta
so that the command would work in gvim as well as vim.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply b
I wrote:
> [P.S.: I originally sent this to which is the address listed
> on the official Vim mailing list page, but it never showed up. Is that still
> valid, or must vim_use@googlegroups.com now be used?]
As you can see above, after a long delay (3 days), the original message
(duplicte)to v
I previously asked how I could set up a toggle for syntax highlighting
of non-ASCII characters. I was having problems clearing a
highlighting group and then never being able to reactivate it.
Ben Fritz suggested using the matchadd()/matchdelete() functions
for the job. That looks like a good
On Monday, August 28, 2017 at 8:52:16 PM UTC-5, cjsmall wrote:
> To find non-ascii characters in a file, I have defined the following:
>
>
> syntax match nonascii "[^\x00-\x7F]"
> highlight nonascii ctermbg=13
>
>
>
> I can disable this with the command:
>
>
> syntax off
>
>
>
To find non-ascii characters in a file, I have defined the following:
syntax match nonascii "[^\x00-\x7F]"
highlight nonascii ctermbg=13
I can disable this with the command:
syntax off
I would like to create a command that toggles this highlight group on/off
and
hopefully do so with
On Tue, Aug 29, 2017 at 3:51 AM, Jeffery Small wrote:
> To find non-ascii characters in a file, I have defined the following:
>
> syntax match nonascii "[^\x00-\x7F]"
> highlight nonascii ctermbg=13
>
> I can disable this with the command:
>
> syntax off
>
> I would like to create a c
To find non-ascii characters in a file, I have defined the following:
syntax match nonascii "[^\x00-\x7F]"
highlight nonascii ctermbg=13
I can disable this with the command:
syntax off
I would like to create a command that toggles this highlight group on/off
and
hopefully do so with
Using 8.0.596, playing with the Less markup language for the first
time (a preprocessor producing CSS for a webserver). The regular
expression controlling comment blocks has gone a bit wrong. I'm
cc'ing Alessandro Vioni, listed as the maintainer in that file.
In CSS, one can use C-style comments
Marcin Szewczyk wrote:
> I have noticed a problem with syntax highlighting when using the
> following .vimrc (minimal to reproduce the thing):
> #v+
> syntax on
> set nocompatible
> set foldmethod=syntax
> set nofoldenable
> #v-
>
> I am not sure if it is a bug or
Hi,
I have noticed a problem with syntax highlighting when using the
following .vimrc (minimal to reproduce the thing):
#v+
syntax on
set nocompatible
set foldmethod=syntax
set nofoldenable
#v-
I am not sure if it is a bug or a feature because I rarely use folding
but I suspect the former.
With
I think the best way is to add a new syntax file into '~/.vim/after/syntax'
with a new rule. This way the default syntax remains the same and you will
get the `#include` highlighted as you want.
2017-04-17 16:13 GMT-03:00 R0b0t1 :
> Perhaps this is better suited for the vim-dev list. As noted in
Perhaps this is better suited for the vim-dev list. As noted in
CONTRIBUTING.md I have tried to follow up with the syntax file
maintainers but received no response.
Per the FreeType library's documentation, it is to be included as follows:
```C++
#include
#include FT_FREETYPE_H
```
However Vim'
n?
Yes indenting is enabled in the vimrc, and disabling it solves the
issue as well (disabling syntax highlighting or indenting).
As for the github report it may be the same problem that causes the
issue, but in my test case there's no complex string on the 'slow'
line.
--
--
Hi François!
On Mo, 03 Okt 2016, François Ingelrest wrote:
> On 2 October 2016 at 22:29, Dominique Pellé wrote:
> > Can you also try to measure it automatically as I did? Just to make
> > sure that what I measure is what you also observe.
>
> This is what I got with line 85 (the slow one):
>
>
On 2 October 2016 at 22:29, Dominique Pellé wrote:
> Can you also try to measure it automatically as I did? Just to make
> sure that what I measure is what you also observe.
This is what I got with line 85 (the slow one):
% time vim -u ./vimrc --noplugin +85 -c 'norm! o' -c 'q!' foo.py
0.17s use
François Ingelrest wrote:
> Hi Dominique,
>
> On 1 October 2016 at 09:46, Dominique Pellé wrote:
>> Can you provide a file where it happens and a minimalistic
>> vimrc, just enough to reproduce it?
>
> Here's what I came up with.
>
> If I type o to open a new line:
> - On line 87, it's instantane
Hi Dominique,
On 1 October 2016 at 09:46, Dominique Pellé wrote:
> Can you provide a file where it happens and a minimalistic
> vimrc, just enough to reproduce it?
Here's what I came up with.
If I type o to open a new line:
- On line 87, it's instantaneous
- On line 85, there's a noticeable la
François Ingelrest wrote:
> Hi all,
>
> I'm not sure when this started, but for some Python files there's a
> noticeable lag due to syntax highlighting.
>
> For example, using O to open a new line can take up to a few hundreds
> of ms at some places of the file w
Hi all,
I'm not sure when this started, but for some Python files there's a
noticeable lag due to syntax highlighting.
For example, using O to open a new line can take up to a few hundreds
of ms at some places of the file while it's instantaneous at some
other places of the same f
Bernd Feige wrote:
> Looks good to me, thanks!
>
> @Bram: Can you pull that patch?
I'll include the change, thanks.
--
"The amigos also appear to be guilty of not citing the work of others who had
gone before them. Even worse, they have a chapter about modeling time and
space without making
im/tree/bibtex-syntax-escaped-
> braces
>
> There appears to be a bug in the syntax highlighting for Bibtex files
> (*.bib).
> Note that this bug has nothing to do with compiling anything. For any
> fields
> that contain set-theoretic notation (like \{a,b\}) the syntax file
>
cc'ed Bernd Feige as maintainer of bib.tex syntax file. Fix can be found in
branch https://github.com/WPettersson/vim/tree/bibtex-syntax-escaped-braces
There appears to be a bug in the syntax highlighting for Bibtex files (*.bib).
Note that this bug has nothing to do with compiling anything
Hi Vim script developers,
Catch up Vim 7.4.2054!
https://github.com/vim-jp/syntax-vim-ex
I was corresponding to the following reports in vim_dev.
[PATCH resend] is not highlighted when editing Vim configuration files
https://groups.google.com/d/msg/vim_dev/zhzo438Kvhg/AH0Q11arBwAJ
Minor update
s mine as an example
--- snip ---
hlnum,ctermfg,ctermbg,guifg,guibg
1,white,red,white,red
2,white,blue,white,blue
3,white,green,white,green
4,white,magenta,white,magenta
5,white,black,white,black
6,white,red,white,red
7,white,blue,white,blue
8,white,green,white,green
9,white,magenta,white,magenta
--- e
Hello,
I'm looking for hash syntax highlighting capability --- words that are not
highlighted as keywords, such as user variables, etc., are hashed to a random
color. The color would be consistent for the same variable though. This makes
it easy to spot where the variable is being used
hi, I am working with some gas asm program and I have some problem with
the syntax highlighting.
I find a bug, and fix it like this in my .vimrc:
autocmd FileType asm syn match asmInclude "#include.*"
autocmd FileType asm hi def link asmInclude Include
This make vim
On Thu, Apr 28, 2016 at 11:55:28PM +0300, Dmitri Vereshchagin wrote:
> As a workaround you can set g:is_bash in your Vim configuration.
That works. Since Bash is generally a superset of POSIX shell scripting,
I can live with that. Thank you for the assistance.
Eric
--
--
You received this mess
* Eric Pruitt [2016-04-28 22:34]:
> I'm very familiar with the differences in POSIX shell syntax and
> Bash-specific constructs, and I already explicitly use "#!/usr/bin/env
> bash" for all Bash scripts and "#!/bin/sh" for things I want to be
> portable. Changing the symlink on my Debian box does
On Thu, Apr 28, 2016 at 10:05:56PM +0300, Dmitri Vereshchagin wrote:
> The reason of this behavior is that /bin/sh on these two systems is
> a symbolic link. On Debian it points to dash and on Red Hat it points
> to bash.
>
> These two shells have slightly different syntax. [...]
> Among the othe
ptnames" on both hosts, the text is identical. Does
> anyone have any ideas what's up with the difference in syntax
> highlighting?
The reason of this behavior is that /bin/sh on these two systems is
a symbolic link. On Debian it points to dash and on Red Hat it points
to bash.
Th
I have a problem with Bash syntax highlighting on two different machines
using the same version of Vim. If I define a Bash function on either
machine **without** using the "function" keyword, the function
definition is highlighted green in my color scheme as expected:
some_bas
On 05:14 Wed 13 Apr , h_east wrote:
> Hi Marcin,
>
> 2016-4-13(Wed) 18:44:29 UTC+9 Marcin:
> > Hi,
> >
> > Have you reached the maintainer of the original syntax file. He might
> > be interested in issues you found.
>
> I know that he is watching this thread. (Hi Charles :-)
> Because, Mos
Hi Marcin,
2016-4-13(Wed) 18:44:29 UTC+9 Marcin:
> Hi,
>
> Have you reached the maintainer of the original syntax file. He might
> be interested in issues you found.
I know that he is watching this thread. (Hi Charles :-)
Because, Most of the individual pointed out has been fixed in about 18 h
Hi,
Have you reached the maintainer of the original syntax file. He might
be interested in issues you found.
Best regards,
Marcin
On 08:20 Sun 10 Apr , h_east wrote:
> Hi,
>
> 2016-4-9(Sat) 10:26:40 UTC+9 h_east:
> > Hi Vim users,
> >
> > An excellent Vim
Hi,
2016-4-9(Sat) 10:26:40 UTC+9 h_east:
> Hi Vim users,
>
> An excellent Vim's syntax highlighting file for Vim script.
>
> https://github.com/vim-jp/syntax-vim-ex
>
> Of course, we have to follow the updates of the latest of Vim! (7.4.1721)
> Please check it.
1 - 100 of 564 matches
Mail list logo
