Re: screen not updated after backspace

Hi,

Sven Eppler wrote:
>
> since about a week on my server vim behaves strange. The backspace-key
> is working correctly beside the fact, that the deleted characters are
> not removed from the screen. Only when leaving insert-mode or switch
> lines the screen will get updated and the deleted characters will
> vanish from the screen.
>
> e.g.: when backspacing 5 characters and typing 4 new, the newly typed
> chars will be shown correctly, but the first backspaced char will stay
> again until i leave the insert-mode or navigate into another line.

in addition to the 'compatible' option you might want to look at the
'cpoptions' option. If it includes a lower-case 'v' Vim behaves the
way you noticed (:help cpo-v).

Regards,
Jürgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)

--
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

Re: Digest for vim_use@googlegroups.com - 13 Messages in 4 Topics

On 6/30/10, vim_use+noreply@googlegroups.com
<vim_use+noreply@googlegroups.com> wrote:
> =============================================================================
> Today's Topic Summary
> =============================================================================
>
> Group: vim_use@googlegroups.com
> Url: http://groups.google.com/group/vim_use/topics
>
> - percentage of vim users running python [4 Updates]
> http://groups.google.com/group/vim_use/t/1d712fce3922891a
> - Conditional imap [6 Updates]
> http://groups.google.com/group/vim_use/t/e8276bcf816b90b4
> - au BufReadPost * if &readonly | set nomodifiable [2 Updates]
> http://groups.google.com/group/vim_use/t/82946ab8ac7e1c62
> - :set wrap Range [1 Update]
> http://groups.google.com/group/vim_use/t/dcfc48f2372aada7
>
>
> =============================================================================
> Topic: percentage of vim users running python
> Url: http://groups.google.com/group/vim_use/t/1d712fce3922891a
> =============================================================================
>
> ---------- 1 of 4 ----------
> From: Ted <cecinemapasderange@gmail.com>
> Date: Jun 29 06:20PM -0700
> Url: http://groups.google.com/group/vim_use/msg/31d285fbfbe9f673
>
> Hello folks,
>
> I'm wondering if there are some figures somewhere that would provide
> some sort of estimate of the percentage of vim users who have python
> installed, or would be free of objections to installing it if a module
> required it. I'm working on some vim modules, to be released for
> general use, that are threatening to become pretty complicated, and
> would prefer to write them in python. Is it likely that this would
> lock out a significant portion of the vim user population? Is it
> frowned upon to use external languages in cases where it's not
> entirely necessary? Python is more or less ubiquitous on linux
> installs, but I don't feel like I could guess at how many vim users on
> other platforms would be unable or unwilling to install it.
>
> The modules themselves are relatively general purpose; my motivation
> to code them in Python stems partly from this very generality: it's
> advantageous to have that code available outside of the context of
> vim. I also find that I tend more and more toward a functional
> programming style that doesn't work particularly well in vimscript.
>
> Cheers
> -Ted
>
>
> ---------- 2 of 4 ----------
> From: AK <andrei.avk@gmail.com>
> Date: Jun 29 09:32PM -0400
> Url: http://groups.google.com/group/vim_use/msg/9c50f535a5600c04
>
> On 06/29/2010 09:20 PM, Ted wrote:
>> programming style that doesn't work particularly well in vimscript.
>
>> Cheers
>> -Ted
>
> Do you mean Vim compiled with python or just python installed on the
> system? If I understand right, windown installer for Vim comes with
> python compiled into Vim. Same goes for Vim in Ubuntu. On other
> distributions, I'm not sure, I believe I heard that Redhat's Vim does
> not have Python compiled in.
>
> If you're using python from Vim, it might make sense to use compiled in
> interpreter because there's closer integration with Vim rather than
> outside interpreter. If you haven't done this already, read :help python.
>
> -ak
>
> --
> Python plugins for vim: outliner, todo list, project manager, calendar,
> expenses tracker, sortable table, and more |
> http://lightbird.net/pysuite/
>
>
> ---------- 3 of 4 ----------
> From: "George V. Reilly" <george@reilly.org>
> Date: Jun 29 07:22PM -0700
> Url: http://groups.google.com/group/vim_use/msg/622ef587ad326ef9
>
>
>> If you're using python from Vim, it might make sense to use compiled in
>> interpreter because there's closer integration with Vim rather than
>> outside interpreter. If you haven't done this already, read :help python.
>
> The Windows build refers to a Python DLL and will load it if it can find
> it. However, Python itself is not included with Windows Vim and must be
> separately installed. It must also be the same version of Python (e.g.,
> python26.dll) and the DLL must be in the search path, :h python-dynamic
>
> The average Vim user on Windows is, I suppose, somewhat likely to already
> have Python, and, if not, will likely be amenable to installing it
> -- especially if it gets them some useful Vim extensions.
> But this is all supposition; I know of no way to get meaningful numbers on
> this.
> --
> /George V. Reilly  george@reilly.org  Twitter: @georgevreilly
> http://www.georgevreilly.com/blog  http://blogs.cozi.com/tech
>
>
> ---------- 4 of 4 ----------
> From: sc <toothpik@swbell.net>
> Date: Jun 29 11:05PM -0500
> Url: http://groups.google.com/group/vim_use/msg/e014a992d3102af1
>
> On Tuesday 29 June 2010 20:20:27 Ted wrote:
>
>> linux installs, but I don't feel like I could guess at how
>> many vim users on other platforms would be unable or
>> unwilling to install it.
>
> i'd like to count myself among those who like a lean build
> with no extra languages compiled in and as few plugins running
> as possible
>
> whatever your modules do i would not consider them if they
> require a python enabled vim
>
> sc
>
>
>
> =============================================================================
> Topic: Conditional imap
> Url: http://groups.google.com/group/vim_use/t/e8276bcf816b90b4
> =============================================================================
>
> ---------- 1 of 6 ----------
> From: gitterrost4 <gitterrost4@gmx.de>
> Date: Jun 29 12:22AM -0700
> Url: http://groups.google.com/group/vim_use/msg/314a782a771db0f0
>
> I did what you told me to (i dont want to use "(<Tab>" but just "(" to remap
> to "\left("). When I enter the command while i opended the Document
> everything works fine. But when I put the command in my .vimrc (or the
> tex.vim respectively) it stops working.
>
> The map is present, it just won't replace the "(".
>
> Any Idea?
>
>
> Christian Brabandt-3 wrote:
>
> --
> View this message in context:
> http://old.nabble.com/Conditional-imap-tp29008528p29020858.html
> Sent from the Vim - General mailing list archive at Nabble.com.
>
>
> ---------- 2 of 6 ----------
> From: "Christian Brabandt" <cblists@256bit.org>
> Date: Jun 29 12:01PM +0200
> Url: http://groups.google.com/group/vim_use/msg/96b7b8b04105918f
>
> On Tue, June 29, 2010 9:22 am, gitterrost4 wrote:
>> to "\left("). When I enter the command while i opended the Document
>> everything works fine. But when I put the command in my .vimrc (or the
>> tex.vim respectively) it stops working.
>
> So when you enter a "(" in insert mode, vim enters the "(" or what are
> you expecting? The mapping might not be active or vim doen't recognize
> the math-mode.
>
> Please show us the output of:
> :verbose imap (
> You can do this, by issuing:
> :redir @+
> :verbose imap (
> :redir end
> and pasting your clipboard into your mail. If this doesn't output the
> mapping that was given, it might be, that some plugin (maybe Latexsuite
> ?) overrides your mapping.
>
> If you want that mapping only for latex documents, I suggest, that you
> put it into a filetype specific file. Create a file
> ~/.vim/ftplugin/tex.vim (This is for Unix, create Directories that don't
> exist yet, for Windows, you can use $HOME/vimfiles/ftplugin/tex.vim) and
> in that file you write your mapping. Note, that you probably want to
> change the map to be buffer-local, so that in only applies to TeX-files.
>
> To do that change the map to something like this:
> imap ( <expr> <buffer> …
>
> If you want to make sure, that no plugin overrides the mapping, you
> could place the file tex.vim also below ~/.vim/after/ftplugin/ for Unix
> and $HOME/vimfiles/after/ftplugin/ for Windows. That way, it will be
> applied last overriding any setting that might have been applied by a
> global or filetype plugin.
>
> It might also be, that the math-mode is not correctly
> recognized. To find out, what the name of the syntax highlighing for the
> math mode is, put the cursor on the math-mode and issue:
> :echo synIDattr(synID(line('.'),col('.'),1), "name")
>
> This should output something like texMathSomething. In case it is
> something different, you need to adjust your mapping.
>
> Oh and please don't top post. It is general list consensus to trim
> quotes and reply inline.
>
> regards,
> Christian
>
>
> ---------- 3 of 6 ----------
> From: "Christian Brabandt" <cblists@256bit.org>
> Date: Jun 29 12:04PM +0200
> Url: http://groups.google.com/group/vim_use/msg/e902468dc2adfbbd
>
> On Tue, June 29, 2010 12:01 pm, Christian Brabandt wrote:
>> To do that change the map to something like this:
>> imap ( <expr> <buffer> …
>
> This should obviously be
> :imap <expr> <buffer> ( …
>
> regards,
> Christian
>
>
> ---------- 4 of 6 ----------
> From: gitterrost4 <gitterrost4@gmx.de>
> Date: Jun 29 04:04AM -0700
> Url: http://groups.google.com/group/vim_use/msg/6eb81e5cf072ffb2
>
> Indeed it was latex-suite overriding the map from my tex.vim file. I fixed
> this by appending the line
>
> exe 'source '.fnameescape('~/.vim/ftplugin/tex.vim')
>
> to the file $VIM/ftplugin/latex-suite/main.vim
>
> I do not know, if this could be solved better, but now it works...
>
> I also had to adapt the matching, because your suggestion would only match
> if the cursor was between math characters, but not if the cursor was at the
> end of the line or after a math delimiter. It now boiled down to:
>
> inoremap <expr> ( synIDattr(synID(line('.'), col('.')-1, 1),
> "name")=~"texMath" ? "\\left(" : synIDattr(synID(line('.'), col('.'), 1),
> "name")=~ "texMath" ? "\\left(" : synIDattr(synID(line('.'), col('.')-1, 1),
> "name")=~"Delimiter" ? synIDattr(synID(line('.'), col('.')-2, 1),
> "name")=~"Delimiter" ? synIDattr(synID(line('.'), col('.')-3, 1),
> "name")!~"texMath" ? "\\left(" : "(" : synIDattr(synID(line('.'),
> col('.')-2, 1), "name")!~"texMath" ? "\\left(" : "(" : "("
>
>
> Thanks for helping :)
> --
> View this message in context:
> http://old.nabble.com/Conditional-imap-tp29008528p29022437.html
> Sent from the Vim - General mailing list archive at Nabble.com.
>
>
> ---------- 5 of 6 ----------
> From: Christian Brabandt <cblists@256bit.org>
> Date: Jun 29 08:15PM +0200
> Url: http://groups.google.com/group/vim_use/msg/939e244210302e82
>
> Hi gitterrost4!
>
> On Di, 29 Jun 2010, gitterrost4 wrote:
>
>> "name")=~"Delimiter" ? synIDattr(synID(line('.'), col('.')-3, 1),
>> "name")!~"texMath" ? "\\left(" : "(" : synIDattr(synID(line('.'),
>> col('.')-2, 1), "name")!~"texMath" ? "\\left(" : "(" : "("
>
> Ok, I admit, I don't understand, why you need to check for 3 columns in
> front of the cursor. But hey, if it works, I won't complain ;)
>
> regards,
> Christian
> --
>
>
> ---------- 6 of 6 ----------
> From: gitterrost4 <gitterrost4@gmx.de>
> Date: Jun 29 12:55PM -0700
> Url: http://groups.google.com/group/vim_use/msg/c76d13b39cb72302
>
>>Ok, I admit, I don't understand, why you need to check for 3 columns in
>>front of the cursor. But hey, if it works, I won't complain ;)
>
> Well in the \[ or the $$ environment, I need to check, if there is a
> delimiter one space in front of the cursor, a delimiter two before cursor
> and a non-math environment before that. Thet's why I need to check 3 columns
> before the cursor.
> --
> View this message in context:
> http://old.nabble.com/Conditional-imap-tp29008528p29027684.html
> Sent from the Vim - General mailing list archive at Nabble.com.
>
>
>
> =============================================================================
> Topic: au BufReadPost * if &readonly | set nomodifiable
> Url: http://groups.google.com/group/vim_use/t/82946ab8ac7e1c62
> =============================================================================
>
> ---------- 1 of 2 ----------
> From: Tony Mechelynck <antoine.mechelynck@gmail.com>
> Date: Jun 29 09:24AM +0200
> Url: http://groups.google.com/group/vim_use/msg/e53a83ff8ff618b4
>
> On 06/05/10 22:26, Ben Fritz wrote:
>> with no arguments to reload the file and set the appropriate readonly/
>> modifiable options based on file attributes. I do not know why this is
>> not currently working.
>
> Hm. Just a wild thought (untested): try the following (which assumes
> 'nocompatible'):
>
>
> if has('autocmd')
> au VimEnter * augroup nomodif
> au VimEnter * au BufReadPost,BufNewFile * if &buftype == ""
> \ | let &l:ma = &l:ro | endif
> au VimEnter * augroup END
> endif
>
>
> Then restart Vim (every time you make changes to your vimrc, and after
> saving your changes) in order to test it.
>
> If it doesn't work: while editing a file where 'modifiable' is not what
> you expect:
>
> :verbose setlocal ma? ro? bt?
>
>
> Best regards,
> Tony.
> --
> A disciple of another sect once came to Drescher as he was
> eating his morning meal. "I would like to give you this personality
> test", said the outsider, "because I want you to be happy."
> Drescher took the paper that was offered him and put it into
> the toaster -- "I wish the toaster to be happy too".
>
>
> ---------- 2 of 2 ----------
> From: Benjamin Fritz <fritzophrenic@gmail.com>
> Date: Jun 29 01:08PM -0500
> Url: http://groups.google.com/group/vim_use/msg/1d398e40e2375c2a
>
> On Tue, Jun 29, 2010 at 2:24 AM, Tony Mechelynck
>>                \ | let &l:ma = &l:ro | endif
>>        au VimEnter * augroup END
>>  endif
>
> Won't work. The problem seen here was a netrw bug that prevented the
> 'readonly' option from being set properly. This autocmd will still
> fail because the readonly option is not being set.
>
> I believe this issue in netrw was fixed, I vaguely remember reading
> something on vim_dev. But, I don't recall the version it was fixed in.
>
> Chip?
>
>
>
> =============================================================================
> Topic: :set wrap Range
> Url: http://groups.google.com/group/vim_use/t/dcfc48f2372aada7
> =============================================================================
>
> ---------- 1 of 1 ----------
> From: Paul <google01239@rainslide.net>
> Date: Jun 29 03:34PM +0100
> Url: http://groups.google.com/group/vim_use/msg/564f252e4287d932
>
> It would be cool if we could :set wrap or nowrap on particular lines but not
> others. I tried it already (of course) but it said no range allowed. What do
> you think about adding this feature in a future version perhaps?
>
> --
>
> .
>
>
>
>
> --
> 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
>

--
Sent from my mobile device

天行健，君子以自强不息！

--
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

Re: screen not updated after backspace

On Jul 1, 7:34 am, Sven Eppler <s...@sveneppler.de> wrote:
> the deleted characters are
> not removed from the screen. Only when leaving insert-mode or switch
> lines the screen will get updated and the deleted characters will
> vanish from the screen.

That's ancient vi behaviour; you've somehow got vim running in vi
compatible mode. See :help compatible. Try

:verbose set cp?

to see where it's being set.

If your vim came from the repositories I'd expect it to have run /usr/
share/vim/vim70/debian.vim, which usually has set nocompatible; in its
absence moving your .vimrc is one way to get compatible mode; if vim
finds a .vimrc it sets nocompatible.

BTW, 7.0 is a bit old, there have been hundreds of fixes since then.
Building your own vim is easy on Debian. Hmm, the ftp server for vim
doesn't have 300 patches for 7.0, maybe you've actually got 7.1 or
7.2.

Regards, 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

RE: Analog to SHIFT+Asterisk

Hoss wrote:
> Is there an analogous key combination, that will highlight
> the current word, WITHOUT moving my cursor?

See this tip:
http://vim.wikia.com/wiki/Highlight_all_search_pattern_matches

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

Re: percentage of vim users running python

Thanks to all for providing input on my question. I realized that the
demographic is a bit more restricted than the general population of
vim users; it is that portion thereof who actually install vim modules
at all. It's informative to learn that there are some in that group
who would not be willing to install python as a module dependency.

At the risk of straying off-topic: is there a consensus on the correct
term for a "vim script"? That phrase itself seems too specific, and
too easily conflated with one of the files contained in such a
package, or any file with the `.vim` extension. I tend to call them
"modules", coming from Drupal and Python; Marc here seems to prefer
the term "addon"; is there a standard term that should be used to
avoid confusion?

Marc's response gave me the most food for thought, so I am going to
reply to his questions and observations, but much of this applies in a
general context (thus the reply to all response).

On Jun 30, 5:34 am, Marc Weber <marco-owe...@gmx.de> wrote:

> Go for Python because VimL can be a lock-in (speed issues if you want to
> do a lot).
Portability outside of vim is also a consideration in my case, as it
is with any code that's not closely tied to vim's functionality. I
guess I'm wondering if it's expected, or at least recommended, that
general-purpose routines be re-implemented in VimL rather than being
made available through dependencies on other languages.

I've written (in addition to the code that prompted my question)
some -- decidedly low-rent -- URL parsing code; this is another
example of something that is definitely readily available in other
languages that vim has bindings for. Without regular additions to the
VimL "standard library", ie the set of autoloads and plugins that come
installed in $VIMRUNTIME, there ends up being a lot of potential code
that is in this ambiguous area. The absence of a widely used system
of dependency management [1] means that much of this code may need to
be, or has already been, implemented on a module-by-module basis.
This is the alternative to having the typical user manually install 6
different modules in order to get something working, or perhaps
instead decide that the thing requires far too much effort. Which in
turn means that, especially as vim modules become more powerful, there
will end up being a lot of redundant code loaded into memory. Or
underused scripts.

1: at least to my knowledge; Marc, I am aware of your vim-addon-
manager plugin. It sounds pretty useful and is one of those things
that I haven't had time to try out and hopefully start using
regularly. But it seems like it's not yet widely used, and I would
hesitate before taking advantage of its presence by splitting a
comprehensive vim module into a set of interdependent components.
It's again a question of how open the average user (of addons) is to
integrating higher-level tools in order to satisfy their immediate
goals.

> Maybe you want to get some ideas from my sbt plugin:www.github.com/MarcWeber/vim-addon-sbt
>
> It mocks Vim functionality so that you can test it without Vim and use a
That's interesting. From glancing through the autoload file it
looks like you're just implementing the stuff you need to test that
script.. is there a more general purpose vim "test double" Python
module somewhere? In addition to various other projects, I've also
got a fledgeling drop-in replacement for the `vim` module on the go,
after I didn't find anything with some Googles.

> Can you tell more about what you're going to implement?
The URL-parsing code I mentioned earlier is not what I had in mind
when I wrote the original post. The project in question is basically
a set of routines for manipulating an outlining/markup file format
that I sort of .. accidentally evolved over the past couple of years.
The format itself is still fairly nebulous so I don't expect anything
to be releasable any time soon. I've not needed anything really high-
level so far, but I'm getting to the point where it's going to start
saving me time and confusion to have something more complex built.
The format is basically syntactic sugar on XML (err, I guess the XML
is "on sugar"?), so it could be appealing to eventually be able to use
Python's DOM classes to work with it, and in the meantime it would be
more convenient to do a lot of the off-the-cuff text processing in
Python.

For example, I use this format for taking notes, and one of the things
that I commonly do is to paste in a quotation from a browser, split it
into sentences, and make each of those sentences a "quoted" node,
which is just a line which at the right indentation level that
contains a double-quote character and a space followed by the
sentence. There are a few subroutines inherent to this procedure, and
the sentence-splitting in particular is something that could be very
context-dependent, with a varying degree of generality: for example,
in some cases I want to split out the elements of a list of items,
delimited by commas or words like "and" or "or", rather than splitting
on sentence boundaries. In other cases I need to specify that the
text is already in point form. In Python I would make the basic
sentence splitting subroutine the default value of a parameter, and
then just override it with a different function, or maybe use a class
if it started getting really complex.

Although this is doable in VimL, I think it's necessarily a bit ugly,
and I would perhaps face censure from would-be contributors if I were
to, for example, write a closure by execing a string that contains an
anonymous function definition. That being said, VimL is not
particularly similar to Python, so perhaps there are better models to
be applied than that of Python. If there is a comprehensive coding
style guide somewhere, please point me to it; I see a lot of
possibilities, especially with respect to copy-prototypal inheritance,
but few signs pointing to existing conventions or common techniques.
The lack of development in this direction could suggest that people
are still tending to do complicated things in bound languages (Python,
perl, etc.), or perhaps external tools (though this would seem to be
more of a portability issue than most languages). Or it may perhaps
just indicate a desire to prevent vim from expanding into an operating
system lacking a decent editor.

I'm currently experimenting with making the top-level function a
dictionary function, and using the dictionary as I would, in Python,
use keyword arguments. To this end I wrote some code to make it
convenient to copy the prototype dictionary that contains the function
and its defaults, while applying options, and then call the function.
It ends up using method chaining and being somewhat Javascript-ey. I
called it "Merger": it has Ours (keeps defaults), Theirs (overrides
defaults), and Safe (throws exceptions on conflict) methods, as well
as recursive versions of said methods, which deepcopy the original and
merge in their dictionary parameter, then return the result. There
are also some methods like Apply and Call that make it easier to call
dictionary or non-dictionary functions on the object. It appeared to
me that, although not particularly complex (I think the whole thing is
about 40 lines), it should really go into some kind of general-purpose
library or into a separate module.

I remembered that I had a few of those in my list of things that might
be useful later on, and I should probably scan through them to see if
this sort of thing is implemented in any of them. But they seem
pretty time-consuming to go through, and I was a bit worried that the
procedure might, at this point, cause my brain to have some sort of
stack overflow error from yet another level of sub-task. I also
thought that if this module that I'm building is going to depend on a
separate utility module, and at this rate likely 6 or 10 others, how
much more of a portability issue is it going to be to just write the
whole thing in Python in the first place? And thus my question.

> :-). Vim does neither support Scala, F# nor Haskell. Maybe you should be
> using lisp or scheme then.
I actually don't know any of those languages either, except for a hint
of lisp. Actually my use of the term "functional programming" should
probably be taken with a grain of salt; my experience in this respect
is mostly limited to what's possible in Python through the
`itertools`, `functools`, and `functional` modules, and through the
use of closures. But I like what I've learned of it so far.

--
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

Re: Analog to SHIFT+Asterisk

On Wed, 30 Jun 2010, Hoss wrote:

> Esteemed Vim Users,
>
> One of the useful key combinations in vim is shift+asterisk, which
> will locate the word your cursor is "on", and put that word into your
> "/ buffer (surrounded by \<\> word boundaries). This has the effect of
> highlighting all occurrences of that word.
>
> It also has the effect of jumping the cursor to the next instance of
> that word in your buffer.
>
> Is there an analogous key combination, that will highlight the current
> word, WITHOUT moving my cursor?

Fun:

:nmap A :call setreg('/','\<'.expand('<lt>cword>').'\>')<CR>

Replace 'A' with whatever key(s) you want to map it to.

That sets the search register to start-of-word + the current word +
end-of-word without actually performing the search. The search doesn't
show up in the search history (q/), though. The much-simpler:

:nmap A *<C-O>

will perform a star search (ha), and then go back to the prior position.
Has the advantage of putting it in the search history but (IMO,
significantly-worse) disadvantage of moving the cursor if the next match
is off-screen.

See:

:help key-mapping
:help :nmap
:help expand()
:help map.txt | /<lt> -- for why I used '<lt>' in the mapping
:help :<cword>

--
Best,
Ben

--
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

Analog to SHIFT+Asterisk

Esteemed Vim Users,

One of the useful key combinations in vim is shift+asterisk, which
will locate the word your cursor is "on", and put that word into your
"/ buffer (surrounded by \<\> word boundaries). This has the effect of
highlighting all occurrences of that word.

It also has the effect of jumping the cursor to the next instance of
that word in your buffer.

Is there an analogous key combination, that will highlight the current
word, WITHOUT moving my cursor?

Thanks,

Todd

(I know I can just shift+N afterwards, to get back where I was.
Something more elegant?)

--
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

Re: question about lua source navigation

On 2010-06-30, X Heruacles wrote:

> On Wed, Jun 30, 2010 at 3:42 PM, Gary Johnson <garyjohn@spocom.com> wrote:
>
> On 2010-06-30, X Heruacles wrote:
> > I'm just learning lua and I use vim to navigate some lua projects. I use
> ctags
> > to generate tags using a map:
> >
> > map <F12> <Esc>:!ctags -R .<CR>
> >
> > but it rarely helps. When I want to jump to some function definition, it
> always
> > errs. Then I checked the generated tag and it seems fine. So my question
> is
> > just is there a better way to navigate lua project?(esp. jumping to
> function
> > definition?)
>
> I don't know what else might be available for navigating Lua, but
> the ctags web page at SourceForge says that it understands Lua, and
> you write that the tags appear fine, so I would suggest that you
> find out why your Lua tags aren't working as you expect and fix that
> problem. If you post a short file containing Lua code and explain
> what you do and what happens when you try to jump to a tag in that
> code, we might be able to spot the problem and give you a solution.
>
> Regards,
> Gary

> thanks Gary. Then I show the code here:
> the generated tag has a line looks like this:
>
> TaskHandler.prizeTask .\init\taskHandler.lua /^function
> TaskHandler.prizeTask(plr, task)$/;" f
>
> and I have a function:
>
> function Task:succeed()
>
> debug_log("Task:succeed")
>
> self.isSucceed = true
>
> TaskHandler.prizeTask(self.owner, self)
>
> self:eventOnSuccess()
>
> if self.spanTimerId > 0 then self:clearSpanTimer() end
>
> self.owner:addFinishedTask(self)
>
> if self.entry.type == taskType.TASK_TYPE_MAIN then
>
> self.owner:setSaveRecord("MainTask", self:getId(), 0)
>
> else
>
> end
>
> if self.entry.nexttask ~= nil and self.entry.nexttask ~= 0 then
>
> debug_log("self.owner:addTask")
>
> self.owner:addTask(self.entry.nexttask)
>
> end
>
> end
>
>
>
> in the file task.lua in the subdirectory of where the tags file lies. While my
> cursor on "prizeTask", I press Ctrl-], only to find it shows me an error that
> can't find the tag: prizeTask. So it is.

Thanks for the code. I tried to replicate the problem but ctags is
not generating the same tags for me as it did for you.

I created a new directory for testing this and within that directory
created a subdirectory, subdir. I put your code into a file named
task.lua in subdir. In the top-level directory I executed

ctags -R .

Here is the resulting tags file.

!_TAG_FILE_FORMAT 2 /extended format; --format=1 will not append ;" to lines/
!_TAG_FILE_SORTED 1 /0=unsorted, 1=sorted, 2=foldcase/
!_TAG_PROGRAM_AUTHOR Darren Hiebert /dhiebert@users.sourceforge.net/
!_TAG_PROGRAM_NAME Exuberant Ctags //
!_TAG_PROGRAM_URL http://ctags.sourceforge.net /official site/
!_TAG_PROGRAM_VERSION 5.7 //
Task:succeed subdir/task.lua /^ function Task:succeed()$/;" f

As you can see, it contains only one tag.

I opened a file in the top-level directory and added the line

Task:succeed

Typing ^] over "Task" resulted in

E426: tag not found: Task

and typing ^] over "succeed" resulted in

E426: tag not found: succeed

I then executed

:set iskeyword+=:

Typing ^] anywhere over "Task:succeed" then resulted in Vim jumping
to the top of that function.

