On 2022-09-27, M wrote:
> You're using cmd token that doesn't switch the modes. The effect is that as
> long as you're in visual mode the < and > marks are not updated. This is
> the way how it works and always worked.
Aha, that's it! In fact, I have switched to use when I have
migrated to Vim
вт, 27 сент. 2022 г., 22:33 Lifepillar :
> Source this script:
>
> vim9script
>
> def g:Select(): list
> const lnum1 = getpos("'<")[1]
> const lnum2 = getpos("'>")[1]
> return getline(lnum1, lnum2)
> enddef
>
> vnoremap x echo Select()
>
> Then select some
Source this script:
vim9script
def g:Select(): list
const lnum1 = getpos("'<")[1]
const lnum2 = getpos("'>")[1]
return getline(lnum1, lnum2)
enddef
vnoremap x echo Select()
Then select some line(s) and type \x. What I would expect (and what
I think Vim used to
On 2022-09-27, Lifepillar wrote:
> Today, I checked the value of getpos("'>") after selecting some text,
> and got:
>
> [0, 15, 2147483647, 0]
Now I have seen that the large number is expected. I will try to make
a reproducible example of my issue.
Life.
--
--
You received this message
Has something changed recently in the way Visual mode marks are handled?
I have a couple of functions using '<, '> and the like and they have
started misbehaving recently. Today, I checked the value of getpos("'>")
after selecting some text, and got:
[0, 15, 2147483647, 0]
This using Vim
On 2018-12-06 14:39, Christian Brabandt wrote:
> > Brought to my attention by this thread:
> >
> > https://www.reddit.com/r/vim/comments/a3e80i/is_vim_right_for_me/
> >
> > It seems to me that :p should always only print the line, even if
> > 'number' is set. If you want to print the line with
Tim Chase wrote:
> Brought to my attention by this thread:
>
> https://www.reddit.com/r/vim/comments/a3e80i/is_vim_right_for_me/
>
> It seems to me that :p should always only print the line, even if
> 'number' is set. If you want to print the line with its line-number,
> you can either use
On Do, 06 Dez 2018, Tim Chase wrote:
> Brought to my attention by this thread:
>
> https://www.reddit.com/r/vim/comments/a3e80i/is_vim_right_for_me/
>
> It seems to me that :p should always only print the line, even if
> 'number' is set. If you want to print the line with its line-number,
>
Hi,
Tim Chase schrieb am 06.12.2018 um 14:19:
> Brought to my attention by this thread:
>
> https://www.reddit.com/r/vim/comments/a3e80i/is_vim_right_for_me/
>
> It seems to me that :p should always only print the line, even if
> 'number' is set. If you want to print the line with its
Brought to my attention by this thread:
https://www.reddit.com/r/vim/comments/a3e80i/is_vim_right_for_me/
It seems to me that :p should always only print the line, even if
'number' is set. If you want to print the line with its line-number,
you can either use ":p#" (:help ex-flags) or even just
7 de março de 2018 22:16:58 UTC-3, Renato Fabbri escreveu:
>
> > Em terça-feira, 27 de fevereiro de 2018 15:08:21 UTC-3, Christian Brabandt
> > escreveu:
>
> > > On Di, 27 Feb 2018, Renato Fabbri wrote:
>
> > >
>
> > > > On Mon, Feb 26, 2018 at
On Do, 08 Mär 2018, Renato Fabbri wrote:
> (screenshot attached.)
>
> option 'noh' not highlighted as expected.
>
> other options related to the
> [''vimSet'', [''vimOption'', ''PreProc'']]'
> highlighting groups while
> noh is only related to
> [''vimSet'']'
:noh is the command. The option
, 2018 at 4:06 PM, Bram Moolenaar <b...@moolenaar.net>
> wrote:
> > > >
> > > >
> > > > Renato Fabbri wrote:
> > > >
> > > > > Would you call these bugs?
> > > > >
> > > > > 1)
>
Em terça-feira, 27 de fevereiro de 2018 15:08:21 UTC-3, Christian Brabandt
escreveu:
> On Di, 27 Feb 2018, Renato Fabbri wrote:
>
> > On Mon, Feb 26, 2018 at 4:06 PM, Bram Moolenaar <b...@moolenaar.net> wrote:
> >
> >
> > Renato Fabbri wrote:
>
ops... email sent only for you... I apologise and am sending to the list as
well.
On Tue, Feb 27, 2018 at 3:16 PM, Bram Moolenaar <b...@moolenaar.net> wrote:
>
>>
>> Renato Fabbri wrote:
>>
>> > > > Would you call these bugs?
>> > > >
&
Renato Fabbri wrote:
> > > Would you call these bugs?
> > >
> > > 1)
> > > vim script (vimL) syntax highlighting highlights on (:only) as an option
> > > value, e.g.
> > > if a ==# 'banana'
> > > on
> > > en
> >
>
On Di, 27 Feb 2018, Renato Fabbri wrote:
> On Mon, Feb 26, 2018 at 4:06 PM, Bram Moolenaar <b...@moolenaar.net> wrote:
>
>
> Renato Fabbri wrote:
>
> > Would you call these bugs?
> >
> > 1)
> > vim script (vimL) syntax hi
On Mon, Feb 26, 2018 at 4:06 PM, Bram Moolenaar <b...@moolenaar.net> wrote:
>
> Renato Fabbri wrote:
>
> > Would you call these bugs?
> >
> > 1)
> > vim script (vimL) syntax highlighting highlights on (:only) as an option
> > value, e.g.
> > i
Renato Fabbri wrote:
> Would you call these bugs?
>
> 1)
> vim script (vimL) syntax highlighting highlights on (:only) as an option
> value, e.g.
> if a ==# 'banana'
> on
> en
Doesn't happen for me.
> 2)
> termguicolors was (AFAIU) mostly or only for GUI, i
Would you call these bugs?
1)
vim script (vimL) syntax highlighting highlights on (:only) as an option
value, e.g.
if a ==# 'banana'
on
en
2)
termguicolors was (AFAIU) mostly or only for GUI, including the
colorscheme gui= guibg= and guibf= settings
in terminal vim, if you set
skywind3000 wrote:
> Does anyone knows how to contact DrChip ?
> His email is invalid now.
>
My email is and has been "valid". Did you happen to neglect to remove
the NOSPAM embedded therein?
Regards,
Chip Campbell
--
--
You received this message from the "vim_use" maillist.
Do not top-post!
Hi, DrChip
I have encountered a serious netrw bug on windows:
https://groups.google.com/forum/#!topic/vim_use/45FO_l_QakM
I don't know how to contact you, your email is invalid now.
Will you please have a look at it ? thanks
--
--
You received this message from the "vim_use" maillist.
Do not
Does anyone knows how to contact DrChip ?
His email is invalid now.
--
--
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
I have found out how to do this. I downloaded source code and searched/replaced
the sting and reported a bug at https://github.com/vim/vim/issues/1176 with
instructions how to fix the bug.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the
Hi,
I have been using Vim 7.4 and spotted some localization's translation bugs and
some missing translation strings (I see English strings). But now I have also
downloaded/installed Vim 8 nightly from vim github, to be sure this problems
are not already fixed, but exactly the same problems
Matteo Cavalleri wrote:
snip
still not what i want to do. If I have one file open, call :Explore,
and then :q vim quits. I want to go back to the file i was editing.
The functions I wrote seems to work, except for the weird lag...
snip
Hello!
Please try netrw v151e
Matteo Cavalleri wrote:
another problem: let's say I do :e app/etc/local.xml and then open
netrw. I move over ../ and press cr to go back up one level in the
hierarchy. the cursor move on row 0. is it possibile to let it stay on
the first line of the file listings? i.e. after the netrw
I'm starting to learn netrw (the version shipped with the latest vim 7.4.142)
but I already have a couple of problems and maybe a bug. Try to do this:
open any file
:Explorecr
press F1 for netrw help (will open in an horizontal split)
go back to netrw split
move over any file and press P
the
Matteo Cavalleri wrote:
I'm starting to learn netrw (the version shipped with the latest vim 7.4.142)
but I already have a couple of problems and maybe a bug. Try to do this:
open any file
:Explorecr
press F1 for netrw help (will open in an horizontal split)
go back to netrw split
move over
Matteo Cavalleri wrote:
Just tried this sequence out and didn't see any problem. Please try the
latest version of netrw (v150t, available from my website:
http://www.drchip.org/astronaut/vim/index.html#NETRW)
I installed it. if there's nothing else to do to load the new version then the
* what o/s are you using?
ubuntu 13.10 64bit
* what netrw-oriented options are you using? In looking at your image,
let g:netrw_list_hide = '^\..*, .*\.sw[op]$'
let g:netrw_browse_split = 0
let g:netrw_liststyle = 3
let g:netrw_banner = 0
* netrw's banner will tell you what version
On Jan 14, 2014 9:13 AM, Charles Campbell charles.e.campb...@nasa.gov
wrote:
Matteo Cavalleri wrote:
I'm starting to learn netrw (the version shipped with the latest vim
7.4.142) but I already have a couple of problems and maybe a bug. Try to do
this:
open any file
:Explorecr
press F1 for
Hi,
http://mcmc-jags.sourceforge.net/
http://www.openbugs.info/w/
I only find the following syntax highlight file for the BUGS language
(see the above websites). Because the keywords are bugs or bug, it
is extremely hard to search whether there are any other existing vim
files for it. Has
Stop Modifying vimfiles !
I am using Gvim under windows seven and I like to have a big toolbar
with 48px icon'size so
== I have linked my own version of gvim7.3.46 only with toolbar
changes.
== I know Innosetup So I have made an InnoSetup Installer to deploy
my own version of gvim correctly.
niva wrote:
Stop Modifying vimfiles !
I am using Gvim under windows seven and I like to have a big toolbar
with 48px icon'size so
== I have linked my own version of gvim7.3.46 only with toolbar
changes.
== I know Innosetup So I have made an InnoSetup Installer to deploy
my own version of
2011/7/14 Charles Campbell charles.e.campb...@nasa.gov
niva wrote:
Stop Modifying vimfiles !
I am using Gvim under windows seven and I like to have a big toolbar
with 48px icon'size so
== I have linked my own version of gvim7.3.46 only with toolbar
changes.
== I know Innosetup So I
Hi niva!
On Do, 14 Jul 2011, niva wrote:
Stop Modifying vimfiles !
It doesn't really matter in this case. When you install new runtime
files, they will override your custom changes, but changes are good,
your bug will then still be fixed.
I am using Gvim under windows seven and I like to
Hi ni!
On Do, 14 Jul 2011, ni va wrote:
I just wana tell you that it is not necessary to modify vimfiles like
help.vim beacause it works with the original one.
With the deploy that I have done with innosetup
So how did you modify help.vim?
--
Es gibt Situationen im Menschenleben, wo es
Yeah, that's the other half of the bug you found. I think (and hope)
that Bram (maintainer of that syntax script) will update both
syntax/help.vim and ftplugin/help.vim, since AFAICT Nikolai Weibull
(maintainer of the ftplugin) has washed his hands of it.
Its easy enough to fix (I think
Hi niva!
On Mi, 13 Jul 2011, niva wrote:
Sorry but It seems you have done a unix diff and I dont happen to
interpret good lines
Well basically, change every line that contains the 'conceal' keyword to
if has(conceal)
original line
else
original line without conceal keyword
endif
That
On 11/07/11 22:33, niva wrote:
On 11 juil, 21:48, Bram Moolenaarb...@moolenaar.net wrote:
Tony Mechelynck wrote:
On 10/07/11 14:50, niva wrote:
Hi,
I recently install Vim 7.3 under win seven and I got some errors when
I navigate through vim's help system.
pattern.txt [RO] 1289L,
Tony Mechelynck wrote:
On 10/07/11 14:50, niva wrote:
Hi,
I recently install Vim 7.3 under win seven and I got some errors when
I navigate through vim's help system.
pattern.txt [RO] 1289L, 54946C
Erreur détectée en traitant C:\Program Files (x86)\Vim\vim73\ftplugin
\help.vim
On 11 juil, 21:48, Bram Moolenaar b...@moolenaar.net wrote:
Tony Mechelynck wrote:
On 10/07/11 14:50, niva wrote:
Hi,
I recently install Vim 7.3 under win seven and I got some errors when
I navigate through vim's help system.
pattern.txt [RO] 1289L, 54946C
Erreur d tect e en
On 10/07/11 14:50, niva wrote:
Hi,
I recently install Vim 7.3 under win seven and I got some errors when
I navigate through vim's help system.
pattern.txt [RO] 1289L, 54946C
Erreur détectée en traitant C:\Program Files (x86)\Vim\vim73\ftplugin
\help.vim :
ligne 16 :
E518: Option inconnue:
On 10/07/11 15:38, Nikolai Weibull wrote:
On Sun, Jul 10, 2011 at 15:26, Tony Mechelynck
antoine.mechely...@gmail.com wrote:
Hm, it seems that the latest versions of ftplugin/help.vim and
syntax/help.vim don't make provision for the possibility that the +conceal
feature might have been left
Hi,
It seems that Emacs can handle BUGS language. Some syntax of BUGS
language is similar to the syntax R (http://cran.r-project.org/). I'm
wondering if there is any vim files that can help handle BUGS files.
http://www.mrc-bsu.cam.ac.uk/bugs/weblinks/webresource.shtml
ESS (Emacs Speaks
Птн, 17 Сен 2010, Bram Moolenaar писал(а):
Bill Lam wrote:
I was able to build window vim using mingw cross-compiled under debian. But
I found it failed to link for TINY build, the reason is inside os_mswin.c,
enc_to_utf8 and acp_to_enc routines are nested inside feature clipboard,
Bill Lam wrote:
ðÔÎ, 17 óÅÎ 2010, Bram Moolenaar ÐÉÓÁÌ(Á):
Bill Lam wrote:
I was able to build window vim using mingw cross-compiled under debian.
But
I found it failed to link for TINY build, the reason is inside os_mswin.c,
enc_to_utf8 and acp_to_enc routines are nested
Сбт, 18 Сен 2010, Bram Moolenaar писал(а):
It appears that IME is defined, resulting in FEAT_MBYTE_IME to be
defined, and feature.h will then define FEAT_MBYTE.
Try removing IME.
I tested it needs to turn off MBYTE and IME in order to compile TINY. I'm
still not convincing why MBYTE and IME
Bill Lam wrote:
I was able to build window vim using mingw cross-compiled under debian. But
I found it failed to link for TINY build, the reason is inside os_mswin.c,
enc_to_utf8 and acp_to_enc routines are nested inside feature clipboard,
but moving these feat_mbyte out of clipboard's #IF
I was able to build window vim using mingw cross-compiled under debian. But
I found it failed to link for TINY build, the reason is inside os_mswin.c,
enc_to_utf8 and acp_to_enc routines are nested inside feature clipboard,
but moving these feat_mbyte out of clipboard's #IF block. It can build
On 28 July 2010 20:49, Tony Mechelynck antoine.mechely...@gmail.com wrote:
Works for me. The 'keymap' option is still present, but it's (always ben) a
compile-time feature.
I know it is a compile-time feature, but I never compiled Vim myself so far,
and I thought it is included by default. I'd
version. However, I'd like to report of other
bugs.
One is the incorrect display of Unicode characters with grave (U+0300)
or acute (U+0301) combining accents (that I already mentioned).
Another (at least I see it as a bug) is that the keymap option is
dropped, rendering the ‘set keymap’ command
On 28/07/10 17:16, bill lam wrote:
[...]
I usually use xterm and vim does not any problem in displaying
characters. FYI fonts of xterm can be configured in ~/.Xresources
XTerm*VT100*faceNameDoublesize: AR PL UMing HK
or your favourite xft font.
Usually I use gvim, or more rarely Vim in
with parsing and printing
f.p. numbers in the new version. However, I'd like to report of other
bugs.
One is the incorrect display of Unicode characters with grave (U+0300)
or acute (U+0301) combining accents (that I already mentioned).
Another (at least I see it as a bug) is that the keymap option
')
and
:echo eval('1,23')
evaluates to a correct floating-point number, printing an error
message instead (both the dot and the comma are rejected).
As a result, no normal floating-point computations can be done
within this version of gVim.
The terminal version of Vim does *not* have these bugs
.
The terminal version of Vim does *not* have these bugs.
Please try out Vim 7.3b. It includes a change that should fix the comma
vs. decimal point problems.
Also, on the same system, I tried to compile vim 7.3b.
Running the configure script failed, suggesting that I should
install ncurses – which I do
version of Vim does *not* have these bugs.
~
Also, on the same system, I tried to compile vim 7.3b.
Running the configure script failed, suggesting that I should
install ncurses – which I do have installed already.
Do others share the same experience?
Regards,
Boyko
computations can be done
within this version of gVim.
The terminal version of Vim does *not* have these bugs.
~
Also, on the same system, I tried to compile vim 7.3b.
Running the configure script failed, suggesting that I should
install ncurses – which I do have
floating-point computations can be done
within this version of gVim.
The terminal version of Vim does *not* have these bugs.
~
Also, on the same system, I tried to compile vim 7.3b.
Running the configure script failed, suggesting that I should
install ncurses – which I do have
On Oct 3, 2:16 pm, Matt Wozniski m...@drexel.edu wrote:
On Sat, Oct 3, 2009 at 3:07 PM, Ben Fritz fritzophre...@gmail.com wrote:
On Oct 2, 1:51 pm, Peng Yu pengyu...@gmail.com wrote:
Can somebody help me figure out what the bug is?
E323: line count wrong in block 1
E316: ml_get:
On Fri, Oct 02, 2009 at 11:51:17AM -0700, Peng Yu wrote:
Hi,
Recently, I compile vim with python support. Then I frequently get the
following errors when I :w .R files (I'm not sure if I will get such
errors when I :w other type of files, as I am not editing them).
Recently, I also
Evan schrieb:
So ever since folding showed up in vim I've been annoyed by some
behaviours.
Rule of thumb: If you're not sure that it is a bug, look in the help if
it can be customized.
I assumed they were bugs and would be fixed in the next version, but
they're still there many years later
On Oct 2, 1:51 pm, Peng Yu pengyu...@gmail.com wrote:
Can somebody help me figure out what the bug is?
E323: line count wrong in block 1
E316: ml_get: cannot find line 76
76 ???
E323: line count wrong in block 1
Press ENTER or type command to continue
E316: ml_get: cannot find line 76
On Sat, Oct 3, 2009 at 3:07 PM, Ben Fritz fritzophre...@gmail.com wrote:
On Oct 2, 1:51 pm, Peng Yu pengyu...@gmail.com wrote:
Can somebody help me figure out what the bug is?
E323: line count wrong in block 1
E316: ml_get: cannot find line 76
76 ???
E323: line count wrong in block 1
Hi,
Recently, I compile vim with python support. Then I frequently get the
following errors when I :w .R files (I'm not sure if I will get such
errors when I :w other type of files, as I am not editing them).
Recently, I also modified my .vimrc and installed indent/python.vim
Can somebody help
Hi,
Recently, I compile vim with python support. Then I frequently get the
following errors when I :w .R files (I'm not sure if I will get such
errors when I :w other type of files, as I am not editing them).
Recently, I also modified my .vimrc and installed indent/python.vim
Can somebody help
So ever since folding showed up in vim I've been annoyed by some
behaviours. I assumed they were bugs and would be fixed in the next
version, but they're still there many years later, and I'm finally
wondering if maybe others don't see them, or maybe they're not
considered bugs, or maybe I'm
On Wed, Nov 12, 2008 at 11:53, Dennis Benzinger
[EMAIL PROTECTED] wrote:
Where can you report bugs in the help files?
AFAICT, they should be reported to the vim_dev mailing list.
--~--~-~--~~~---~--~~
You received this message from the vim_use maillist.
For more
On Wed 12-Nov-08 6:08am -0600, Bram Moolenaar wrote:
Was already fixed in my copy. Latest version can be found at
ftp://ftp.vim.org/pub/vim/runtime/doc/
Or, for Windows users, wanting CR/LF:
ftp.vim.org/pub/vim/runtime/dos/doc
--
Best regards,
Bill
PROTECTED] bounced (so :h bugs should probably be fixed too).
Messages to vim-dev are moderated for new users, so may take some hours
to show up. Bugs are to be sent to [EMAIL PROTECTED] Note the extra s.
--
hundred-and-one symptoms of being an internet addict:
245. You use Real Audio to listen
Dennis Benzinger wrote:
Hi!
Where can you report bugs in the help files?
You can send them to me.
I think there is a typo in the second paragraph of :help gui-init .
I think in the first list item the value of the 'term' option is
buildin_gui and not builgin_gui.
Was already fixed
Hi!
Where can you report bugs in the help files?
I think there is a typo in the second paragraph of :help gui-init .
I think in the first list item the value of the 'term' option is
buildin_gui and not builgin_gui.
Dennis Benzinger
--~--~-~--~~~---~--~~
You
On 11/11/08 06:36, StarWing wrote:
BUT, this is not the responsibility of c.vim! now i had to add this
line to c.vim, but it should be done by Vim when i changed the
filetype! because every indent script should define a variable named
b:undo_indent, and Vim will exec b:undo_indent when it use
okay, the question caused because i add setf text in my vimrc. and i
have tested, Vim does have b:undo_indent at begining. the only
question is Vim didn't execute the b:undo_indent of the init buffer.
i had to add a file c.vim in my .vim/indent folder, the only thing
it does is set inde and indk
On 10/11/08 09:58, StarWing wrote:
first bug, when you open Vim, you can set the first buffer's filetype
in vim.
e.g. set filetype to vim
:setf vim (or setl filetype=vim, has the same issue)
then, if you find, the file you want to create is not vim script, e.g.
is C, then you change the
On 11/11/08 04:39, Tony Mechelynck wrote:
On 10/11/08 09:58, StarWing wrote:
[...]
second bug:
open Vim, and type :setf vim, now type :edit a.c then you can see some
settings in Vim:
:set: inde indk
they are still value in filetype Vim.
Solution: can't find.
[...]
P.S. I think the real
BUT, this is not the responsibility of c.vim! now i had to add this
line to c.vim, but it should be done by Vim when i changed the
filetype! because every indent script should define a variable named
b:undo_indent, and Vim will exec b:undo_indent when it use a new
indent (see indent.vim in vim
On 09/11/08 06:52, Linda W wrote:
[...]
If +yis supposed to work and is documented to work (but
doesn't),
and if *y is not supposed to work (but does) might it not qualify
as a 'bug' in some sense of the word? Should the menu text tell me that
'plus'
is the key to
On Fri, Nov 7, 2008 at 9:30 PM, Linda W wrote:
Erik Hahn wrote:
No wonder - the command is *y , with an asterisk instead of a plus. You
press them in succession.
That works alot betterum...there seem to be a few bugs on my menu.
Just looking at the Edit menu (Gvim 7.1
Linda W wrote:
If +y is supposed to work and is documented to work
(but doesn't), and if *y is not supposed to work
(but does) might it not qualify as a 'bug'
Please post exactly what you do, and what result you see. It's not clear to me
whether you select something with the mouse (how?), or
Erik Hahn wrote:
No wonder - the command is *y , with an asterisk instead of a plus. You
press them in succession.
That works alot betterum...there seem to be a few bugs on my menu.
Just looking at the Edit menu (Gvim 7.1, win32), I see:
--x
Undou
Redo
82 matches
Mail list logo
