I am working with a monitoring tool that exports events to XML. In
many cases, long XML strings are part of the event detail, thus I wind
up with XML inside of XML where some characters are escaped (ex.
"'http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Working with some Python code inside a pugin (python << EOF ...). In
GVim 7.2 it appears at though the entire block of code is highlighted
according to the Highlight Error section of the current color scheme.
Knowing that I will not likely get Python syntax highlighting inside a
Vimscript file, i
I am building current version 7.2 from source, with Python support
enabled (see :version from the console version output below, same
config for GUI). I have also verified that g:vimsyn_embed contains the
Python flag (g:vimsyn_embed = mpPr)
:version
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov
and it is in the path.
On Dec 5, 6:39 pm, Tony Mechelynck <[EMAIL PROTECTED]>
wrote:
> On 05/12/08 23:41, Matt wrote:
>
> > I am building current version 7.2 from source, with Python support
> > enabled (see :version from the console version output below, same
> > co
It also looks like I made the boneheaded mistake of not updating my
runtime with updated .vim files when building new versions from
source. Following the path suggested by David, I discovered that some
of the source scripts were not current, and simply updating them
solved the problem (* smacks fo
What is desired is that every time a new file is opened (after the
initial one) that it automatically opens in a tab.
As if ":tab ball" is done after every file open. Is this possible?
Matt
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your
; project.git/index.html
>
> Don't know about matching problem, but the job can be accomplished by
>
> %s/\.[^./]*$//c
>
> WBR,
> Ivan.
A slight tweak to fix the original approach would be
:%s/.*\zs\..\{-}$//
Or, a more verbose option would be this:
:%s/.*/\=fnamemod
echnically most correct is probably to put
>
> syn keyword cppOperator typeof
>
> in a file ~/.vim/syntax/cpp.vim
Don't you mean ~/.vim/after/syntax/cpp.vim ?
Or am I missing something?
~Matt
--~--~-~--~~~---~--~~
You received this message
it with a broken DOS-format file - line 1 ends \r\n,
line 2 \n.
echo -n "a\r\nb\n" >tmp/testfile
However, I also can't find any reference to this behavior in the help,
and it definitely strikes me as a bug - I can't see why you'd ever
want autodetection to override a ma
ldn't use TERM=xterm , it should use TERM=konsole (or, more likely
these days, TERM=konsole-256color ). If your terminfo database
doesn't have these entries, you should add them first. You can do
this on debian with "apt-get install ncurses-term"; this
It's not uncommon for large projects to have coding guidelines
that mandate that there be no trailing spaces whatsoever. What
advantage would the extra spaces give? Why do you want them?
~Matt
--~--~-~--~~~---~--~~
You received this message from the &
, I'd much rather put the
administration of the site in the hands of those who stand to profit
from it, rather than volunteers who might to get bored or distracted
with the project.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
On Sat, Oct 25, 2008 at 3:02 AM, John Beckett wrote:
>
> Matt Wozniski wrote:
>>> I say we move things to a new independent, ad-free wiki.
>>> I'd be happy to help set up a MediaWiki site.
>>
>> I disagree pretty strongly. The vim community has already
take a while, but it won't kill your system/vim.
The fact that sed needs to read the the file up until it hits the
lines you're interested in can't be helped, but you can have it quit
after the last line that you want printed. That will help
significantly if you only want a fe
hwarzvogel.de/~klausman/screen_and_vim/
>
> The names should be self-explanatory.
>
> What I'd like to have is the look of urxvt_vim_t_Co_88.png in the
> default case of screen (i.e. instead of
> urxvt_screen_vim_t_Co_8.png)
>
> So what I wonder about is this:
>
>
mode, Vim compiled with +x11 will try to connect to the
> X server at startup because it still uses X for the +clipboard and/or
> +clientserver features, to save and restore the console window title,
> its contents (+xterm_save), and to "save itself" at X-windows closedown
> (+x
On Tue, Nov 4, 2008 at 4:35 PM, Tony Mechelynck wrote:
>
> On 04/11/08 22:25, Matt Wozniski wrote:
>>
>> On Tue, Nov 4, 2008 at 3:48 PM, Tony Mechelynck wrote:
>>> Even in Console mode, Vim compiled with +x11 will try to connect to the
>>> X server at sta
On Tue, Nov 4, 2008 at 5:37 PM, Dominique Pelle wrote:
>
> 2008/11/4 Matt Wozniski:
>>
>> ... My WAG is that they're seeing a
>> font rendering regression (Pango? Freetype?), since I can reproduce
>> this problem in Debian Unstable with GTK2-GNOME gvim (105 s
On Wed, Nov 5, 2008 at 3:06 AM, François Ingelrest wrote:
>
> On Tue, Nov 4, 2008 at 23:15, Matt Wozniski <[EMAIL PROTECTED]> wrote:
>> It might be good to know, but it's certainly not relevant to whatever
>> problem these people are seeing... My WAG is that they&
gister instead of one of the unnamed
registers... Sure, it's better to not clobber either one without
saving and restoring, but at least users tend not to expect the things
in the unnamed register to stick around for long, but often want the
lettered registers saved for a long time.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
ith 'p/P'"?
Perhaps a case could be made for it, but there are many strong
arguments for keeping things the way they are - It teaches people new
commands like [p and ]p and gP, and teaches people about registers,
and pastes that are indent-adjusted are probably useful to more people
On Thu, Nov 6, 2008 at 7:35 AM, Richard Hartmann wrote:
> On Thu, Nov 6, 2008 at 11:55, John Beckett wrote:
>
>> Richard Hartmann wrote:
>>> Can you add the patch to the list, please? :)
>>
>> Sure but I don't have time to work out what text to put.
>
&g
On Sun, Nov 9, 2008 at 8:43 AM, Bram Moolenaar wrote:
>
> Matt Wozniski wrote:
>>
>> That being said, there's one thing I'd like to have changed in vim's
>> source to better support CSApprox, namely that gui colors are not
>> stored unless vim has +g
On Sun, Nov 9, 2008 at 9:32 PM, Richard Hartmann wrote:
>
> On Sun, Nov 9, 2008 at 22:43, Matt Wozniski wrote:
>
>> all Konsole has changed is the handling of bold for foreground
>> colors 0 through 7.
>
> Correct.
>
> PS: Still not sure if you don't need spe
On Sun, Nov 9, 2008 at 10:48 PM, bgold12 wrote:
>
> map mz"*yv`z
Seems like you don't know the gv command.
:map "*ygv
:help gv
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more inform
because the keys sent by feedkeys() seem to
> bypass the functions responsible for the menus. So how do I open a
> menu from within vimscript? Any ideas?
Maybe with :simalt?
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
ompiled into vim, otherwise you should
set it to something that's a superset of every other character set
you'll want to use in your ~/.vimrc.
> This doesn't answer your question, but have you considered adding a
> modeline to the end of the file
mands
evidently override existing vim commands (see :help zs and :help zc).
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
ge their ways, but to make it easier for those who
don't want to spend their time collecting patches and patching the
source themselves.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
On Fri, Nov 14, 2008 at 1:53 PM, Tony Mechelynck wrote:
>
> On 14/11/08 18:03, Matt Wozniski wrote:
>> On Fri, Nov 14, 2008 at 10:37 AM, Tony Mechelynck wrote:
>>> You can also use patches even if you don't want to use gif (sic)
>>
>> Of course you can - you
just typed DBExecVisualSQL. If there are other
mappings beginning with DBExecVisualSQL, then this is ambiguous
and it waits to see if you'll type more.
By way of a "for instance", if that wasn't as clear as I hoped...
:imap a b
:imap bc d
And then try typing a - it will lag, wai
=conf, which happens to work well enough in this case.
Ideally, though, you'd want filetype=perl, and there's no way to know
that should be done. Either add a modeline to the file that sets it
as a perl file, or use one of the autocmd methods suggested at :help
new-filetype to automatically set the irssi config's filetype as
'perl'.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
al with just that sort of
problem by making gvim colorschemes look the same in terminal vim.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
g/messages"). Since Vim uses bash (or cmd.exe or whatever) to run
> the external command, the bar must be escaped on the bash command-line.
> In the :perl and :perldo commands it might be different.
You can even go one character shorter by leaving out the redirection.
7;runtime plugin/CSApprox.vim' -c q
and then posting the file /tmp/CSA.txt - but that file will probably
be pretty big; that should be a last resort... If you can get me some
more information, I'm sure I can help you get things working.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
otherwise. If you press it again,
it will do nothing if 'bs' does not contain 'eol', and will delete
over the beginning of the line, putting the cursor at the end of the
previous line, otherwise.
This is certainly intentional behavior, and it's very useful behavior
at that
-u is much worse.
>
> i use Vim in windows, i don't know whether it will happened in other
> platform.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
t; Most
> people manage to reply without quoting addresses, and that makes sense to me.
Not terribly on-topic, but... I intentionally snip them. On the
cygwin mailing lists, you're likely to get many nasty flames for doing
anything else.
~Matt
--~--~-~--~~~---~--~
onsole vim has GUI support).
Or check out CSApprox - it tries to make gvim-only colorschemes look
right in 88- and 256-color terminals.
http://www.vim.org/scripts/script.php?script_id=2390
~Matt
PS. If you want to try it but have any problems setting it up, feel
free to ask me about it. :)
-
ue for other people who need to edit utf-8 files
> in an 8-bit environment.
I don't understand what the bug you're saying you have is... If you
want to use utf-8 files in an 8-bit environment, you just need to set
'enc' to utf-8, and set 'tenc' to your 8-bit encodin
here, you're using the thing mentioned at :help :/ and :help :?
- they are linewise searches that specify a line address. To get the
behavior that you want, either use the search() function, or use
"norm!" to make vim behave as though you typed the ? normal mode
command in
On Sat, Nov 29, 2008 at 5:29 AM, Tony Mechelynck wrote:
>
> You might try
>normal ?[\|(\|{
This won't work. And I gave a correct answer 6 hours ago.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" mailli
ere
filenames are case insensitive and 'a' and 'A' are the same file.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
hi def link gitcommitSummaryKeyword
>hi def link gitcommitBlank Error
Or, much nicer, adding
hi def link gitcommitSummary Normal
hi def link gitcommitBlank Normal
to your ~/.vimrc - same effect, but the changes won't be reverted next
time gitcommit.vim is upgra
endif
That is, if 'formatoptions' contains both 'o' and 'r', remove those
flags, otherwise add those flags.
see...
:help expr-option
:help :set+=
:help :set-=
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
On Mon, Dec 1, 2008 at 3:19 PM, Tim Chase wrote:
> Matt's solution is good, but I think he missed a "o" in his
> transcription of the "-=" bits:
>
> set fo-=o fo-=r
> ^
Good catch, it was a typo. :)
Thanks Tim.
~Matt
--~--~-~-
'^.*{\(.*\)}*.*$', '\1', 'g')
> let matched = "title: " . matcht . " author: " . matcha
> return v:folddashes . matched
> endfunction
Try that, see if it helps.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
7;textwidth' and 'formatoptions' -
the textwidth used for gitcommit is 72, which so vim would have
automatically wrapped that line - the last 'e' in "white" would be the
71st character on the line.
~Matt
--~--~-~--~~~---~--~~
You
See :help matchparen - which tells you that to disable the plugin
completely, you can use the (unintuitive, I know) command
let loaded_matchparen = 1
in your ~/.vimrc
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
matically closed when I close all normal windows (like it works with
> help pages)?
I'm not sure what the best way to do this one is.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
On Tue, Dec 2, 2008 at 8:17 PM, Tony Mechelynck wrote:
> On 01/12/08 19:04, Matt Wozniski wrote:
>> On Mon, Dec 1, 2008 at 11:15 AM, Simon Ruderich wrote:
>>> If you want to changes this, remove these lines from gitcommit.vim (my
>>> version
>>> is from 2
econd fails. Why ?
Both seem to work for me... larger test case?
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
forward slash, and neither of those are
suitable for what use here - vim strings can't contain a NUL byte, and
123/ is a valid name for a directory that you may need to sort. I
suppose one work-around might be to substitute all \ for \\ and all /
for \/ and then use / as a separator character,
e to get the font of the gvim menu bar the same as the terminal.
>
> A trivial problem you'll say ...
Looks like you're running a Motif gvim. Try switching to a GTK2 gvim
and it will probably look just like all your other applications.
~Matt
--~--~-~--~~~--
On Thu, Dec 4, 2008 at 1:13 PM, Charles Campbell wrote:
>
> Matt Wozniski wrote:
>> Looking at the code, the way this is done seems fundamentally
>> broken... If I'm understanding things correctly, you're trying to
>> separate the priority from the filename wi
On Thu, Dec 4, 2008 at 3:31 PM, Tony Mechelynck wrote:
>
> On 04/12/08 20:02, Matt Wozniski wrote:
> [...]
>> Fundamentally broken, as in there's no separator character that can be
>> used on all systems, and requiring users to try to come up with their
>> own
at the moment... someone else
might know more about it and be able to take it from there...
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
terminal emulation? Ie, how is
xterm with TERM=xterm-256color better than PuTTY with
TERM=putty-256color?
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
uot;db". If I do this:
> vim -c 'set key=jjj' -c 'r !cat /tmp/new-note' db
> the contents of /tmp/new-note end up getting inserted after the 1st
> line of the original "db".
>
> Basically, I don't know how to open a new line (the 'O'
On Sun, Dec 7, 2008 at 2:46 AM, Harry wrote:
> On Dec 6, 2:35 pm, "Matt Wozniski" wrote:
>> On Sat, Dec 6, 2008 at 2:09 AM, Harry wrote:
>> > What I've seen so far is this.
>>
>> > 1. If I issue
>> > vim -c 'set key=foo"
r 'dosini'
aren't inappropriate, they just don't know as much about the format
git requires and can't highlight it as well because of that. Like
setting ft=c in a C++ file, most things will work but not everything.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
the buffer.
'whichwrap' needs to include "<,>" for arrow keys in normal mode, and
also needs "[,]" for arrow keys in insert mode. After doing :set
ww+=<,>,[,] it works fine for me, on vim 7.2.49 - are you sure that
you don't have some other map
On Tue, Dec 9, 2008 at 7:10 PM, Matt Wozniski wrote:
> On Tue, Dec 9, 2008 at 11:48 AM, Tony Mechelynck wrote:
>>
>> Hm. In my gvim 7.2.68, when 'whichwrap' includes "h,l", hitting the h
>> key repeatedly moves from the start of one line to the end
show up in Vim, or
> if you use the 2html feature. I believe this is discussed in the
> txtfmt documentation (though I don't use it at all, so I could be
> wrong).
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
mdflag=-ic
Quoting.
~> "bash" "-i -c" "ls"
bash: - : invalid option
~> "bash" "-i" "-c" "ls"
(works as desired)
setting shellcmdflag to '-i -c' makes that be passed as one argument
to bash, so bash sees "-" m
weren't a student doing this for a class) or try my hand at writing
a merge sort that makes decent use of locality of reference to be fast
enough (if I knew a professor would fail me for using
std::stable_sort()).
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
opy of a real algorithms book, clearly
my class books left me a bit short uninformed about sorting
algorithms. :)
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
control+M (as entered with "control+V control-M), you
>>> might use "\r" instead of the "^M".
>>
>> Btw, I mad the ^M with control+V, ENTER. I thought that was the (a?)
>> correct way to get a new line character in the replace section of a
>>
t.txt
What you were looking for is something like
ls | vim -
where the dash at the end tells vim to treat the text on its standard
input as a buffer to be edited, rather than commands to be run.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
en
using a multibyte encoding [1].
[1]
http://groups.google.com/group/vim_dev/browse_thread/thread/6c9435f656c2550c/9c7ae1b74a457306
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
.txt format). I
> enterred the recommended command (copy and paste from your e-mail) in the
> first line that is before the text.
> Nothing happened.
Does
:set ff?
print out 'dos' or 'mac'? If so, you can convert the file to unix
line
scape is much, much less nice. The
biggest reason is that will use 'timeoutlen' instead of 'ttimeoutlen',
meaning that typing a will often be recognized as a
instead, unless you tweak 'timeoutlen' to be ridiculously low and deal
with all the problems caused by that.
m!
Well, you can install Cygwin/X and rxvt-unicode - or, for that matter,
a Cygwin GTK2 gvim... apart from that, I don't know of any way to get
this sort of behavior in windows.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use"
the
selected color isn't saved anywhere, meaning that synIDattr() can't
return those colors, and CSApprox can't pick out terminal colors that
are close to them. Is there any reason for doing things this way, or
was it just a premature optimization done to save some memory? It
w
27;preserveindent' and
'copyindent' are steps in the right direction, but nowhere close to a
working solution.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
mixture of tabs and spaces as the second one.
Which is still a far cry away from properly using tabs for indenting
blocks and spaces for aligning code automatically. Like I said
before, vim just isn't capable of doing the right thing here, and
On Wed, Dec 24, 2008 at 6:25 AM, Antony Scriven wrote:
>
> On Wed, Dec 24, 2008 at 12:17 AM, Matt Wozniski wrote:
>
>> On Tue, Dec 23, 2008 at 11:26 PM, Tony Mechelynck wrote:
>>
>>> However, as others have repeatedly said, with ":set
>>> autoindent
zero, which means failure.*/
>--return returnval; /* This is where I return it.*/
}
This is why using tabs for indenting a block, and spaces for aligning
code and comments within that block, is the nicest coding style to
work with.
On Wed, Dec 24, 2008 at 11:43 PM, pansz wrote:
>
> Matt Wozniski 写道:
>> Assuming this indent/alignment style is used, you could get code that
>> looked like this:
>
> Let's add something more, okay?
...
> The comment will not get aligned after you changed the tab s
en I tried to use the K command, it always used the rest of the
> current line as the keyword.
This was a known regression, introduced by vim 7.2.010, and fixed by 7.2.026.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" mailli
x27;) matches /\e[?0c/, replace
the 0c with 6;14;224c" - ie, use *your* prefered cursor type,
instead of the default cursor type. It's pretty likely that other
applications will also use cnorm, though, so you might want to
just change your 'cnorm' sequence in your terminfo database,
instead...
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
anyone has further ideas,
> especially on margins, that would be fine too.
I don't know of any better way to do what you want than opening a
split window and sizing it to force wrapping where you want it, but
note that changing 'columns' can have bad effects if
e
directory changes, and is *much* nicer to plugins.
> With :lcd, triggering on BufRead,BufNewFile ought to be enough.
No. :lcd sets the working directory for the window. With BufEnter,
the working directory for the window gets changed when doing a :bp,
and with BufRead,BufNewFile it doesn&
gt; terminal)
> >
> > My OS is ubuntu 8.10.
> >
> > Could you help me? thanks.
>
> Some terminals use Ctrl-Q and Ctrl-S for flow control. These keys are
> not available to programs running in the terminal then.
And, to disable flow control
AFAICS, there's no way to make multibyte characters non-keyword
characters. :help 'isk' says "See 'isfname' for a description of the
format of this option." and :help 'isfname' says "Multi-byte
characters 256 and above are
cter on
the second to last line becomes the second character on the first
line, etc, and then searching through it with matchstr() so I could
handle pattern matches... just not sure how to treat the gaps caused
if not all lines have the same number of columns... hm.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
regular vimscripts in a special directory. I've
never seen that do anything malicious, but I've seen a few that do
some really questionable things like changing terminal settings...
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use&
except for line
numbers. The color for line numbers isn't specified in the
developer.vim colorscheme, so it falls through to the default
colorscheme, where the color depends on the 'background' setting...
Anyway, if you try it and run into any problems, feel free to ask me.
~Matt
--~--~
mplicated than Tony's, but is by necessity completely generic, and
doesn't rely on :redir (which is very slow, and is non-trivial to
parse).
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
On Tue, Jan 13, 2009 at 8:50 AM, Tony Mechelynck wrote:
>
> On 12/01/09 19:16, Andy Wokula wrote:
>>
>> Matt Wozniski schrieb:
>>> Well, using synIDattr() you should be able to get all the information
>>
>> which needs a {synID}, provided by
>> :
n-specific.
> You can remap it to ","
Sure; you could remap it to any key you wanted - but, comma is already
used, and is a very useful key at that... I wouldn't use comma if I
were you.
~Matt
--~--~-~--~~~---~--~~
You received this message
{}
for item in a:list
let dict[item[0]] = item[1]
endfor
return dict
endfunction
echo MakeDict(map(items({'a':1,'b':2}),'reverse(v:val)'))
Admittedly, neither of them are particularly great... just different
than your suggestion.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
#x27;>
But, the cursor might sometimes have been on the first character of
the visual selection...
> Extending on the `> tip from Andreas, you can create the following
> mapping in your ~/.vimrc
>
> :vnoremap gy y`>
>
>
autocmds, which is
presumably why it's always behaved better for me. I did try out
autochdir when the option was added, but I switched back to the
autocmd when I found out it behaved better.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
ath' then do "runtime! plugin/**/*.vim" and restore the
old value of 'runtimepath' - or some such.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
cs-bom,utf-8,iso-8859-7
:e file.iso
:set fenc=utf-8
:w! file.utf
:!cat file.utf
[No write since last change]
αβγ
Do those exact steps yield something different for you, running in a
UTF-8 locale?
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
gt;
~/.vim/ftdetect/underscores.vim
Something more-or-less like that should do the trick.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
t you override it
per-mouse-button. Of course, you could hack the code of your terminal
emulator to allow it, but there's nothing that can be done from the
vim side.
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
hose that know
> more about this before proceeding.
Well... how much harm is there in including it even if it isn't
supported? It would only affect people who assign a variable a value
matching /<<\(\I\i*\)/ - wouldn't it be safe to assume that no one
would do that unless they
r list at all.
>
> Is there anyway to restore the buffer list when I start vim with a file
> name?
As of 7.2.031, v:oldfiles
~Matt
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
1 - 100 of 477 matches
Mail list logo