[Time passes while I do other work and think some more.]

I just appended those lines from your tags file to mine and added
tabs between the fields. Typing ^] over "TaskHandler" or
"prizeTask" resulted in E426. Then I executed

:set iskeyword+=.

and tried again. This time I got this error:

E429: File ".\init\taskHandler.lua" does not exist

So I think that's the problem: you need to have . in your
'iskeyword' option for Lua files.

HTH,
Gary

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

screen not updated after backspace

Hi There,

since about a week on my server vim behaves strange. The backspace-key
is working correctly beside the fact, that the deleted characters are
not removed from the screen. Only when leaving insert-mode or switch
lines the screen will get updated and the deleted characters will
vanish from the screen.

e.g.: when backspacing 5 characters and typing 4 new, the newly typed
chars will be shown correctly, but the first backspaced char will stay
again until i leave the insert-mode or navigate into another line.

This is something which just happend one day to the other. Moving my
~/.vimrc file and my ~/.vim/ folder doesn't help, so i assume it's not
a missconfiguration of mine.

Version information:
Debian Etch, 64bit
Vim 7.0.305

Anybody a idea, where these odd behavior may come from?

Thanks in advance,
Sven

--
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

Re: Daily Vim Devotional

On Wed, 30 Jun 2010, nlloyds wrote:

