You shouldn't really do this in gvim or vim, because Comic Sans is not a
monospaced font. Some GUIs will allow you to do it in gvim, though.
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
LOL, OK, fair enough. It's not well-defined, but it isn't unpredictable
or undesirable either. So it's not a bad kind of undefined.
Setting 'bt' to help manually won't be a problem, particularly as the
buffer will shortly be unloaded (when the window is changed to show a
real help buffer). Of course, things could be a little icky in the case
that a help topic doesn't exist.
Neither approach is ideal.
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
> How do you figure that? You can easily get multiple buffers with
> buftype=help perfectly naturally by splitting help windows and moving to
> new help topics, using commands like ctrl-w ctrl-], and so on, and Vim
> behaves perfectly normally and as expected.
Just point me where help describes which of multiple buffers with 'bt' set to
`help' will be used to open new help topic? Also note that ``:h 'bt''' says that
you are not supposed to set 'buftype' to `help' manually.
> Well, my set should definitely have been setl, but apart from that, I
> think it's still arguably a better approach.
I would have agreed with you if it was described in a documentation: your
solution should delete buffers on window close, while my won't.
Original message:
> >> You may want to change "&ft" (shortcut to "&filetype") to "&bt"
> >> (shortcut to "&buftype"), but I would use&ft because vim behavior
> >> when you have more then one buffer with 'buftype' set to `help' is
> >> undefined
>
> How do you figure that? You can easily get multiple buffers with
> buftype=help perfectly naturally by splitting help windows and moving to
> new help topics, using commands like ctrl-w ctrl-], and so on, and Vim
> behaves perfectly normally and as expected.
>
> >> (that is why I would have written `setl bt= | vert help
> >> subject' instead of suggested `vnew | set bt=help | help subject').
>
> Well, my set should definitely have been setl, but apart from that, I
> think it's still arguably a better approach.
>
> > The suggested pipe 'setl bt= | help' does indeed override Vim's miserly
> > behavior relative to help windows..
> >
> > Why?
>
> Because Vim identifies help windows by the buftype, so if you clear it,
> Vim no longer thinks it is a help window, so doesn't reuse it.
>
> I would advise against this, as it has other side effects, e.g. using
>
> :help in the existing window will not reuse it as desired, but open a
>
> new window. A few other help-window-specific behaviours will also not
> work on the old help window if you do this.
>
> > Another quick question.. in Vimscript, what is the natural idiom to code:
> >
> > if count == 0; do proc_0; fi
> > if count == 1; do proc_1; fi
> > if count> 1; do proc_n; fi
> >
> > Otherwise, is there a decent tutorial on how to write functions in Vim..?
>
> I'm not sure Vimscript has any natural idioms! You will probably get a
> whole bunch of opinions on how best to do anything. Quite possibly the
> best idiom is what seems most natural to you.
>
> But what you wrote above seems fine, though of course in Vimscript, the
> syntax is different:
>
> if count == 0 | call proc_0() | endif
> if count == 1 | call proc_1() | endif
> if count> 1 | call proc_n() | endif
>
> Ben.
> The suggested pipe 'setl bt= | help' does indeed override Vim's miserly
> behavior relative to help windows..
>
> Why?
Because vim uses 'buftype' to check whether some buffer is a help buffer. If you
write your own plugin and edit a help file, then you won't have 'buftype' set to
`help'.
> Another quick question.. in Vimscript, what is the natural idiom to code:
>
> if count == 0; do proc_0; fi
> if count == 1; do proc_1; fi
> if count > 1; do proc_n; fi
What language is this? On zsh I would have written this as
if (( count==0 )) ; then proc_0
elif (( count==1 )) ; then proc_1
elif (( count>1 )) ; then proc_n
fi
. In vim:
if count==0 | proc_0
elseif count==1 | proc_1
elseif count>1 | proc_n
endif
(Note that `count' is alias to read-only variable v:count that is keeped for
backwards compatibility, so you may not use it in your script with other
meaning.)
Original message:
> On Mon, Feb 28, 2011 at 03:53:27PM EST, ZyX wrote:
> > > How could I figure out the number of help windows in the current tab?
> > >
> > let helpcount=len(filter(range(1, winnr('$')),
> > 'getbufvar(winbufnr(v:val), "&ft")==#"help"'))
>
> Works out of the box. :-)
>
> > You may want to change "&ft" (shortcut to "&filetype") to "&bt"
> > (shortcut to "&buftype"), but I would use &ft because vim behavior
> > when you have more then one buffer with 'buftype' set to `help' is
> > undefined (that is why I would have written `setl bt= | vert help
> > subject' instead of suggested `vnew | set bt=help | help subject').
>
> The suggested pipe 'setl bt= | help' does indeed override Vim's miserly
> behavior relative to help windows..
>
> Why?
>
> Another quick question.. in Vimscript, what is the natural idiom to code:
>
> if count == 0; do proc_0; fi
> if count == 1; do proc_1; fi
> if count > 1; do proc_n; fi
>
> Otherwise, is there a decent tutorial on how to write functions in Vim..?
>
> Thanks a bunch,
>
> cj
> Another quick question.. in Vimscript, what is the natural idiom to
> code:
>
> if count == 0; do proc_0; fi
> if count == 1; do proc_1; fi
> if count > 1; do proc_n; fi
In what language is that a natural idiom? Is it...
... a for loop? VimL has :for loops if you're just trying to call a
function for 0 through 'count':
" +1 makes it [0,count] inclusive
for i in range(count+1)
call Proc(i)
endfor
See:
:help range()
:help :for
... something recursive?
fun! Factorial(count)
if a:count < 2
return 1
endif
return a:count * Factorial(a:count - 1)
endfun
:help function-argument
... a 'case' or 'select' statement?
Vim doesn't have that, so resort to if ... elseif ... elseif ... else ...
endif:
if count == 0
" do Proc_0 here
elseif count == 1
" do Proc_1 here
else
" do Proc_n here
endif
... some kind of "call a function with a user-specified name" or
dispatch table? Vim handles "symbolic references" or "variable
variables" (probably more names in other langs):
if exists('*Proc_'.count)
call Proc_{count}()
else
echo "Oh no, there's no Proc_".count."() defined"
endif
See:
:help exists()
:help :call
:help curly-braces-names
> Otherwise, is there a decent tutorial on how to write functions in
> Vim..?
:help script
--
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
I've done something like this in the past where I've modified my
buffer such as you have with
:%s/.*/:&d
which leaves the buffer looking like
:%g/pattern_a/d
:%g/pattern_b/d
...
with leading colons and trailing "d" commands.
You can then yank that entire buffer's contents and execute it as
a macro:
:%y
@"
or if you want to name it,
:%ya
@a
You can also modify registers by using the "@" notation:
:let @a='hello' . @a . 'world'
-tim
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
You can enter any register onto the commandline by using ^R, so just do
this if you want (after pressing a, the contents of the register will
appear on the commandline)
:^Rad
If you prefer, you could issue a command to append a d to the register
and then execute the modified register
:let @a.="d"
:@a
And there are other possibilities too....
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
How do you figure that? You can easily get multiple buffers with
buftype=help perfectly naturally by splitting help windows and moving to
new help topics, using commands like ctrl-w ctrl-], and so on, and Vim
behaves perfectly normally and as expected.
>> (that is why I would have written `setl bt= | vert help
>> subject' instead of suggested `vnew | set bt=help | help subject').
Well, my set should definitely have been setl, but apart from that, I
think it's still arguably a better approach.
> The suggested pipe 'setl bt= | help' does indeed override Vim's miserly
> behavior relative to help windows..
>
> Why?
Because Vim identifies help windows by the buftype, so if you clear it,
Vim no longer thinks it is a help window, so doesn't reuse it.
I would advise against this, as it has other side effects, e.g. using
:help in the existing window will not reuse it as desired, but open a
new window. A few other help-window-specific behaviours will also not
work on the old help window if you do this.
> Another quick question.. in Vimscript, what is the natural idiom to code:
>
> if count == 0; do proc_0; fi
> if count == 1; do proc_1; fi
> if count> 1; do proc_n; fi
>
> Otherwise, is there a decent tutorial on how to write functions in Vim..?
I'm not sure Vimscript has any natural idioms! You will probably get a
whole bunch of opinions on how best to do anything. Quite possibly the
best idiom is what seems most natural to you.
But what you wrote above seems fine, though of course in Vimscript, the
syntax is different:
if count == 0 | call proc_0() | endif
if count == 1 | call proc_1() | endif
if count> 1 | call proc_n() | endif
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
I have thought to do this as follows:
-- yank a list command into a register "ayy
-- execute the command :@a"
-- inspect the lines as they are listed
Then if I'd now like to delete this set of lines, I'd like to append a d
to the contents of register a changing it from a list to a delete command,
and execute the command.
So how do I _easily_ modify, edit, the contents of a register?
I'd like something simpler than loading a list command into the clipboard
via highlighting and ^C followed by :^V and if choosing to delete
then :^Vd ???
--
Rostyk
--
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
> > How could I figure out the number of help windows in the current tab?
> let helpcount=len(filter(range(1, winnr('$')), 'getbufvar(winbufnr(v:val), "&ft")==#"help"'))
Works out of the box. :-)
> You may want to change "&ft" (shortcut to "&filetype") to "&bt"
> (shortcut to "&buftype"), but I would use &ft because vim behavior
> when you have more then one buffer with 'buftype' set to `help' is
> undefined (that is why I would have written `setl bt= | vert help
> subject' instead of suggested `vnew | set bt=help | help subject').
The suggested pipe 'setl bt= | help' does indeed override Vim's miserly
behavior relative to help windows..
Why?
Another quick question.. in Vimscript, what is the natural idiom to code:
if count == 0; do proc_0; fi
if count == 1; do proc_1; fi
if count > 1; do proc_n; fi
Otherwise, is there a decent tutorial on how to write functions in Vim..?
Thanks a bunch,
cj
--
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
--
View this message in context: http://vim.1045645.n5.nabble.com/mapping-F3-to-map-q-B-tp3392648p3404140.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
> How could I figure out the number of help windows in the current tab?
let helpcount=len(filter(range(1, winnr('$')),
\'getbufvar(winbufnr(v:val), "&ft")==#"help"'))
You may want to change "&ft" (shortcut to "&filetype") to "&bt" (shortcut to
"&buftype"), but I would use &ft because vim behavior when you have more then
one buffer with 'buftype' set to `help' is undefined (that is why I would have
written `setl bt= | vert help subject' instead of suggested `vnew | set bt=help
| help subject').
Original message:
> On Sun, Feb 27, 2011 at 06:01:23PM EST, Ben Schmidt wrote:
> >> When I am editing a file rather than displaying a help subject, I issue
> >> a ':vhl topic' command (with vhl mapped to ':vertical help', and Vim
> >> vertically splits the screen and displays the topic's help file in
> >> a separate window, so that the buffer I am editing remains visible.
> >>
> >> Unfortunately, when I already have a help window open in the current
> >> tab, this does not work.
> >
> > This is a little more complicated, but I'm sure you can :map or :command
> >
> > or :cabbrev it:
> > :vnew | set bt=help | help subject
>
> Thanks, Ben.. The bt=help is probably what I was looking for.
>
> I'll set this up via a custom :Help command that will additionally take
> care of removing the scratch buffers. And possibly add some logic that
> counts the number of help windows in the current tab.. if zero: create
> a new tab, if one: do a vertical split on the current tab.. and if two
> or more... do horizontal splits.
>
> Not very flexible but it should cover my limited needs.
>
> How could I figure out the number of help windows in the current tab?
>
> Thanks,
>
> cj
>> When I am editing a file rather than displaying a help subject, I issue
>> a ':vhl topic' command (with vhl mapped to ':vertical help', and Vim
>> vertically splits the screen and displays the topic's help file in
>> a separate window, so that the buffer I am editing remains visible.
>>
>> Unfortunately, when I already have a help window open in the current
>> tab, this does not work.
>
> This is a little more complicated, but I'm sure you can :map or :command
> or :cabbrev it:
>
> :vnew | set bt=help | help subject
Thanks, Ben.. The bt=help is probably what I was looking for.
I'll set this up via a custom :Help command that will additionally take
care of removing the scratch buffers. And possibly add some logic that
counts the number of help windows in the current tab.. if zero: create
a new tab, if one: do a vertical split on the current tab.. and if two
or more... do horizontal splits.
Not very flexible but it should cover my limited needs.
How could I figure out the number of help windows in the current tab?
Thanks,
cj
--
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
Use case:
$ vim -o /path/to/stuff/./app/models/blah.rb /path/to/other/project/./app/models/blee.rb
Then,
:e app/mod<Tab>/<Tab>
in either window will tab-complete filenames only within that project's
app/ subdir.
Unfortunately, at startup with the '-o' option, it seems as though the
act of :lcd'ing in one window (or buffer?) is causing the '/./' portion
of the filename in another window to be lost.
So, a simplified, but tested version of what I'm trying to do:
==> ~/.vim/plugin/dotted-dirs.vim <==
aug DottedLCD
au!
au BufReadPost * call DottedLCD(expand("<afile>"))
aug END
fun! DottedLCD(filename)
let parts = split(a:filename, '/\./')
if len(parts) > 1
echomsg parts[0]
endif
endfun
=====================================
$ mkdir -p /tmp/a/some/long /tmp/b/some/other
$ touch /tmp/a/some/long/directory.txt /tmp/b/some/other/hierarchy.txt
$ vim -o /tmp/a/./some/long/directory.txt /tmp/b/./some/other/hierarchy.txt
:messages
"/tmp/a/./some/long/directory.txt" 0L, 0C
/tmp/a
"/tmp/b/./some/other/hierarchy.txt" 0L, 0C
/tmp/b
But, if the 'echomsg parts[0]' line is changed to:
exe ":lcd ".fnameescape(parts[0])
The first file succeeds (:pwd reports /tmp/a), but the second file
doesn't. And the opened filename is reported in the :messages output
without the '/./':
:messages
"/tmp/a/./some/long/directory.txt" 0L, 0C
"/tmp/b/some/other/hierarchy.txt" 0L, 0C
In my initial attempt at a fix, I tried using BufReadCmd (and cribbing
NETRW's idiom of surrounding an executed ":e" with ":silent doau
BufRead{Pre,Post}"), but had the same issue.
I also tried splitting it into two portions. BufReadPost would setup a
buffer-local variable to hold the correct pre-/./ directory, and then
BufEnter would actually :lcd to that dir. But apparently the BufEnter
happens too quickly or the order isn't sufficiently different to matter.
Does anyone see what's happening? and/or a simple way around this? Is
there some variable that holds the originally-specified filename?
--
Thanks,
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
Currently he is running vim 6.4 on a SunOS 5.9 machine. I tried the
sunfreeware binary for vim 7.3, solaris 7 -- on his machine, but this version
of vim seemed to have problems drawing the screen and understanding termimfo.
> If it's really necessary to share the .viminfo file between different
> versions of Vim, I'm not sure what your best approach would be.
There is no need for this. What is needed is sharing viminfo between different
instances of vim. That is, he has 3 or 4 instances of vim running
simultaneously. Usually, one is actively running in the foreground and the
others are suspended processes.
Does my friend quit vim when quickly logging out of his remote connection? -
No he does not. He does use perhaps 100 maps and abbreviations in vim that he
is wedded to, and uses them to quit vim as well. I should examine these more
closely to see if there is some strangness about them.
--
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
Jean Johner wrote:
> Hello,
> Suppose the .f extension has been allocated to gvim.
>
> In Windows, double clicking on the "file1.f" file sitting in the
> "test_vim" directory results in opening file1.f with test_vim as
> working directory (for example using the file/open menu lists files in
> test_vim).
that's the intended behaviour -- see :help win32-startup.
> Doing the same in KDE 3.5 Konqueror file manager opens file1.f but the
> working directory is always the user's home directory.
>
> Does anybody know a way to solve this problem.
(The following is untested.) Put
au VimEnter * if expand('%') != '' | cd %:h | endif
in your ~/.vimrc.
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
> I know my pleas are getting old for you veterans. But I am trying to
> make .viminfo work for a blind friend, and he keeps getting more and
> more errors.
>
> I've scoured both the usual and unusual documentation, the scripts
> library, the web, and vim_use archives - and still can not find
> certain basic information about the .viminfo file, and how different
> versions of vim interact with it. The usual advice is to delete the
> file, losing all one's mark info., if it corrupts.
Sorry, didn't see this email before I responded to your other question.
In the case of trying to fix .viminfo corruption, direct examination or
modification of the file probably makes sense.
> Most error messages seem to be spawned by vim making a simple format
> error when writing this file. For example, an initial > ls left out of
> a line that specifies a new filname and path. Or, a tab is missing in
> setting a mark, i.e., there is a line like this
>
> z^I13^I2
>
> instead of,
>
> ^Iz^I13^I2
>
If it's really necessary to share the .viminfo file between different
versions of Vim, I'm not sure what your best approach would be.
If the synchronization of the file isn't important though, you could at
least avoid the different-version corruption (if indeed that's what's
happening) by specifying the .viminfo file on Vim invocation.
E.g. on a system with Vim 7+, use something like:
alias vim='vim -i /path/to/viminfo-for-vim7'
On a system with a different Vim:
alias vim='vim -i /path/to/viminfo-for-vim6'
(assuming Vim 6 supports '-i', or just use the default location for the
lowest version)
Sorry to not have a better solution.
--
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
> I just know many will think Im wrong, but I never had much use of the
> jumplist. Any way to tell vim to remember marks between sessions but
> not jumps? Jumps occupy a lot of lines of info. I never use. Only way
> I can think of is to menually edit .viminfo and remove the + lines.
>
> Lord - what if I defined an autocommand to delete + lines in .viminfo,
> whenever I exited vim? Would paralel universes clash?
Why do you want to do this? What benefit do you gain from removing the
jump info from .viminfo? I rarely use the jumplist myself, but keeping
it in the file for the last 100 edited files only occupies about 3KB
(.viminfo total ~18KB, lines starting with spaces then '+', about 3KB).
If you're doing it to keep .viminfo somehow "cleaner", I again question
your motives. There might be another problem you're approaching from
the wrong direction (or at least an "odd" one). Manually inspecting or
modifying .viminfo is usually not the right approach.
--
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
Yes. I quickly tested what I suggested, and it worked for me. I can even
successfully do something hideously tangled like this:
:map a :map s :echomsg "Hello!"<lt>CR><CR>:map d :unmap s<lt>CR><CR>
If you type 'a' then 's' and 'd' are mapped, and after having done so,
's' prints a message, and 'd' unmaps 's'.
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
Has anyone confirmed that they are able to do a mapping, as part of a
mapping? That seems to be the root of the problem here.
--
View this message in context: http://vim.1045645.n5.nabble.com/mapping-F3-to-map-q-B-tp3392648p3402672.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
> > Doing the same in KDE 3.5 Konqueror file manager opens file1.f but the
> > working directory is always the user's home directory. [...]
>
> http://vim.wikia.com/wiki/Set_working_directory_to_the_current_file
I have the same problem with Gnome/Nautilus. But the suggestion »autochdir«
does not not really solve the problem. It always changes the working directory
to the directory of the file in the current buffer.
This can be rather annoying. Imagine you have the following structure.
file1
dirA/file2
dirB/file3
With autochdir set you open file1. Then you open file2 (:e dirA/file3), after
that you want to edit file3 and :e dirB/file3 fails because the working
directory changed to dirA. This is very confusing. You never know in which
direcotry you are.
The OP (and I, too) look for a solution to open file1 in the file manager and
make this direcotry the current directory instead of $HOME. Before I used
Fluxbox/Thunar with the correct behaviour.
Marco
--
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
I think this is what is baffling us. I'm not sure anyone else has
experienced or reported such a problem. Our viminfo files are written
and read just fine unless we experience something like a hardware
failure.
I wonder if it's something to do with how Vim is quit if/when the modem
hangs up (e.g. if it hangs up unexpectedly). Maybe vim is signalled to
quit, starts writing viminfo, and then is killed before it finishes.
That might explain it.
If we had a better idea what was causing the problem, we'd be in a much
better position to solve it.
What version of Vim is running? I suppose you're not in a position to
run a different version, either?
> One possibility: my friend has the (bad) habit of using unix to switch
> between edited files. That is, he runs many instances of vim,
> suspending one with Ctrl-Z to leave one file, and using the shell's
> jobs and fg command to enter another file, by bring a suspended vim
> back to life in the foreground.
I don't think this would be the problem. I do that kind of thing all the
time, too. Vim is meant to work in situations like that.
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
> My first thought would be whether the media he is writing to is beginning to
> die.
> The user isn't using some kind of removable media, which is being removed
> too early?
Bad or portable media is not the culpret. My friend logs into a powerful
networked computer system at Univesity of New York at Buffalo, where he is a
prefessor Emeritus. Vim is run on the Buffalo computers. True, he still uses
dos, an ancient IBM PC monitor, and a dialup modem to log in. Buffalo sets his
term to vt102, and keystrokes seem to be interpreted correctly by the Buffalo
computer.
> It may be something for which you'd need to read the source, but before we
> get to that.
There is a syntax highlight file, viminfo.vim which highlights lines in error.
It does this by simply checking for all types of lines that are OK. There is
no checking for which lines should go where, nor any coordination with the
actual error messages in the code.
> the user may be prepared to add f0 to the viminfo option
> and suppress saving of filenames, but that's an annoying work around.
Unfortunately, the only thing, so far, my blind friend likes about viminfo, it
the ability to save persistent (lowercase) marks in files, between sessions.
> also encoding issues I think would only come up if the user is editing
> something like raw Braille.
Encoding is not the problem. term is set to utf-8, and he edits only pure
ascii text, containing the old-style troff, ascii markup codes (e.g., .ce,
\fB etc.).
> What I saw in the docs says it attempts to merge the file,
The docs are not specific, but: When vim writes to viminfo it seems to add new
info. if it is not there (e.g., marks for a new filename, jumplist for a new
filename), and overwrite mark information for the A-Z and a-z marks, if the
user has changed these marks. It does not update any other old information.
For instance, the jumplist lines for a file previously edited, stay there
forever - until .viminfo is deleted. If not changed, alphbetic marks for old
files also stay forever.
I know of no vim aware scripts that update viminfo, when a file is renamed,
deleted or moved.
It is not clear if vim counts `+' lines of the jumplist towards the limits set
for marks. Too bad if it does, since there are often hundreds of jump lines!
> you mean that there are more errors despite your corrections.
Yes, I manually correct the viminfo file, and within days or hours another
format error occurs, within a line of viminfo. My friend also reports that
line numbers for named marks are not correctly set, as he edits. Somehow, vim
is writing bad lines to viminfo, when my friend quits vim.
One possibility: my friend has the (bad) habit of using unix to switch between
edited files. That is, he runs many instances of vim, suspending one with
Ctrl-Z to leave one file, and using the shell's jobs and fg command to enter
another file, by bring a suspended vim back to life in the foreground.
Off hand I do not see how this would confuse viminfo writes, although running
many instances like these in a console is asking for trouble.
--
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
This is a little more complicated, but I'm sure you can :map or :command
or :cabbrev it:
:vnew | set bt=help | help subject
It basically does a vertical split and avoids reusing an existing help
window by setting the buffer type so Vim thinks you're already reading
help in that window.
Is that what you were after?
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
Here'as a typical scenario: I am reading the help file for a given topic
such as ':help folding' and I want to split the screen vertically so
that I can for instance take a look at relevant Vim options - foldclose,
foldcolumn.. foldopen.. etc.
Vim's behavior when I issue a ':help topic' Ex-mode command is to check
whether there already is an ft=help window open in the current tab, and
if so.. reuse this window to display the requested help.
When I am editing a file rather than displaying a help subject, I issue
a ':vhl topic' command (with vhl mapped to ':vertical help', and Vim
vertically splits the screen and displays the topic's help file in
a separate window, so that the buffer I am editing remains visible.
Unfortunately, when I already have a help window open in the current
tab, this does not work.
If I try..
:vertical split +help topic
.. Vim splits the screen.. creates an empty buffer named 'topic'.. and
displays the new help in the original ft=help window.
If I do a...
:vertical split help topic
.. Vim considers 'help' and 'topic' are file names and gives an 'E172:
Only one file name allowed' error message..
I am able to work around this dilemma like so:
:tab help " creates a tab with full-screen help
:help topic " displays topic's help
:vertical split +help " splits screen, displays help & focuses the
" new sub-window
:help option " displays help for topic-related option
The result of the above is that the Vim window is split down the middle
with e.g. the discussion of 'folding' on the left and the 'foldopen'
help on the left, exactly what I need.
This is just an example.. there are many other scenarios where I find it
considerably more convenient to split the window than use tags and start
yet another descent into hypertext hell. :-)
In any event, what I do after this, is that when I'm done reading the
'auxiliary help', I issue a 'CTRL-W w' and I am back to the main topic
and continue reading. And when I run into something else tha I do not
'understand well enough', I issue another 'CTRL-W w' to switch to my
second help sub-window and issue another :help command to investigate.
And when done with it, another 'CTRL-W w' brings me back to where I was
and I can continue reading in sequence. etc..
Could anyone suggest a better help subwindow management scheme..?
Thanks,
cj
--
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
Please open a file1.
Open a file file2 in a new tab.
Use the File/Close menu to close file2 tab.
The tab is not closed, instead an empty buffer with name "No Name"
replaces file2.
So the File/Close menu is not a synonym for :close.
Is it a feature or a bug ?
Best regards,
Jean Johner
--
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
> Hello,
> Suppose the .f extension has been allocated to gvim.
>
> In Windows, double clicking on the "file1.f" file sitting in the
> "test_vim" directory results in opening file1.f with test_vim as
> working directory (for example using the file/open menu lists files in
> test_vim).
>
> Doing the same in KDE 3.5 Konqueror file manager opens file1.f but the
> working directory is always the user's home directory.
>
> Does anybody know a way to solve this problem.
>
> Best regards,
>
> Jean Johner
http://vim.wikia.com/wiki/Set_working_directory_to_the_current_file
--
Robert
--
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
In Windows, double clicking on the "file1.f" file sitting in the
"test_vim" directory results in opening file1.f with test_vim as
working directory (for example using the file/open menu lists files in
test_vim).
Doing the same in KDE 3.5 Konqueror file manager opens file1.f but the
working directory is always the user's home directory.
Does anybody know a way to solve this problem.
Best regards,
Jean Johner
--
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
> French spelling checker of Vim-7.3.135 incorrectly highlights "L'Italie"
> as a mistake at the beginning of a sentence such as:
>
> L'Italie est un pays européen. [fr]
>
> Pressing z= suggests "l'Italie" but that's incorrect at the beginning
> of the sentence.
>
> It is a systematic problem with all words starting with L'+Uppercase
> such as: L'Amérique, L'Angleterre, etc.
>
> ":spelldump" shows words such as:
>
> l'Amérique
> l'Angleterre
> l'Italie
>
> I see the same problem with the Italian spelling checker: "L'Italia"
> is incorrectly marked as a mistake in a correct sentence such as:
>
> L'Italia è un Paese europeo. [it]
>
> I suspect that the problem comes from Vim rather than from the
> the French or Italian myspell files:
>
> vim/runtime/spell/it/it_IT.dic contains:
>
> Italia/TUqrs
>
> vim/runtime/spell/it/it_IT.aff contains:
>
> MIDWORD '
>
> ...snip...
>
> PFX T 0 l' [aeiouhAEIOUH]
> PFX T a l'A a
> PFX T e l'E e
> PFX T i l'I i
> PFX T o l'O o
> PFX T u l'U u
> PFX T h l'H h
I vagueally recall doing something for this. In Dutch it's slightly
different. This may require a flag in the .aff file to tell the spell
checker what the rule is at the start of the sentence for letters with a
single quote.
--
ARTHUR: Will you ask your master if he wants to join my court at Camelot?!
GUARD #1: But then of course African swallows are not migratory.
GUARD #2: Oh, yeah...
GUARD #1: So they couldn't bring a coconut back anyway...
The Quest for the Holy Grail (Monty Python)
/// 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
French spelling checker of Vim-7.3.135 incorrectly highlights "L'Italie"
as a mistake at the beginning of a sentence such as:
L'Italie est un pays européen. [fr]
Pressing z= suggests "l'Italie" but that's incorrect at the beginning
of the sentence.
It is a systematic problem with all words starting with L'+Uppercase
such as: L'Amérique, L'Angleterre, etc.
":spelldump" shows words such as:
l'Amérique
l'Angleterre
l'Italie
I see the same problem with the Italian spelling checker: "L'Italia"
is incorrectly marked as a mistake in a correct sentence such as:
L'Italia è un Paese europeo. [it]
I suspect that the problem comes from Vim rather than from the
the French or Italian myspell files:
vim/runtime/spell/it/it_IT.dic contains:
Italia/TUqrs
vim/runtime/spell/it/it_IT.aff contains:
MIDWORD '
...snip...
PFX T 0 l' [aeiouhAEIOUH]
PFX T a l'A a
PFX T e l'E e
PFX T i l'I i
PFX T o l'O o
PFX T u l'U u
PFX T h l'H h
Regards
-- 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
I assume you are using vim in terminal, but I think this also works
for vim-app and MacVim. I am using terminal vim.
These work fine for the "window" height, that is the vim window WITHIN
the limit of the terminal window.
ctrl-w -
ctrl-w + (yes use shift =)
These work for changing the width WITHIN the limit of the terminal
window.
ctrl-w <
ctrl-w >
If you want the vim and terminal "window" to change height use:
" set an absolute size
set lines=44
" one side makes you smaller, the other taller
" make the window 4 lines smaller
set lines-=4
" make the window 4 lines taller
set lines+=4
-Bill
--
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
> I know my pleas are getting old for you veterans. But I am trying to make
Only rejoined the list recently, but searching doesn't show up any replies
to your messages about this.
> .viminfo work for a blind friend, and he keeps getting more and more errors.
Increasing? This seems a bit odd. My first thought would be whether
the media he is writing to is beginning to die.
>
> I've scoured both the usual and unusual documentation, the scripts library,
> the web, and vim_use archives - and still can not find certain basic
> information about the .viminfo file, and how different versions of vim
> interact with it. The usual advice is to delete the file, losing all one's
> mark info., if it corrupts.
Agrees with my searches as well. It may be something for which you'd need
to read the source, but before we get to that....
>
> Most error messages seem to be spawned by vim making a simple format error
> when writing this file. For example, an initial > ls left out of a line that
I'm thinking that 'ls' should be 'is' there...
> specifies a new filname and path. Or, a tab is missing in setting a mark,
For the first case, the user may be prepared to add f0 to the viminfo option
and suppress saving of filenames, but that's an annoying work around.
> i.e., there is a line like this
>
> z^I13^I2
>
> instead of,
>
> ^Iz^I13^I2
I was going to suggest the c flag, in order to fix encoding issues, but
missing out a tab is unlikely to be that. Also encoding issues I think
would only come up if the user is editing something like raw Braille,
stored however that is. I've seen people post that to blindness lists
in the past, and it looks rather odd. I could imagine Vim treating it
as a different encoding.
>
> When I manually edit each wrong viminfo line, the error messages disappear.
> Has anyone written a description of the required format for this file? Is
> there some script that can check the file for format errors and/or fix them?
>
> Apparently, vim does not dynamically check much for the current state of a
> file when it updates (overwrites) viminfo.
What I saw in the docs says it attempts to merge the file, which may explain
accumulation of errors, unless you mean that there are more errors despite
your corrections.
The user isn't using some kind of removable media, which is being removed
too early? The r flag would prevent viminfo being written if that were
the case.
Hugh
--
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
I've scoured both the usual and unusual documentation, the scripts library,
the web, and vim_use archives - and still can not find certain basic
information about the .viminfo file, and how different versions of vim
interact with it. The usual advice is to delete the file, losing all one's
mark info., if it corrupts.
Most error messages seem to be spawned by vim making a simple format error
when writing this file. For example, an initial > ls left out of a line that
specifies a new filname and path. Or, a tab is missing in setting a mark,
i.e., there is a line like this
z^I13^I2
instead of,
^Iz^I13^I2
When I manually edit each wrong viminfo line, the error messages disappear.
Has anyone written a description of the required format for this file? Is
there some script that can check the file for format errors and/or fix them?
Apparently, vim does not dynamically check much for the current state of a
file when it updates (overwrites) viminfo.
--
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
I don't have a mac but I think this is the type of action that
should be mapped either to f-key or alt- or ctrl- combo because
you will often want to change win size by 10 or more lines,
and it's far easier to do when you can hold a modifier key
and keep hitting the shortcut, or even holding it for large
resizes.
-Rainyday
--
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
That, in my opinion, is the main question. I know nothing about the Vim
code, and if implementing it would be as difficult as integrating the
bidi algorithm, then there is obviously no point in doing it. The way I
imagined things work is more or less:
1. The user performs some operation, such as adding text or moving the
cursor. The operation is logical, so no bidi considerations are
involved, and no change to the code is needed. At the end of this
stage, Vim has a logical representation of the new text, and the
location of the cursor in terms of the logical text
2. Vim prepares to display the new text (and the new cursor position).
Part of this process would be to determine the syntax regions, and
there would be a new bit here where the direction of the text is
stored
3. Vim actually displays the text. At this point, Vim would need to take
into account the direction, but the information is already available,
and no extra algorithm is required.
So, if things are as I imagine, there would only be a small change to
the syntax highlighting, and the rest in the gui part.
>
> > I also don't see that what I'm suggesting is a hack or a workaround.
>
> I think it is a hack because which direction text should be displayed
> really has nothing to do with syntax regions conceptually. It is about
> what language the text is in, what script the characters in the text
> come from, etc..
>
Well, this is becoming a bit theoretical, but I don't see why the
direction of the text should be inherently determined by the character
set. Imagine that people in Australia decide to start writing from right
to left (but maintain the same alphabet). Then you would have to insert
direction marking in a logical text to determine the text direction (and
consequently could use these markings to define syntax regions). It is
just a (fortunate) coincidence that the direction of the text is
determined by the alphabet.
> >>> If this can be done, I think it will solve most practical
> >>> problems,
> >>> since when editing latex, for example, text in different direction will
> >>> appear in particular commands or environments.
>
> My perspective is a bit different. When I want bidi text, it's not
> because I have text of one language embedded in particular regions of a
> program or script or markup. It's because I'm writing in multiple
> languages. I would have thought this, too, was quite common, i.e. simply
> editing text.
>
Again, I agree that full bidi support would be better, and indeed there
are cases (as in writing emails) when there is no particular markup is
already available. But I would happily pay the price of explicitly
adding Right-Left marks to make use of an existing partial
implementation, rather than have nothing at all.
Thanks,
Moshe
--
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
> Am 25.02.2011 21:12, schrieb sc:
> > all--
> >
> > the help for CTRL-^ says it is the same as e #, but it is
> > clearly different when the alternate buffer is a Scratch
> > buffer -- if you try to use e # (or bp) you get the error
> >
> > E499: Empty file name for '%' or '#'...
> Try :b # instead.
dang if that doesn't work too, in addition to looking more
elegant than the executed normal
thanx andy!
i love this list!
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
CLI Vim depends on the font(s) of the containing console, so it
depends on the font you're using in cmd.exe/xterm/rxvt/Terminal/etc.
For GUI Vim, you can set 'guifont':
:set guifont=?
[snipping verbose, useless, irrelevant, and non-threading digest]
Please note that EVERY post on the list reminds you not to
top-post:
>> Do not top-post! Type your reply below the text you are replying to.
-tim
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Try :b # instead.
--
Andy
--
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
In an expression @ is used as a prefix for registers. So you can use @"
(or @@ if you prefer) for the last yank/delete, or just @0 for the last
yank. E.g.
let findstring = inputdialog('Search string under source\ and include\
',@")
:help @r
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
How can I change my vim's fonts(CLI)?
Best regards,
Tony
On Sat, 2011-02-26 at 06:06 +0000, vim_use+noreply@googlegroups.com
wrote:
> Today's Topic Summary
> Group: http://groups.google.com/group/vim_use/topics
>
> * Remember marks but Not Jumps? [1 Update]
> * inputdialog default string [1 Update]
> * Is it possible to automatically identify the current line with
> [I? [4 Updates]
> * Opening a line with vimscript - autoindent ignored [2 Updates]
> * bidi in vim [1 Update]
> * bp and CTRL-^ [3 Updates]
> * Multiple Substitutes for 'includeexpr' [1 Update]
> * Question about omnicppcomplete [1 Update]
> * Create mapping with '-c' command-line option [2 Updates]
> * Why doesn't the cursor go beyond the last character in Vim
> when in command mode? [3 Updates]
> * Trailing white space in multi line comments (ft=php) [3
> Updates]
> * Any dict plugin to translate English to Japanese? [8 Updates]
> Topic: Remember marks but Not Jumps?
> howard Schwartz <howardb21@gmail.com> Feb 25 08:37PM -0800 ^
>
> I just know many will think Im wrong, but I never had much use
> of the
> jumplist. Any way to tell vim to remember marks between
> sessions but not
> jumps? Jumps occupy a lot of lines of info. more...
>
> Topic: inputdialog default string
> "Michael(Xi Zhang)" <michaelxmail@gmail.com> Feb 25 09:35PM
> -0700 ^
>
> Hi,
>
> I use inputdialog in the following way:
>
> let findstring = inputdialog('Search string under source\ and
> include\
> ',expand('<cword>'))
> execute 'vimgrep ' '/'.findstring.'/' '..\include\*.h more...
>
> Topic: Is it possible to automatically identify the current line with
> [I?
> Shawn Young <spacephys@gmail.com> Feb 25 09:05AM -0700 ^
>
> Hello,
>
> I apologize if this has already been answered but a search
> using "[I"
> in the archive had zero hits, and a google search just sent me
> to vim
> oriented web pages; I'm not sure if there is a more...
>
> "Michael(Xi Zhang)" <michaelxmail@gmail.com> Feb 25 12:44PM
> -0700 ^
>
>
> > --
> > Shawn Young
> > <http://www.vim.org/maillist.php>
>
>
> You can try :vimgrep /<C-R><C-W>/j %<cr>
> The command will search the word under the cursor in current
> file(% -
> current file). more...
>
> Shawn Young <spacephys@gmail.com> Feb 25 04:53PM -0700 ^
>
> On Fri, Feb 25, 2011 at 12:44 PM, Michael(Xi Zhang)
>
> > Then you need use :cw<cr> to open the quickfix window.
>
> > Or you can combine the two command
> together: :vimgrep /<C-R><C-W>/j %<cr> more...
>
> "Michael(Xi Zhang)" <michaelxmail@gmail.com> Feb 25 08:39PM
> -0700 ^
>
> > > :help vimgrep
>
> > > Michael
>
> > Yes, this method doesn't mark the current line in the search
> result.
> Anyway, you can see your current line in the window, and all
> the results in more...
>
> Topic: Opening a line with vimscript - autoindent ignored
> Tim Johnson <tim@johnsons-web.com> Feb 25 07:42AM -0900 ^
>
> using vim 7.2 huge on mint 10.0
> I have a vimscript to handle code expansion from keywords.
> Here is the relevant snippet
> """"""""""""""""""""""""""""""""""""""""""""""""""""
> elseif wrd == "lv0" more...
>
> Tim Johnson <tim@johnsons-web.com> Feb 25 01:19PM -0900 ^
>
> > I to hit <Esc> at the end of the first line and then
> > o
> > The alignment would be retained.
> I think to answer my own question, I have been 'overthinking'
> the
> problem.
> elseif wrd == "lv0" more...
>
> Topic: bidi in vim
> Ben Schmidt <mail_ben_schmidt@yahoo.com.au> Feb 26 09:08AM
> +1100 ^
>
> Hi, Moshe,
>
> I've rearranged things a bit to suit my reply.
>
> > Of course I also would prefer to have full bidi support, but
> I can also
> > see that this would require some serious changes and more...
>
> Topic: bp and CTRL-^
> sc <toothpik@swbell.net> Feb 25 02:12PM -0600 ^
>
> all--
>
> the help for CTRL-^ says it is the same as e #, but it is
> clearly different when the alternate buffer is a Scratch
> buffer -- if you try to use e # (or bp) you get the error
> more...
>
> Ben Schmidt <mail_ben_schmidt@yahoo.com.au> Feb 26 08:42AM
> +1100 ^
>
> > command! BD exe "normal<c-^><c-^> | bd #"
>
> You only want to type control-^ once, don't you?
>
> Also, to use <> notation in a string, you need a \.
>
> Also, it's only the normal command you want more...
>
> sc <toothpik@swbell.net> Feb 25 04:02PM -0600 ^
>
> On Friday 25 February 2011 15:42:26 you wrote:
>
> > it from its argument.
>
> > So try
>
> > command! BD exe "normal \<c-^>" | bd #
>
> that's what i was shooting for -- thanx ben -- it works
> more...
>
> Topic: Multiple Substitutes for 'includeexpr'
> Charles E Campbell Jr <drchip@campbellfamily.biz> Feb 25
> 02:03PM -0500 ^
>
> ZyX wrote:
>
> > What do you mean by adding second substitute?
> > set includeexpr=substitute(...)\|substitute(...)
> > ? This won't work ...[snip]
>
> I think what AK meant was using a substitute as more...
>
> Topic: Question about omnicppcomplete
> jason <beyond291@gmail.com> Feb 26 12:37AM +0800 ^
>
> I use Vim and omnicppcomplete script for C programming for a
> long time.
> There are powerful.
> These day I got some code from product vender.
> There are some struct defines with the same name. more...
>
> Topic: Create mapping with '-c' command-line option
> Jean-Rene David <jrdavid@magma.ca> Feb 25 10:52AM -0500 ^
>
> Hello,
>
> I'm writing a little shell function that opens vim with two
> files in a
> split window. I'm trying to define the following mapping:
>
> map ZZ :qa<cr>
>
> when invoking vim, like so:
> more...
>
> ZyX <zyx.vim@gmail.com> Feb 25 07:59PM +0300 ^
>
> Reply to message «Create mapping with '-c' command-line
> option»,
> sent 18:52:13 25 February 2011, Friday
> by Jean-Rene David:
>
> You should be sure that 'compatible' is not set and `<' flag
> is not more...
>
> Topic: Why doesn't the cursor go beyond the last character in Vim
> when in command mode?
> "John Beckett" <johnb.beckett@gmail.com> Feb 25 05:35PM +1100
> ^
>
> Gerardo Marset wrote:
> > character when in command mode?
> > I find it kind of wierd, and because of that I have to use
> > either a or A to append something to a line (instead of i).
>
> There is also: more...
>
> Erik Christiansen <dvalin@internode.on.net> Feb 25 05:51PM
> +1100 ^
>
> On Thu, Feb 24, 2011 at 09:06:48PM -0200, Gerardo Marset
> wrote:
> > I find it kind of wierd, and because of that I have to use
> either a or A
> > to append something to a line (instead of i).
> more...
>
> Gerardo Marset <gammer1994@gmail.com> Feb 25 12:24PM -0200 ^
>
> On 24/02/11 22:52, Ben Schmidt wrote:
>
> > See
>
> > :help 'virtualedit'
>
> > Ben.
>
> Nice.
> Yes, I have a vimrc and I know how it works.
>
> Well, after reading the replies and the help entry for more...
>
> Topic: Trailing white space in multi line comments (ft=php)
> Marco <netuse@lavabit.com> Feb 25 01:53PM +0100 ^
>
> Hi,
>
> when I edit source code in C (set ft=c) I can input multi line
> comments
> without problems, when I edit PHP files (set ft=php) a
> trailing white space is
> introduced.
>
> To reproduce, my more...
>
> Ben Schmidt <mail_ben_schmidt@yahoo.com.au> Feb 26 12:27AM
> +1100 ^
>
> On 25/02/11 11:53 PM, Marco wrote:
> > */
>
> > Here after consectetur and after tempor there's the space.
> Why? How can I get
> > rid of this?
>
> Check the setting of 'formatoptions'
>
> :help 'fo' more...
>
> Marco <netuse@lavabit.com> Feb 25 02:56PM +0100 ^
>
>
> > > Here after consectetur and after tempor there's the space.
> Why? How can I
> > > get rid of this?
>
> > Check the setting of 'formatoptions'
>
> Thanks. That was a push to the right direction.
> more...
>
> Topic: Any dict plugin to translate English to Japanese?
> robert song <robertsong.japan@gmail.com> Feb 25 05:05PM +0900
> ^
>
> Hi, tyru,
>
> > send pull request to ref.vim's author)
>
> > Please tell me your Vim's version and OS.
> > and check if you installed program required for ref-alc
> source.
>
> yes, I install w3m. more...
>
> robert song <robertsong.japan@gmail.com> Feb 25 05:14PM +0900
> ^
>
> > - but for example, in perldoc buffer, it looks up a perl
> module.
> > - for me, thinca who is the author of ref.vim is my friend
> so I
> > quickly can send a bug report/patch/feature request! :p
> more...
>
> robert song <robertsong.japan@gmail.com> Feb 25 05:14PM +0900
> ^
>
> more...
>
> robert song <robertsong.japan@gmail.com> Feb 25 05:28PM +0900
> ^
>
> A very simple function to dump the selected word from dic
> yahoo and show the
> result.
>
>
> Add the following part to .vimrc file.
>
> function Dict(cmd)
> execute "new"
> execute "r!w3m -dump more...
>
> tyru <tyru.exe@gmail.com> Feb 25 07:02PM +0900 ^
>
> > I use CentOS 5.5 and vim version is
> > vim-enhanced-7.0.109-6.el5
> hmm.. I don't have vim older than 7.2 so I can't test that.
> I recommend to upgrade your vim.
>
> more...
>
> "Christian Brabandt" <cblists@256bit.org> Feb 25 11:04AM +0100
> ^
>
> On Fri, February 25, 2011 9:05 am, robert song wrote:
> > let g:ref_alc_cmd='w3m -dump %s'
>
> > I use CentOS 5.5 and vim version is
> > vim-enhanced-7.0.109-6.el5
>
> Before reporting a bug, please try more...
>
> tyru <tyru.exe@gmail.com> Feb 25 07:07PM +0900 ^
>
> > word will be translated and displayed on the dict window,
> that is why I
> > want to use a local dictionary file, I think this way seems
> to more
> > convenient.
> looks interesting. I will let thinca more...
>
> robert song <robertsong.japan@gmail.com> Feb 25 07:49PM +0900
> ^
>
> >> vim-enhanced-7.0.109-6.el5
> > hmm.. I don't have vim older than 7.2 so I can't test that.
> > I recommend to upgrade your vim.
>
> Hi, tyru,
> yeah, you are correct,
> after upgrading to the latest more...
>
>
> --
> 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
Lord - what if I defined an autocommand to delete + lines in .viminfo,
whenever I exited vim? Would paralel universes clash?
--
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
On Fri, Feb 25, 2011 at 12:44 PM, Michael(Xi Zhang)
>>
>> --
>> Shawn Young
>
> You can try :vimgrep /<C-R><C-W>/j %<cr>
> The command will search the word under the cursor in current file(% -
> current file). The results are in quickfix window. If you don't use the
> option 'j', it will jump to the first search result.
>
> Then you need use :cw<cr> to open the quickfix window.
>
> Or you can combine the two command together: :vimgrep /<C-R><C-W>/j %<cr>
> \| :cw <cr>
>
Thanks Michael,
I have not tried to put this in my .vimrc yet, but in doing it
manually I don't see anything that indicates which line my cursor is
on. What should I see?
-shawn
> Or map the command to shortcut, for example:
> map <F6> <Esc>:vimgrep /<C-R><C-W>/j %<cr> \| :cw<cr>
>
> Check out
> :help vimgrep
>
> Michael
>
>
Thanks Michael,
I have not tried to put this in my .vimrc yet, but in doing it
manually I don't see anything that indicates which line my cursor is
on. What should I see?
-shawn
> Or map the command to shortcut, for example:
> map <F6> <Esc>:vimgrep /<C-R><C-W>/j %<cr> \| :cw<cr>
>
> Check out
> :help vimgrep
>
> Michael
>
>
--
Shawn Young
SpacePhys@Gmail.com
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
--
You received this message 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
I've rearranged things a bit to suit my reply.
> Of course I also would prefer to have full bidi support, but I can also
> see that this would require some serious changes and complications in
> the code,
I think basing it on syntax regions/matches/whatever also would require
serious changes. I don't think there is any 'easy' way to do this, and
if we have to pick between 'hard' ways, I think it would be smartest to
pick the way that is actually most standard/correct.
> and even if this is done, there will probably be a rather serious
> performance penalty (for instance, the full bidi algorithm works on
> whole paragraphs, so you would have to compute something for the whole
> paragraph for every keystroke).
Optimisations can be made so that calculations aren't too inefficient.
Also, the same is true for syntax regions--recalculations must be made
for whole paragraphs/sections on each keypress.
> I also don't see that what I'm suggesting is a hack or a workaround.
I think it is a hack because which direction text should be displayed
really has nothing to do with syntax regions conceptually. It is about
what language the text is in, what script the characters in the text
come from, etc..
That said, there are bound to be edge cases, and perhaps syntax regions
could help solve them. But I would think this would be more of a 'bidi
algorithm override' than where the bidi algorithm actually takes effect
in the first place.
> It could actually be part of a general mechanism: for instance, the
> highlight or the syntax command could take a function as an optional
> argument. This function will be called with the start and end of the
> corresponding region (and maybe other arguments) and will output a new
> string to be displayed instead of the original one. This way the
> reversing can be done in Vim language (and you could use this system
> for other purposes, for instance capitalise all text in the region).
This would not work at all. It is not just a display issue where you can
get different display text from a Vimscript function. Vim also needs to
know where your cursor is within the text, whether to add new characters
to the left or the right of where the cursor is, etc., etc.. Best to
keep Vimscript right out of it.
>>> If this can be done, I think it will solve most practical problems,
>>> since when editing latex, for example, text in different direction will
>>> appear in particular commands or environments.
My perspective is a bit different. When I want bidi text, it's not
because I have text of one language embedded in particular regions of a
program or script or markup. It's because I'm writing in multiple
languages. I would have thought this, too, was quite common, i.e. simply
editing text.
This stuff should also work when syntax highlighting is turned off,
IMHO.
So, as I said before, my opinion is that bidi would be great, but I'd
love to see it done properly. There are a number of other benefits to
this, too: e.g. if Vim knows the underlying terminal supports bidi, it
can omit doing the character swapping itself, but just interface
properly with the terminal; how well that would work, I don't know, but
it may be worth a try.
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
> > command! BD exe "normal<c-^><c-^> | bd #"
> You only want to type control-^ once, don't you?
> Also, to use <> notation in a string, you need a \.
> Also, it's only the normal command you want to quote--quoting
> the stuff after it enforces the problem that the | will be
> part of the normal command.
> And you probably need a space at the end of normal to delimit
> it from its argument.
> So try
> command! BD exe "normal \<c-^>" | bd #
that's what i was shooting for -- thanx ben -- it works
perfectly now
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
You only want to type control-^ once, don't you?
Also, to use <> notation in a string, you need a \.
Also, it's only the normal command you want to quote--quoting the stuff
after it enforces the problem that the | will be part of the normal
command.
And you probably need a space at the end of normal to delimit it from
its argument.
So try
command! BD exe "normal \<c-^>" | bd #
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