Thanks for the detailed response Ben -
On Monday, September 30, 2013 5:01:54 PM UTC+2, Ben Fritz wrote:
> > nmap <C-Enter> <C-w><C-]><C-w>T
>
>
>
> Side note: Is this last mapping necessary? You have an autocmd to
>
> already force a new buffer into a new tab. What's this one for? Opening
>
> a new tab for existing buffers?
You can ignore this one - it was an experiment which I forgot to remove before posting my query.
> > map OA k
>
> > map <Down> j
>
> > map <Left> h
>
> > map <Right> l
>
>
>
> Side note: By default Vim already moves around in every mode when you
>
> use the arrow keys, I don't think these mappings are needed.
This was me trying to get terminals to work correctly on an older Solaris machine which had old crappy terminfos - I eventually got it to work, so left this as-is.
> Your first problem is trying to force one-buffer-per-tab in all
>
> situations. That's always a recipe for headaches. But with that "maybe
>
> you should reconsider" note, I'll try to work with you here.
I hear you - It would be nice to perhaps get a new buffer only when I hit C-].
> It seems like the BuffAdd event fires before the file is actually read
>
> into the buffer. For after the file gets read, there is the BufRead
>
> event. So, your autocmd to force new buffers into tabs is messing with
>
> window layout and all sorts of things before Vim has any text to jump to
>
> to find the tag. Without any more details, I'd suggest trying a few
>
> other buffer related events, trying to get one which happens as late as
>
> possible in the process of opening the buffer so it has less chance of
>
> interfering with commands in progress.
>
>
>
> If that doesn't work, you could try modifying your MatchCaseTag function
>
> to issue a second tjump command in case the first doesn't work. It's a
>
> hack, but maybe it will fix your problem.
>
>
>
> Other than that, I think we need more info. Is there a pattern to the
>
> location in the new file where the bad tag jump takes you? Is it the
>
> last edited position, restored by your BufReadPost autocmd? Is it the
>
> same line number as the file you're jumping from, but in the new file?
>
> Somewhere else? No discernible pattern at all? This may give some clues.
>
>
>
> You can also try removing that BufReadPost autocmd temporarily to see
>
> whether it plays into this problem. I know you want to keep that one,
>
> but perhaps it needs tweaking to not fire while doing a tag jump via
>
> your function.
If I disable BufReadPost, then this is what happens:
C-] on a function call (A) in file (1) opens a new tab, but positions the cursor at the top of file (2), not on the function declaration itself.
If I then close the tab (returning to the original file (1)), and hit C-] again (on the same function call (A)), it then jumps to file (2) correctly positioning the cursor on the function declaration, but interestingly, does not open file (2) in a new tab, but instead re-uses the existing one (as it would if the function declaration was in the same file).
If enable BufReadPost, but disable au BufAdd,BufNewFile..., then all works perfectly, but without tabs obviously.
I'll continue scratching around, but any suggestions are welcome.
Regards
Henry
--
--
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/groups/opt_out.
Monday, September 30, 2013
Re: BufEnter buggy?
On 9/28/13, Aaron Bohannon <aaron678@gmail.com> wrote:
> I have an autocmd that updates the window title in my terminal based on the
> current file name. BufEnter clearly seems to be the event I would want to
> trigger it with. But I've noticed two problems:
>
> (a) BufEnter isn't getting triggered after closing the last window in a tab
> and ending up in a different tab. ...
Which Vim version are you using? I remember such bug being reported by
someone and it was subsequently fixed before version 7.4. It can be
tested as follows:
tabnew Foo
autocmd BufEnter <buffer> let g:foo+=1
tabmove
tabnew
let g:foo = 0
wincmd c
echo g:foo
The output is:
0 (wrong) in Vim 7.3.829
1 (correct) in Vim 7.3.145, Vim 7.4.000
Regards,
Vlad
--
--
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/groups/opt_out.
> I have an autocmd that updates the window title in my terminal based on the
> current file name. BufEnter clearly seems to be the event I would want to
> trigger it with. But I've noticed two problems:
>
> (a) BufEnter isn't getting triggered after closing the last window in a tab
> and ending up in a different tab. ...
Which Vim version are you using? I remember such bug being reported by
someone and it was subsequently fixed before version 7.4. It can be
tested as follows:
tabnew Foo
autocmd BufEnter <buffer> let g:foo+=1
tabmove
tabnew
let g:foo = 0
wincmd c
echo g:foo
The output is:
0 (wrong) in Vim 7.3.829
1 (correct) in Vim 7.3.145, Vim 7.4.000
Regards,
Vlad
--
--
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/groups/opt_out.
Re: BufEnter buggy?
The autocmd that sets the variable does not get run when I close the last window on a tab page. It is easy to check that it _does_ get run in other circumstances.
On Sep 30, 2013 12:06 PM, "Christian Brabandt" <cblists@256bit.org> wrote:
-- On Sun, September 29, 2013 19:58, Aaron Bohannon wrote:
> So I did this:
>
> autocmd BufEnter * let g:foo = expand('%')
>
> And then I'd check the value of g:foo with :echo after switching/closing
> windows.
Now I am confused. Does this work for you yes or no?
regards,
Christian
--
--
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/rIDzIjQ04sc/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/groups/opt_out.
--
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/groups/opt_out.
Re: (Vimscript) Stack Overflow Question
Excerpts from Benjamin Klein's message of Tue Oct 01 01:43:31 +0200 2013:
> I do not know whether Vimscript is a popular topic over on Stack
> Overflow, but this question was asked in July and has apparently
> received no answers; perhaps SO users here could look at it:
I just replied to it also telling the asker that he should have asked on
the mailinglist to get a faster reply :)
If eval() works, then this is a nice little implementation I used myself
to interface with ruby-debug-ide, eclim, scion and similar:
https://github.com/MarcWeber/vim-addon-json-encoding
Marc Weber
--
--
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/groups/opt_out.
> I do not know whether Vimscript is a popular topic over on Stack
> Overflow, but this question was asked in July and has apparently
> received no answers; perhaps SO users here could look at it:
I just replied to it also telling the asker that he should have asked on
the mailinglist to get a faster reply :)
If eval() works, then this is a nice little implementation I used myself
to interface with ruby-debug-ide, eclim, scion and similar:
https://github.com/MarcWeber/vim-addon-json-encoding
Marc Weber
--
--
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/groups/opt_out.
(Vimscript) Stack Overflow Question
I do not know whether Vimscript is a popular topic over on Stack Overflow, but this question was asked in July and has apparently received no answers; perhaps SO users here could look at it:
Iterating over a string in Vimscript or Parse a JSON file
http://stackoverflow.com/q/17751186/758011?sem=2
**Note that there is a bounty of 300 reputation on it now (for a week), and also that answers might be better given over there than as a reply to this, as that way they make it to SO as an answer to that question** (and of course SO reputation, in case that's of interest, can't be awarded by means of email). :)
Thanks!
--
b
Iterating over a string in Vimscript or Parse a JSON file
http://stackoverflow.com/q/17751186/758011?sem=2
**Note that there is a bounty of 300 reputation on it now (for a week), and also that answers might be better given over there than as a reply to this, as that way they make it to SO as an answer to that question** (and of course SO reputation, in case that's of interest, can't be awarded by means of email). :)
Thanks!
--
b
Re: Vim and Lilypond setup
On Monday, September 30, 2013 7:40:25 PM UTC+2, ke...@toughlife.org wrote:
> I have written the following block of text to Fedora forums and received
> a partial answer. Following the curly bracketed text block is a further
> question perhaps best answered by the talented folks here.
>
> {{
>
> I am just starting a school for children to learn English and guitar at
> the same time here in Germany. I've spent many hours trying to evaluate
> my options with the commercial software "GuitarPro" in comparison to
> using Tuxguitar and Lilypond. Tuxguitar appears to be "dead in the
> water" and does not correctly output input files for Lilypond.
>
> In searching for the reason why vim7.4 does not highlight Lilypond
> source files in Fedora 19 I have run into some confusion. The Lilypond
> website:
>
> http://www.lilypond.org/doc/v2.17/Do...editor-support
>
> suggests an entry into .vimrc such as:
>
>
> filetype off
> set runtimepath+=/usr/local/share/lilypond/current/vim/
> filetype on
>
> A bug report says that perhaps the above code should have the line
> "syntax on" following to be correct.
>
> With the Fedora Software Manager I have installed "Lilypond 2.16.2". In
> the installed directory /usr/share/lilypond there is no such vim
> directory present??? I am suspecting, without much knowledge, that they
> wish to provide their own vim scripts because they change their syntax
> often. Could it be??? If so where is the directory?
>
> Otherwise, my now old .../vim/vim73/syntax directory has only the three
> files left in it; lilypond.vim, lilypond-words, and lilypond-words.vim.
> I suspect the software manager may not have installed the files to the
> correct directory, vim74, as I have only recently installed Lilypond. I
> have copied the files to the vim74/syntax directory but the highlighting
> appears to be very limited without change. Comments and quotes are
> highlighted but not much more! In the lilypond.vim file a maintainer is
> mentioned: Heikki Junes but the Email address is no longer used
> "hjunes@cc.hut.fi".
>
> I would greatly appreciate advice on how to configure vim for Lilypond
> in Fedora 19.
>
> }}
See this other mailing list thread for a similar query:
https://groups.google.com/d/msg/vim_dev/3H9B5acDuzU/tZyupkDsyDcJ
Vim itself doesn't seem to have any support for lilypond, if the command
grep -Ri lilypond runtime
on Mercurial tip can be trusted. You will have to look elsewhere. But
I'm sure somebody here has a better answer.
Best,
--
--
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/groups/opt_out.
> I have written the following block of text to Fedora forums and received
> a partial answer. Following the curly bracketed text block is a further
> question perhaps best answered by the talented folks here.
>
> {{
>
> I am just starting a school for children to learn English and guitar at
> the same time here in Germany. I've spent many hours trying to evaluate
> my options with the commercial software "GuitarPro" in comparison to
> using Tuxguitar and Lilypond. Tuxguitar appears to be "dead in the
> water" and does not correctly output input files for Lilypond.
>
> In searching for the reason why vim7.4 does not highlight Lilypond
> source files in Fedora 19 I have run into some confusion. The Lilypond
> website:
>
> http://www.lilypond.org/doc/v2.17/Do...editor-support
>
> suggests an entry into .vimrc such as:
>
>
> filetype off
> set runtimepath+=/usr/local/share/lilypond/current/vim/
> filetype on
>
> A bug report says that perhaps the above code should have the line
> "syntax on" following to be correct.
>
> With the Fedora Software Manager I have installed "Lilypond 2.16.2". In
> the installed directory /usr/share/lilypond there is no such vim
> directory present??? I am suspecting, without much knowledge, that they
> wish to provide their own vim scripts because they change their syntax
> often. Could it be??? If so where is the directory?
>
> Otherwise, my now old .../vim/vim73/syntax directory has only the three
> files left in it; lilypond.vim, lilypond-words, and lilypond-words.vim.
> I suspect the software manager may not have installed the files to the
> correct directory, vim74, as I have only recently installed Lilypond. I
> have copied the files to the vim74/syntax directory but the highlighting
> appears to be very limited without change. Comments and quotes are
> highlighted but not much more! In the lilypond.vim file a maintainer is
> mentioned: Heikki Junes but the Email address is no longer used
> "hjunes@cc.hut.fi".
>
> I would greatly appreciate advice on how to configure vim for Lilypond
> in Fedora 19.
>
> }}
See this other mailing list thread for a similar query:
https://groups.google.com/d/msg/vim_dev/3H9B5acDuzU/tZyupkDsyDcJ
Vim itself doesn't seem to have any support for lilypond, if the command
grep -Ri lilypond runtime
on Mercurial tip can be trusted. You will have to look elsewhere. But
I'm sure somebody here has a better answer.
Best,
--
--
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/groups/opt_out.
Vim and Lilypond setup
I have written the following block of text to Fedora forums and received
a partial answer. Following the curly bracketed text block is a further
question perhaps best answered by the talented folks here.
{{
I am just starting a school for children to learn English and guitar at
the same time here in Germany. I've spent many hours trying to evaluate
my options with the commercial software "GuitarPro" in comparison to
using Tuxguitar and Lilypond. Tuxguitar appears to be "dead in the
water" and does not correctly output input files for Lilypond.
In searching for the reason why vim7.4 does not highlight Lilypond
source files in Fedora 19 I have run into some confusion. The Lilypond
website:
http://www.lilypond.org/doc/v2.17/Do...editor-support
suggests an entry into .vimrc such as:
filetype off
set runtimepath+=/usr/local/share/lilypond/current/vim/
filetype on
A bug report says that perhaps the above code should have the line
"syntax on" following to be correct.
With the Fedora Software Manager I have installed "Lilypond 2.16.2". In
the installed directory /usr/share/lilypond there is no such vim
directory present??? I am suspecting, without much knowledge, that they
wish to provide their own vim scripts because they change their syntax
often. Could it be??? If so where is the directory?
Otherwise, my now old .../vim/vim73/syntax directory has only the three
files left in it; lilypond.vim, lilypond-words, and lilypond-words.vim.
I suspect the software manager may not have installed the files to the
correct directory, vim74, as I have only recently installed Lilypond. I
have copied the files to the vim74/syntax directory but the highlighting
appears to be very limited without change. Comments and quotes are
highlighted but not much more! In the lilypond.vim file a maintainer is
mentioned: Heikki Junes but the Email address is no longer used
"hjunes@cc.hut.fi".
I would greatly appreciate advice on how to configure vim for Lilypond
in Fedora 19.
}}
Frescobaldi is an application, editor with a pre-view window for
Lilypond *.pdf files. Has anyone experience with using Gvim or vim to
acomplish the same thing using our favorite editor?
Namaste,
Kevin Tough
--
--
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/groups/opt_out.
a partial answer. Following the curly bracketed text block is a further
question perhaps best answered by the talented folks here.
{{
I am just starting a school for children to learn English and guitar at
the same time here in Germany. I've spent many hours trying to evaluate
my options with the commercial software "GuitarPro" in comparison to
using Tuxguitar and Lilypond. Tuxguitar appears to be "dead in the
water" and does not correctly output input files for Lilypond.
In searching for the reason why vim7.4 does not highlight Lilypond
source files in Fedora 19 I have run into some confusion. The Lilypond
website:
http://www.lilypond.org/doc/v2.17/Do...editor-support
suggests an entry into .vimrc such as:
filetype off
set runtimepath+=/usr/local/share/lilypond/current/vim/
filetype on
A bug report says that perhaps the above code should have the line
"syntax on" following to be correct.
With the Fedora Software Manager I have installed "Lilypond 2.16.2". In
the installed directory /usr/share/lilypond there is no such vim
directory present??? I am suspecting, without much knowledge, that they
wish to provide their own vim scripts because they change their syntax
often. Could it be??? If so where is the directory?
Otherwise, my now old .../vim/vim73/syntax directory has only the three
files left in it; lilypond.vim, lilypond-words, and lilypond-words.vim.
I suspect the software manager may not have installed the files to the
correct directory, vim74, as I have only recently installed Lilypond. I
have copied the files to the vim74/syntax directory but the highlighting
appears to be very limited without change. Comments and quotes are
highlighted but not much more! In the lilypond.vim file a maintainer is
mentioned: Heikki Junes but the Email address is no longer used
"hjunes@cc.hut.fi".
I would greatly appreciate advice on how to configure vim for Lilypond
in Fedora 19.
}}
Frescobaldi is an application, editor with a pre-view window for
Lilypond *.pdf files. Has anyone experience with using Gvim or vim to
acomplish the same thing using our favorite editor?
Namaste,
Kevin Tough
--
--
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/groups/opt_out.
Re: Scrolling (diffing) through VCS revisions
On Sep 30, 2013 8:56 PM, "Paul" <google1241@rainslide.net> wrote:
>
> On Monday, 30 September, 2013 at 15:30:24 BST, Nikolay Pavlov wrote:
>>>
>>> I've encountered similar problems in the past, because I have a
>>
>> BufRead/BufWinEnter autocmd which sets 'nomodifiable' if 'readonly' is set.
>> At one point I was doing a global "set nomodifiable" but now I do
>> "setlocal" instead. Otherwise, any new buffers created also have
>> 'nomodifiable' set.
>>>
>>>
>>> Jan, if you've got a similar autocmd, you should make the same fix.
>
>
> I don't have any mention of 'modif' in my ~/.vimrc, and I even disabled all other plugins. I didn't see a mention of modifiable in the output of ':au BufRead' and ':au BufWinEnter'.
>
> There are no mappings for gJ / gK. There are maps for J and K, both set from frawor/mappings.vim.
What version of aurum do you use? Just found out that I not have this functionality in release: it was added in https://bitbucket.org/ZyX_I/aurum/commits/49b075fb190379a76e2d55f86309e9a15c664d1f (nearly two weeks after last release).
>
>> If what you mentioned here is the case he must be doing gJ in the wrong
>> buffer (this must be done in the buffer with the committed version).
>
>
> I open a file, do ':AuVimDiff' on it. The version of the file in the repo opens in a new window. I switch to that new window, and it's there I do gJ / gK.
>
>
> --
> --
> 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/groups/opt_out.
--
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/groups/opt_out.
Re: Scrolling (diffing) through VCS revisions
On Monday, 30 September, 2013 at 15:30:24 BST, Nikolay Pavlov wrote:
>> I've encountered similar problems in the past, because I have a
>BufRead/BufWinEnter autocmd which sets 'nomodifiable' if 'readonly' is set.
>At one point I was doing a global "set nomodifiable" but now I do
>"setlocal" instead. Otherwise, any new buffers created also have
>'nomodifiable' set.
>>
>> Jan, if you've got a similar autocmd, you should make the same fix.
I don't have any mention of 'modif' in my ~/.vimrc, and I even disabled all other plugins. I didn't see a mention of modifiable in the output of ':au BufRead' and ':au BufWinEnter'.
There are no mappings for gJ / gK. There are maps for J and K, both set from frawor/mappings.vim.
>If what you mentioned here is the case he must be doing gJ in the wrong
>buffer (this must be done in the buffer with the committed version).
I open a file, do ':AuVimDiff' on it. The version of the file in the repo opens in a new window. I switch to that new window, and it's there I do gJ / gK.
--
--
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/groups/opt_out.
>> I've encountered similar problems in the past, because I have a
>BufRead/BufWinEnter autocmd which sets 'nomodifiable' if 'readonly' is set.
>At one point I was doing a global "set nomodifiable" but now I do
>"setlocal" instead. Otherwise, any new buffers created also have
>'nomodifiable' set.
>>
>> Jan, if you've got a similar autocmd, you should make the same fix.
I don't have any mention of 'modif' in my ~/.vimrc, and I even disabled all other plugins. I didn't see a mention of modifiable in the output of ':au BufRead' and ':au BufWinEnter'.
There are no mappings for gJ / gK. There are maps for J and K, both set from frawor/mappings.vim.
>If what you mentioned here is the case he must be doing gJ in the wrong
>buffer (this must be done in the buffer with the committed version).
I open a file, do ':AuVimDiff' on it. The version of the file in the repo opens in a new window. I switch to that new window, and it's there I do gJ / gK.
--
--
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/groups/opt_out.
Re: BufEnter buggy?
On Sun, September 29, 2013 19:58, Aaron Bohannon wrote:
> So I did this:
>
> autocmd BufEnter * let g:foo = expand('%')
>
> And then I'd check the value of g:foo with :echo after switching/closing
> windows.
Now I am confused. Does this work for you yes or no?
regards,
Christian
--
--
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/groups/opt_out.
> So I did this:
>
> autocmd BufEnter * let g:foo = expand('%')
>
> And then I'd check the value of g:foo with :echo after switching/closing
> windows.
Now I am confused. Does this work for you yes or no?
regards,
Christian
--
--
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/groups/opt_out.
Re: Scrolling (diffing) through VCS revisions
On Sep 30, 2013 7:06 PM, "Ben Fritz" <fritzophrenic@gmail.com> wrote:
>
> On Monday, September 30, 2013 9:30:24 AM UTC-5, ZyX wrote:
> > On Sep 30, 2013 6:21 PM, "Ben Fritz" <fritzo...@gmail.com> wrote:
> > > ZyX, if the new buffer your plugin is creating should always be modifiable, it would be smart to set 'modifiable' explicitly just in case it inherits a bad value.
> >
> > As I said, gJ does not modify current buffer: it instead opens a new one.
>
> And as I said, the new buffer may have 'nomodifiable' set already, inherited from the global value of the option.
>
> gvim -N -u NONE -i NONE
> :set nomodifiable
> :new
> :set modifiable?
> nomodifiable
This means buffer will be empty as it is populated with setline() (or some manipulations with vim.current.buffer in python). Who cares about not working gJ if buffer is empty while it should show committed version?
Though I do not recall whether or not I was unsetting &modifiable. But this cannot lead to *just* not working gJ.
> --
> --
> 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/groups/opt_out.
--
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/groups/opt_out.
Re: Scrolling (diffing) through VCS revisions
On Monday, September 30, 2013 9:30:24 AM UTC-5, ZyX wrote:
> On Sep 30, 2013 6:21 PM, "Ben Fritz" <fritzo...@gmail.com> wrote:
> > ZyX, if the new buffer your plugin is creating should always be modifiable, it would be smart to set 'modifiable' explicitly just in case it inherits a bad value.
>
> As I said, gJ does not modify current buffer: it instead opens a new one.
And as I said, the new buffer may have 'nomodifiable' set already, inherited from the global value of the option.
gvim -N -u NONE -i NONE
:set nomodifiable
:new
:set modifiable?
nomodifiable
--
--
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/groups/opt_out.
> On Sep 30, 2013 6:21 PM, "Ben Fritz" <fritzo...@gmail.com> wrote:
> > ZyX, if the new buffer your plugin is creating should always be modifiable, it would be smart to set 'modifiable' explicitly just in case it inherits a bad value.
>
> As I said, gJ does not modify current buffer: it instead opens a new one.
And as I said, the new buffer may have 'nomodifiable' set already, inherited from the global value of the option.
gvim -N -u NONE -i NONE
:set nomodifiable
:new
:set modifiable?
nomodifiable
--
--
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/groups/opt_out.
Re: Each buffer in own tab/function lookup seem to clash
On Monday, September 30, 2013 9:01:17 AM UTC-5, Henry Combrinck wrote:
>
>
> The problem: if I enable "au BufAdd,BufNewFile...", then C-] often
> jumps to the incorrect position in the file containing a
> function/subroutine declaration. This happens whether I use the call
> to MatchCaseTag() or not.
>
>
> If I disable "au BufAdd,BufNewFile...", then it always jumps to the
> correct position - without fail. But having vim remember my cursor
> position per file is indispensable.
>
OK, but why are you mentioning the remembered cursor position? If I
understand your .vimrc (below) correctly, that's a completely separate
autocmd that (so far) hasn't entered into your description.
But maybe it's one culprit.
> My .vimrc contains:
>
> [snip]
>
> " remember last cursor position
> if has("autocmd")
> au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
> endif
>
> [snip]
>
> map <C-]> :call MatchCaseTag()<CR>
> " following is so g] works on class::method
> set iskeyword+=:
>
> nmap <C-Enter> <C-w><C-]><C-w>T
Side note: Is this last mapping necessary? You have an autocmd to
already force a new buffer into a new tab. What's this one for? Opening
a new tab for existing buffers?
> [snip]
>
> " each buffer in it's own tab.
> au BufAdd,BufNewFile * nested tab sball
>
> "set nocompatible
> map OA k
> map <Down> j
> map <Left> h
> map <Right> l
>
Side note: By default Vim already moves around in every mode when you
use the arrow keys, I don't think these mappings are needed.
>
> fun! MatchCaseTag()
> let ic = &ic
> set noic
> try
> exe 'tjump ' . expand('<cword>')
> finally
> let &ic = ic
> endtry
> endfun
>
> " auto-add comments
>
>
> I'd appreciate any pointers on what I'm doing incorrectly.
>
Your first problem is trying to force one-buffer-per-tab in all
situations. That's always a recipe for headaches. But with that "maybe
you should reconsider" note, I'll try to work with you here.
It seems like the BuffAdd event fires before the file is actually read
into the buffer. For after the file gets read, there is the BufRead
event. So, your autocmd to force new buffers into tabs is messing with
window layout and all sorts of things before Vim has any text to jump to
to find the tag. Without any more details, I'd suggest trying a few
other buffer related events, trying to get one which happens as late as
possible in the process of opening the buffer so it has less chance of
interfering with commands in progress.
If that doesn't work, you could try modifying your MatchCaseTag function
to issue a second tjump command in case the first doesn't work. It's a
hack, but maybe it will fix your problem.
Other than that, I think we need more info. Is there a pattern to the
location in the new file where the bad tag jump takes you? Is it the
last edited position, restored by your BufReadPost autocmd? Is it the
same line number as the file you're jumping from, but in the new file?
Somewhere else? No discernible pattern at all? This may give some clues.
You can also try removing that BufReadPost autocmd temporarily to see
whether it plays into this problem. I know you want to keep that one,
but perhaps it needs tweaking to not fire while doing a tag jump via
your function.
--
--
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/groups/opt_out.
>
>
> The problem: if I enable "au BufAdd,BufNewFile...", then C-] often
> jumps to the incorrect position in the file containing a
> function/subroutine declaration. This happens whether I use the call
> to MatchCaseTag() or not.
>
>
> If I disable "au BufAdd,BufNewFile...", then it always jumps to the
> correct position - without fail. But having vim remember my cursor
> position per file is indispensable.
>
OK, but why are you mentioning the remembered cursor position? If I
understand your .vimrc (below) correctly, that's a completely separate
autocmd that (so far) hasn't entered into your description.
But maybe it's one culprit.
> My .vimrc contains:
>
> [snip]
>
> " remember last cursor position
> if has("autocmd")
> au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
> endif
>
> [snip]
>
> map <C-]> :call MatchCaseTag()<CR>
> " following is so g] works on class::method
> set iskeyword+=:
>
> nmap <C-Enter> <C-w><C-]><C-w>T
Side note: Is this last mapping necessary? You have an autocmd to
already force a new buffer into a new tab. What's this one for? Opening
a new tab for existing buffers?
> [snip]
>
> " each buffer in it's own tab.
> au BufAdd,BufNewFile * nested tab sball
>
> "set nocompatible
> map OA k
> map <Down> j
> map <Left> h
> map <Right> l
>
Side note: By default Vim already moves around in every mode when you
use the arrow keys, I don't think these mappings are needed.
>
> fun! MatchCaseTag()
> let ic = &ic
> set noic
> try
> exe 'tjump ' . expand('<cword>')
> finally
> let &ic = ic
> endtry
> endfun
>
> " auto-add comments
>
>
> I'd appreciate any pointers on what I'm doing incorrectly.
>
Your first problem is trying to force one-buffer-per-tab in all
situations. That's always a recipe for headaches. But with that "maybe
you should reconsider" note, I'll try to work with you here.
It seems like the BuffAdd event fires before the file is actually read
into the buffer. For after the file gets read, there is the BufRead
event. So, your autocmd to force new buffers into tabs is messing with
window layout and all sorts of things before Vim has any text to jump to
to find the tag. Without any more details, I'd suggest trying a few
other buffer related events, trying to get one which happens as late as
possible in the process of opening the buffer so it has less chance of
interfering with commands in progress.
If that doesn't work, you could try modifying your MatchCaseTag function
to issue a second tjump command in case the first doesn't work. It's a
hack, but maybe it will fix your problem.
Other than that, I think we need more info. Is there a pattern to the
location in the new file where the bad tag jump takes you? Is it the
last edited position, restored by your BufReadPost autocmd? Is it the
same line number as the file you're jumping from, but in the new file?
Somewhere else? No discernible pattern at all? This may give some clues.
You can also try removing that BufReadPost autocmd temporarily to see
whether it plays into this problem. I know you want to keep that one,
but perhaps it needs tweaking to not fire while doing a tag jump via
your function.
--
--
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/groups/opt_out.
Re: Scrolling (diffing) through VCS revisions
On Sep 30, 2013 6:21 PM, "Ben Fritz" <fritzophrenic@gmail.com> wrote:
>
> On Monday, September 30, 2013 5:13:45 AM UTC-5, ZyX wrote:
> > On Sep 30, 2013 1:20 PM, "Paul" <googl...@rainslide.net> wrote:
> >
> > >> Note: gJ and gK should be typed in the buffer with repository version, not
> >
> > >> in the buffer with version from current working directory. J and K are for
> >
> > >> just next/previous revision. If you are diffing two revisions they should
> >
> > >> work for both (in fact it is aurum://file mapping, not the
> >
> > >> AuVimDiff-specific one).
> >
> > >
> >
> > >
> >
> > > When I do gJ / gK, I get "E21: Cannot make changes, 'modifiable' is off". I tried making this an issue on bitbucket but I got a 403.
> >
> > Do you have any mappings to gJ/gK? These commands do not do any changes, they open a new buffer.
> >
> > : what does ":verbose nmap gJ" show?
> >
>
> Hi, ZyX and Jan!
>
> I've encountered similar problems in the past, because I have a BufRead/BufWinEnter autocmd which sets 'nomodifiable' if 'readonly' is set. At one point I was doing a global "set nomodifiable" but now I do "setlocal" instead. Otherwise, any new buffers created also have 'nomodifiable' set.
>
> Jan, if you've got a similar autocmd, you should make the same fix.
>
> ZyX, if the new buffer your plugin is creating should always be modifiable, it would be smart to set 'modifiable' explicitly just in case it inherits a bad value.
As I said, gJ does not modify current buffer: it instead opens a new one. 'nomodifiable' is set by aurum for all aurum://file buffers. Thus I assume he has similar problem with conflicting mappings as I have (I have remapped J for vim files though and not gJ, thus I am not much willing to resolve conflict).
If what you mentioned here is the case he must be doing gJ in the wrong buffer (this must be done in the buffer with the committed 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/groups/opt_out.
--
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/groups/opt_out.
Re: Scrolling (diffing) through VCS revisions
On Monday, September 30, 2013 5:13:45 AM UTC-5, ZyX wrote:
> On Sep 30, 2013 1:20 PM, "Paul" <googl...@rainslide.net> wrote:
>
> >> Note: gJ and gK should be typed in the buffer with repository version, not
>
> >> in the buffer with version from current working directory. J and K are for
>
> >> just next/previous revision. If you are diffing two revisions they should
>
> >> work for both (in fact it is aurum://file mapping, not the
>
> >> AuVimDiff-specific one).
>
> >
>
> >
>
> > When I do gJ / gK, I get "E21: Cannot make changes, 'modifiable' is off". I tried making this an issue on bitbucket but I got a 403.
>
> Do you have any mappings to gJ/gK? These commands do not do any changes, they open a new buffer.
>
> : what does ":verbose nmap gJ" show?
>
Hi, ZyX and Jan!
I've encountered similar problems in the past, because I have a BufRead/BufWinEnter autocmd which sets 'nomodifiable' if 'readonly' is set. At one point I was doing a global "set nomodifiable" but now I do "setlocal" instead. Otherwise, any new buffers created also have 'nomodifiable' set.
Jan, if you've got a similar autocmd, you should make the same fix.
ZyX, if the new buffer your plugin is creating should always be modifiable, it would be smart to set 'modifiable' explicitly just in case it inherits a bad value.
--
--
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/groups/opt_out.
> On Sep 30, 2013 1:20 PM, "Paul" <googl...@rainslide.net> wrote:
>
> >> Note: gJ and gK should be typed in the buffer with repository version, not
>
> >> in the buffer with version from current working directory. J and K are for
>
> >> just next/previous revision. If you are diffing two revisions they should
>
> >> work for both (in fact it is aurum://file mapping, not the
>
> >> AuVimDiff-specific one).
>
> >
>
> >
>
> > When I do gJ / gK, I get "E21: Cannot make changes, 'modifiable' is off". I tried making this an issue on bitbucket but I got a 403.
>
> Do you have any mappings to gJ/gK? These commands do not do any changes, they open a new buffer.
>
> : what does ":verbose nmap gJ" show?
>
Hi, ZyX and Jan!
I've encountered similar problems in the past, because I have a BufRead/BufWinEnter autocmd which sets 'nomodifiable' if 'readonly' is set. At one point I was doing a global "set nomodifiable" but now I do "setlocal" instead. Otherwise, any new buffers created also have 'nomodifiable' set.
Jan, if you've got a similar autocmd, you should make the same fix.
ZyX, if the new buffer your plugin is creating should always be modifiable, it would be smart to set 'modifiable' explicitly just in case it inherits a bad value.
--
--
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/groups/opt_out.
Each buffer in own tab/function lookup seem to clash
Greets,
I've tried this on vim 7.3 and 7.4.
I've tried this on vim 7.3 and 7.4.
The problem: if I enable "au BufAdd,BufNewFile...", then C-] often jumps to the incorrect position in the file containing a function/subroutine declaration. This happens whether I use the call to MatchCaseTag() or not.
If I disable "au BufAdd,BufNewFile...", then it always jumps to the correct position - without fail. But having vim remember my cursor position per file is indispensable.
set ai
set tabstop=4
set shiftwidth=4
syntax on
set expandtab
set smarttab
set smartindent
set backspace=indent,eol,start
set tags+=tags;~
" don't format/autoindent pasted text
nnoremap <F2> :set invpaste paste?<CR>
set pastetoggle=<F2>
set showmode
" remember last cursor position
if has("autocmd")
au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
endif
" toggle last search term highlighting
"map <F12> :set hls!<CR>
"imap <F12> <ESC>:set hls!<CR>a
"vmap <F12> <ESC>:set hls!<CR>gv
map <C-h> :set hls!<CR>
imap <C-h> <ESC>:set hls!<CR>a
vmap <C-h> <ESC>:set hls!<CR>gv
" uppercase current word
map <C-u> gUiw
" lowercase current word
map <C-l> guiw
" switch off last found highlight
map ; /adfadf<CR><C-g>
map <C-]> :call MatchCaseTag()<CR>
" following is so g] works on class::method
set iskeyword+=:
nmap <C-Enter> <C-w><C-]><C-w>T
set hlsearch
highlight MatchParen ctermbg=yellow guibg=yellow
set showtabline=2 " File tabs allways visible
" c-pageup/down switches tabs
" :tabnew etc
" each buffer in it's own tab.
au BufAdd,BufNewFile * nested tab sball
"set nocompatible
map OA k
map <Down> j
map <Left> h
map <Right> l
fun! MatchCaseTag()
let ic = &ic
set noic
try
exe 'tjump ' . expand('<cword>')
finally
let &ic = ic
endtry
endfun
" auto-add comments
set formatoptions+=r
" check with :make
autocmd FileType perl set makeprg=perl\ -c\ %\ $*
autocmd FileType perl set errorformat=%f:%l:%m
autocmd FileType perl set autowrite
" Tidy selected lines (or entire file) with _t:
" (perltidy does not exist on eros)
nnoremap <silent> _t :%!perltidy -q<Enter>
vnoremap <silent> _t :!perltidy -q<Enter>
" my perl includes pod
let perl_include_pod = 1
" syntax color complex things like @{${"foo"}}
let perl_extended_vars = 1
---
Thanks
Henry
--
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/groups/opt_out.
Re: Scrolling (diffing) through VCS revisions
On Sep 30, 2013 1:20 PM, "Paul" <google1241@rainslide.net> wrote:
>
> On Wednesday, 18 September, 2013 at 20:29:49 BST, Nikolay Pavlov wrote:
>>
>> Aurum is capable of doing this: :AuVimDiff, then gJ for previous and gK for
>> next revision with modifications, but its subversion and bazaar backends
>> are least stable as the only place where I use both VCSes is aurum test
>> suite. Feel free to report bugs to https://bitbucket.org/ZyX_I/aurum/issues.
>>
>> Note: gJ and gK should be typed in the buffer with repository version, not
>> in the buffer with version from current working directory. J and K are for
>> just next/previous revision. If you are diffing two revisions they should
>> work for both (in fact it is aurum://file mapping, not the
>> AuVimDiff-specific one).
>
>
> When I do gJ / gK, I get "E21: Cannot make changes, 'modifiable' is off". I tried making this an issue on bitbucket but I got a 403.
Do you have any mappings to gJ/gK? These commands do not do any changes, they open a new buffer.
: what does ":verbose nmap gJ" show?
>
> --
> --
> 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/groups/opt_out.
--
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/groups/opt_out.
Re: Scrolling (diffing) through VCS revisions
On Wednesday, 18 September, 2013 at 20:29:49 BST, Nikolay Pavlov wrote:
>Aurum is capable of doing this: :AuVimDiff, then gJ for previous and gK for
>next revision with modifications, but its subversion and bazaar backends
>are least stable as the only place where I use both VCSes is aurum test
>suite. Feel free to report bugs to https://bitbucket.org/ZyX_I/aurum/issues.
>
>Note: gJ and gK should be typed in the buffer with repository version, not
>in the buffer with version from current working directory. J and K are for
>just next/previous revision. If you are diffing two revisions they should
>work for both (in fact it is aurum://file mapping, not the
>AuVimDiff-specific one).
When I do gJ / gK, I get "E21: Cannot make changes, 'modifiable' is off". I tried making this an issue on bitbucket but I got a 403.
--
--
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/groups/opt_out.
>Aurum is capable of doing this: :AuVimDiff, then gJ for previous and gK for
>next revision with modifications, but its subversion and bazaar backends
>are least stable as the only place where I use both VCSes is aurum test
>suite. Feel free to report bugs to https://bitbucket.org/ZyX_I/aurum/issues.
>
>Note: gJ and gK should be typed in the buffer with repository version, not
>in the buffer with version from current working directory. J and K are for
>just next/previous revision. If you are diffing two revisions they should
>work for both (in fact it is aurum://file mapping, not the
>AuVimDiff-specific one).
When I do gJ / gK, I get "E21: Cannot make changes, 'modifiable' is off". I tried making this an issue on bitbucket but I got a 403.
--
--
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/groups/opt_out.
Sunday, September 29, 2013
Re: Latest failed compilation
On 29/09/13 20:40, Gregory M. Caughey wrote:
> On 9/29/2013 9:35 AM, Tony Mechelynck wrote:
>> On 29/09/13 17:32, Gregory M. Caughey wrote:
>>> Hi everybody,
>>> Since build 'Vim-7.4.041' my builds have been failing with error message
>>> "Makefile:2697: recipe for target `objects/mbyte.o' failed".
>>>
>>> I've captured the last few lines from my screen output and included as
>>> an attachment. I don't know if the fault is Vim or my Cygwin environment
>>> which I update regularly.
>>> Has anybody else experienced this problem? I have been building Vim for
>>> console mode and the GUI version for years and failed compilations have
>>> rarely occurred.
>>>
>>> I'm working on a Windows 7 box with the latest Cygwin (x86) environment
>>> installed. I'm running with all of the latest upgrades and security
>>> upgrades.
>>>
>>> v/r,
>>> Greg
>>>
>> There seems to be a conflict between Cygwin headers and Vim headers.
>> Could you paste lines 4951 and 5090 of /usr/include/w32api/winnt.h (as
>> seen from Cygwin bash) into a reply email please?
>>
>>
>> Best regards,
>> Tony.
> Hope this is what you're looking for.
>
> Thanks, Greg
>
In my Vim for GTK2/Gnome2, cscope finds the Status identifier as follows:
- defined by typedef at
/usr/include/X11/SM/SMlib.h line 168
/usr/include/X11/SM/SMlib.h line 306
/usr/include/X11/ICE/ICElib.h line 163
- defined by #define at
/usr/include/X11/Xlib.h line 87
/usr/include/X11/ICE/ICElib.h line 36
- used 77 times; the Vim sources among them (as opposed to system
include files) are:
src/gui_x11.c line 775
src/if_xcmdsrv.c line 266
src/os_unix.c line 1858
src/os_unix.c line 1923
In all cases (and also in system include files) I see that identifier
used as a type, which conflicts with its use as a data-name in your
/usr/include/w32api/winnt.h which is indirectly included by the line
# include <windows.h>
at line 86 of src/mbyte.c and within the range of an #ifdef WIN32UNIX.
The only #include earlier in the same source file is for "vim.h" with
quotes.
Bram, do you think we _can_ avoid this conflict, considering that the
conflicting definitions are both in system include files?
Best regards,
Tony.
--
There once was a girl from Madras
Who had such a beautiful ass --
It was not round and pink
(As you bastards think)
But had two ears, a tail, and ate grass.
--
--
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/groups/opt_out.
> On 9/29/2013 9:35 AM, Tony Mechelynck wrote:
>> On 29/09/13 17:32, Gregory M. Caughey wrote:
>>> Hi everybody,
>>> Since build 'Vim-7.4.041' my builds have been failing with error message
>>> "Makefile:2697: recipe for target `objects/mbyte.o' failed".
>>>
>>> I've captured the last few lines from my screen output and included as
>>> an attachment. I don't know if the fault is Vim or my Cygwin environment
>>> which I update regularly.
>>> Has anybody else experienced this problem? I have been building Vim for
>>> console mode and the GUI version for years and failed compilations have
>>> rarely occurred.
>>>
>>> I'm working on a Windows 7 box with the latest Cygwin (x86) environment
>>> installed. I'm running with all of the latest upgrades and security
>>> upgrades.
>>>
>>> v/r,
>>> Greg
>>>
>> There seems to be a conflict between Cygwin headers and Vim headers.
>> Could you paste lines 4951 and 5090 of /usr/include/w32api/winnt.h (as
>> seen from Cygwin bash) into a reply email please?
>>
>>
>> Best regards,
>> Tony.
> Hope this is what you're looking for.
>
> Thanks, Greg
>
In my Vim for GTK2/Gnome2, cscope finds the Status identifier as follows:
- defined by typedef at
/usr/include/X11/SM/SMlib.h line 168
/usr/include/X11/SM/SMlib.h line 306
/usr/include/X11/ICE/ICElib.h line 163
- defined by #define at
/usr/include/X11/Xlib.h line 87
/usr/include/X11/ICE/ICElib.h line 36
- used 77 times; the Vim sources among them (as opposed to system
include files) are:
src/gui_x11.c line 775
src/if_xcmdsrv.c line 266
src/os_unix.c line 1858
src/os_unix.c line 1923
In all cases (and also in system include files) I see that identifier
used as a type, which conflicts with its use as a data-name in your
/usr/include/w32api/winnt.h which is indirectly included by the line
# include <windows.h>
at line 86 of src/mbyte.c and within the range of an #ifdef WIN32UNIX.
The only #include earlier in the same source file is for "vim.h" with
quotes.
Bram, do you think we _can_ avoid this conflict, considering that the
conflicting definitions are both in system include files?
Best regards,
Tony.
--
There once was a girl from Madras
Who had such a beautiful ass --
It was not round and pink
(As you bastards think)
But had two ears, a tail, and ate grass.
--
--
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/groups/opt_out.
Re: Multilingual spell check error in vim
On Sun, Sep 29, 2013 at 09:22:06PM +0200, John Niendorf wrote:
>Hi Guys,
>
>I started trying to learn vim again and have made it further than I
>did before, but....
>
>I need spell checking in both Swedish and English.
>
>Following instructions I found at
>http://ubuntu-se.org/phpBB3/viewtopic.php?f=67&t=32844 I downloaded
>the Swedish language files:
>
>sv.latin1.spl
>sv.latin1.sug
>sv.utf-8.spl
>sv.utf-8.sug
>
>I'm not sure if I need the latin or just utf so I grabbed both
>from:ftp://ftp.vim.org/pub/vim/runtime/spell/
>
>The instructions I found say:
>
>"By default, Vim only installs spell files for the English language.
>To install spell files for your preferred language, download the *.spl
>and optionally, the *.sug files for your language and character
>encoding from ftp://ftp.vim.org/pub/vim/runtime/spell/ and save them
>to /usr/share/vim/vim72/spell/.
>
>To use these spell files, some configuration in /etc/vimrc is needed, e.g.:
>
>set spelllang=en,ru
>set spell"
>(The example on the website uses English and Russian, obviously.)
>I copied the language files I downloaded to
>/usr/share/vim/vim73/spell/
>
>I now have both English and Swedish spell checking in vim, which is
>cool, but I have a couple of questions.
>
>When I type :set spelllang=sv,en I get an error that says
>Error detected while processing /home/john/.vim/spell/sv.utf-8.spl:
>E763: Word characters differ between spell files
>
>If I ignore this error and go about my text processing business,
>everything seems to work fine. Vim catches and suggests words for
>misspellings in both languages.
>
>Does anyone know how I can get rid of this error? It is a bit annoying.
I should have looked harder before emailing the list.
The solution was simple. I replaced the English files with files
downloaded from vim.org. The error is gone.
--
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/groups/opt_out.
>Hi Guys,
>
>I started trying to learn vim again and have made it further than I
>did before, but....
>
>I need spell checking in both Swedish and English.
>
>Following instructions I found at
>http://ubuntu-se.org/phpBB3/viewtopic.php?f=67&t=32844 I downloaded
>the Swedish language files:
>
>sv.latin1.spl
>sv.latin1.sug
>sv.utf-8.spl
>sv.utf-8.sug
>
>I'm not sure if I need the latin or just utf so I grabbed both
>from:ftp://ftp.vim.org/pub/vim/runtime/spell/
>
>The instructions I found say:
>
>"By default, Vim only installs spell files for the English language.
>To install spell files for your preferred language, download the *.spl
>and optionally, the *.sug files for your language and character
>encoding from ftp://ftp.vim.org/pub/vim/runtime/spell/ and save them
>to /usr/share/vim/vim72/spell/.
>
>To use these spell files, some configuration in /etc/vimrc is needed, e.g.:
>
>set spelllang=en,ru
>set spell"
>(The example on the website uses English and Russian, obviously.)
>I copied the language files I downloaded to
>/usr/share/vim/vim73/spell/
>
>I now have both English and Swedish spell checking in vim, which is
>cool, but I have a couple of questions.
>
>When I type :set spelllang=sv,en I get an error that says
>Error detected while processing /home/john/.vim/spell/sv.utf-8.spl:
>E763: Word characters differ between spell files
>
>If I ignore this error and go about my text processing business,
>everything seems to work fine. Vim catches and suggests words for
>misspellings in both languages.
>
>Does anyone know how I can get rid of this error? It is a bit annoying.
I should have looked harder before emailing the list.
The solution was simple. I replaced the English files with files
downloaded from vim.org. The error is gone.
--
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/groups/opt_out.
Multilingual spell check error in vim
Hi Guys,
I started trying to learn vim again and have made it further than I did
before, but....
I need spell checking in both Swedish and English.
Following instructions I found at
http://ubuntu-se.org/phpBB3/viewtopic.php?f=67&t=32844 I downloaded the
Swedish language files:
sv.latin1.spl
sv.latin1.sug
sv.utf-8.spl
sv.utf-8.sug
I'm not sure if I need the latin or just utf so I grabbed both
from:ftp://ftp.vim.org/pub/vim/runtime/spell/
The instructions I found say:
"By default, Vim only installs spell files for the English language. To
install spell files for your preferred language, download the *.spl and
optionally, the *.sug files for your language and character encoding from
ftp://ftp.vim.org/pub/vim/runtime/spell/ and save them to
/usr/share/vim/vim72/spell/.
To use these spell files, some configuration in /etc/vimrc is needed, e.g.:
set spelllang=en,ru
set spell"
(The example on the website uses English and Russian, obviously.)
I copied the language files I downloaded to /usr/share/vim/vim73/spell/
I now have both English and Swedish spell checking in vim, which is cool,
but I have a couple of questions.
When I type :set spelllang=sv,en I get an error that says
Error detected while processing /home/john/.vim/spell/sv.utf-8.spl:
E763: Word characters differ between spell files
If I ignore this error and go about my text processing business, everything
seems to work fine. Vim catches and suggests words for misspellings in both
languages.
Does anyone know how I can get rid of this error? It is a bit annoying.
--
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/groups/opt_out.
I started trying to learn vim again and have made it further than I did
before, but....
I need spell checking in both Swedish and English.
Following instructions I found at
http://ubuntu-se.org/phpBB3/viewtopic.php?f=67&t=32844 I downloaded the
Swedish language files:
sv.latin1.spl
sv.latin1.sug
sv.utf-8.spl
sv.utf-8.sug
I'm not sure if I need the latin or just utf so I grabbed both
from:ftp://ftp.vim.org/pub/vim/runtime/spell/
The instructions I found say:
"By default, Vim only installs spell files for the English language. To
install spell files for your preferred language, download the *.spl and
optionally, the *.sug files for your language and character encoding from
ftp://ftp.vim.org/pub/vim/runtime/spell/ and save them to
/usr/share/vim/vim72/spell/.
To use these spell files, some configuration in /etc/vimrc is needed, e.g.:
set spelllang=en,ru
set spell"
(The example on the website uses English and Russian, obviously.)
I copied the language files I downloaded to /usr/share/vim/vim73/spell/
I now have both English and Swedish spell checking in vim, which is cool,
but I have a couple of questions.
When I type :set spelllang=sv,en I get an error that says
Error detected while processing /home/john/.vim/spell/sv.utf-8.spl:
E763: Word characters differ between spell files
If I ignore this error and go about my text processing business, everything
seems to work fine. Vim catches and suggests words for misspellings in both
languages.
Does anyone know how I can get rid of this error? It is a bit annoying.
--
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/groups/opt_out.
Re: Latest failed compilation
DWORD64 Status;
DWORD HitCount;
DWORD Reserved1;
DWORD64 Reserved2;
DWORD64 Reserved3;
} PPM_WMI_PERF_STATE,*PPPM_WMI_PERF_STATE;
typedef struct {
DWORD Count;
DWORD MaxFrequency;
DWORD CurrentState;
DWORD MaxPerfState;
DWORD MinPerfState;
DWORD LowestPerfState;
DWORD ThermalConstraint;
BYTE BusyAdjThreshold;
BYTE PolicyType;
BYTE Type;
BYTE Reserved;
DWORD TimerInterval;
DWORD64 TargetProcessors;
DWORD PStateHandler;
DWORD PStateContext;
DWORD TStateHandler;
DWORD TStateContext;
DWORD FeedbackHandler;
DWORD Reserved1;
DWORD64 Reserved2;
PPM_WMI_PERF_STATE State[ANYSIZE_ARRAY];
} PPM_WMI_PERF_STATES,*PPPM_WMI_PERF_STATES;
typedef struct {
DWORD Count;
DWORD MaxFrequency;
DWORD CurrentState;
DWORD MaxPerfState;
DWORD MinPerfState;
DWORD LowestPerfState;
DWORD ThermalConstraint;
BYTE BusyAdjThreshold;
BYTE PolicyType;
BYTE Type;
BYTE Reserved;
DWORD TimerInterval;
PVOID TargetProcessors;
DWORD PStateHandler;
DWORD PStateContext;
DWORD TStateHandler;
DWORD TStateContext;
DWORD FeedbackHandler;
DWORD Reserved1;
DWORD64 Reserved2;
PPM_WMI_PERF_STATE State[ANYSIZE_ARRAY];
} PPM_WMI_PERF_STATES_EX,*PPPM_WMI_PERF_STATES_EX;
#define PROC_IDLE_BUCKET_COUNT 6
#define PROC_IDLE_BUCKET_COUNT_EX 16
typedef struct {
DWORD IdleTransitions;
DWORD FailedTransitions;
DWORD InvalidBucketIndex;
DWORD64 TotalTime;
DWORD IdleTimeBuckets[PROC_IDLE_BUCKET_COUNT];
} PPM_IDLE_STATE_ACCOUNTING,*PPPM_IDLE_STATE_ACCOUNTING;
typedef struct {
DWORD StateCount;
DWORD TotalTransitions;
DWORD ResetCount;
DWORD64 StartTime;
PPM_IDLE_STATE_ACCOUNTING State[ANYSIZE_ARRAY];
} PPM_IDLE_ACCOUNTING,*PPPM_IDLE_ACCOUNTING;
typedef struct {
DWORD64 TotalTimeUs;
DWORD MinTimeUs;
DWORD MaxTimeUs;
DWORD Count;
} PPM_IDLE_STATE_BUCKET_EX,*PPPM_IDLE_STATE_BUCKET_EX;
typedef struct {
DWORD64 TotalTime;
DWORD IdleTransitions;
DWORD FailedTransitions;
DWORD InvalidBucketIndex;
DWORD MinTimeUs;
DWORD MaxTimeUs;
DWORD CancelledTransitions;
PPM_IDLE_STATE_BUCKET_EX IdleTimeBuckets[PROC_IDLE_BUCKET_COUNT_EX];
} PPM_IDLE_STATE_ACCOUNTING_EX,*PPPM_IDLE_STATE_ACCOUNTING_EX;
typedef struct {
DWORD StateCount;
DWORD TotalTransitions;
DWORD ResetCount;
DWORD AbortCount;
DWORD64 StartTime;
PPM_IDLE_STATE_ACCOUNTING_EX State[ANYSIZE_ARRAY];
} PPM_IDLE_ACCOUNTING_EX,*PPPM_IDLE_ACCOUNTING_EX;
#define ACPI_PPM_SOFTWARE_ALL 0xfc
#define ACPI_PPM_SOFTWARE_ANY 0xfd
#define ACPI_PPM_HARDWARE_ALL 0xfe
#define MS_PPM_SOFTWARE_ALL 0x1
#define PPM_FIRMWARE_ACPI1C2 0x1
#define PPM_FIRMWARE_ACPI1C3 0x2
#define PPM_FIRMWARE_ACPI1TSTATES 0x4
#define PPM_FIRMWARE_CST 0x8
#define PPM_FIRMWARE_CSD 0x10
#define PPM_FIRMWARE_PCT 0x20
#define PPM_FIRMWARE_PSS 0x40
#define PPM_FIRMWARE_XPSS 0x80
#define PPM_FIRMWARE_PPC 0x100
#define PPM_FIRMWARE_PSD 0x200
#define PPM_FIRMWARE_PTC 0x400
#define PPM_FIRMWARE_TSS 0x800
#define PPM_FIRMWARE_TPC 0x1000
#define PPM_FIRMWARE_TSD 0x2000
#define PPM_FIRMWARE_PCCH 0x4000
#define PPM_FIRMWARE_PCCP 0x8000
#define PPM_FIRMWARE_OSC 0x10000
#define PPM_FIRMWARE_PDC 0x20000
#define PPM_FIRMWARE_CPC 0x40000
#define PPM_PERFORMANCE_IMPLEMENTATION_NONE 0
#define PPM_PERFORMANCE_IMPLEMENTATION_PSTATES 1
#define PPM_PERFORMANCE_IMPLEMENTATION_PCCV1 2
#define PPM_PERFORMANCE_IMPLEMENTATION_CPPC 3
#define PPM_PERFORMANCE_IMPLEMENTATION_PEP 4
#define PPM_IDLE_IMPLEMENTATION_NONE 0x0
#define PPM_IDLE_IMPLEMENTATION_CSTATES 0x1
#define PPM_IDLE_IMPLEMENTATION_PEP 0x2
typedef struct {
DWORD State;
DWORD Status;
On 9/29/2013 9:35 AM, Tony Mechelynck wrote:
> On 29/09/13 17:32, Gregory M. Caughey wrote:
>> Hi everybody,
>> Since build 'Vim-7.4.041' my builds have been failing with error message
>> "Makefile:2697: recipe for target `objects/mbyte.o' failed".
>>
>> I've captured the last few lines from my screen output and included as
>> an attachment. I don't know if the fault is Vim or my Cygwin environment
>> which I update regularly.
>> Has anybody else experienced this problem? I have been building Vim for
>> console mode and the GUI version for years and failed compilations have
>> rarely occurred.
>>
>> I'm working on a Windows 7 box with the latest Cygwin (x86) environment
>> installed. I'm running with all of the latest upgrades and security
>> upgrades.
>>
>> v/r,
>> Greg
>>
> There seems to be a conflict between Cygwin headers and Vim headers.
> Could you paste lines 4951 and 5090 of /usr/include/w32api/winnt.h (as
> seen from Cygwin bash) into a reply email please?
>
>
> Best regards,
> Tony.
Hope this is what you're looking for.
Thanks, Greg
--
--
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/groups/opt_out.
DWORD HitCount;
DWORD Reserved1;
DWORD64 Reserved2;
DWORD64 Reserved3;
} PPM_WMI_PERF_STATE,*PPPM_WMI_PERF_STATE;
typedef struct {
DWORD Count;
DWORD MaxFrequency;
DWORD CurrentState;
DWORD MaxPerfState;
DWORD MinPerfState;
DWORD LowestPerfState;
DWORD ThermalConstraint;
BYTE BusyAdjThreshold;
BYTE PolicyType;
BYTE Type;
BYTE Reserved;
DWORD TimerInterval;
DWORD64 TargetProcessors;
DWORD PStateHandler;
DWORD PStateContext;
DWORD TStateHandler;
DWORD TStateContext;
DWORD FeedbackHandler;
DWORD Reserved1;
DWORD64 Reserved2;
PPM_WMI_PERF_STATE State[ANYSIZE_ARRAY];
} PPM_WMI_PERF_STATES,*PPPM_WMI_PERF_STATES;
typedef struct {
DWORD Count;
DWORD MaxFrequency;
DWORD CurrentState;
DWORD MaxPerfState;
DWORD MinPerfState;
DWORD LowestPerfState;
DWORD ThermalConstraint;
BYTE BusyAdjThreshold;
BYTE PolicyType;
BYTE Type;
BYTE Reserved;
DWORD TimerInterval;
PVOID TargetProcessors;
DWORD PStateHandler;
DWORD PStateContext;
DWORD TStateHandler;
DWORD TStateContext;
DWORD FeedbackHandler;
DWORD Reserved1;
DWORD64 Reserved2;
PPM_WMI_PERF_STATE State[ANYSIZE_ARRAY];
} PPM_WMI_PERF_STATES_EX,*PPPM_WMI_PERF_STATES_EX;
#define PROC_IDLE_BUCKET_COUNT 6
#define PROC_IDLE_BUCKET_COUNT_EX 16
typedef struct {
DWORD IdleTransitions;
DWORD FailedTransitions;
DWORD InvalidBucketIndex;
DWORD64 TotalTime;
DWORD IdleTimeBuckets[PROC_IDLE_BUCKET_COUNT];
} PPM_IDLE_STATE_ACCOUNTING,*PPPM_IDLE_STATE_ACCOUNTING;
typedef struct {
DWORD StateCount;
DWORD TotalTransitions;
DWORD ResetCount;
DWORD64 StartTime;
PPM_IDLE_STATE_ACCOUNTING State[ANYSIZE_ARRAY];
} PPM_IDLE_ACCOUNTING,*PPPM_IDLE_ACCOUNTING;
typedef struct {
DWORD64 TotalTimeUs;
DWORD MinTimeUs;
DWORD MaxTimeUs;
DWORD Count;
} PPM_IDLE_STATE_BUCKET_EX,*PPPM_IDLE_STATE_BUCKET_EX;
typedef struct {
DWORD64 TotalTime;
DWORD IdleTransitions;
DWORD FailedTransitions;
DWORD InvalidBucketIndex;
DWORD MinTimeUs;
DWORD MaxTimeUs;
DWORD CancelledTransitions;
PPM_IDLE_STATE_BUCKET_EX IdleTimeBuckets[PROC_IDLE_BUCKET_COUNT_EX];
} PPM_IDLE_STATE_ACCOUNTING_EX,*PPPM_IDLE_STATE_ACCOUNTING_EX;
typedef struct {
DWORD StateCount;
DWORD TotalTransitions;
DWORD ResetCount;
DWORD AbortCount;
DWORD64 StartTime;
PPM_IDLE_STATE_ACCOUNTING_EX State[ANYSIZE_ARRAY];
} PPM_IDLE_ACCOUNTING_EX,*PPPM_IDLE_ACCOUNTING_EX;
#define ACPI_PPM_SOFTWARE_ALL 0xfc
#define ACPI_PPM_SOFTWARE_ANY 0xfd
#define ACPI_PPM_HARDWARE_ALL 0xfe
#define MS_PPM_SOFTWARE_ALL 0x1
#define PPM_FIRMWARE_ACPI1C2 0x1
#define PPM_FIRMWARE_ACPI1C3 0x2
#define PPM_FIRMWARE_ACPI1TSTATES 0x4
#define PPM_FIRMWARE_CST 0x8
#define PPM_FIRMWARE_CSD 0x10
#define PPM_FIRMWARE_PCT 0x20
#define PPM_FIRMWARE_PSS 0x40
#define PPM_FIRMWARE_XPSS 0x80
#define PPM_FIRMWARE_PPC 0x100
#define PPM_FIRMWARE_PSD 0x200
#define PPM_FIRMWARE_PTC 0x400
#define PPM_FIRMWARE_TSS 0x800
#define PPM_FIRMWARE_TPC 0x1000
#define PPM_FIRMWARE_TSD 0x2000
#define PPM_FIRMWARE_PCCH 0x4000
#define PPM_FIRMWARE_PCCP 0x8000
#define PPM_FIRMWARE_OSC 0x10000
#define PPM_FIRMWARE_PDC 0x20000
#define PPM_FIRMWARE_CPC 0x40000
#define PPM_PERFORMANCE_IMPLEMENTATION_NONE 0
#define PPM_PERFORMANCE_IMPLEMENTATION_PSTATES 1
#define PPM_PERFORMANCE_IMPLEMENTATION_PCCV1 2
#define PPM_PERFORMANCE_IMPLEMENTATION_CPPC 3
#define PPM_PERFORMANCE_IMPLEMENTATION_PEP 4
#define PPM_IDLE_IMPLEMENTATION_NONE 0x0
#define PPM_IDLE_IMPLEMENTATION_CSTATES 0x1
#define PPM_IDLE_IMPLEMENTATION_PEP 0x2
typedef struct {
DWORD State;
DWORD Status;
On 9/29/2013 9:35 AM, Tony Mechelynck wrote:
> On 29/09/13 17:32, Gregory M. Caughey wrote:
>> Hi everybody,
>> Since build 'Vim-7.4.041' my builds have been failing with error message
>> "Makefile:2697: recipe for target `objects/mbyte.o' failed".
>>
>> I've captured the last few lines from my screen output and included as
>> an attachment. I don't know if the fault is Vim or my Cygwin environment
>> which I update regularly.
>> Has anybody else experienced this problem? I have been building Vim for
>> console mode and the GUI version for years and failed compilations have
>> rarely occurred.
>>
>> I'm working on a Windows 7 box with the latest Cygwin (x86) environment
>> installed. I'm running with all of the latest upgrades and security
>> upgrades.
>>
>> v/r,
>> Greg
>>
> There seems to be a conflict between Cygwin headers and Vim headers.
> Could you paste lines 4951 and 5090 of /usr/include/w32api/winnt.h (as
> seen from Cygwin bash) into a reply email please?
>
>
> Best regards,
> Tony.
Hope this is what you're looking for.
Thanks, Greg
--
--
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/groups/opt_out.
Re: BufEnter buggy?
Yeah, I couldn't get any definitive information from :echo/:echom either. So I did this:
autocmd BufEnter * let g:foo = expand('%')
And then I'd check the value of g:foo with :echo after switching/closing windows.
On Sunday, September 29, 2013 9:06:54 AM UTC-4, Christian Brabandt wrote:
> Hi Aaron!
>
>
>
> On Sa, 28 Sep 2013, Aaron Bohannon wrote:
>
>
>
> > (a) BufEnter isn't getting triggered after closing the last window in
>
> > a tab and ending up in a different tab. It *should* be getting
>
> > triggered, right? I mean, it gets triggered when I close a window and
>
> > end up in a different window in the same tab, so why wouldn't it get
>
> > triggered when I close a tab?
>
>
>
> Are you sure? I can't replicate it. I don't see a message when doing
>
> :au BufEnter * :echom "BufEnter triggered!"
>
> But that seems to be related to the redrawing (since the old tabpage is
>
> closed), but the event fires, nevertheless.
>
>
>
> Best,
>
> Christian
>
> --
>
> Es gibt kaum einen Menschen, von dem man nichts lernen kann.
>
> -- Chinesisches 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/groups/opt_out.
autocmd BufEnter * let g:foo = expand('%')
And then I'd check the value of g:foo with :echo after switching/closing windows.
On Sunday, September 29, 2013 9:06:54 AM UTC-4, Christian Brabandt wrote:
> Hi Aaron!
>
>
>
> On Sa, 28 Sep 2013, Aaron Bohannon wrote:
>
>
>
> > (a) BufEnter isn't getting triggered after closing the last window in
>
> > a tab and ending up in a different tab. It *should* be getting
>
> > triggered, right? I mean, it gets triggered when I close a window and
>
> > end up in a different window in the same tab, so why wouldn't it get
>
> > triggered when I close a tab?
>
>
>
> Are you sure? I can't replicate it. I don't see a message when doing
>
> :au BufEnter * :echom "BufEnter triggered!"
>
> But that seems to be related to the redrawing (since the old tabpage is
>
> closed), but the event fires, nevertheless.
>
>
>
> Best,
>
> Christian
>
> --
>
> Es gibt kaum einen Menschen, von dem man nichts lernen kann.
>
> -- Chinesisches 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/groups/opt_out.
Re: Calling a user function via a map cancels visual mode
On Saturday, September 28, 2013 5:42:46 PM UTC-5, skeept wrote:
> vnoremap ,n :<C-U>call JumpToNextNonMatching(2)<CR>gv
> vnoremap ,N :<C-U>call JumpToNextNonMatching(-2)<CR>gv
>
> This almost works, if I am moving backwards it progressively increases the visual selected area, but if I am moving forward the visually selected area remains the same because it seems that `gv` brings the cursor back to the beginning of the selection...
> Any idea on how to make this work also for the forward movement?
>
Yes, you can jump to the other side of the visual selection when in visual mode by pressing 'o', so append one more letter to your forward mapping.
:help v_o
--
--
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/groups/opt_out.
> vnoremap ,n :<C-U>call JumpToNextNonMatching(2)<CR>gv
> vnoremap ,N :<C-U>call JumpToNextNonMatching(-2)<CR>gv
>
> This almost works, if I am moving backwards it progressively increases the visual selected area, but if I am moving forward the visually selected area remains the same because it seems that `gv` brings the cursor back to the beginning of the selection...
> Any idea on how to make this work also for the forward movement?
>
Yes, you can jump to the other side of the visual selection when in visual mode by pressing 'o', so append one more letter to your forward mapping.
:help v_o
--
--
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/groups/opt_out.
Re: Latest failed compilation
On 29/09/13 17:32, Gregory M. Caughey wrote:
> Hi everybody,
> Since build 'Vim-7.4.041' my builds have been failing with error message
> "Makefile:2697: recipe for target `objects/mbyte.o' failed".
>
> I've captured the last few lines from my screen output and included as
> an attachment. I don't know if the fault is Vim or my Cygwin environment
> which I update regularly.
> Has anybody else experienced this problem? I have been building Vim for
> console mode and the GUI version for years and failed compilations have
> rarely occurred.
>
> I'm working on a Windows 7 box with the latest Cygwin (x86) environment
> installed. I'm running with all of the latest upgrades and security
> upgrades.
>
> v/r,
> Greg
>
There seems to be a conflict between Cygwin headers and Vim headers.
Could you paste lines 4951 and 5090 of /usr/include/w32api/winnt.h (as
seen from Cygwin bash) into a reply email please?
Best regards,
Tony.
--
Planet Claire has pink hair.
All the trees are red.
No one ever dies there.
No one has a head....
--
--
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/groups/opt_out.
> Hi everybody,
> Since build 'Vim-7.4.041' my builds have been failing with error message
> "Makefile:2697: recipe for target `objects/mbyte.o' failed".
>
> I've captured the last few lines from my screen output and included as
> an attachment. I don't know if the fault is Vim or my Cygwin environment
> which I update regularly.
> Has anybody else experienced this problem? I have been building Vim for
> console mode and the GUI version for years and failed compilations have
> rarely occurred.
>
> I'm working on a Windows 7 box with the latest Cygwin (x86) environment
> installed. I'm running with all of the latest upgrades and security
> upgrades.
>
> v/r,
> Greg
>
There seems to be a conflict between Cygwin headers and Vim headers.
Could you paste lines 4951 and 5090 of /usr/include/w32api/winnt.h (as
seen from Cygwin bash) into a reply email please?
Best regards,
Tony.
--
Planet Claire has pink hair.
All the trees are red.
No one ever dies there.
No one has a head....
--
--
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/groups/opt_out.
Latest failed compilation
In file included from /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/minwindef.h:146:0,
from /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/windef.h:8,
from /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/windows.h:69,
from mbyte.c:86:
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/winnt.h:4951:15: error: two or more data types in declaration specifiers
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/winnt.h:5090:13: error: two or more data types in declaration specifiers
Makefile:2697: recipe for target `objects/mbyte.o' failed
make[2]: *** [objects/mbyte.o] Error 1
make[2]: Leaving directory `/home/caugheygm/build/vim/src'
Makefile:1762: recipe for target `myself' failed
make[1]: *** [myself] Error 2
make[1]: Leaving directory `/home/caugheygm/build/vim/src'
Makefile:26: recipe for target `first' failed
make: *** [first] Error 2
Hi everybody,
Since build 'Vim-7.4.041' my builds have been failing with error message
"Makefile:2697: recipe for target `objects/mbyte.o' failed".
I've captured the last few lines from my screen output and included as
an attachment. I don't know if the fault is Vim or my Cygwin environment
which I update regularly.
Has anybody else experienced this problem? I have been building Vim for
console mode and the GUI version for years and failed compilations have
rarely occurred.
I'm working on a Windows 7 box with the latest Cygwin (x86) environment
installed. I'm running with all of the latest upgrades and security
upgrades.
v/r,
Greg
--
--
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/groups/opt_out.
from /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/windef.h:8,
from /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/windows.h:69,
from mbyte.c:86:
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/winnt.h:4951:15: error: two or more data types in declaration specifiers
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/winnt.h:5090:13: error: two or more data types in declaration specifiers
Makefile:2697: recipe for target `objects/mbyte.o' failed
make[2]: *** [objects/mbyte.o] Error 1
make[2]: Leaving directory `/home/caugheygm/build/vim/src'
Makefile:1762: recipe for target `myself' failed
make[1]: *** [myself] Error 2
make[1]: Leaving directory `/home/caugheygm/build/vim/src'
Makefile:26: recipe for target `first' failed
make: *** [first] Error 2
Hi everybody,
Since build 'Vim-7.4.041' my builds have been failing with error message
"Makefile:2697: recipe for target `objects/mbyte.o' failed".
I've captured the last few lines from my screen output and included as
an attachment. I don't know if the fault is Vim or my Cygwin environment
which I update regularly.
Has anybody else experienced this problem? I have been building Vim for
console mode and the GUI version for years and failed compilations have
rarely occurred.
I'm working on a Windows 7 box with the latest Cygwin (x86) environment
installed. I'm running with all of the latest upgrades and security
upgrades.
v/r,
Greg
--
--
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/groups/opt_out.
Syntax highlighting for select groups of variables?
for example, a section of verilog code:
// define input and output ports
input A;
output B;
// main logic
wire C;
assign C = A & B;
A,B and C are all treated as variables, so displayed in the same color. I'm wondering if vim can use different color for A and B than C?
--
--
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/groups/opt_out.
// define input and output ports
input A;
output B;
// main logic
wire C;
assign C = A & B;
A,B and C are all treated as variables, so displayed in the same color. I'm wondering if vim can use different color for A and B than C?
--
--
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/groups/opt_out.
Re: BufEnter buggy?
Hi Aaron!
On Sa, 28 Sep 2013, Aaron Bohannon wrote:
> (a) BufEnter isn't getting triggered after closing the last window in
> a tab and ending up in a different tab. It *should* be getting
> triggered, right? I mean, it gets triggered when I close a window and
> end up in a different window in the same tab, so why wouldn't it get
> triggered when I close a tab?
Are you sure? I can't replicate it. I don't see a message when doing
:au BufEnter * :echom "BufEnter triggered!"
But that seems to be related to the redrawing (since the old tabpage is
closed), but the event fires, nevertheless.
Best,
Christian
--
Es gibt kaum einen Menschen, von dem man nichts lernen kann.
-- Chinesisches 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/groups/opt_out.
On Sa, 28 Sep 2013, Aaron Bohannon wrote:
> (a) BufEnter isn't getting triggered after closing the last window in
> a tab and ending up in a different tab. It *should* be getting
> triggered, right? I mean, it gets triggered when I close a window and
> end up in a different window in the same tab, so why wouldn't it get
> triggered when I close a tab?
Are you sure? I can't replicate it. I don't see a message when doing
:au BufEnter * :echom "BufEnter triggered!"
But that seems to be related to the redrawing (since the old tabpage is
closed), but the event fires, nevertheless.
Best,
Christian
--
Es gibt kaum einen Menschen, von dem man nichts lernen kann.
-- Chinesisches 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/groups/opt_out.
Re: Something to wrap a selection
Harry Putnam <reader@newsguy.com> a écrit:
> Paul Isambert <zappathustra@free.fr> writes:
>
> > I say goodbye here, the code follows. I'll hope you'll be satisfied
> > this time (there might be glitches, I did not test the command much,
> > just basic tries).
>
> Oh boy, yup this baby works now.
>
> Man, you went so far beyond the call of duty, and let me tell you that
> it was really appreciated here.
If duty there was, it was only not to give you half-baked code. Plus
writing scriptlets is so funnier than dish-washing.
> There are so many examples and techniques in that code I will be
> learning from it for a good while.
>
> Oh, and I promise not to post one more thing to this thread.. : )
But you should if the code goes wrong. By the way there was a small
mistake. In:
let s:commentfile = expand("<sfile>:p:h") . "/.markchangerc"
if filereadable(s:commentfile)
let s:data = readfile(s:commentfile)
for line in s:data
if line !~ '^#' && line =~ '='
let s:matches = matchlist(line, '\([^=[:blank:]]\+\)\s*=\s*\(\S\+\)')
if len(s:matches)
let s:markchangecomments[s:matches[1]] = s:matches[2]
endif
endif
endfor
endif
you should replace all occurrences of "line" with "s:line", otherwise
it defines a global variable whereas you want it to be only visible in
the script (I'm used to loop variables being local, à la Lua).
Best,
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/groups/opt_out.
> Paul Isambert <zappathustra@free.fr> writes:
>
> > I say goodbye here, the code follows. I'll hope you'll be satisfied
> > this time (there might be glitches, I did not test the command much,
> > just basic tries).
>
> Oh boy, yup this baby works now.
>
> Man, you went so far beyond the call of duty, and let me tell you that
> it was really appreciated here.
If duty there was, it was only not to give you half-baked code. Plus
writing scriptlets is so funnier than dish-washing.
> There are so many examples and techniques in that code I will be
> learning from it for a good while.
>
> Oh, and I promise not to post one more thing to this thread.. : )
But you should if the code goes wrong. By the way there was a small
mistake. In:
let s:commentfile = expand("<sfile>:p:h") . "/.markchangerc"
if filereadable(s:commentfile)
let s:data = readfile(s:commentfile)
for line in s:data
if line !~ '^#' && line =~ '='
let s:matches = matchlist(line, '\([^=[:blank:]]\+\)\s*=\s*\(\S\+\)')
if len(s:matches)
let s:markchangecomments[s:matches[1]] = s:matches[2]
endif
endif
endfor
endif
you should replace all occurrences of "line" with "s:line", otherwise
it defines a global variable whereas you want it to be only visible in
the script (I'm used to loop variables being local, à la Lua).
Best,
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/groups/opt_out.
Saturday, September 28, 2013
Re: Wishlist item: comma object-selecting motion
I've been meaning to implement that sort of text region on top of textobj-user but haven't found the time.
On a related note, it's worth mentioning...you can probably get more mileage out of the % motion than you realize. I didn't pay attention to this fact until recently, but you do not have to be on a bracket character when you use it. It will advance the cursor forward to the nearest bracket character and then jump to the matching one. For example, if you can yank/delete 'bar(b, baz(c, d))' in the text below by moving your cursor to the 'b' of 'bar' and using y% or d%:
foo(a, bar(b, baz(c, d)), e, f)
This fact doesn't get you the region command you're looking for, but it's useful in general and good to remember if you're trying to implement your own text object (obviously, you aren't going to be able to find matching brackets with a regular expression).
...Aaron
On Friday, September 27, 2013 1:52:51 PM UTC-4, Christian Brabandt wrote:
> On Fr, 27 Sep 2013, Codie Codemonkey wrote:
>
>
>
> > Object selections have become one of my favorite Vim features. (See :help object-select for some context for this request.) It took me awhile to discover them, but now that I have I use them constantly.
>
> >
>
> > I'd like to see a new one (or actually two considering the a and i forms) to select comma separated items in a list.
>
> >
>
> > In the simplest use case, comma object selection would include text starting at the previous comma or '(' to the next comma or ')'.
>
> >
>
> > a, - Select the current parameter in a C-style parameter list. Any previous whitespace will be included, as well as any trailing ','. Whitespace after the trailing ',' will not be included. If the parameter is the last in the parameter list, the ending delimiter will not be selected.
>
> >
>
> > i, - Same as a, except that leading whitespace and a trailing ',' (if present) will not be part of the selection.
>
> >
>
> > Other bracketing delimeters should work in addition to '(' and ')', including '[' and ']', '{' and '}' and possibly '<' and '>'.
>
> >
>
> > Examples:
>
> >
>
> > Consider this line of programming code:
>
> > func( a, b(c, d[0]), "this, is a test")
>
> >
>
> > In normal mode with the cursor on the first parameter, "da," would change this to:
>
> > func( b(c, d[0]), "this, is a test")
>
> >
>
> > Or, if the cursor is on 'b' in the second parameter, "da," would yield:
>
> > func( a, "this, is a test")
>
> > (Note the ignored ')' and ']' characters.)
>
> >
>
> > Or if the cursor was in the string of the third parameter, "da," would yield:
>
> > func( a, b(c, d[0]), )
>
> > (Note that the ',' in the string was not a delimiter because it was nested between quotes.)
>
> >
>
> > Some filetypes have other needs. For example in a CDF file, <C-R> is a bracketing character. To accommodate this I suggest some accompanying options:
>
> >
>
> > listsep - Characters used to separate items in a list. Default: ',;'
>
> > liststart - Characters used to start a list (if not nested in quotes or balanced bracketed strings). Default: '({[<'.
>
> > listend - Characters used to end a list (if not nested in quotes or balanced bracketed strings). Default: ')}]>'.
>
>
>
> This is probably already implemented using some plugin. I just recently
>
> stumbled over this�, but haven't used it, so this might or might not do
>
> what you want.
>
>
>
> �)https://github.com/kurkale6ka/vim-pairs
>
>
>
> Best,
>
> Christian
>
> --
>
> Marionetten lassen sich sehr leicht in Gehenkte verwandeln. Die
>
> Stricke sind schon da.
>
> -- Stanislaw Jerzy Lec (eig. S. J. de Tusch-Letz)
--
--
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/groups/opt_out.
On a related note, it's worth mentioning...you can probably get more mileage out of the % motion than you realize. I didn't pay attention to this fact until recently, but you do not have to be on a bracket character when you use it. It will advance the cursor forward to the nearest bracket character and then jump to the matching one. For example, if you can yank/delete 'bar(b, baz(c, d))' in the text below by moving your cursor to the 'b' of 'bar' and using y% or d%:
foo(a, bar(b, baz(c, d)), e, f)
This fact doesn't get you the region command you're looking for, but it's useful in general and good to remember if you're trying to implement your own text object (obviously, you aren't going to be able to find matching brackets with a regular expression).
...Aaron
On Friday, September 27, 2013 1:52:51 PM UTC-4, Christian Brabandt wrote:
> On Fr, 27 Sep 2013, Codie Codemonkey wrote:
>
>
>
> > Object selections have become one of my favorite Vim features. (See :help object-select for some context for this request.) It took me awhile to discover them, but now that I have I use them constantly.
>
> >
>
> > I'd like to see a new one (or actually two considering the a and i forms) to select comma separated items in a list.
>
> >
>
> > In the simplest use case, comma object selection would include text starting at the previous comma or '(' to the next comma or ')'.
>
> >
>
> > a, - Select the current parameter in a C-style parameter list. Any previous whitespace will be included, as well as any trailing ','. Whitespace after the trailing ',' will not be included. If the parameter is the last in the parameter list, the ending delimiter will not be selected.
>
> >
>
> > i, - Same as a, except that leading whitespace and a trailing ',' (if present) will not be part of the selection.
>
> >
>
> > Other bracketing delimeters should work in addition to '(' and ')', including '[' and ']', '{' and '}' and possibly '<' and '>'.
>
> >
>
> > Examples:
>
> >
>
> > Consider this line of programming code:
>
> > func( a, b(c, d[0]), "this, is a test")
>
> >
>
> > In normal mode with the cursor on the first parameter, "da," would change this to:
>
> > func( b(c, d[0]), "this, is a test")
>
> >
>
> > Or, if the cursor is on 'b' in the second parameter, "da," would yield:
>
> > func( a, "this, is a test")
>
> > (Note the ignored ')' and ']' characters.)
>
> >
>
> > Or if the cursor was in the string of the third parameter, "da," would yield:
>
> > func( a, b(c, d[0]), )
>
> > (Note that the ',' in the string was not a delimiter because it was nested between quotes.)
>
> >
>
> > Some filetypes have other needs. For example in a CDF file, <C-R> is a bracketing character. To accommodate this I suggest some accompanying options:
>
> >
>
> > listsep - Characters used to separate items in a list. Default: ',;'
>
> > liststart - Characters used to start a list (if not nested in quotes or balanced bracketed strings). Default: '({[<'.
>
> > listend - Characters used to end a list (if not nested in quotes or balanced bracketed strings). Default: ')}]>'.
>
>
>
> This is probably already implemented using some plugin. I just recently
>
> stumbled over this�, but haven't used it, so this might or might not do
>
> what you want.
>
>
>
> �)https://github.com/kurkale6ka/vim-pairs
>
>
>
> Best,
>
> Christian
>
> --
>
> Marionetten lassen sich sehr leicht in Gehenkte verwandeln. Die
>
> Stricke sind schon da.
>
> -- Stanislaw Jerzy Lec (eig. S. J. de Tusch-Letz)
--
--
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/groups/opt_out.
Re: Calling a user function via a map cancels visual mode
>
> The : in your mappings is what ends visual mode.
>
> You can't avoid this, but you can go back into visual mode with the same region as you had, simply by adding 'gv' to the end of your mapping.
>
> :help gv
Thanks Ben,
I modified my function and mappings to the following:
function! JumpToNextNonMatching(direction)
let flags = ''
if a:direction < 0
let flags = flags . 'b'
endif
let ntimes = max([v:count, 1])
let i = 1
while i <= ntimes
let i = i + 1
let curr_line = getline('.')
let spattern = '^[^' . curr_line[0] . '][^' . curr_line[1] . ']'
call search(spattern, flags)
endwhile
nohlsearch
if a:direction == 2
mark >
endif
if a:direction == -2
mark <
endif
endfunction
nnoremap ,n :<C-U>call JumpToNextNonMatching(1)<CR>
nnoremap ,N :<C-U>call JumpToNextNonMatching(-1)<CR>
vnoremap ,n :<C-U>call JumpToNextNonMatching(2)<CR>gv
vnoremap ,N :<C-U>call JumpToNextNonMatching(-2)<CR>gv
This almost works, if I am moving backwards it progressively increases the visual selected area, but if I am moving forward the visually selected area remains the same because it seems that `gv` brings the cursor back to the beginning of the selection...
Any idea on how to make this work also for the forward movement?
Regards,
Jorge
--
--
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/groups/opt_out.
> The : in your mappings is what ends visual mode.
>
> You can't avoid this, but you can go back into visual mode with the same region as you had, simply by adding 'gv' to the end of your mapping.
>
> :help gv
Thanks Ben,
I modified my function and mappings to the following:
function! JumpToNextNonMatching(direction)
let flags = ''
if a:direction < 0
let flags = flags . 'b'
endif
let ntimes = max([v:count, 1])
let i = 1
while i <= ntimes
let i = i + 1
let curr_line = getline('.')
let spattern = '^[^' . curr_line[0] . '][^' . curr_line[1] . ']'
call search(spattern, flags)
endwhile
nohlsearch
if a:direction == 2
mark >
endif
if a:direction == -2
mark <
endif
endfunction
nnoremap ,n :<C-U>call JumpToNextNonMatching(1)<CR>
nnoremap ,N :<C-U>call JumpToNextNonMatching(-1)<CR>
vnoremap ,n :<C-U>call JumpToNextNonMatching(2)<CR>gv
vnoremap ,N :<C-U>call JumpToNextNonMatching(-2)<CR>gv
This almost works, if I am moving backwards it progressively increases the visual selected area, but if I am moving forward the visually selected area remains the same because it seems that `gv` brings the cursor back to the beginning of the selection...
Any idea on how to make this work also for the forward movement?
Regards,
Jorge
--
--
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/groups/opt_out.
BufEnter buggy?
I have an autocmd that updates the window title in my terminal based on the current file name. BufEnter clearly seems to be the event I would want to trigger it with. But I've noticed two problems:
(a) BufEnter isn't getting triggered after closing the last window in a tab and ending up in a different tab. It *should* be getting triggered, right? I mean, it gets triggered when I close a window and end up in a different window in the same tab, so why wouldn't it get triggered when I close a tab?
(b) When switching directories in netrw (which switches buffers), BufEnter gets triggered before the directory location is known, so expand('%') will be empty. But once I'm in the directory, I get the directory location just fine by calling expand('%'), so I'm not sure how netrw is changing the buffer location *after* the BufEnter event. It seems like there's some questionable logic going on there, but I'm not sure who's to blame.
...Aaron
--
--
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/groups/opt_out.
(a) BufEnter isn't getting triggered after closing the last window in a tab and ending up in a different tab. It *should* be getting triggered, right? I mean, it gets triggered when I close a window and end up in a different window in the same tab, so why wouldn't it get triggered when I close a tab?
(b) When switching directories in netrw (which switches buffers), BufEnter gets triggered before the directory location is known, so expand('%') will be empty. But once I'm in the directory, I get the directory location just fine by calling expand('%'), so I'm not sure how netrw is changing the buffer location *after* the BufEnter event. It seems like there's some questionable logic going on there, but I'm not sure who's to blame.
...Aaron
--
--
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/groups/opt_out.
Re: Delete from search history
>> Hi,
>> The call to histdel below doesn't seem to be doing what I want it to do.
>> It doesn't delete my 3 search patterns added by the 2 :substitute and
>> the :global calls. Not sure what it does exactly, it seems to delete
>> one correct entry and 2 wrong ones.
>> All I want is no trace of those patterns in my search history,
>> but histdel('/', '\\s\\+\$') wouldn't be a solution since I still want
>> this pattern in my history if I enter it manually at some point.
>> Any help appreciated.
>>
>>
>> " Squeeze empty lines
>> function! s:Squeeze()
>> let save_cursor = getpos(".")
>> " empty lines at BOF|EOF
>>
>> silent %substitute/\%^\_s*\n\|\_s*\%$//
>> " empty line clusters
>> silent global/^\%(\s*$\n\)\{2,}/delete
>> silent! %substitute/\s\+$//e
>> for i in range(1, 3)
>> call histdel('/', -1)
>> endfor
>> call setpos('.', save_cursor)
>> endfunction
>>
>> nmap <silent> <leader>z :call <sid>Squeeze()<cr>
>
>Not sure what happens there, but it might be a lot simpler if we have a
>way to avoid patterns to be put in the history, instead of deleting them
>afterwards. When a pattern was typed you may want to keep it, but after
>executing a :s command you don't know if the pattern was typed before
>you used it with :s. That gets complicated.
>
>For :s we could add a flag, but for :g/pattern/ there is is no place to
>put a flag. Perhaps we should use a modifier ":keeppatterns", like
>":keepjumps" and ":keepmarks" ?
Yes that would be perfect. In fact I spent quite a lot of time searching the
help thinking there would be something like that.
Also the help at line 67 in cmdline.txt might need changing as it implies only
one search pattern would be remembered if coming from a mapping. Not all of them
as it happens in this example.
>> The call to histdel below doesn't seem to be doing what I want it to do.
>> It doesn't delete my 3 search patterns added by the 2 :substitute and
>> the :global calls. Not sure what it does exactly, it seems to delete
>> one correct entry and 2 wrong ones.
>> All I want is no trace of those patterns in my search history,
>> but histdel('/', '\\s\\+\$') wouldn't be a solution since I still want
>> this pattern in my history if I enter it manually at some point.
>> Any help appreciated.
>>
>>
>> " Squeeze empty lines
>> function! s:Squeeze()
>> let save_cursor = getpos(".")
>> " empty lines at BOF|EOF
>>
>> silent %substitute/\%^\_s*\n\|\_s*\%$//
>> " empty line clusters
>> silent global/^\%(\s*$\n\)\{2,}/delete
>> silent! %substitute/\s\+$//e
>> for i in range(1, 3)
>> call histdel('/', -1)
>> endfor
>> call setpos('.', save_cursor)
>> endfunction
>>
>> nmap <silent> <leader>z :call <sid>Squeeze()<cr>
>
>Not sure what happens there, but it might be a lot simpler if we have a
>way to avoid patterns to be put in the history, instead of deleting them
>afterwards. When a pattern was typed you may want to keep it, but after
>executing a :s command you don't know if the pattern was typed before
>you used it with :s. That gets complicated.
>
>For :s we could add a flag, but for :g/pattern/ there is is no place to
>put a flag. Perhaps we should use a modifier ":keeppatterns", like
>":keepjumps" and ":keepmarks" ?
Yes that would be perfect. In fact I spent quite a lot of time searching the
help thinking there would be something like that.
Also the help at line 67 in cmdline.txt might need changing as it implies only
one search pattern would be remembered if coming from a mapping. Not all of them
as it happens in this example.
Re: Something to wrap a selection
Paul Isambert <zappathustra@free.fr> writes:
> I say goodbye here, the code follows. I'll hope you'll be satisfied
> this time (there might be glitches, I did not test the command much,
> just basic tries).
Oh boy, yup this baby works now.
Man, you went so far beyond the call of duty, and let me tell you that
it was really appreciated here.
There are so many examples and techniques in that code I will be
learning from it for a good while.
Oh, and I promise not to post one more thing to this thread.. : )
--
--
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/groups/opt_out.
> I say goodbye here, the code follows. I'll hope you'll be satisfied
> this time (there might be glitches, I did not test the command much,
> just basic tries).
Oh boy, yup this baby works now.
Man, you went so far beyond the call of duty, and let me tell you that
it was really appreciated here.
There are so many examples and techniques in that code I will be
learning from it for a good while.
Oh, and I promise not to post one more thing to this thread.. : )
--
--
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/groups/opt_out.
Re: Delete from search history
Dimitar Dimitrov wrote:
> Hi,
> The call to histdel below doesn't seem to be doing what I want it to do.
> It doesn't delete my 3 search patterns added by the 2 :substitute and
> the :global calls. Not sure what it does exactly, it seems to delete
> one correct entry and 2 wrong ones.
> All I want is no trace of those patterns in my search history,
> but histdel('/', '\\s\\+\$') wouldn't be a solution since I still want
> this pattern in my history if I enter it manually at some point.
> Any help appreciated.
>
>
> " Squeeze empty lines
> function! s:Squeeze()
> let save_cursor = getpos(".")
> " empty lines at BOF|EOF
>
> silent %substitute/\%^\_s*\n\|\_s*\%$//
> " empty line clusters
> silent global/^\%(\s*$\n\)\{2,}/delete
> silent! %substitute/\s\+$//e
> for i in range(1, 3)
> call histdel('/', -1)
> endfor
> call setpos('.', save_cursor)
> endfunction
>
> nmap <silent> <leader>z :call <sid>Squeeze()<cr>
Not sure what happens there, but it might be a lot simpler if we have a
way to avoid patterns to be put in the history, instead of deleting them
afterwards. When a pattern was typed you may want to keep it, but after
executing a :s command you don't know if the pattern was typed before
you used it with :s. That gets complicated.
For :s we could add a flag, but for :g/pattern/ there is is no place to
put a flag. Perhaps we should use a modifier ":keeppatterns", like
":keepjumps" and ":keepmarks" ?
--
### Hiroshima 45, Chernobyl 86, Windows 95 ###
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/groups/opt_out.
> Hi,
> The call to histdel below doesn't seem to be doing what I want it to do.
> It doesn't delete my 3 search patterns added by the 2 :substitute and
> the :global calls. Not sure what it does exactly, it seems to delete
> one correct entry and 2 wrong ones.
> All I want is no trace of those patterns in my search history,
> but histdel('/', '\\s\\+\$') wouldn't be a solution since I still want
> this pattern in my history if I enter it manually at some point.
> Any help appreciated.
>
>
> " Squeeze empty lines
> function! s:Squeeze()
> let save_cursor = getpos(".")
> " empty lines at BOF|EOF
>
> silent %substitute/\%^\_s*\n\|\_s*\%$//
> " empty line clusters
> silent global/^\%(\s*$\n\)\{2,}/delete
> silent! %substitute/\s\+$//e
> for i in range(1, 3)
> call histdel('/', -1)
> endfor
> call setpos('.', save_cursor)
> endfunction
>
> nmap <silent> <leader>z :call <sid>Squeeze()<cr>
Not sure what happens there, but it might be a lot simpler if we have a
way to avoid patterns to be put in the history, instead of deleting them
afterwards. When a pattern was typed you may want to keep it, but after
executing a :s command you don't know if the pattern was typed before
you used it with :s. That gets complicated.
For :s we could add a flag, but for :g/pattern/ there is is no place to
put a flag. Perhaps we should use a modifier ":keeppatterns", like
":keepjumps" and ":keepmarks" ?
--
### Hiroshima 45, Chernobyl 86, Windows 95 ###
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/groups/opt_out.
Re: Something to wrap a selection
This summary is not available. Please
click here to view the post.
Subscribe to:
Posts (Atom)