> Some of my Vim-using colleagues at cramerdev.com and myself just
> created http://dailyvim.tumblr.com/, for a daily Vim tip. Check it
> out!

Cool.

I signed up for a Tumblr account (finally), because I wanted to post a
response. Do you have to enable it for a given [tumblr-noun] (==
feed?). The 'Customize' page[1] has some reply options under the
'Community' tab. Maybe it just takes some amount of time to show up?

E.g. I reblogged your '~ (tilde)' post[2], adding the fact that
linewise-visual makes the 'holding-down-~' portion unneccesary.

--
Best,
Ben

[1] http://www.tumblr.com/customize
[2] http://benizi.tumblr.com/post/754614794/tilde

--
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

Re: percentage of vim users running python

On Wed, 30 Jun 2010 10:34:16 +0200, Marc Weber <marco-oweber@gmx.de>
wrote:

> Go for Python because VimL can be a lock-in (speed issues if you want to
> do a lot).

Isn't it rather the opposite? If something requires Python it's at the
mercy of the availability of Python and the ability of Vim to make use
of the available Python if the language is installed, while something
in native Vim will run anywhere.

I remain unconvinced of the utility of the additional languages for
anything other than personal use. Even when they are available the
linking may require a particular version, and that version may not be
the same as the version needed by other applications.

