Rebbe Malachi: September 2015

Wednesday, September 30, 2015

Re: Highlight if-else-endif structures in Vim

I wrote my own (first) Vim plugin that does this (at least for FORTRAN, which is my use-case): https://github.com/fpnick/flowhighlight
Feel free to give it a try and/or extend it to your needs.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

remote_send - client ids - all lost on busy server

:ver

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 23 2015 09:51:11)

MS-Windows 32-bit GUI version with OLE support

Included patches: 1-873

Thanks for all the help so far, I making it farther using the clientserver features of Vim.

The general flow is this:

1. A different Vim instance issues a remote_send("VimServerName", 'command", "serverid")

The "serverid" gets populated by Vim and is then used in the remote_peek() or remote_read() functions.

2. The receiving Vim, must get the clientid of the Vim sending the request, so that it can respond with a client2server() call (if a response is necessary).

Now, the Vim receiving these requests, gets the clientid using:

let client_id = expand("<client>")

From the docs:

The {clientid} for server2client() can be obtained with expand("<client>")

server2client( {clientid}, {string}) *server2client()*

Send a reply string to {clientid}. The most recent {clientid}

that sent a string can be retrieved with expand("<client>").

{only available when compiled with the |+clientserver| feature}

Note:

This id has to be stored before the next command can be

received. I.e. before returning from the received command and

before calling any commands that waits for input.

Re: vimdiff options by file type?

>David Woodfall wrote:
>> Sorry for going off topic a little, but is the order that
>> .vimrc, .vim/plugin/* etc. are read listed somewhere?
>
>For more detail than can be digested:
>
>:help startup
>
>John

Thanks. Lots of info there.

-D

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: vimdiff options by file type?

David Woodfall wrote:
> Sorry for going off topic a little, but is the order that
> .vimrc, .vim/plugin/* etc. are read listed somewhere?

For more detail than can be digested:

:help startup

John

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vimdiff options by file type?

>On 2015-09-29, dbr517 wrote:
>> I would like to set different vimdiff options by filetype . . . in
>> particular, I would like to ignore whitespace by default, but NOT
>> ignore whitespace for python files.
>>
>> I added the following to the rc file, but I still get "iwhite" set
>> in diffopt for python files:
>>
>> set diffopt+=iwhite
>> if &filetype == 'python'
>> set diffopt-=iwhite
>> endif
>>
>> I'm probably missing something obvious :-))
>
>It's obvious only after some experience with Vim. It's in the
>documentation, but not in one place.
>
>The problem is that Vim determines filetypes after it reads
>~/.vimrc; 'filetype' is not set when that if statement is executed.
>
>One way to fix that is to use these commands instead:
>
> set diffopt+=iwhite
> au FileType python set diffopt-=iwhite
>
>Note that 'diffopt' is a global option; it can't be set differently
>for different buffers. Therefore, the autocommand above will remove
>"iwhite" from 'diffopt' whenever you edit a Python file and not
>restore "iwhite" if you later diff two buffers of a different
>filetype. Whether that's a problem for you and how you might fix
>that depends on how you use Vim.
>
>Regards,
>Gary

Sorry for going off topic a little, but is the order that .vimrc,
.vim/plugin/* etc. are read listed somewhere?

-D

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tuesday, September 29, 2015

Re: Capitalizing SQL keywords

Thanks for the multiple suggestions. I particularly liked David Fishburn's suggestion; I am now motivated to learn Vimscript to hack his plugin to my particular formating fancy....

The plugin is configurable (to a point), so feel free to start a dialogue on it.

David

Re: Capitalizing SQL keywords

Hey Guys,

Thanks for the multiple suggestions. I particularly liked David Fishburn's suggestion; I am now motivated to learn Vimscript to hack his plugin to my particular formating fancy....

On Fri, Sep 25, 2015 at 4:48 PM, Josef Fortier <josef.fortier@gmail.com> wrote:

On Wednesday, September 23, 2015 at 2:09:51 PM UTC-5, Sonny Chee wrote:

> I've defined a bunch of (SQL) keywords I would like to capitalize
> using "abbreviate".

It's not your question, but you might like this approach I put together:

https://github.com/fourjay/upsql-vim

It has a (potential) advantage over the abbreviate approach, in that it uses syntax to determine SQL keywords. The consequences are minor, but are real, notably that a) It works on mixed case b) it's source is the syntax file, which means no having to worry about maintaining the keyword list.

I'm the only user. The basic approach comes from this group (Christian Brandt post from a long time a go that I found through google). It's put together with the assumption that a user will use a plugin manager to run it (that's how I use it and how I expect many others do).

That said, David's work is wonderful. I use his plugins all the time. His sqlutil formatter works very well (and is quite configurable). I've used it more then once to make sense out of of some unformatted glob of SQL. Likewise dbext is pretty wonderful.

--
--
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 because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/IRGHxgYbYCQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sonny.
----------------------------------------------------------------------------
Be true to your work, your word, and your friend. Henry David Thoreau.

Re: vimdiff options by file type?

On Tuesday, September 29, 2015 at 11:04:25 AM UTC-4, Gary Johnson wrote:
> On 2015-09-29, dbr517 wrote:
> > I would like to set different vimdiff options by filetype . . . in
> > particular, I would like to ignore whitespace by default, but NOT
> > ignore whitespace for python files.
> >
> > I added the following to the rc file, but I still get "iwhite" set
> > in diffopt for python files:
> >
> > set diffopt+=iwhite
> > if &filetype == 'python'
> > set diffopt-=iwhite
> > endif
> >
> > I'm probably missing something obvious :-))
>
> It's obvious only after some experience with Vim. It's in the
> documentation, but not in one place.
>
> The problem is that Vim determines filetypes after it reads
> ~/.vimrc; 'filetype' is not set when that if statement is executed.
>
> One way to fix that is to use these commands instead:
>
> set diffopt+=iwhite
> au FileType python set diffopt-=iwhite
>
> Note that 'diffopt' is a global option; it can't be set differently
> for different buffers. Therefore, the autocommand above will remove
> "iwhite" from 'diffopt' whenever you edit a Python file and not
> restore "iwhite" if you later diff two buffers of a different
> filetype. Whether that's a problem for you and how you might fix
> that depends on how you use Vim.
>
> Regards,
> Gary

Gary -

Excellent, thanks! That explains some other errors in my .vimrc too :-) I can actually use the autocommand because I commonly run ONLY the diff in a given session; if I'm doing extensive editing it's in a different session.

Dan

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vimdiff options by file type?

On 2015-09-29, dbr517 wrote:
> I would like to set different vimdiff options by filetype . . . in
> particular, I would like to ignore whitespace by default, but NOT
> ignore whitespace for python files.
>
> I added the following to the rc file, but I still get "iwhite" set
> in diffopt for python files:
>
> set diffopt+=iwhite
> if &filetype == 'python'
> set diffopt-=iwhite
> endif
>
> I'm probably missing something obvious :-))

It's obvious only after some experience with Vim. It's in the
documentation, but not in one place.

The problem is that Vim determines filetypes after it reads
~/.vimrc; 'filetype' is not set when that if statement is executed.

One way to fix that is to use these commands instead:

set diffopt+=iwhite
au FileType python set diffopt-=iwhite

Note that 'diffopt' is a global option; it can't be set differently
for different buffers. Therefore, the autocommand above will remove
"iwhite" from 'diffopt' whenever you edit a Python file and not
restore "iwhite" if you later diff two buffers of a different
filetype. Whether that's a problem for you and how you might fix
that depends on how you use Vim.

Regards,
Gary

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

vimdiff options by file type?

I would like to set different vimdiff options by filetype . . . in particular, I would like to ignore whitespace by default, but NOT ignore whitespace for python files.

I added the following to the rc file, but I still get "iwhite" set in diffopt for python files:

set diffopt+=iwhite
if &filetype == 'python'
set diffopt-=iwhite
endif

I'm probably missing something obvious :-))

Thanks!

Dan

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Monday, September 28, 2015

Re: remote_read() never returns

...
It looks like for this to work, your "MyFunc" function will need to call server2client() internally. The value you send with this function should be received by your remote_read call. Is this how you MyFunc works, or are you expecting to receive the return value instead? Note that the :call command does not have any mechanism to get the return value.

My second suggestion is that remote_read *returns* the value received from the server, but it looks like you're trying to access the return value by reading the firstfile_bufnr variable. This is incorrect. In your example, firstfile_bufnr is updated by remote_send to store a server ID, it is used *as* a server ID in your remote_read call, but the variable name and its presence in your echomsg command indicate you expect it to be something else (presumably the return value of MyFunc).

I just read through :h remote.txt, where it explains more on this topic and you are right.

I can use remote_peek() to check if there is something ready to come back and remote_read() if there is.

The client2server() function is used server side, which remote_peek() is checking for.

Thanks for the response Ben, much appreciated.

David

Re: remote_read() never returns

On Sunday, September 27, 2015 at 8:46:34 PM UTC-5, David Fishburn wrote:
> VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 23 2015 09:51:11)
> MS-Windows 32-bit GUI version with OLE support
> Included patches: 1-873
>
>
> I am making a remote_send() call to a different server and I really want to get the value returned from the function I am calling.
>
>
> The help indicates I can do this:
> :h remote_send()
>
>
>
>
>
> call remote_send( g:remotediff_servername, ":call MyFunc( '".a:filename1."' )\<CR>", "firstfile_bufnr" )
> call remote_read(firstfile_bufnr)
> echomsg "remote_read:" firstfile_bufnr
>
>
>
>
> Problem is, we never get to the echomsg statement. Vim just hangs forever.
>
>
> If I don't use the remote_read() everything functions correctly, except I do not get the return code from the function I called.
>
>
> Anyone have any suggestions?
>

The way I'm reading the help, I have two suggestions:

It looks like for this to work, your "MyFunc" function will need to call server2client() internally. The value you send with this function should be received by your remote_read call. Is this how you MyFunc works, or are you expecting to receive the return value instead? Note that the :call command does not have any mechanism to get the return value.

My second suggestion is that remote_read *returns* the value received from the server, but it looks like you're trying to access the return value by reading the firstfile_bufnr variable. This is incorrect. In your example, firstfile_bufnr is updated by remote_send to store a server ID, it is used *as* a server ID in your remote_read call, but the variable name and its presence in your echomsg command indicate you expect it to be something else (presumably the return value of MyFunc).

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: visincr and mswin not compatible

Thanks Chip,

works wonderfully, just what I needed

Thanks to all of you for your help

regards

Jordi

--
View this message in context: http://vim.1045645.n5.nabble.com/visincr-and-mswin-not-compatible-tp5725829p5725867.html
Sent from the Vim - General mailing list archive at Nabble.com.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sunday, September 27, 2015

remote_read() never returns

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 23 2015 09:51:11)

MS-Windows 32-bit GUI version with OLE support

Included patches: 1-873

I am making a remote_send() call to a different server and I really want to get the value returned from the function I am calling.

The help indicates I can do this:

:h remote_send()

call remote_send( g:remotediff_servername, ":call MyFunc( '".a:filename1."' )\<CR>", "firstfile_bufnr" )

call remote_read(firstfile_bufnr)

echomsg "remote_read:" firstfile_bufnr

Problem is, we never get to the echomsg statement. Vim just hangs forever.

If I don't use the remote_read() everything functions correctly, except I do not get the return code from the function I called.

Anyone have any suggestions?

TIA,

David

Re: Weird 's' command behavior.

What version of vim?
On what platform?
Does it happen with all file types?
.txt .sh .html ???

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird 's' command behavior.

On Sunday, September 27, 2015 at 11:27:44 AM UTC-7, sycc wrote:
> Ok, so it's finally happened once again.
> I was mistaken about 'cl' though, it behaves incorrectly, same as 's' does.
> I've checked the mapping for either 's', 'c', 'l', 'cl'... I couldn't
> really think of anything else related to this and no, none of them are
> being mapped to anything. 'c<space>' does the same thing.

If you use 'c<space>' or 'cl' what is copied to the "" or "- register?
Use :reg to print the registers.

Is it the 2 characters?

In normal mode does 'l' or '<space>' move one char to the right,
provided you do not re-map '<space>' like I do to 'PageDown' :)

What is the content of 'cpoptions'?
before and after the 's' problem?

:set cpo?
cpoptions=aABceFs

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird 's' command behavior.

On Sunday, September 27, 2015 at 11:27:44 AM UTC-7, sycc wrote:
> Ok, so it's finally happened once again.
> I was mistaken about 'cl' though, it behaves incorrectly, same as 's' does.
> I've checked the mapping for either 's', 'c', 'l', 'cl'... I couldn't
> really think of anything else related to this and no, none of them are
> being mapped to anything. 'c<space>' does the same thing.

If you use 'c<space>' or 'cl' what is copied to the "" or "- register?
Use :reg to print the registers.

Is it the 2 characters?

In normal mode does 'l' or '<space>' move one char to the right,
provided you do not re-map '<space>' like I do to 'PageDown' :)

What is the content of 'cpoptions'?
:set cpo?
cpoptions=aABceFs

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird 's' command behavior.

On Sun, Sep 27, 2015 at 8:27 PM, sycc <sycc90@mail.com> wrote:
> Ok, so it's finally happened once again.
> I was mistaken about 'cl' though, it behaves incorrectly, same as 's' does.
> I've checked the mapping for either 's', 'c', 'l', 'cl'... I couldn't really
> think of anything else related to this and no, none of them are being mapped
> to anything. 'c<space>' does the same thing.
> I'll try leaving this vim session open in case any of you think there's
> something I could try to troubleshoot this. I've closed the files I was
> working on and re-opened them with another vim session and that's working
> correctly.
>
>
>
>
> On 09/21/2015 10:55 PM, sycc wrote:
>>
>> Te respond to both tests:
>> 1) I'm certain it's not an issue with me typing a 2 accidentally. Once
>> this starts happening I've tried manually hitting the 's' a single time,
>> tried 2s, 3s (as explained in the first email), 'cl' works as 's' should.
>> Next time this happens I'll try mapping 'cl' to 's' as Bee suggested to see
>> what happens. But yes, I'm certain that's not it because once it starts,
>> it's persistent and doesn't go away until restarting vim. It is a
>> possibility, however, that I might be entering some sequence that could
>> cause this instead of some other regular commands, like 'noh' which I use
>> quite frequently and have been mistyping some times because of the new
>> keyboard.
>> 2) I'm also certain it's not the keyboard. Once the problem starts, it's
>> just that 's' command that behaves weirdly. If I go into insert mode I can
>> type an "s" without trouble whatsoever, same thing in any other
>> applications, terminal, etc.
>>
>> I'll keep my eyes open until it happens again and check if it's somehow
>> been remapped.
>>
>> Thank you all for your suggestions!
>>
>>
>> On 09/21/2015 10:39 PM, Tim Chase wrote:
>>>
>>> On 2015-09-21 19:21, sycc wrote:
>>>>
>>>> Given all that, I was left thinking I might be accidentally hitting
>>>> some command sequence that would change its behavior, I'm breaking
>>>> in a new keyboard and making quite a bit of mistakes while typing
>>>> so it's a possibility I think
>>>
>>> Given this new information, that would be my top suspicion. My
>>> laptop keyboard has a column that sometimes double-strike or skip
>>> (makes typing passwords a real joy; enough that I got a USB keyboard
>>> to lessen the annoyance), and my netbook has tighter spacing and an
>>> odd arrangement that frequently causes me to hit the wrong key until
>>> my fingers have adapted to that particular keyboard. So with that in
>>> mind, your attempts to type a "w" or "q" on your new key-board's
>>> spacing might cause you to bump "2" to get the effect you're seeing.
>>> Other possibilities might be a short in the keyboard or some sort of
>>> gunk that's causing a neighboring key to trigger.
>>>
>>> So my next tests would be:
>>>
>>> - if you can take notice of whether you recently typed a "w" or "q"
>>> preceding the "s", there might be some neighbor bumping. Using
>>> "set showcmd" in your vimrc would show you if you have a pending
>>> "2" as your count.
>>>
>>> - try using/borrowing/buying an alternate keyboard to see if the
>>> issue persists. If it doesn't, it's likely a hardware issue
>>>
>>> -tim
>>>
>>>
>>>
>>

Try (in the misbehaving Vim, of course)
:new
:source $VIMRUNTIME/bugreport.vim
:view ./bugreport.txt
in that order (this assumes it is compiled with +windows, otherwise
omit the first command)

Do you see anything suspicious?

Best regards,
Tony.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird 's' command behavior.

Ok, so it's finally happened once again.
I was mistaken about 'cl' though, it behaves incorrectly, same as 's' does.
I've checked the mapping for either 's', 'c', 'l', 'cl'... I couldn't
really think of anything else related to this and no, none of them are
being mapped to anything. 'c<space>' does the same thing.
I'll try leaving this vim session open in case any of you think there's
something I could try to troubleshoot this. I've closed the files I was
working on and re-opened them with another vim session and that's
working correctly.

On 09/21/2015 10:55 PM, sycc wrote:
> Te respond to both tests:
> 1) I'm certain it's not an issue with me typing a 2 accidentally. Once
> this starts happening I've tried manually hitting the 's' a single
> time, tried 2s, 3s (as explained in the first email), 'cl' works as
> 's' should. Next time this happens I'll try mapping 'cl' to 's' as Bee
> suggested to see what happens. But yes, I'm certain that's not it
> because once it starts, it's persistent and doesn't go away until
> restarting vim. It is a possibility, however, that I might be entering
> some sequence that could cause this instead of some other regular
> commands, like 'noh' which I use quite frequently and have been
> mistyping some times because of the new keyboard.
> 2) I'm also certain it's not the keyboard. Once the problem starts,
> it's just that 's' command that behaves weirdly. If I go into insert
> mode I can type an "s" without trouble whatsoever, same thing in any
> other applications, terminal, etc.
>
> I'll keep my eyes open until it happens again and check if it's
> somehow been remapped.
>
> Thank you all for your suggestions!
>
>
> On 09/21/2015 10:39 PM, Tim Chase wrote:
>> On 2015-09-21 19:21, sycc wrote:
>>> Given all that, I was left thinking I might be accidentally hitting
>>> some command sequence that would change its behavior, I'm breaking
>>> in a new keyboard and making quite a bit of mistakes while typing
>>> so it's a possibility I think
>> Given this new information, that would be my top suspicion. My
>> laptop keyboard has a column that sometimes double-strike or skip
>> (makes typing passwords a real joy; enough that I got a USB keyboard
>> to lessen the annoyance), and my netbook has tighter spacing and an
>> odd arrangement that frequently causes me to hit the wrong key until
>> my fingers have adapted to that particular keyboard. So with that in
>> mind, your attempts to type a "w" or "q" on your new key-board's
>> spacing might cause you to bump "2" to get the effect you're seeing.
>> Other possibilities might be a short in the keyboard or some sort of
>> gunk that's causing a neighboring key to trigger.
>>
>> So my next tests would be:
>>
>> - if you can take notice of whether you recently typed a "w" or "q"
>> preceding the "s", there might be some neighbor bumping. Using
>> "set showcmd" in your vimrc would show you if you have a pending
>> "2" as your count.
>>
>> - try using/borrowing/buying an alternate keyboard to see if the
>> issue persists. If it doesn't, it's likely a hardware issue
>>
>> -tim
>>
>>
>>
>

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Saturday, September 26, 2015

Re: Bug: Inconsistent result with searchpair()?

Hi David!

On Fr, 25 Sep 2015, David Fishburn wrote:

>
>
> On Thu, Sep 24, 2015 at 1:22 AM, Christian Brabandt <cblists@256bit.org> wrote:
>
> Hi David!
>
> On Mi, 23 Sep 2015, David Fishburn wrote:
>
> > Christian, do you think it is worth putting together a reproducible
> > that should work with basic Vim?
>
> Sure, If you get a reproducible test, I'll look into it.
>
>
>
> So I have narrowed things down, looking for suggestions.
>
> syntax_searchpair_vimrc
> ***
> set nocompatible
> set selectmode=
> behave xterm
> syntax on
> filetype indent on
>
> ***
>
> I start Vim with:
> c:\opensrc\vim\src\gvim.exe -u syntax_searchpair_vimrc -U
> syntax_searchpair_vimrc --noplugins +"source c:\vim\vimfiles\plugin\
> sqlutilities.vim" +"source c:\vim\vimfiles\autoload\sqlutilities.vim" +"source
> C:\Vim\test\sqlutilities\searchpair_function.vim" searchpair.sql

Looks like sqlutilities.vim is not distributed with vim:
#v+
chrisbra@debian ~/code/vim/runtime (hg)-[default]- % find . -type f
-name "*.vim" |grep sql
./ftplugin/sql.vim
./syntax/sqlhana.vim
./syntax/sqlforms.vim
./syntax/plsql.vim
./syntax/sqlj.vim
./syntax/mysql.vim
./syntax/sqlanywhere.vim
./syntax/sql.vim
./syntax/sqloracle.vim
./syntax/esqlc.vim
./syntax/msql.vim
./syntax/sqlinformix.vim
./indent/sqlanywhere.vim
./indent/sql.vim
./autoload/sqlcomplete.vim
0 12592 chrisbra@debian ~/code/vim/runtime (hg)-[default]- %
#v-

So can you please provide the sqlutitilities.vim plugin and
searchpair_function.vim and searchpair.sql files.

Mit freundlichen Grüßen
Christian
--
In der Liebe wird der Ernst der Jungfrau bezaubern; in der Ehe, die
selber ein langer Ernst ist, möchte leichtes Scherzen und Bescherzen
der Welt besser einschlagen.
-- Jean Paul

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: colors when using tiny vim

2015-09-25 21:12 GMT+03:00 DwigtArmyOfChampions
<dwightarmyofchampions@hotmail.com>:
> I am using tiny vim, which has no syntax highlighting (according to the output from the :version command). So how are my line numbers in yellow and my list characters (:set list) are in blue? Where is this being set?

Absense of syntax highlighting means absense of working :syn command
(== regex-based file parsing), not absense of terminal color support.
To configure this you need to use :highlight command (:h :highlight),
:h 'highlight' contains an index of highlight groups you may
configure, it is suggested to *not* alter the option itself.

>
> --
> --
> 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 because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: visincr and mswin not compatible

jordi_frei wrote:
> Do I need to place the script file paste.vim in autoload?
> I could not find this file

The file vim74/autoload/paste.vim is part of Vim and you should have it.

In Vim, enter the command:

:echo $VIMRUNTIME

That should display the path to your vim74 directory.

In Vim, put the cursor on the following line then type gf

$VIMRUNTIME/autoload/paste.vim

That works on Windows, and should show the file.

Try the commands I gave earlier. They should work.

John

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Friday, September 25, 2015

Re: colors when using tiny vim

On Fri, Sep 25, 2015 at 8:12 PM, DwigtArmyOfChampions
<dwightarmyofchampions@hotmail.com> wrote:
> I am using tiny vim, which has no syntax highlighting (according to the output from the :version command). So how are my line numbers in yellow and my list characters (:set list) are in blue? Where is this being set?

See :help 'highlight'

Best regards,
Tony.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Capitalizing SQL keywords

On Wednesday, September 23, 2015 at 2:09:51 PM UTC-5, Sonny Chee wrote:

> I've defined a bunch of (SQL) keywords I would like to capitalize
> using "abbreviate".

It's not your question, but you might like this approach I put together:

https://github.com/fourjay/upsql-vim

It has a (potential) advantage over the abbreviate approach, in that it uses syntax to determine SQL keywords. The consequences are minor, but are real, notably that a) It works on mixed case b) it's source is the syntax file, which means no having to worry about maintaining the keyword list.

I'm the only user. The basic approach comes from this group (Christian Brandt post from a long time a go that I found through google). It's put together with the assumption that a user will use a plugin manager to run it (that's how I use it and how I expect many others do).

That said, David's work is wonderful. I use his plugins all the time. His sqlutil formatter works very well (and is quite configurable). I've used it more then once to make sense out of of some unformatted glob of SQL. Likewise dbext is pretty wonderful.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: visincr and mswin not compatible

jordi_frei wrote:
> Thanks Chip!
>
> I tried this new version but I still get the same error. but on the web in
> says version 21d, I don't know if this is important.
>
> I commented the following lines from your script and then it works, but I
> don't know if this would mess up other functionalities.
>
> " if &selection == "exclusive"
> " let rghtcol= rghtcol - 1
> " endif
>
Hello!

Looks like my updating scripts had a glitch due to my website server
changing a path on me (ie. the cd ... in the ftp failed, so the upload
went to the wrong directory, which isn't linked to by the html). I
think I have cleaned up most of the situation; at least, visincr is now
showing as v21e and, when I downloaded it, I got v21e.

So if you'd try downloading visincr again, you should get the corrected
copy.

Regards,
Chip Campbell

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug: Inconsistent result with searchpair()?

On Thu, Sep 24, 2015 at 1:22 AM, Christian Brabandt <cblists@256bit.org> wrote:

Hi David!

On Mi, 23 Sep 2015, David Fishburn wrote:

> Christian, do you think it is worth putting together a reproducible
> that should work with basic Vim?

Sure, If you get a reproducible test, I'll look into it.

So I have narrowed things down, looking for suggestions.

syntax_searchpair_vimrc

***

set nocompatible

set selectmode=

behave xterm

syntax on

filetype indent on

***

I start Vim with:

c:\opensrc\vim\src\gvim.exe -u syntax_searchpair_vimrc -U syntax_searchpair_vimrc --noplugins +"source c:\vim\vimfiles\plugin\sqlutilities.vim" +"source c:\vim\vimfiles\autoload\sqlutilities.vim" +"source C:\Vim\test\sqlutilities\searchpair_function.vim" searchpair.sql

Visually select first 2 lines of file:

'<,'>call SQLUFormatter

This is where things get a little complicated.

I had it reproduced with a function (not my plugin) but then it stopped failing and I had to go back to the binary commenting out of code.

If I use the function it works, but when I use my plugin now, it fails.

It is like enough stuff has to get loaded in memory before I get the issue.

So besides my 2 files for my plugin everything else is coming from vim74\runtime.

Is this good enough for you Christian?

Thanks,

David

colors when using tiny vim

I am using tiny vim, which has no syntax highlighting (according to the output from the :version command). So how are my line numbers in yellow and my list characters (:set list) are in blue? Where is this being set?

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: visincr and mswin not compatible

On Friday, September 25, 2015 at 10:54:27 AM UTC-5, jordi wrote:
> Thanks for your answer
>
> Yes I only need it for numbers but I don't understand how to use the
> commands you say
>
> Jordi
>

If you have at least version 7.4.848* then you can make a list of the number "1" as long as you want it, then select the list in visual mode (you may need visual-block-mode, i.e. by pressing CTRL-V or CTRL-Q). Finally, press g followed by CTRL-A to automatically form an increasing list.

For example, enter the following text:

1.
1.
1.
1.
1.

Place the cursor on the second line, and type CTRL-V to enter visual block mode. Highlight down to the final line. Type g followed by CTRL-A and you will get:

1.
2.
3.
4.
5.

*I said at least 7.4.848 is needed; technically the feature was introduced before that, but I think this was the last bugfix for problems the feature introduced, so you'll want at least that version.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: visincr and mswin not compatible

Thanks John,

Do I need to place the script file paste.vim in autoload? I could not find
this file

Jordi

--
View this message in context: http://vim.1045645.n5.nabble.com/visincr-and-mswin-not-compatible-tp5725829p5725850.html
Sent from the Vim - General mailing list archive at Nabble.com.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: visincr and mswin not compatible

Thanks for your answer

Yes I only need it for numbers but I don't understand how to use the
commands you say

Jordi

--
View this message in context: http://vim.1045645.n5.nabble.com/visincr-and-mswin-not-compatible-tp5725829p5725849.html
Sent from the Vim - General mailing list archive at Nabble.com.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: visincr and mswin not compatible

Thank you Tony,

I will try this, but I need to configure as well other things like key
mapping. you are right though that I don't need all the features of mswin

Jordi

--
View this message in context: http://vim.1045645.n5.nabble.com/visincr-and-mswin-not-compatible-tp5725829p5725848.html
Sent from the Vim - General mailing list archive at Nabble.com.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: visincr and mswin not compatible

Thanks Chip!

I tried this new version but I still get the same error. but on the web in
says version 21d, I don't know if this is important.

I commented the following lines from your script and then it works, but I
don't know if this would mess up other functionalities.

" if &selection == "exclusive"
" let rghtcol= rghtcol - 1
" endif

Jordi

--
View this message in context: http://vim.1045645.n5.nabble.com/visincr-and-mswin-not-compatible-tp5725829p5725847.html
Sent from the Vim - General mailing list archive at Nabble.com.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thursday, September 24, 2015

Re: gvim on cygwin/xfree inherits height of xterm

On Fri, Sep 25, 2015 at 3:02 AM, Paul <Paul.Domaskis@gmail.com> wrote:
[…]
> I think I've been bastardizing the [g]vimrc scheme to maintain my
> habits from before, when I used vi. I was used to having one rc file,
> and there was no concept of a gui version. I think I jumped on the
> vim bandwagon about 1.5 decades ago, and look, it has now taken over
> the world. I am not implying that I had anything to do with that, just
> that I fortuitously made a good choice. It might have been the only
> logical choice at the time, if it was dominant already. In fact, I
> think I still vaguely recall the times when I was trying to get a
> decent code editor after many years away from vi, and I was messing
> around with emacs.
>
> Anyway, about bastardizing the [g]vimrc scheme, I only maintain one rc
> file: vimrc. It has conditional statements depending on the value of
> has('gui'), though I should probably join the 21st century and change
> it to has('gui_running'). It might make the console vim experience
> less...mysterious. Thanks again, Tony.
>

I've never used vi (except as a nickname for a "tiny build of vim")
but I also have only a vimrc, with
:if has('gui_running')
and/or
:autocommand GUIEnter …
for statements not to be executed when starting in console mode. The
latter (autocommand) method is for settings which must happen only at
the very moment of starting the GUI, and not earlier, e.g. settings
which would be overridden if set in the short lapse of time between
starting a Unix-like gvim (from a bash shell, maybe) and its going
over to GUI mode. Some termcap settings, for instance, are of that
kind.

IIRC I've become a steady user of Vim when it was at version 6.1 or
thereabouts. It already had multibyte capability (if the feature was
selected at compile-time, of course) but that was still a novelty.

Best regards,
Tony.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: gvim on cygwin/xfree inherits height of xterm

Tony Mechelynck <antoine.mechelynck <at> gmail.com> writes:
> has('gui') means "compiled with GUI capability". On Unix-like
> platforms (but not on Windows) it is possible to use a single
> executable binary as both vim and gvim (with the help of symlinks
> and/or command-line switches). It will have has('gui') on in both
> cases, has('gui_running') on when it knows it is (or will soon be)
> in GUI mode and off otherwise, and of course it doesn't source the
> gvimrc when starting in Console mode. Of course a console-only Vim
> (where has('gui') is zero) will never source a gvimrc (unless, of
> course, you mistakenly specifically order ":source ~/.gvimrc" at the
> console or in a script).

I think I've been bastardizing the [g]vimrc scheme to maintain my
habits from before, when I used vi. I was used to having one rc file,
and there was no concept of a gui version. I think I jumped on the
vim bandwagon about 1.5 decades ago, and look, it has now taken over
the world. I am not implying that I had anything to do with that, just
that I fortuitously made a good choice. It might have been the only
logical choice at the time, if it was dominant already. In fact, I
think I still vaguely recall the times when I was trying to get a
decent code editor after many years away from vi, and I was messing
around with emacs.

Anyway, about bastardizing the [g]vimrc scheme, I only maintain one rc
file: vimrc. It has conditional statements depending on the value of
has('gui'), though I should probably join the 21st century and change
it to has('gui_running'). It might make the console vim experience
less...mysterious. Thanks again, Tony.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: visincr and mswin not compatible

jordi_frei wrote:
> I just installed the visincr script and it only works when I comment the
> following two lines:
>
> source $VIMRUNTIME/mswin.vim
> behave mswin
>
> When mswin is active the first line is changed instead of the selected
> column
>
> The thing is that, I really need to use cntrl-C, cntrl-V... in windows
> style. I am too much used to those commands and I am working with several
> applications that use these commands. I am copying pasting things from
> windows to vim and viceversa.
>
> Is there a way to use both mswin and visincr?
>
Hello!

Please try v21e of visincr which you can get from:

http://www.drchip.org/astronaut/vim/index.html#VISINCR

The problem was associated with set selection=exclusive (which :behave
mswin sets). Visincr now works around that setting.

Thank you for the report,
Chip Campbell

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: visincr and mswin not compatible

On Thu, Sep 24, 2015 at 2:09 PM, John Beckett <johnb.beckett@gmail.com> wrote:
> jordi_frei wrote:
>> The thing is that, I really need to use cntrl-C, cntrl-V
>
> Do not source mwwin.vim and do not use 'behave mswin'.
> Instead, put the following in your _vimrc.
>
> " Select all, cut, copy, paste.
> nnoremap <C-A> ggVG
> vnoremap <C-X> "+x
> vnoremap <C-C> "+y
> nnoremap <C-V> "+gP
> cnoremap <C-V> <C-R>+
> exe 'inoremap <script> <C-V>' paste#paste_cmd['i']
> exe 'vnoremap <script> <C-V>' paste#paste_cmd['v']
>
> " Save.
> nnoremap <C-S> :update<CR>
>
> " Increment/decrement (tip 30).
> nnoremap <A-a> <C-a>
> nnoremap <A-x> <C-x>
>
> Save/Increment/decrement are useful, so included above.
>
> Use ':help autoload' to see how paste#paste_cmd works. It
> invokes vim74/autoload/paste.vim for the insert mode and
> visual mode mappings.
>
> John

The :behave command is probably not harmful (less that sourcing
mswin.vim anyway) but for fine control I recommend setting these 4
options individually, each one to your liking, rather than all of them
together. What I use is the following (of course, YMMV):

" :behave tonymec
if exists('+selectmode')
set slm=mouse,key
endif
if exists('+mousemodel')
set mousemodel=popup
endif
if exists('+keymodel')
set keymodel=startsel
endif
if exists('+selection')
set selection=inclusive
endif

As you can see, these settings share some properties of both ":behave
mswin" and ":behave xterm". The ":if" wrappers are to avoid errors
regardless of which features have been compiled-in. They admittedly
have the side-effect that all four of these options are left at their
defaults (if any) in Vim executables compiled with -eval (i.e. in Tiny
and Small builds).

Best regards,
Tony.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Questions for the OptionSet event

Hi Rick!

On Do, 24 Sep 2015, Rick Howe wrote:

> Hi,
>
> The OptionSet event has been introduced in 7.4.786, which looks useful.
> I am trying to understand the behavior and I have found 2 questions now.
>
> #1
> For example,
> set number
> let &number = 1
> generates the event, but
> call setwinvar(0, '&number', 1)
> does not. Why?

That is a bug. switch_win() blocks autocommands. I'll post a patch
later.

>
> #2
> diffthis and diffoff
> generate the event only for scrollopt option.
> How about other options like diff, scrollbind, cursorbind, wrap, foldmethod, and foldcolumn?

My guess is, those functions set the values directly, not using the
set_bool_option function calls.

Best,
Christian
--
Geduld verlieren heißt Würde verlieren.
-- Indisches Sprichwort

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: visincr and mswin not compatible

On Thursday, September 24, 2015 at 7:09:20 AM UTC-5, JohnBeckett wrote:
> jordi_frei wrote:
> > The thing is that, I really need to use cntrl-C, cntrl-V
>
> Do not source mwwin.vim and do not use 'behave mswin'.

What's wrong with :behave mswin?

The help shows that it just sets a few options automatically. Although one could certainly set those options manually, nothing is wrong with using :behave to do it.

I agree that sourcing mswin.vim can cause problems, so in general I'd second your recommendation to not use it. However, plugins should be able to work around any weird mappings as needed.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Questions for the OptionSet event

Hi,

The OptionSet event has been introduced in 7.4.786, which looks useful.
I am trying to understand the behavior and I have found 2 questions now.

#1
For example,
set number
let &number = 1
generates the event, but
call setwinvar(0, '&number', 1)
does not. Why?

#2
diffthis and diffoff
generate the event only for scrollopt option.
How about other options like diff, scrollbind, cursorbind, wrap, foldmethod, and foldcolumn?

Thank you for your help.

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: visincr and mswin not compatible

jordi_frei wrote:
> The thing is that, I really need to use cntrl-C, cntrl-V

Do not source mwwin.vim and do not use 'behave mswin'.
Instead, put the following in your _vimrc.

" Select all, cut, copy, paste.
nnoremap <C-A> ggVG
vnoremap <C-X> "+x
vnoremap <C-C> "+y
nnoremap <C-V> "+gP
cnoremap <C-V> <C-R>+
exe 'inoremap <script> <C-V>' paste#paste_cmd['i']
exe 'vnoremap <script> <C-V>' paste#paste_cmd['v']

" Save.
nnoremap <C-S> :update<CR>

" Increment/decrement (tip 30).
nnoremap <A-a> <C-a>
nnoremap <A-x> <C-x>

Save/Increment/decrement are useful, so included above.

Use ':help autoload' to see how paste#paste_cmd works. It
invokes vim74/autoload/paste.vim for the insert mode and
visual mode mappings.

John

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Wednesday, September 23, 2015

Re: Bug: Inconsistent result with searchpair()?

Hi David!

On Mi, 23 Sep 2015, David Fishburn wrote:

> Christian, do you think it is worth putting together a reproducible
> that should work with basic Vim?

Sure, If you get a reproducible test, I'll look into it.

Best,
Christian
--
"Vollkommenheit ist die Norm des Himmels; Vollkommenes wollen,
die Norm des Menschen."
-- Goethe, Maximen und Reflektionen, Nr. 525

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug: Inconsistent result with searchpair()?

...
When I choose :SQLSetType plsql.vim instead of :SQLSetType sqlanywhere.vim, the problem also goes away.

I take that back, if I use a more complex query with more ()s in it, using the runtime\syntax\plsql.vim, the same error is reported, just a little later on. So it seems that the internals for syntax elements is getting messed up some how.

I have tried this with 7.4.0 (no patches) and it suffers from the same issue).

Christian, do you think it is worth putting together a reproducible that should work with basic Vim?

Thanks,

David

Re: Capitalizing SQL keywords

On Wed, Sep 23, 2015 at 3:09 PM, Sonny Chee <sonny.chee@gmail.com> wrote:

Hey Guys,

I've defined a bunch of (SQL) keywords I would like to capitalize using "abbreviate". This works great when I am typing in fresh new file.

Is there a way to apply these abbreviations to an existing file?

I created this plugin for this exact reason:

SrchRplcHiGrp.vim : Search and/or replace based on a syntax highlight group

http://www.vim.org/scripts/script.php?script_id=848

The default action will do exactly what you want.

Except I made it more general.

This gives you the ability to perform search and replace based on the syntax colouring of your Vim file.

Since SQL keywords are usually as a group (like keyword or statement) it can operate of those words of a given syntax group.

This one will also do it:

SQLUtilities : SQL utilities - Formatting, generate - columns lists, procedures for databases

http://www.vim.org/scripts/script.php?script_id=492

It will also format your SQL queries.

It has an option that while it reformats your SQL, it can change the case of the keywords.

HTH,

David

Re: Capitalizing SQL keywords

You might try this plugin:

http://www.vim.org/scripts/script.php?script_id=869

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Capitalizing SQL keywords

Hey Guys,

I've defined a bunch of (SQL) keywords I would like to capitalize using "abbreviate". This works great when I am typing in fresh new file.

Is there a way to apply these abbreviations to an existing file?

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug: Inconsistent result with searchpair()?

On Wed, Sep 23, 2015 at 12:24 PM, Christian Brabandt <cblists@256bit.org> wrote:

On Mi, 23 Sep 2015, David Fishburn wrote:

>
> I am about to run this searchpair() function
> line 38: let indent_to = searchpair( '(', '', ')', 'W', 'synID(line
> ("."),col("."),1)>0' )
>
> So, I check my line, column, current character and show the full line:
> >echo line('.') col('.') getline('.')[col('.')-1] getline('.')
> 3 15 ( SELECT-@- (
>
...

My suspicion is, that syntax highlighting changes slightly and your skip
part catches it. Could you check the synid(line('.'),col('.'),1) for
when it does not move on both parenthesis? Did this perhaps get out of
sync and your (...) is somehow syntax highlighed?

Thanks for the response Christian.

I had run :echo synID(line("."),col("."),1) at each position and it always comes back as 0, which is correct, there are no syntax elements on the ()s.

But given you comment, if I run:

:syntax off

I do not get the error.

:syntax on

:syntax sync fromstart

Get the error again.

If I choose a different ftplugin (:setlocal ft=javascript) I do not get the error.

Vim's SQL support allows you to set different SQL dialects using :SQLSetType, using <TAB> allows completion through the different types.

:SWhen I choose :SQLSetType plsql.vim instead of :SQLSetType sqlanywhere.vim, the problem also goes away.

I am the author the sqlanywhere.vim syntax file, so it appears I have either done something wrong, or added some additional things in this file that leads to the issue.

Not exactly sure where to start looking to find out what might be the issue here, as :echo synID(line("."),col("."),1) shows there are no syntax elements on these characters. But I can try to binary commenting of the syntax script to see if I can narrow it down.

David

Re: Bug: Inconsistent result with searchpair()?

On Mi, 23 Sep 2015, David Fishburn wrote:

> Windows 8.1 Vim 7.4.1-873
>
> In one of my plugins I am seeing inconsistent behaviour with searchpair()
>
> When it runs, it returns 0, when the cursor is in the exact same position and I
> run it a second time, it correctly finds the matching ).
>
> When I run it myself from :echo searchpair() it always works.
> But it fails everytime in my plugin.
>
> See my debug session here which I will annotate.
>
>
> I am about to run this searchpair() function
> line 38: let indent_to = searchpair( '(', '', ')', 'W', 'synID(line
> ("."),col("."),1)>0' )
>
> So, I check my line, column, current character and show the full line:
> >echo line('.') col('.') getline('.')[col('.')-1] getline('.')
> 3 15 ( SELECT-@- (
>
> So I am on an open (, searchpair() should find the closing )
>
> >n
> line 42: if indent_to == 0 && linenum == line(".") && curcol == col(".")
> >echo line('.') col('.') getline('.')[col('.')-1] getline('.')
> 5 12 ) -@-END CASE) AS 'POTYP', COALESCE( OLTXT.LTXT, '' ) AS LTXT
>
> Good, clearly the cursor has been moved from line:3, col :15 to line:5 col:12
>
> And verify the result from the searchpair() call:
> >echo indent_to
> 5
>
> Continue to the next open ( (which is on the same line)
>
> >c
> Breakpoint in "<SNR>90_SQLU_SplitUnbalParan" line 38
>
> Same deal, before we run this same line again, lets check the current cursor
> position:
>
> line 38: let indent_to = searchpair( '(', '', ')', 'W', 'synID(line("."),col
> ("."),1)>0' )
>
> >echo line('.') col('.') getline('.')[col('.')-1] getline('.')
> 6 26 ( -@-) AS 'POTYP', COALESCE( OLTXT.LTXT, '' ) AS LTXT
>
> So, line 6: col:26 we are on an open ( which is at the end of the COALESCE
> word) and we want to match the closing ), which is right before the word "AS".
>
> >n
>
> Lets check the results:
>
> >echo indent_to
> 0
>
> This is bad, it says there is no match for searchpair().
>
> So, lets check the cursor position again:
>
> >echo line('.') col('.') getline('.')[col('.')-1] getline('.')
> 6 26 ( -@-) AS 'POTYP', COALESCE( OLTXT.LTXT, '' ) AS LTXT
>
> So, the cursor has not moved (and it shouldn't since searchpair() didn't match)
>
> But this time, simply copy and paste the same line it just executed:
>
> >let indent_to = searchpair( '(', '', ')', 'W', 'synID(line("."),col("."),1)>0'
> )
>
> And check the result:
>
> >echo indent_to
> 6
>
> This time it found a match and all I did was run the same line 2x after
> verifying the cursor has not moved.
>
> >echo line('.') col('.') getline('.')[col('.')-1] getline('.')
> 6 43 ) -@-) AS 'POTYP', COALESCE( OLTXT.LTXT, '' ) AS LTXT
>
> Now we can see we have moved to the closing ) at col:43.
>
>
> Anyone have any suggestions on what I might look into to figure this out.

My suspicion is, that syntax highlighting changes slightly and your skip
part catches it. Could you check the synid(line('.'),col('.'),1) for
when it does not move on both parenthesis? Did this perhaps get out of
sync and your (...) is somehow syntax highlighed?

Best,
Christian
--
Mein Lebensmotto ist: Mittagsschläfchen, Masturbation und Müßiggang.
-- Hermes Phettberg

--
--
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 because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.