Ian Young wrote:
I have a couple questions to start things off. First: I couldn't see
much need for 'fuzzy matching' in Vim, but some of you are probably
much better acquainted with regexp use cases than I am. Would this be
a useful feature to have available?
As you likely know, fuzzy
John Beckett wrote:
A.J.Mechelynck wrote:
What about a different function to return, say, the number of
1K blocks (or the number of times 2^n bytes, with a parameter
passed to the function) that a file uses?
Yes, that's a much more general and better idea.
Since there's probably not much
A.J.Mechelynck wrote:
I'm not sure what varnumber_T means: will st.stsize (the dividend) be
wide enough to avoid losing bits on the left?
varnumber_T is int (long if an sizeof(int) = 3).
st.stsize 's size depends on whether 32bit or 64bit integers are available.
So, its possible to lose
A.J.Mechelynck wrote:
Yes, yes, but before the division, will it be able to hold the file
size? (sorry, I meant st.st_size) Will mch_stat (at line 10134, one
line before the context of your patch) be able to return huge file
sizes?
mch_stat is variously defined, depending on o/s.
Under
Viktor Kojouharov wrote:
It turned out that these mappings broke the arrow keys in the terminal:
inoremap expr Esc pumvisible()?\C-E:\Esc
inoremap expr CR pumvisible()?\C-Y:\CR
inoremap expr Down pumvisible()?\C-N:\Down
inoremap expr Up pumvisible()?\C-P:\Up
inoremap expr
Peter Michaux wrote:
And now I see that VIM doesn't need more features...
http://www.vim.org/soc/ideas.php
May I suggest taking a look at:
http://vim.sourceforge.net/sponsor/vote_results.php
Regards,
Chip Campbell
Ian Tegebo wrote:
On 4/9/07, Nikolai Weibull [EMAIL PROTECTED] wrote:
The manSubHeading is defined as
syn match manSubHeading ^\s\{3\}[a-z][a-z ]*[a-z]$
This will, however, match more lines than I think is intended. It
will, for example, match the line
\t returns are what are
Nikolai Weibull wrote:
On 4/9/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
In this case, by looking at syntax/man.vim, its: Gautam H. Mudunuri
gmudunur AT informatica.com.
Actually, this was actually the wrong maintainer. Gautam was the
previous maintainer of this file. Nam
Nikolai Weibull wrote:
The manSubHeading is defined as
syn match manSubHeading ^\s\{3\}[a-z][a-z ]*[a-z]$
This will, however, match more lines than I think is intended. It
will, for example, match the line
\t returns are what are recorded and compared with the data git keeps
where
Denis Perelyubskiy wrote:
in version 7.0.188 (I am on windows xp, us) nothing works when I select
'..' when browsing a directory. has anyone seen this? is this something
peculiar to my installation, a bug, or a feature?
I suspect that you need a recent version of netrw.
To get an
Matthew Winn wrote:
Text editors don't do encryption and never should.
How else would you ensure that you can have encrypted text _without_
the need to temporarily store a plaintext copy of the file?
Pipe the text through to an external encryption tool, such as pgp.
Assuming your
The idea would be to leave the undo list alone, so that when the undo
table gets updated next it'll have a bigger change.
Regards,
Chip Campbell
Nikolai Weibull wrote:
On 1/29/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
The idea would be to leave the undo list alone, so that when the undo
table gets updated next it'll have a bigger change.
What do you mean? From the very short description it sounds like your
describing
Denis Perelyubskiy wrote:
Thanks. While I can't tell what went wrong by just eye-balling the
patches, I did find that the problem results from netrwPlugin.vim.
Basically, netrw registers this autocommand:
au BufEnter .* silent! call s:LocalBrowse(expand(amatch))
When it is executed on a
A.J.Mechelynck wrote:
Charles E Campbell Jr wrote:
OK, with all that:
vim -U NONE -c set nocp|so $HOME/.vim/plugin/netrwPlugin.vim -c
so scp://HOSTNAME/.vimrc
Rather than -U NONE (i.e., no gvimrc) shouldn't that be -u NORC
(i.e., with small u: don't source $HOME/.vimrc but do source
Hello, Scott!
I mentioned how there were lots of garbage notes that have been
appended to nearly all tips; as an example, I gave out tip#1. I see
that the garbage has been cleaned from tip#1, but tips #12-1393 also
need cleaning. Seems like it needs some automation to do it, especially
if
Hello!
Looks like the spammers have been adding their pollution to the tips.
Our (unfortunately) hardworking tip inspectors have been getting rid of
new spamtips, but the spammers have now started using the Additional
Notes process. I note that many of my own tips seem to have four or
more
Zvi Har'El wrote:
I tried to use view with the 'man' syntax, for example on the file vimtutor.man
obtained by
GROFF_NO_SGR=y groff -Tascii -man $(man -w vimtutor) vimtutor.man
(see http://www.math.technion.ac.il/~rl/etc/vimtutor.man)
(this is not the file vimtutor.man in the vim
A.J.Mechelynck wrote:
Charles E Campbell Jr wrote:
[...]
Unfortunately, IMHO, inline folding didn't get enough votes during
vim 7.0's development, and Bram is uncomfortable with the idea of
inline folding because it, naturally enough, suppresses information
(Vince's patch typically folds
scott wrote:
has anyone else lost the ability to get a menu by entering
:set guioptions+=m
nothing happens
i see
4: /usr/local/share/vim/vim70/menu.vim
in :scriptnames...
no glaring errors on build (7.0.178)
i build with
export CONF_OPT_GUI='--enable-gnome-check'
in SUSE linux 10.0
I
[EMAIL PROTECTED] wrote:
How to swap the three columns in file without using substitute
command?
Let us say file with the following contents,
A1 B1 C1
A2 B2 C2
Then after swapping the file content should be,
C1 A1 B1
C2 A2 B2
There's visswap, which you can get from
scott wrote:
i am running SUSE linux 10.0, my current vim is 7.0.178
i've tried this before in an attempt to get away from the way all these
latest netrws reset my formatoptions for me
I'm afraid that I don't see this problem. I've even tried it with your
stated preference of fo=tcroqn.
Since no one had mentioned it yet; the scripts appear to be inaccessible.
Clicking on top rated yields:
Can't open file: 'vs_scripts.MYI' (errno: 145)
Regards,
Chip Campbell
Victor Hsieh wrote:
With vim 7.0 and netrw.vim version 98, I've encountered a problem
when trying to vim http://somewhere/file.txt;. This patch will fix
the problem:
By the way, netrw is up to version 107a on my website. If you have a
problem
with netrw, its always best to get the latest
Victor Hsieh wrote:
On 10/6/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
Victor Hsieh wrote:
With vim 7.0 and netrw.vim version 98, I've encountered a problem
when trying to vim http://somewhere/file.txt;. This patch will fix
the problem:
This would silently let users overwrite
Bram Moolenaar wrote:
Suresh Govindachar wrote:
Is it possible to add an autocommand-event for Clipboard Changed?
Not really. This is not something that happens inside Vim. Polling for
changes in the system is not really something I would like to add to Vim.
Bram -- would you be
Yegappan Lakshmanan wrote:
Are you referring to a sample code similar to the xcmdsrv_client.c
file under
the $VIM/tools directory? This sample code shows how to send commands
to a remote Vim from a C program in Unix systems running X-Windows.
A similar sample code for MS-Windows is needed.
Bram Moolenaar wrote:
Matt Mzyzik wrote:
I don't like this one more, but it's a good alternative:
g/
g?
Also, I feel that one day might do something in visual; at least
visual line mode.
g? is already used for rot13 encoding.
g/ is scheduled to be used to search
Bram Moolenaar wrote:
Charles Campbell wrote:
Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave would
almost do, but if two or more windows are open on the same buffer, then
no event. WinLeave fires whenever one changes windows, which isn't
what I want, either. Unless
Hello!
Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave would
almost do, but if two or more windows are open on the same buffer, then
no event. WinLeave fires whenever one changes windows, which isn't
what I want, either. Unless I'm misunderstanding the help for these two
Edward L. Fox wrote:
But we should change one thing before we include this patch into the
official version. In the patch file, line 97:
+execute normal! A\npre { font-family: courier; color: . s:fgc
. ; background-color: . s:bgc . ; }\e
Should be:
+execute normal! A\npre {
Charles E Campbell Jr wrote:
Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave
would almost do, but if two or more windows are open on the same
buffer, then no event. WinLeave fires whenever one changes windows,
which isn't what I want, either. Unless I'm
Mark Manning wrote:
First you have to have a lot of open and close braces (}).
..snip..
Ok. So the problem happens when you delete sub b and then hit the
dd key to delete the blank line between sub a's ending close brace
and where sub b's starting line was. When you do this VIM
A.J.Mechelynck wrote:
The wierdness appeared after installing the manpageview plugin from
vim-online, and disappeared after removing it as well as versions of
the netrw and vimball plugins which had become older than the default
ones due to a runtime rsync. Don't know what _any_ of those had
scott wrote:
ok, so help me out here
i've looked at filetype vim, and i see nothing that associates
_.txt modules with ft=txt
whether i enter my 'ai' modules with the script or by navigating
to where they are and, with my bloody fingers typing 'gvim
ai_200609.txt', still, inside the module,
David Brown wrote:
A.J.Mechelynck wrote:
David Brown wrote:
What I'm having difficulty with is figuring out what to put there. Is
there a way of finding out what region a given part of the buffer
is in?
I'm not a specialist of these matters; but try help completion on synID
Well, I
Benji Fisher wrote:
A quick look at netrw.vba.gz (searching for swf) suggests that
this may be the problem:
fun! netrw#NetBrowseX(fname,remote)
[snip]
if a:remote == 1
set bh=delete bt=nofile noswf
exe norm! \c-o
redraw!
endif
call Dret(NetBrowseX)
endfun
All the other matches
Mark S. Williams wrote:
I think I've uncovered an odd bug involving Netrw and the cindent
local buffer option for Java files, where cindent is unset under
certain conditions.
I'm afraid that I don't see this problem; I tried both your examples.
Please try v103f from my website:
Yakov Lerner wrote:
On 8/7/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
Hello!
What is the message about (given on the subject line and here: modified
1.2.6.55 Tv1).
I get it when I'm using tags:
vi -t sometag
I grepped vim source, and found that strings 1.2.6.55 Tv1 do
A.J.Mechelynck wrote:
Can't select bottom window by mouse-clicking
Happens every time. How to reproduce:
1. :set ch=2 wmh=0 wh= don't know if relevant
2. Open at least two horizontally split windows
3. Make some window current, other than the bottom one
4. Click the bottom status line.
Stefan Karlsson wrote:
By the way, is there anyone out there that is working on a KDE version? I have
tried Kyzis a bit, but didn't really like it ...
As I recall, the vim7 kde port was dropped because there was no
maintainer for the port. I'm not a KDE
user myself, so I'm not a
Benji Fisher wrote:
I think I see the problem. In $VIMRUNTIME/autoload/netrw.vim , in
the function netrw#DirBrowse() , there are the lines
if fo =~ '[ta]'
set fo-=t
set fo-=a
echohl Warning
echo '***warning*** directory browsing and formatoptions ta are
incompatible'
echohl
Alexei Alexandrov wrote:
In Vim 7, there seems to be a bug in netrw plugin behavior. It looks like it wipes out
clipboard register (mine is set to unnamed). That is, I yank something in one file, then
I do, say, :e ., pick up a new file, open it with Enter and try to paste the
text. A space
Gary Johnson wrote:
I was following Chip Campbell's advice in the vim list to download
v100 of the netrw plugin when I discovered the following
undesirable behavior of the gzip.vim plugin. I downloaded
netrw.vba.gz, then opened it with
view netrw.vba.gz
and saw the following messages
Zdenek Sekera wrote:
I also thought 'runtime' is somehow equivalent
to :source, except it is smart enough
to use 'runtimepath'. Using the same test above
(':runtime test.vim') I found this does *not*
fire up the autocmd while :source does.
Is this intentional or can it be considered a bug?
Steve Hall wrote:
Just assume all paths are Windows-hostile unless passed through such a
wrapper. (I never see these errors on *nix, so I assume it's path
related.)
I'll try it! The unfortunate part is, I can't test it. Or rather, I
can test to see if the wrapper introduces some
new
Zdenek Sekera wrote:
Sorry, I should have been clearer:
Note the placement of the '+' in my pattern, somewhere
in the middle, there it doesn't cause any problem:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]'
^
|
Benji Fisher wrote:
Did you notice this thread on vim-dev?
- Forwarded message from Thomas [EMAIL PROTECTED] -
To: vim-dev@vim.org
From: Thomas [EMAIL PROTECTED]
Subject: vim7: formatoptions
Date: Fri, 19 May 2006 13:48:51 +0200
I just realized that editing a directory removes
A.J.Mechelynck wrote:
Charles E Campbell Jr wrote:
Hello, Tony!
I've had several folks having a problem with WinXP and netrw. The
problems seem to involve temporary files during attempts to use ftp;
since temporary filenames are produced by tempname(), they're o/s
dependent. Admittedly
Hello!
This one appears to be a ctrl-f (and ctrl-b) bug. Here's the setup:
(using Linux,vim-7.0g, huge)
.vimrc :
set nocp
.gvimrc :
set lines=21
no .vim/ directory.
Now, for the problem:
gvim -geometry 139x22+0+4 netrw.vim
11jspace
zcr
4jspace6k4j
ctrl-f
Note that the ctrl-f does not
William S Fulton wrote:
run: gvim .
on Windows at bottom it will say, eg: C:\ Illegal file name
on Solaris and Linux at the bottom it will say, eg: . is a directory
The Unix message is less confusing. Can this for Windows versions as
it still occurs in vim7.0f? Same message appears when doing
[EMAIL PROTECTED] wrote:
All,
I found a bug related to syntax highlighting, although I wouldn't be
surprised if people already know about this. Simply, the syntax
highlighting sometimes gets messed up and I have to refresh the window
(with c-l) in order make the highlighting correct again.
I
[EMAIL PROTECTED] wrote:
On Fri, Apr 28, 2006 at 04:08:32PM +0200, Nikolai Weibull wrote:
On 4/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I found a bug related to syntax highlighting, although I wouldn't be
surprised if people already know about this. Simply, the syntax
James Vega wrote:
On Tue, Apr 25, 2006 at 02:21:07PM -0400, Charles E Campbell Jr wrote:
I know this is a late date, but I think it would be helpful if
for var in list
...
endfor
would complete with var= . For example where this might come in handy:
for home in split(rtp
Bram Moolenaar wrote:
Charles Campbell wrote:
I know this is a late date, but I think it would be helpful if
for var in list
...
endfor
would complete with var= ...
This for loop is like it is in Python, and it has proven to be very
useful.
It's easy to add something to the
Hari Krishna Dara wrote:
On Thu, 20 Apr 2006 at 9:58am, Charles E Campbell Jr wrote:
Please try setting g:netrw_fastbrowse=0 in your .vimrc. Hopefully the
jumplist will then be
retained.
Did you mean the value 2?
Whoops -- yes, I meant 2. If you want the jumplist to work, you
Hari Krishna Dara wrote:
I am wondering if we can have netrw set the 'ft' of the buffer to
'netrw' at the end of generating the directory listing...
Its already netrwlist; I named it that quite awhile ago so as to reduce
the danger that someone
might move syntax/netrw.vim atop
Hari Krishna Dara wrote:
This is exactly the reason, I didn't suspect this at all. I had netrw in
my plugin directory for use with 6.3 Vim. Now, how do I make sure I can
use the same plugin directory for both 6.3 and 7.0? I think the
g:loaded_xxx variable should be different for these two so
58 matches
Mail list logo