I can't remember the last time I saw a machine with Python installed
in a generally available form, and that machine only had it because
I put it there. (I've seen a few with it installed privately for one
specific application, but that's not terribly useful.) It's far from
ubiquitous, and very few people are going to go to the trouble of
installing a new language just to use a plugin.

--
Matthew Winn

--
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

Daily Vim Devotional

Some of my Vim-using colleagues at cramerdev.com and myself just
created http://dailyvim.tumblr.com/, for a daily Vim tip. Check it
out!

Nathan

--
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

Re: Conditional imap

On Jun 29, 6:04 am, gitterrost4 <gitterro...@gmx.de> wrote:
> Indeed it was latex-suite overriding the map from my tex.vim file. I fixed
> this by appending the line
>
> exe 'source '.fnameescape('~/.vim/ftplugin/tex.vim')
>
> to the file $VIM/ftplugin/latex-suite/main.vim
>

This could certainly be done better!

Just put your mapping in ~/.vim/after/ftplugin/latex-suite.vim, and
don't add any extra "source" logic to anything.

--
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

Page Up/Down in xterm

Is it possible, does anyone know, to have xterm key mappings that allow
normal scrolling with page up/down in normal mode, and mappable code
sequences in 'alternate' mode (which I have vim enter while it runs)?

I.e., Page Up/Down has diff. mappings between normal and alternate mode.

The mouse-wheel (buttons 4-5) does behave differently in the manner I want.

--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

--
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

Re: question about lua source navigation

The error code is E426.

After I set iskeyword, the command set iskeyword? echos

iskeyword=@,48-57,_,128-167,224-235,:

but it still didn't solve the problem. Thanks anyway.

2010/6/30 Dominique Pellé <dominique.pelle@gmail.com>

X Heruacles wrote:

> I'm just learning lua and I use vim to navigate some lua projects. I  use
> ctags to generate tags using a map:
>>
>> map <F12>  <Esc>:!ctags -R .<CR>
>
> but it rarely helps. When I want to jump to some function definition, it
> always errs. Then I checked the generated tag and it seems fine. So my
> question is just is there a better way to navigate lua project?(esp. jumping
> to function definition?)

What error number do you get?
Does adding colon character to 'iskeyword' helps?    :set iskeyword+=:

-- Dominique

--

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 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

Re: vimdiff-like highlighting within the same file?

On Mi, 30 iun 10, 15:42:37, Jürgen Krämer wrote:
>
> maybe the following can be a start. Open your .po file and execute these
> commands (the fourth command is one long line):
>
> :%y
> :vert new
> :put!
> :%s/^\(#| msgid ""\n\(\_.\{-\}\n\)msgid ""\n\)\(\_.\{-\}\n\)\(msgstr ""\)/\=submatch(1).substitute(submatch(2), '#| ', '', 'g').submatch(4)/
> :nohls
> :diffthis
:set hidden
> :wincmd w
:wincmd o
> :diffthis
>
> Modifications are now highlighted in the new string -- but not in the old
> string.

Cool ;)

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

Re: vimdiff-like highlighting within the same file?

Hi,

Andrei Popescu wrote:
> On Mi, 30 iun 10, 13:32:22, Marc Weber wrote:
>>
>> Can't you just provide two files? The old and the new one? Most VCS
>> systems do that anyway
>
> vimdiff can be used (but it's not ideal) if you have access to the
> previous .po file, but this is not always the case. Especially bigger
> projects will only provide .po files through some web interface.
>
>> #| msgid ""
>> #| "The following disk access storage devices (DASD) are available. Please "
>> #| "select each device you want to use one at a time."
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ old English msgid
>>
>> You can get rid of those comments: :g/^$|/d
>> Then you can diff old and new files directly
>
> Not really. The workflow is like this (best illustrated with a sample):
>
> #: ../file.c: 123
> msgid "translatable string"
> msgstr "translation of the string"
>
> 1. programmer changes the translatable string in the program source code
> and uses automated tools to update the .po. During this update the
> changed msgid is completely replaced with the new one (might involve
> wrapping changes)
> 2. fuzzy flag is set for the respective string
> 3. (optional) for the benefit of translators the old msgid is *added* to
> the file and marked as such with the '#|'
>
> #: ../file.c: 123
> #, fuzzy
> #| msgid "translatable string"
> msgid ""
> "This is the new translatable string, too big to fit on one line, which"
> "is why the line is wrapped"
> msgstr "translation of the string"
>
> a) the translator opens the new .po file and updates the translation
> b) removes fuzzy flag (and the previous msgid if present) to indicate
> that the translation is now ok
>
> #: ../file.c: 123
> msgid ""
> "This is the new translatable string, too big to fit on one line, which"
> "is why the line is wrapped"
> msgstr ""
> "new translation ....................................................."
> "................................................."
>
>
> (of course, this example shows a big change, were highlighting the
> changes is rather unnecessary, but I think you get the point and why the
> usual diff tools are not very useful)

maybe the following can be a start. Open your .po file and execute these
commands (the fourth command is one long line):

:%y
:vert new
:put!
:%s/^\(#| msgid ""\n\(\_.\{-\}\n\)msgid ""\n\)\(\_.\{-\}\n\)\(msgstr ""\)/\=submatch(1).substitute(submatch(2), '#| ', '', 'g').submatch(4)/
:nohls
:diffthis
:wincmd w
:diffthis

Modifications are now highlighted in the new string -- but not in the old
string.

Regards,
Jürgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)

--
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

Re: vimdiff-like highlighting within the same file?

> Because the previous msgid is not needed in the translated .po file I
> thought of pre-processing the .po file[1]. Unfortunately I don't have
> the programing skills for that either :(

Can you describe this preprocessing?

What do you expect from the highlighting?

one line:
"Hello World"

two lines
"Hello"
"World"

should they "differ" ?

file 1:

#| msgid "foo bar"
msgid "foo bar changed"

if you created a second file from that:

#| msgid "foo bar"
msgid "foo bar" << duplicate the msgid found in comments

can you diff both files then? Is this what you're looking for?

Can you illustrate which example you want to be highlighted?

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

Re: vimdiff-like highlighting within the same file?

On Mi, 30 iun 10, 13:32:22, Marc Weber wrote:
>
> Can't you just provide two files? The old and the new one? Most VCS
> systems do that anyway

vimdiff can be used (but it's not ideal) if you have access to the
previous .po file, but this is not always the case. Especially bigger
projects will only provide .po files through some web interface.

> #| msgid ""
> #| "The following disk access storage devices (DASD) are available. Please "
> #| "select each device you want to use one at a time."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ old English msgid
>
> You can get rid of those comments: :g/^$|/d
> Then you can diff old and new files directly

Not really. The workflow is like this (best illustrated with a sample):

#: ../file.c: 123
msgid "translatable string"
msgstr "translation of the string"

1. programmer changes the translatable string in the program source code
and uses automated tools to update the .po. During this update the
changed msgid is completely replaced with the new one (might involve
wrapping changes)
2. fuzzy flag is set for the respective string
3. (optional) for the benefit of translators the old msgid is *added* to
the file and marked as such with the '#|'

#: ../file.c: 123
#, fuzzy
#| msgid "translatable string"
msgid ""
"This is the new translatable string, too big to fit on one line, which"
"is why the line is wrapped"
msgstr "translation of the string"

a) the translator opens the new .po file and updates the translation
b) removes fuzzy flag (and the previous msgid if present) to indicate
that the translation is now ok

#: ../file.c: 123
msgid ""
"This is the new translatable string, too big to fit on one line, which"
"is why the line is wrapped"
msgstr ""
"new translation ....................................................."
"................................................."

(of course, this example shows a big change, were highlighting the
changes is rather unnecessary, but I think you get the point and why the
usual diff tools are not very useful)

> Then translater will see as well what changed.
> Moreover they can see if a id changed but the translation was not
> changed yet.

The fuzzy flag already shows that.

> Scripting up the solution I proposed can be done in several minutes.
> However I'm not sure wether it serves you best?

Because the previous msgid is not needed in the translated .po file I
thought of pre-processing the .po file[1]. Unfortunately I don't have
the programing skills for that either :(

[1] http://nuvreauspam.ro/2010/05/6-translate-tool-needed/

> Do your translators know Vim ? Or do they use it because of the syntax
> highlighting? I"m asking because there are existing gui solutions.

The translator is me :) I already tried the GUI tools, but I still
prefer vim, even without this feature.

I'm also sure, that any other translators using vim will be very
grateful for such a feature, which is why I plan on submitting the
feature as patch to the ftplugin or the syntax file for .po (whatever
makes more sense).

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

Re: vimdiff-like highlighting within the same file?

Excerpts from Andrei Popescu's message of Wed Jun 30 13:19:23 +0200 2010:
> On Mi, 30 iun 10, 12:30:15, Christian Brabandt wrote:
> >
> > I would use the NarrowRegion plugin[1]. Make sure, it uses vertical
> > split windows, (:let g:nrrw_rgn_vert = 1), set nowinfixwidth in each
> > narrowed window (:set nowinfixwidth), resize each window to your desired
> > width and diff each narrowed window (:diffthis). You can then
> > interactively merge the differences (see :h copy-diff) and when
> > finished, simply write the Narrowed window. Be sure to read the
> > documentation of the plugin (:h NrrwRgn.txt)
>
> I'll try it out, but seems a little too much for just *showing* the
> differences (the translator must *not* touch the current msgid and the
> previous msgid is just a convenience to easily spot changes).

Can't you just provide two files? The old and the new one? Most VCS
systems do that anyway

#| msgid ""
#| "The following disk access storage devices (DASD) are available. Please "
#| "select each device you want to use one at a time."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ old English msgid

You can get rid of those comments: :g/^$|/d
Then you can diff old and new files directly
Then translater will see as well what changed.
Moreover they can see if a id changed but the translation was not
changed yet.

That's even better because translators want to pay attention to
translations which didn't change but whos id changed.

Scripting up the solution I proposed can be done in several minutes.
However I'm not sure wether it serves you best?

Do your translators know Vim ? Or do they use it because of the syntax
highlighting? I"m asking because there are existing gui solutions.

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

Re: vimdiff-like highlighting within the same file?

On Mi, 30 iun 10, 12:30:15, Christian Brabandt wrote:
>
> I would use the NarrowRegion plugin[1]. Make sure, it uses vertical
> split windows, (:let g:nrrw_rgn_vert = 1), set nowinfixwidth in each
> narrowed window (:set nowinfixwidth), resize each window to your desired
> width and diff each narrowed window (:diffthis). You can then
> interactively merge the differences (see :h copy-diff) and when
> finished, simply write the Narrowed window. Be sure to read the
> documentation of the plugin (:h NrrwRgn.txt)

I'll try it out, but seems a little too much for just *showing* the
differences (the translator must *not* touch the current msgid and the
previous msgid is just a convenience to easily spot changes).

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

Re: vimdiff-like highlighting within the same file?

On Wed, June 30, 2010 11:59 am, Andrei Popescu wrote:
> What I posted was an excerpt of a .po file. Here is a full "string" with
> comments:
>
> [blank line]
> #. Type: select
> #. Description
> #. :sl5:
> #: ../s390-dasd.templates:1002
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ other stuff, not interesting in this case
> #, fuzzy
> ^^^^^^^^ fuzzy flag, indicates the original (usually English) msgid
> (string) has changed
> #| msgid ""
> #| "The following disk access storage devices (DASD) are available. Please
> "
> #| "select each device you want to use one at a time."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ old English msgid
> msgid ""
> "The following direct access storage devices (DASD) are available. Please
> "
> "select each device you want to use one at a time."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ new English msgid
> msgstr ""
> "Următoarele Dispozitive de stocare cu acces la disc (DASD) sunt
> disponibile. "
> "Vă rugăm să alegeți pe rând fiecare dispozitiv pe care doriți să-l
> folosiți."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ translation
> [blank line]
>
> "strings" are always separated by (at least) one blank line and a .po
> file usually contains a lot of them (hundreds or more), which is why I
> won't post a complete file. A translator must not, ever, touch the
> "other stuff" and the current msgid.
>
> After editing the translation the fuzzy flag must be removed to indicate
> the translation is ok (handled by po.vim) and the previous msgid becomes
> useless and is removed as well (I have a patch for po.vim).
>
> It would be of great help to the translator to have the differences
> between the previous and current msgid highlighted, especially in long
> strings with only small changes.

Thanks, that makes it clearer to me.

I would use the NarrowRegion plugin[1]. Make sure, it uses vertical
split windows, (:let g:nrrw_rgn_vert = 1), set nowinfixwidth in each
narrowed window (:set nowinfixwidth), resize each window to your desired
width and diff each narrowed window (:diffthis). You can then
interactively merge the differences (see :h copy-diff) and when
finished, simply write the Narrowed window. Be sure to read the
documentation of the plugin (:h NrrwRgn.txt)

But then again, I am a little bit biased, as I am the author of the
plugin and there might be better ways to do it.

[1] http://www.vim.org/scripts/script.php?script_id=3075

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

Re: vimdiff-like highlighting within the same file?

On Mi, 30 iun 10, 11:41:49, Marc Weber wrote:
> Hi Christian,
>
> Excerpts from Christian Brabandt's message of Wed Jun 30 11:12:03 +0200 2010:
> > I don't understand your question. Can you elaborate, on what the file
> > looks like and where the previous message id comes from? Please show a
> > sample file, with which we can see your problem.
>
> He gave an example. Note that two sentences start with "The following"
> He wants to diff both ignoring the '#| ' in the first sentence.

Unfortunately it's a bit more complicated. Changes in the msgid can and
do affect the wrapping (which is why diffing by line is useless or even
counterproductive).

> So both sentences which should be diffed are in the same file. That's
> how I understood the task

Yep. Something like what wdiff is doing.

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

Re: vimdiff-like highlighting within the same file?

On Mi, 30 iun 10, 11:12:03, Christian Brabandt wrote:
> On Wed, June 30, 2010 10:52 am, Andrei Popescu wrote:
> > I'm trying to add new features to vim's handling of .po files. How could
> > I highlight the differences between the current msgid and the previous
> > one?
>
> I don't understand your question. Can you elaborate, on what the file
> looks like and where the previous message id comes from? Please show a
> sample file, with which we can see your problem.

What I posted was an excerpt of a .po file. Here is a full "string" with
comments:

[blank line]
#. Type: select
#. Description
#. :sl5:
#: ../s390-dasd.templates:1002
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ other stuff, not interesting in this case
#, fuzzy
^^^^^^^^ fuzzy flag, indicates the original (usually English) msgid
(string) has changed
#| msgid ""
#| "The following disk access storage devices (DASD) are available. Please "
#| "select each device you want to use one at a time."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ old English msgid
msgid ""
"The following direct access storage devices (DASD) are available. Please "
"select each device you want to use one at a time."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ new English msgid
msgstr ""
"Următoarele Dispozitive de stocare cu acces la disc (DASD) sunt disponibile. "
"Vă rugăm să alegeți pe rând fiecare dispozitiv pe care doriți să-l folosiți."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ translation
[blank line]

"strings" are always separated by (at least) one blank line and a .po
file usually contains a lot of them (hundreds or more), which is why I
won't post a complete file. A translator must not, ever, touch the
"other stuff" and the current msgid.

After editing the translation the fuzzy flag must be removed to indicate
the translation is ok (handled by po.vim) and the previous msgid becomes
useless and is removed as well (I have a patch for po.vim).

It would be of great help to the translator to have the differences
between the previous and current msgid highlighted, especially in long
strings with only small changes.

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

Re: vimdiff-like highlighting within the same file?

Hi Christian,

Excerpts from Christian Brabandt's message of Wed Jun 30 11:12:03 +0200 2010:
> I don't understand your question. Can you elaborate, on what the file
> looks like and where the previous message id comes from? Please show a
> sample file, with which we can see your problem.

He gave an example. Note that two sentences start with "The following"
He wants to diff both ignoring the '#| ' in the first sentence.
So both sentences which should be diffed are in the same file. That's
how I understood the task

#, fuzzy
#| msgid ""
#| "The following disk access storage devices (DASD) are available. Please "
#| "select each device you want to use one at a time."
msgid ""
"The following direct access storage devices (DASD) are available. Please "
"select each device you want to use one at a time."
msgstr ""
"Următoarele Dispozitive de stocare cu acces la disc (DASD) sunt disponibile. "
"Vă rugăm să alegeți pe rând fiecare dispozitiv pe care doriți să-l folosiți."

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

Re: vimdiff-like highlighting within the same file?

On Wed, June 30, 2010 10:52 am, Andrei Popescu wrote:
> I'm trying to add new features to vim's handling of .po files. How could
> I highlight the differences between the current msgid and the previous
> one?

I don't understand your question. Can you elaborate, on what the file
looks like and where the previous message id comes from? Please show a
sample file, with which we can see your problem.

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

Re: vimdiff-like highlighting within the same file?

> I'd be grateful for any hints or RTFM pointing to the right FM, because
> I have no idea where to start.

I don't know details. I'd guess that the highlighting is implemented
somewhere in Vims C code. But I don't know for sure.

You can always write a script which creates two files you can diff then.

If you add file:line locations you can jump to the original source file
using gf fast. (Jump back by using ctrl-^). Maybe this is a bearable workaround.

Example

tmp-file1:

goto: your.po:20
msgid ""
"The following disk access storage devices (DASD) are available. Please "
"select each device you want to use one at a time."
> msgid ""

goto: your.po:20
tmp-file2:
> "The following direct access storage devices (DASD) are available. Please "
> "select each device you want to use one at a time."

Then you can diff both tmp files.

It should be easy to create those tmp files using Vim script.

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

Re: question about lua source navigation

X Heruacles wrote:

> I'm just learning lua and I use vim to navigate some lua projects. I  use
> ctags to generate tags using a map:
>>
>> map <F12>  <Esc>:!ctags -R .<CR>
>
> but it rarely helps. When I want to jump to some function definition, it
> always errs. Then I checked the generated tag and it seems fine. So my
> question is just is there a better way to navigate lua project?(esp. jumping
> to function definition?)

What error number do you get?
Does adding colon character to 'iskeyword' helps? :set iskeyword+=:

-- Dominique

--
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

vimdiff-like highlighting within the same file?

Hello,

I'm trying to add new features to vim's handling of .po files. How could
I highlight the differences between the current msgid and the previous
one?

#, fuzzy
#| msgid ""
#| "The following disk access storage devices (DASD) are available. Please "
#| "select each device you want to use one at a time."
msgid ""
"The following direct access storage devices (DASD) are available. Please "
"select each device you want to use one at a time."
msgstr ""
"Următoarele Dispozitive de stocare cu acces la disc (DASD) sunt disponibile. "
"Vă rugăm să alegeți pe rând fiecare dispozitiv pe care doriți să-l folosiți."

I'd be grateful for any hints or RTFM pointing to the right FM, because
I have no idea where to start.

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

Re: question about lua source navigation

thanks Gary. Then I show the code here:

the generated tag has a line looks like this:

TaskHandler.prizeTask .\init\taskHandler.lua /^function TaskHandler.prizeTask(plr, task)$/;" f

and I have a function:

function Task:succeed()

debug_log("Task:succeed")

self.isSucceed = true

TaskHandler.prizeTask(self.owner, self)

self:eventOnSuccess()

if self.spanTimerId > 0 then self:clearSpanTimer() end

self.owner:addFinishedTask(self)

if self.entry.type == taskType.TASK_TYPE_MAIN then

self.owner:setSaveRecord("MainTask", self:getId(), 0)

else

end

if self.entry.nexttask ~= nil and self.entry.nexttask ~= 0 then

debug_log("self.owner:addTask")

self.owner:addTask(self.entry.nexttask)

end

end

 

in the file task.lua in the subdirectory of where the tags file lies. While my cursor on "prizeTask", I press Ctrl-], only to find it shows me an error that can't find the tag: prizeTask. So it is.

On Wed, Jun 30, 2010 at 3:42 PM, Gary Johnson <garyjohn@spocom.com> wrote:

On 2010-06-30, X Heruacles wrote:
> I'm just learning lua and I use vim to navigate some lua projects. I  use ctags
> to generate tags using a map:
>
>     map <F12>  <Esc>:!ctags -R .<CR>
>
> but it rarely helps. When I want to jump to some function definition, it always
> errs. Then I checked the generated tag and it seems fine. So my question is
> just is there a better way to navigate lua project?(esp. jumping to function
> definition?)

I don't know what else might be available for navigating Lua, but
the ctags web page at SourceForge says that it understands Lua, and
you write that the tags appear fine, so I would suggest that you
find out why your Lua tags aren't working as you expect and fix that
problem.  If you post a short file containing Lua code and explain
what you do and what happens when you try to jump to a tag in that
code, we might be able to spot the problem and give you a solution.

Regards,
Gary

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--
You received this message 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

Re: percentage of vim users running python

Hi Ted,

Go for Python because VimL can be a lock-in (speed issues if you want to
do a lot).

Can you tell more about what you're going to implement?

Maybe you want to get some ideas from my sbt plugin:
www.github.com/MarcWeber/vim-addon-sbt

It mocks Vim functionality so that you can test it without Vim and use a
Python debugger etc. It also illustrates how to load an external .py
file (syntax highlighting, etc will be better then). Probably you
already know..

> vim. I also find that I tend more and more toward a functional
> programming style that doesn't work particularly well in vimscript.

:-). Vim does neither support Scala, F# nor Haskell. Maybe you should be
using lisp or scheme then.

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

Re: question about lua source navigation

On 2010-06-30, X Heruacles wrote:
> I'm just learning lua and I use vim to navigate some lua projects. I use ctags
> to generate tags using a map:
>
> map <F12> <Esc>:!ctags -R .<CR>
>
> but it rarely helps. When I want to jump to some function definition, it always
> errs. Then I checked the generated tag and it seems fine. So my question is
> just is there a better way to navigate lua project?(esp. jumping to function
> definition?)

I don't know what else might be available for navigating Lua, but
the ctags web page at SourceForge says that it understands Lua, and
you write that the tags appear fine, so I would suggest that you
find out why your Lua tags aren't working as you expect and fix that
problem. If you post a short file containing Lua code and explain
what you do and what happens when you try to jump to a tag in that
code, we might be able to spot the problem and give you a solution.

Regards,
Gary

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: percentage of vim users running python

On Jun 30, 3:20 am, Ted <cecinemapasdera...@gmail.com> wrote:
> Hello folks,
>
> I'm wondering if there are some figures somewhere that would provide
> some sort of estimate of the percentage of vim users who have python
> installed, or would be free of objections to installing it if a module
> required it.

Maybe you could make an estimate by looking at ratings/downloads of
some of the plugins that already use +python:

vimpdb http://www.vim.org/scripts/script.php?script_id=2043
postmail http://www.vim.org/scripts/script.php?script_id=2341
pysmell http://www.vim.org/scripts/script.php?script_id=2421
pyflakes http://www.vim.org/scripts/script.php?script_id=2441
vimuiex http://www.vim.org/scripts/script.php?script_id=2606
utilsnips http://www.vim.org/scripts/script.php?script_id=2715
conque http://www.vim.org/scripts/script.php?script_id=2771

Marko

--
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

Re: percentage of vim users running python

On Wed, June 30, 2010 6:05 am, sc wrote:
> i'd like to count myself among those who like a lean build
> with no extra languages compiled in and as few plugins running
> as possible
>
> whatever your modules do i would not consider them if they
> require a python enabled vim

Same is true for me. On windows, I don't even have Python installed
and wouldn't bother to install it just for a plugin. (Though, I'd like
to try out command-t[1], but even for that, I wouldn't install Ruby).

And on linux, it depends what build of vim I am using. Not all versions
are build with python/ruby/perl support and I usually can't rely on
having any interpreter available.

[1] http://www.vim.org/scripts/script.php?script_id=3025

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

Re: percentage of vim users running python

I think you need just release your utility program, if people really
want it, they will not mind installing python. I personally aren't a
fans of python and will not bother to use vim with python albeit
python is installed here in linux.

--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

--
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

question about lua source navigation

I'm just learning lua and I use vim to navigate some lua projects. I  use ctags to generate tags using a map:

map <F12>  <Esc>:!ctags -R .<CR>

but it rarely helps. When I want to jump to some function definition, it always errs. Then I checked the generated tag and it seems fine. So my question is just is there a better way to navigate lua project?(esp. jumping to function definition?)

--
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

Re: percentage of vim users running python

On Tuesday 29 June 2010 20:20:27 Ted wrote:

> I'm wondering if there are some figures somewhere that would
> provide some sort of estimate of the percentage of vim users
> who have python installed, or would be free of objections to
> installing it if a module required it. I'm working on some
> vim modules, to be released for general use, that are
> threatening to become pretty complicated, and would prefer to
> write them in python. Is it likely that this would lock out
> a significant portion of the vim user population? Is it
> frowned upon to use external languages in cases where it's
> not entirely necessary? Python is more or less ubiquitous on
> linux installs, but I don't feel like I could guess at how
> many vim users on other platforms would be unable or
> unwilling to install it.

i'd like to count myself among those who like a lean build
with no extra languages compiled in and as few plugins running
as possible

whatever your modules do i would not consider them if they
require a python enabled vim

sc

--
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

Re: percentage of vim users running python

On Tue, Jun 29, 2010 at 6:32 PM, AK <andrei.avk@gmail.com> wrote:
> On 06/29/2010 09:20 PM, Ted wrote:
> > I'm wondering if there are some figures somewhere that would provide
> > some sort of estimate of the percentage of vim users who have python
> > installed, or would be free of objections to installing it if a module
> > required it.  I'm working on some vim modules, to be released for
> > general use, that are threatening to become pretty complicated, and
> > would prefer to write them in python.  Is it likely that this would
> > lock out a significant portion of the vim user population?  Is it
> > frowned upon to use external languages in cases where it's not
> > entirely necessary?  Python is more or less ubiquitous on linux
> > installs, but I don't feel like I could guess at how many vim users on
> > other platforms would be unable or unwilling to install it.
> >
> > The modules themselves are relatively general purpose; my motivation
> > to code them in Python stems partly from this very generality: it's
> > advantageous to have that code available outside of the context of
> > vim.  I also find that I tend more and more toward a functional
> > programming style that doesn't work particularly well in vimscript.
>
> Do you mean Vim compiled with python or just python installed on the
> system? If I understand right, windown installer for Vim comes with
> python compiled into Vim. Same goes for Vim in Ubuntu. On other
> distributions, I'm not sure, I believe I heard that Redhat's Vim does
> not have Python compiled in.
>
> If you're using python from Vim, it might make sense to use compiled in
> interpreter because there's closer integration with Vim rather than
> outside interpreter. If you haven't done this already, read :help python.

The Windows build refers to a Python DLL and will load it if it can find
it. However, Python itself is not included with Windows Vim and must be
separately installed. It must also be the same version of Python (e.g.,
python26.dll) and the DLL must be in the search path, :h python-dynamic

The average Vim user on Windows is, I suppose, somewhat likely to already
have Python, and, if not, will likely be amenable to installing it
-- especially if it gets them some useful Vim extensions.
But this is all supposition; I know of no way to get meaningful numbers on this.
--
/George V. Reilly  george@reilly.org  Twitter: @georgevreilly
http://www.georgevreilly.com/blog  http://blogs.cozi.com/tech

--
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

Re: percentage of vim users running python

On 06/29/2010 09:20 PM, Ted wrote:
> Hello folks,
>
> I'm wondering if there are some figures somewhere that would provide
> some sort of estimate of the percentage of vim users who have python
> installed, or would be free of objections to installing it if a module
> required it.  I'm working on some vim modules, to be released for
> general use, that are threatening to become pretty complicated, and
> would prefer to write them in python.  Is it likely that this would
> lock out a significant portion of the vim user population?  Is it
> frowned upon to use external languages in cases where it's not
> entirely necessary?  Python is more or less ubiquitous on linux
> installs, but I don't feel like I could guess at how many vim users on
> other platforms would be unable or unwilling to install it.
>
> The modules themselves are relatively general purpose; my motivation
> to code them in Python stems partly from this very generality: it's
> advantageous to have that code available outside of the context of
> vim.  I also find that I tend more and more toward a functional
> programming style that doesn't work particularly well in vimscript.
>
> Cheers
> -Ted
>

Do you mean Vim compiled with python or just python installed on the
system? If I understand right, windown installer for Vim comes with
python compiled into Vim. Same goes for Vim in Ubuntu. On other
distributions, I'm not sure, I believe I heard that Redhat's Vim does
not have Python compiled in.

If you're using python from Vim, it might make sense to use compiled in
interpreter because there's closer integration with Vim rather than
outside interpreter. If you haven't done this already, read :help python.

   -ak

--
 Python plugins for vim: outliner, todo list, project manager, calendar,
 expenses tracker, sortable table, and more |
 http://lightbird.net/pysuite/

percentage of vim users running python

Hello folks,

I'm wondering if there are some figures somewhere that would provide
some sort of estimate of the percentage of vim users who have python
installed, or would be free of objections to installing it if a module
required it. I'm working on some vim modules, to be released for
general use, that are threatening to become pretty complicated, and
would prefer to write them in python. Is it likely that this would
lock out a significant portion of the vim user population? Is it
frowned upon to use external languages in cases where it's not
entirely necessary? Python is more or less ubiquitous on linux
installs, but I don't feel like I could guess at how many vim users on
other platforms would be unable or unwilling to install it.

The modules themselves are relatively general purpose; my motivation
to code them in Python stems partly from this very generality: it's
advantageous to have that code available outside of the context of
vim. I also find that I tend more and more toward a functional
programming style that doesn't work particularly well in vimscript.

Cheers
-Ted

--
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

Re: Conditional imap

>Ok, I admit, I don't understand, why you need to check for 3 columns in
>front of the cursor. But hey, if it works, I won't complain ;)

Well in the \[ or the $$ environment, I need to check, if there is a
delimiter one space in front of the cursor, a delimiter two before cursor
and a non-math environment before that. Thet's why I need to check 3 columns
before the cursor.
--
View this message in context: http://old.nabble.com/Conditional-imap-tp29008528p29027684.html
Sent from the Vim - General mailing list archive at Nabble.com.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Conditional imap

Hi gitterrost4!

On Di, 29 Jun 2010, gitterrost4 wrote:

> Indeed it was latex-suite overriding the map from my tex.vim file. I fixed
> this by appending the line
>
> exe 'source '.fnameescape('~/.vim/ftplugin/tex.vim')
>
> to the file $VIM/ftplugin/latex-suite/main.vim
>
> I do not know, if this could be solved better, but now it works...
>
> I also had to adapt the matching, because your suggestion would only match
> if the cursor was between math characters, but not if the cursor was at the
> end of the line or after a math delimiter. It now boiled down to:
>
> inoremap <expr> ( synIDattr(synID(line('.'), col('.')-1, 1),
> "name")=~"texMath" ? "\\left(" : synIDattr(synID(line('.'), col('.'), 1),
> "name")=~ "texMath" ? "\\left(" : synIDattr(synID(line('.'), col('.')-1, 1),
> "name")=~"Delimiter" ? synIDattr(synID(line('.'), col('.')-2, 1),
> "name")=~"Delimiter" ? synIDattr(synID(line('.'), col('.')-3, 1),
> "name")!~"texMath" ? "\\left(" : "(" : synIDattr(synID(line('.'),
> col('.')-2, 1), "name")!~"texMath" ? "\\left(" : "(" : "("

Ok, I admit, I don't understand, why you need to check for 3 columns in
front of the cursor. But hey, if it works, I won't complain ;)

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