Wednesday, March 31, 2010

Re: Command switching to Normal mode with no mapping is used

Hi Anna,

> I have found a workaround for it.
> I want to detect when command-line mode starts.
Tell about the whole use case. Why do you want to detect switching to
normal mode?

There is InsertLeave. But this doesn't catch visual -> normal.

Marc Weber

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

To unsubscribe, reply using "remove me" as the subject.

Re: Command switching to Normal mode with no mapping is used

One workaround is to unmap the disturbing mapping and remap it again
later.. But this can be unfeasible..

In general it is worth talking about the task you're trying to solve
rather than asking about how to implement the solution you think is
best. So which is your use case leading to this question?

I have found a workaround for it. 
I want to detect when command-line mode starts. But, I don't find any event generation related to mode switching. So, my initial solution is to map : in normal mode. But, the problem is sometimes I don't want to detect it; execute the command as it is.  Now, I add my solution with a mapping of other command which I can use to start command-line without being detected: nnoremap z: :
Any other idea would be appreciated ..

Anna

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

Highlighting of NERDTree Plugin off when I source my _vimrc

Hi,


I am using NERDTree plugin and it is highlighted well.
When I source _vimrc, highlight of its buffer is down.

I would like to avoid to highlight down this particular buffer.
No name is reusable cause expand("%:p:h") tell me mycurrentdir.

My _vimrc is that one :

colorscheme nuvola " Color, Font
filetype plugin on
" Only do this part when compiled with support for autocommands.
if has("autocmd")

filetype plugin indent on
" Put these in an autocmd group, so that we can delete them easily.
augroup vimrcEx
au!

autocmd FileType text setlocal textwidth=90

autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
\ exe "normal! g`\"" |
\ endif
augroup END
endif

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

Re: Command switching to Normal mode with no mapping is used

Hi Anna
> Any advice on this matter?

One workaround is to unmap the disturbing mapping and remap it again
later.. But this can be unfeasible..

In general it is worth talking about the task you're trying to solve
rather than asking about how to implement the solution you think is
best. So which is your use case leading to this question?

Marc Weber

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

To unsubscribe, reply using "remove me" as the subject.

Command switching to Normal mode with no mapping is used

Hi all,

Is there a command which can be used to go to Normal mode but no
mapping is used in the Normal mode?
That would be similar to :normal!, but in this case I can only start
from Command-Line mode.

So, the command that I need is like
<Command>dd
I can start from any mode, <Command> will make Vim switch to Normal
mode, then it deletes the current line.

Any advice on this matter?
Thank you very much.

Anna

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

To unsubscribe, reply using "remove me" as the subject.

Re: Google Chrome under Linux and problems with "* and "+

On Wed, 31 Mar 2010, Ted wrote:

> Hi Raúl,
> I've been having the same problem. Somewhere along the line the
> copied text is getting converted from ISO-8859-1 to utf-8. This
> causes problems because it's actually already in UTF-8. So to convert
> the current line back you can do
>
> :.!iconv -f utf-8 -t ISO-8859-1
>
> I have no idea why this is, but this is at least a usable workaround.
> I'd like to know more about this.
>
> I've noticed what seems to be a related issue: If you _select_ (not
> copy) your name in Chrome, and then go to a console and type
> xclip -o
> the ú will be garbled.

FWIW, this appears to work fine for me (both selection and
copying-to-clipboard) with Chromium 4.0.266.0 (Developer Build 33995).

Chromium still seems to be in very volatile development. (I didn't
realize there was even a 'real' Chrome for Linux, though.) It wouldn't
surprise me if this simply 'fixes itself' in some future Chrome release.

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

To unsubscribe, reply using "remove me" as the subject.

Re: Google Chrome under Linux and problems with "* and "+

Hi Raúl,
I've been having the same problem. Somewhere along the line the
copied text is getting converted from ISO-8859-1 to utf-8. This
causes problems because it's actually already in UTF-8. So to convert
the current line back you can do

:.!iconv -f utf-8 -t ISO-8859-1

I have no idea why this is, but this is at least a usable workaround.
I'd like to know more about this.

I've noticed what seems to be a related issue: If you _select_ (not
copy) your name in Chrome, and then go to a console and type
xclip -o
the ú will be garbled.

A bit more detail:
$ xclip -o | xxd
0000000: 5261 fa6c Ra.l

It looks like the opposite is happening here, ie it is being converted
from UTF-8 into ISO-8859-1:
$ xclip -o | iconv -f ISO-8859-1 -t utf-8 | xxd
0000000: 5261 c3ba 6c Ra..l
$ echo -n "Raúl" | xxd
0000000: 5261 c3ba 6c Ra..l
Both of these are the correct UTF-8 rendering of your name.


On Mar 31, 4:54 pm, Raúl Núñez de Arenas Coronado <raul...@gmail.com>
wrote:
> Hi all :)
>
> Since this may be my fault (or Chrome's fault) I won't go into deep
> details. Instead, I'll show a small example.
>
> I select and copy in Google Chrome (using Ctrl-C) the word "Raúl"
> (that is, my name). I open any program and paste, and the text pasted
> is exactly "Raúl".
>
> Now I open console Vim under gnome-terminal and I run ":registers".
> This is what I have (excerpted):
> "*   Raúl
> "+   Raúl
>
> In the first line the text is correct, but in the second line the
> uacute doesn't appear and instead you can see the latin-1
> representation.
>
> Any other program I've tested works perfectly when pasting text from
> Google Chrome, and Vim works perfectly when pasting text from other
> programs, so the problem looks like a weird interaction between Google
> Chrome and Vim, or just with the way Google Chrome uses the clipboard
> selection.
>
> Anyone knows which can be the problem?
>
> Thanks in advance, guys!
>
> --
> Raúl "DervishD" Núñez de Arenas Coronado
> Linux Registered User 88736 |http://www.dervishd.net
> It's my PC and I'll cry if I want to... RAmen!

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

To unsubscribe, reply using "remove me" as the subject.

Re: how to center items on statusline

On 31/03/10 22:45, viki wrote:
> Hello,
>
> How do I center-align some items on statusline ?
>
> Thanks.
> Viki
>

Hm. The status lines allows a "left-side group" and a "right-side group"
of items, separated by %= and in addition you may have one %< item to
define where to truncate the line if too long.

I haven't tried bracketing an item (or a set of items) between two %=
markers. If it doesn't give an error, it might be what you want.

See :help 'statusline'


Best regards,
Tony.
--
Taxes, n.:
Of life's two certainties, the only one for which you can get
an extension.

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

To unsubscribe, reply using "remove me" as the subject.

calling dictionary functions with call()

Hello,
I'm hoping to call a "static" dictionary function using call(). By
"static" I mean that the keyword 'dict' is not used in the function's
definition. I use this nomenclature in the hopes that the effect of
this keyword is to declare a static member function as is possible in
java/C++/etc, ie to restrict the scope of the function name without
requiring it to be associated with an object. However this doesn't
seem to work. For example:

" Setup:
let testdict = { }
funct! testdict.funct()
echo "called"
endfunct

" Tests:
" Following each line is an indented comment containing its
output in message land, ie what was echoed.
call testdict.funct()
" called
echo testdict.funct
" 667
echo string(testdict.funct)
" function('667')
echo function('667')
" E475: Invalid argument: 667
echo function('testdict.funct')
" testdict.funct
call call(testdict.funct, [ ])
" E725: Calling dict function without Dictionary: 667

" Same deal if there's an intermediate variable involved.
let TestdictDotFunct = testdict.funct
echo TestdictDotFunct
" 667
echo string(TestdictDotFunct)
" function('667')
call TestdictDotFunct()
" E725: Calling dict function without Dictionary: 667

From the help topic *E725*:
It is also possible to add a function without the "dict" attribute
as a
Funcref to a Dictionary, but the "self" variable is not available
then.

So logic would seem to indicate that if "self" is not available, then
it should be possible to call the function referenced by the Funcref
without a Dictionary. However this doesn't seem to be the case. Am I
missing something?


Vim version info:

$ aptitude show vim-gnome
Package: vim-gnome
State: installed
Automatically installed: no
Version: 2:7.2.245-2ubuntu2

$ vim --version
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Sep 21 2009 11:22:21)
Included patches: 1-245
Compiled by buildd@crested.buildd
Huge version with GTK2-GNOME GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
+cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
+comments
+cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -
ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
+find_in_path
+float +folding -footer +fork() +gettext -hangul_input +iconv
+insert_expand
+jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds
+localmap
+menu +mksession +modify_fname +mouse +mouseshape +mouse_dec
+mouse_gpm
-mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm
+multi_byte
+multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl
+postscript
+printer +profile +python +quickfix +reltime +rightleft +ruby
+scrollbind
+signs +smartindent -sniff +statusline -sun_workshop +syntax
+tag_binary
+tag_old_static -tag_any_white +tcl +terminfo +termresponse
+textobjects +title
+toolbar +user_commands +vertsplit +virtualedit +visual +visualextra
+viminfo
+vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset
+xim
+xsmp_interact +xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -
D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/
include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/
include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/
usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/
include -DORBIT2=1 -pthread -D_REENTRANT -I/usr/include/
libgnomeui-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/
include/gnome-keyring-1 -I/usr/include/libgnome-2.0 -I/usr/include/
libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/
gtk-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -
I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/
include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/
include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/
include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/gail-1.0 -I/
usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib/gtk-2.0/
include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/
directfb -I/usr/include/libpng12 -Wall -g -O2 -D_REENTRANT -
D_GNU_SOURCE -DDEBIAN -I/usr/local/include -D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64 -I/usr/lib/perl/5.10/CORE -I/usr/include/
python2.6 -pthread -I/usr/include/tcl8.4 -D_REENTRANT=1 -
D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1 -I/usr/lib/ruby/1.8/x86_64-
linux
Linking: gcc -L. -Wl,-Bsymbolic-functions -rdynamic -Wl,-export-
dynamic -Wl,-E -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -
latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lgio-2.0 -
lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lglib-2.0 -lgnomeui-2 -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -
lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lORBit-2 -lart_lgpl_2 -
lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -
lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -
lgconf-2 -lgthread-2.0 -lrt -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -
lXt -lncurses -lselinux -lacl -lgpm -Wl,-E -L/usr/local/lib -L/usr/
lib/perl/5.10/CORE -lperl -L/usr/lib/python2.6/config -lpython2.6 -L/
usr/lib -lz -lutil -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-
functions -L/usr/lib -ltcl8.4 -lieee -lruby1.8 -lrt -lm

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

To unsubscribe, reply using "remove me" as the subject.

Re: What are your "auto-nextline commenting" habits? [sj]

On 2010-03-31, smu johnson <smujohnson@gmail.com> wrote:
> Hi,
>
> I have an interesting question for all of you. Lately I've found I might enjoy
> the feature that keeps commenting lines after you hit <CR>, as it makes
> commenting in Perl much easier than having to add # to each of your lines.
>
> My question is... how do you quickly "exit" that commenting mode in a way that
> isn't annoying or frustrating? I am not quite sure how to "turn it off"
> without having to manually delete the new comment starter when I hit the 'o'
> command to open a new line. It thinks I want a comment still!
>
> PS: I noticed this behaviour starting when I installed NERDCommenter. I am
> not even sure if I can turn it off if I decide I don't like this
> newline-commenting feature.
>
> Thank you in advance.

The problem is that your 'formatoptions' (or just 'fo') option
includes the 'o' flag. It sounds like you want the 'r' flag but not
the 'o' flag. See

:help fo-table

for an explanation of what the various flags do.

To the question of why that behavior seems to have changed for you
recently, execute this:

:verbose set fo?

That will tell you the current value of the 'fo' option and where it
was last set. The proper way to set or restore the value of 'fo'
to what you want will depend on the output from that command.

My preferred value of 'formatoptions' contains 'r' but not 'o'.
That way I can easily insert code below a comment by typing 'o' on
the last comment line. If instead I want to insert more lines of
comment below an existing comment, I move the cursor to the last
comment line, hit 'A' then Enter, and I have a new line beginning
with the comment leader.

HTH,
Gary

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

To unsubscribe, reply using "remove me" as the subject.

Re: What are your "auto-nextline commenting" habits? [sj]

* smu johnson <smujohnson@gmail.com> [2010-04-01 00:24]:
> Lately I've found I might enjoy the feature that keeps commenting
> lines after you hit <CR>, as it makes commenting in Perl
> much easier than having to add # to each of your lines.
>
> how do you quickly "exit" that commenting mode in a way that isn't
> annoying or frustrating? I am not quite sure how to "turn it off"
> without having to manually delete the new comment starter when I hit
> the 'o' command to open a new line. It thinks I want a comment still!

when i open a new line from a "commented line" then vim
automatically copies the comment indentation. feature.
if however i dont want the comment on the line then
i simply delete it (within insert mode) with CTRL-U.

no need to change the comments options or anything.
easy and effective. :-)

Sven

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

To unsubscribe, reply using "remove me" as the subject.

Re: Why is there no :foldupdate?

set viminfo=
exe "norm! /fold\<cr>"
set foldlevel=0 foldmethod=expr foldexpr=getline(v:lnum)!~getreg('/',1) hls
redraw!
echo "search: fold"
sleep 5
exe "norm! /TRUE\<cr>"
norm! zX
norm! zx
norm! zC
redraw!
echo "search: TRUE"
"foldupdate
diff --git a/runtime/doc/fold.txt b/runtime/doc/fold.txt
index 60704c5..46a62a0 100644
--- a/runtime/doc/fold.txt
+++ b/runtime/doc/fold.txt
@@ -344,6 +344,12 @@ za When on a closed fold: open it. When folds are nested, you
zA When on a closed fold: open it recursively.
When on an open fold: close it recursively and set
'foldenable'.
+ *zU*
+zU Update folds and re-apply 'foldlevel'.
+ (This is usefull, to reevaluate a fold-expression).
+
+:foldu[pdate] *:foldupdate*
+ Force updating folds. Works like "zU".

*zv*
zv View cursor line: Open just enough folds to make the line in
diff --git a/src/ex_cmds.h b/src/ex_cmds.h
index bf66b40..319028c 100644
--- a/src/ex_cmds.h
+++ b/src/ex_cmds.h
@@ -399,6 +399,8 @@ EX(CMD_folddoclosed, "folddoclosed", ex_folddo,
RANGE|DFLALL|NEEDARG|EXTRA|NOTRLCOM),
EX(CMD_foldopen, "foldopen", ex_foldopen,
RANGE|BANG|WHOLEFOLD|TRLBAR|SBOXOK|CMDWIN),
+EX(CMD_foldupdate, "foldupdate", ex_foldupdate,
+ TRLBAR),
EX(CMD_for, "for", ex_while,
EXTRA|NOTRLCOM|SBOXOK|CMDWIN),
EX(CMD_function, "function", ex_function,
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index f8795fa..1279451 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -423,10 +423,12 @@ static void ex_X __ARGS((exarg_T *eap));
static void ex_fold __ARGS((exarg_T *eap));
static void ex_foldopen __ARGS((exarg_T *eap));
static void ex_folddo __ARGS((exarg_T *eap));
+static void ex_foldupdate __ARGS(());
#else
# define ex_fold ex_ni
# define ex_foldopen ex_ni
# define ex_folddo ex_ni
+# define ex_foldupdate ex_ni
#endif
#if !((defined(HAVE_LOCALE_H) || defined(X_LOCALE)) \
&& (defined(FEAT_GETTEXT) || defined(FEAT_MBYTE)))
@@ -11104,6 +11106,13 @@ ex_X(eap)

#ifdef FEAT_FOLDING
static void
+ex_foldupdate()
+{
+ curwin->w_foldinvalid = TRUE;
+ newFoldLevel();
+}
+
+ static void
ex_fold(eap)
exarg_T *eap;
{
diff --git a/src/normal.c b/src/normal.c
index 8b9fea7..6acfe5b 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -4930,6 +4930,12 @@ dozet:
curwin->w_p_fen = TRUE;
break;

+ /* "zU": Update Folding, replay 'foldlevel' */
+ case 'U': curwin->w_p_fen = TRUE;
+ curwin->w_foldinvalid = TRUE;
+ old_fdl = -1; /* force an update */
+ break;
+
/* "zv": open folds at the cursor */
case 'v': foldOpenCursor();
break;
(fullquote, because copying vim_dev)

On Mi, 31 Mär 2010, Christian Brabandt wrote:

> Hi,
>
> sometimes I am using fold expressions to simply hide away unwanted
> parts. Usually this boils down to
> :set fdm=expr fde=getline(v:lnum)!~getreg('/',1)
>
> While this works fine, it is only limited to whatever was in register @/
> when this setting was entered. Now this leaves an interesting question:
> When are 'foldexpr' reevaluated (are they at all)? Reading :h fold.txt
> does not mentioned when the fold expressions are reevaluated and folds
> are updated (or I might have missed it).
>
> Now the obvious cure to this is to reenter the foldexpression. So if I
> am searching for a different term, I need to enter
> :set fde=getline(v:lnum)!~getreg('/',1)
> and the folds will be updated.
>
> Of course, I could define my own :Foldupdate like this:
> :com! Foldupdate :exe "set fde=".&fde
>
> But this looks so fundamental, that I am wondering, whether I am the
> only one who is missing :foldupdate. Does anybody else think so? Or am I
> missing something obvious?
>
> PS: Looking at the source, it does not seem too hard, to define an extra
> :foldupdate command. Does that sound like a reasonable idea? I could
> prepare a patch for this, if there is interest.
>
> regards,
> Christian
>
> (Actually, I'd really like an RegisterChanged autocommand event, which
> could trigger an :foldupdate)

Ok, here is a patch, that implements :foldupdate as ex command and zU as
normal mode command.

Here is the testcase:
go to the vim-Src directory and execute the attached vim-script:

chrisbra t41:~/vim/src [1296]% ./vim -u NONE -N -S foldupdate.vim eval.c

Note, how the folding will be wrong, after the second search command
(and I have found no way to refresh the folding. zx and zX do not work,
though its description led me believe it could have. Well actually I
found one way: filtering the whole buffer through cat will also update
the folding)

When recompiling vim with the patch, the folding will be updated, when
:foldupdate is called.

regards,
Christian

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

To unsubscribe, reply using "remove me" as the subject.

how to center items on statusline

Hello,

How do I center-align some items on statusline ?

Thanks.
Viki

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

To unsubscribe, reply using "remove me" as the subject.

Re: No more 8-character limit?

On Mar 29, 8:40 pm, Antony Scriven <adscri...@gmail.com> wrote:

> You've never needed more than eight letters? --Antony

For what ? -- Yakov

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

To unsubscribe, reply using "remove me" as the subject.

What are your "auto-nextline commenting" habits? [sj]

Hi,

I have an interesting question for all of you.  Lately I've found I might enjoy the feature that keeps commenting lines after you hit <CR>, as it makes commenting in Perl much easier than having to add # to each of your lines.

My question is... how do you quickly "exit" that commenting mode in a way that isn't annoying or frustrating?  I am not quite sure how to "turn it off" without having to manually delete the new comment starter when I hit the 'o' command to open a new line.  It thinks I want a comment still!

PS:  I noticed this behaviour starting when I installed NERDCommenter.  I am not even sure if I can turn it off if I decide I don't like this newline-commenting feature.

Thank you in advance.

--
smu johnson <smujohnson@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

Re: Why is there no :foldupdate?

On Wed, 31 Mar 2010, Christian Brabandt wrote:

> On Wed, March 31, 2010 5:15 pm, Benjamin R. Haskell wrote:
> > On Wed, 31 Mar 2010, Paul wrote:
> >> On Wed, Mar 31, 2010 at 03:02:41PM +0200, Christian Brabandt wrote:
> >> > But this looks so fundamental, that I am wondering, whether I am
> >> > the only one who is missing :foldupdate. Does anybody else think
> >> > so? Or am I missing something obvious?
> >>
> >> You are not the only one. Every once in a while I will somehow see
> >> my folds messed up after some serious editing, when I know they are
> >> correct, and have to quit and re-edit the file in order to have
> >> them show correctly.
> >
> > I generally just type Ctrl-L to clear and redraw the screen. For
> > most filetypes I prefer fdm=syntax, so maybe something's different
> > with fdm=expr.
>
> Ctrl-L does not update folds.

Are you sure? Ctrl-L appears to just call redraw_later, and I didn't
fully trace the call tree, but redraw_later seems to end up calling
FOR_ALL_WINDOWS...redraw_win_later, which would end up calling
redrawWinline (which does something with folds), eventually... yes?

All I know is that every time I've noticed an improper fold, I've hit
Ctrl-L to correct the problem.

But again, I don't use fdm=expr. So, maybe whatever mechanism marks a
fold as invalid doesn't use the same logic when fdm=syntax.

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

To unsubscribe, reply using "remove me" as the subject.

Google Chrome under Linux and problems with "* and "+

Hi all :)

Since this may be my fault (or Chrome's fault) I won't go into deep
details. Instead, I'll show a small example.

I select and copy in Google Chrome (using Ctrl-C) the word "Raúl"
(that is, my name). I open any program and paste, and the text pasted
is exactly "Raúl".

Now I open console Vim under gnome-terminal and I run ":registers".
This is what I have (excerpted):
"* Raúl
"+ Raúl

In the first line the text is correct, but in the second line the
uacute doesn't appear and instead you can see the latin-1
representation.

Any other program I've tested works perfectly when pasting text from
Google Chrome, and Vim works perfectly when pasting text from other
programs, so the problem looks like a weird interaction between Google
Chrome and Vim, or just with the way Google Chrome uses the clipboard
selection.

Anyone knows which can be the problem?

Thanks in advance, guys!

--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

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

To unsubscribe, reply using "remove me" as the subject.

Re: How to remember end of line when quitting/reopening in insert mode

On Mar 31, 6:19 pm, Andy Wokula <anw...@yahoo.de> wrote:

> - disable existing last-position-jump code in the vimrc
> - put the attached file in the plugin folder

It seems to work very nicely. Thanks.

NB: Your code works when "set insertmode" is present in .vimrc (as a
special case gvim -y).
It does not work when "startinsert" is used instead (which has the
advantage of keeping the Esc key).

Could you cure that?

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

To unsubscribe, reply using "remove me" as the subject.

Re: limiting omnicompletion

On Wed, 31 Mar 2010 11:17:31 -0700
Gary Johnson <garyjohn@spocom.com> wrote:
> :help 'complete'
>
> perhaps?

:D perhaps. Turns out you can turn omnicompletion/ctags right off and
use your own dictionary:

set complete=k
set dictionary=/path/yourtagsdictionary

This way it doesn't even need to be a ctags formatted file. I got
turned onto the completion functions with omincomplete, I didn't
realize there were other options. The options are under:

:help ins-completion

But the bit about how to set which option is indeed under "help
complete". Thanks!

--
MK <halfcountplus@intergate.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

To unsubscribe, reply using "remove me" as the subject.

Re: limiting omnicompletion

On 2010-03-31, MK wrote:
> I'd like to use omnicompletion with a tags file that I write. I
> don't want any other tags included -- however, it seems to
> automatically scan headers (which is particularly annoying in gvim). Is
> there a way to prevent that?

:help 'complete'

perhaps?

HTH,
Gary

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

limiting omnicompletion

I'd like to use omnicompletion with a tags file that I write. I
don't want any other tags included -- however, it seems to
automatically scan headers (which is particularly annoying in gvim). Is
there a way to prevent that?

--
MK <halfcountplus@intergate.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

To unsubscribe, reply using "remove me" as the subject.

Re: How to remember end of line when quitting/reopening in insert mode

" Vim plugin -- last-position-jump improved (esp. for Easy Vim)
" File: lastpos.vim
" Created: 2010 Mar 24
" Last Change: 2010 Mar 31
" Rev Days: 3
" Author: Andy Wokula <anwoku@yahoo.de>
"
" TODO
" + how can we be sure that <C-R>=... will be executed in Insert mode?
" ! use intermediate <Plug>LastPos
" + why is :normal! g`" wrapped with :exec?
" ! once the code was a one-liner
" + use this assumption:
" if not present, Vim will initialize the '"'-mark with [0,1,1,0]
" :au BufReadPost * echomsg string(getpos("'\""))
" + don't move the cursor if another plugin already moved it
" + don't move the cursor for special buffers (buftype not empty) [1]

" [1] added, although jumping to help tags seems to work without this
" guard

map <Plug>LastPos <Nop>
cmap <Plug>LastPos <Nop>
ino <silent> <Plug>LastPos <C-R>=''[setpos('.',getpos("'\""))]<CR>

augroup LastPos
au! BufReadPost * call s:LastPos(&insertmode)
augroup END

func! s:LastPos(mode)
if a:mode == 2
au! LastPos InsertEnter
call feedkeys("\<Plug>LastPos")
return
endif
let m = "'\""
if getpos(m) != [0,1,1,0] && line(m) <= line("$")
\ && getpos(".") == [0,1,1,0]
\ && &buftype == ""
if a:mode == 1
au LastPos InsertEnter * call s:LastPos(2)
else
normal! g`"
endif
endif
endfunc

" vim:et tw=72:
Am 31.03.2010 16:42, schrieb Jean Johner:
> On Mar 31, 1:01 am, Tony Mechelynck<antoine.mechely...@gmail.com>
> wrote:
>
>> so Christian's observations leave
>> me baffled.
>
> Please find below a reproduceable situation where help side-effects of
> Andy's code appear:
>
> Use vimrc_example.vim completed with Andy's code as .vimrc
> Go to home directory
> rm .viminfo (DON'T FORGET)
> gvim file1
> :set insertmode
> CTRL-O :h zR
>
> Result: the help window opens at the beginning of fold.txt (not the
> correct place)
>
> If :set insertmode is not typed, the problem does not occur.
>
> Do you reproduce that?

Yes. Vim first jumps to the tag, then lastpos jumps to `" which is
initialized with (line 1, col 1).

I added more guards.

Installation (suggestion only):
- disable existing last-position-jump code in the vimrc
- put the attached file in the plugin folder

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

To unsubscribe, reply using "remove me" as the subject.

Re: Why is there no :foldupdate?

On Wed, March 31, 2010 5:15 pm, Benjamin R. Haskell wrote:
> On Wed, 31 Mar 2010, Paul wrote:
>> On Wed, Mar 31, 2010 at 03:02:41PM +0200, Christian Brabandt wrote:
>> > But this looks so fundamental, that I am wondering, whether I am the
>> > only one who is missing :foldupdate. Does anybody else think so? Or
>> > am I missing something obvious?
>>
>> You are not the only one. Every once in a while I will somehow see my
>> folds messed up after some serious editing, when I know they are
>> correct, and have to quit and re-edit the file in order to have them
>> show correctly.
>
> I generally just type Ctrl-L to clear and redraw the screen. For most
> filetypes I prefer fdm=syntax, so maybe something's different with
> fdm=expr.

Ctrl-L does not update folds.
(Usually I don't use folding. Only when searching for something
I find foldmethod=expr convenient).

> I notice the improper folds most frequently when I've just added another
> branch to a conditional (e.g. turning something with the structure
> if(1){}else{}
> into
> if(1){}elsif(2){}else{}
> ) but I can't seem to come up with a good minimal case. I'll try to do
> that next time I notice the problem.

I remember that fdm=syntax is mentioned several times in todo.txt.

regards,
Christian

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

To unsubscribe, reply using "remove me" as the subject.

Re: Checking return codes?

>> Is it possible to check the return code of an Ex command?  I currently
>> have:
>>
>> function! Grep(pattern, location)
>>     exe "noautocmd vimgrep /" . a:pattern . "/gj " . a:location " | copen"
>> endfunction
>>
>> which causes an error with copen if vimgrep doesn't return anything.
>> I'd like to handle the error a little more gracefully if possible.
>
> You can use a :try :catch block and catch pattern E480.
> (Seems like the help tag E480 is wrong).
> And you can also check, whether the result returned by getqflist() is
> empty.

The getqflist() is the approach I took:

function! Grep(pattern, location)
exe "noautocmd vimgrep /" . a:pattern . "/gj " . a:location
if (!empty(getqflist()))
silent exe 'copen'
endif
endfunction

which works nicely for me.

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

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

To unsubscribe, reply using "remove me" as the subject.

Re: Checking return codes?

On Wed, March 31, 2010 5:16 pm, Chris Sutcliffe wrote:
> Is it possible to check the return code of an Ex command? I currently
> have:
>
> function! Grep(pattern, location)
> exe "noautocmd vimgrep /" . a:pattern . "/gj " . a:location " | copen"
> endfunction
>
> which causes an error with copen if vimgrep doesn't return anything.
> I'd like to handle the error a little more gracefully if possible.

You can use a :try :catch block and catch pattern E480.
(Seems like the help tag E480 is wrong).
And you can also check, whether the result returned by getqflist() is
empty.

see
:h :try
:h :catch
:h getqflist()

regards,
Christian

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

To unsubscribe, reply using "remove me" as the subject.

Checking return codes?

Hi All,

Is it possible to check the return code of an Ex command? I currently have:

function! Grep(pattern, location)
exe "noautocmd vimgrep /" . a:pattern . "/gj " . a:location " | copen"
endfunction

which causes an error with copen if vimgrep doesn't return anything.
I'd like to handle the error a little more gracefully if possible.

Thank you,

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

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

To unsubscribe, reply using "remove me" as the subject.

Re: Why is there no :foldupdate?

On Wed, 31 Mar 2010, Paul wrote:

> On Wed, Mar 31, 2010 at 03:02:41PM +0200, Christian Brabandt wrote:
> > But this looks so fundamental, that I am wondering, whether I am the
> > only one who is missing :foldupdate. Does anybody else think so? Or
> > am I missing something obvious?
>
> You are not the only one. Every once in a while I will somehow see my
> folds messed up after some serious editing, when I know they are
> correct, and have to quit and re-edit the file in order to have them
> show correctly.

I generally just type Ctrl-L to clear and redraw the screen. For most
filetypes I prefer fdm=syntax, so maybe something's different with
fdm=expr.

I notice the improper folds most frequently when I've just added another
branch to a conditional (e.g. turning something with the structure
if(1){}else{}
into
if(1){}elsif(2){}else{}
) but I can't seem to come up with a good minimal case. I'll try to do
that next time I notice the problem.


In case they affect anything, I also still have the following mappings
in place:

aug NoInsertFolding
au!
au InsertEnter * let b:oldfdm = &l:fdm | setlocal fdm=manual
au InsertLeave * let &l:fdm = b:oldfdm
aug END

They have their own problems (referenced in another thread), but are
better than the madness of folds changing mid-insert.

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

To unsubscribe, reply using "remove me" as the subject.

Re: .vimrc colors ; highlight xxxxxx ctermfg=cccccc what xxxxxx and cccccc are OK?

On 31/03/10 03:27, dgerman wrote:
> I am running on a shared host
>
> $TERM=xterm-color
> vim version 7.0.237
> i686-redhat-linux-gnu
>
> I have added to my .vimrc file:
>
> highlight comment ctermfg=darkgray
> highlight constant ctermfg=darkblue
> highlight Identifier ctermfg=black " html< and />
> highlight search ctermbg=lightYellow ctermfg=black
> highlight Special ctermfg=Gray
> highlight Statment ctermfg=red ctermbg=yellow
> highlight Function ctermfg=darkGray " begin tag wickets , =
> highlight Type ctermfg=Darkgray
> highlight Question ctermfg=red ctermbg=blue
> highlight NonText ctermfg=darkGray
> highlight PreProc ctermfg=darkGray
> highlight htmlTitle ctermfg=DarkGray
>
>
> The entire .vimrc is at http://www.Real-World-Systems.com/docs/vimrc
>
>
> when editing an .html file
>
> text is in black, that's good
> wickets (< and> ) are in black, that's ok
> HTML tag names are in yellow (?) that's good
> broken tag , (second< in a row ) is gray/red that's good
>
> &amp; etc are shown in gray. that's Not Nice
>
> keywords before = are blackBold
> values after = are blue, that's ok
>
> h3 is in violet(?)
>
>
> 1) what colornames are permitted, ( orange is not )
>
> 2) where is the list of keywords?
>
>
>
> Thanks in advance
>

IIUC, for xxxxxx (the highlight group name) almost any keyword is
_permitted_, but a name is only useful if it is _used_ somewhere.

- Some groups are predefined by Vim:
:help hl-<Ctrl-D>
- Some others, even without a help entry, are defined by :syntax on:
:view $VIMRUNTIME/syntax/syncolor.vim
- Some more are defined by the various syntax scripts, usually (but not
always: see for instance htmlBold, htmlItalic, etc.) by linking to one
of Vim's default groups:
:view $VIMRUNTIME/syntax/vim.vim
:view $VIMRUNTIME/syntax/c.vim
:view $VIMRUNTIME/syntax/html.vim
:view $VIMRUNTIME/syntax/sh.vim
:view $VIMRUNTIME/syntax/dosbatch.vim
:view $VIMRUNTIME/syntax/perl.vim
:view $VIMRUNTIME/syntax/python.vim
etc. etc. etc.
- You may use any existing name (including a new one that you define
yourself) for matching:
:help :match
:help :2match
:help :3match
:help matchadd()
:help matchdelete()


For cccc, the color name, some names are permitted for ctermbg=
ctermfg=; the same, plus many more, are permitted for guibg= guifg=

First, in the console: see
:help cterm-colors.
Numbers from 0 to one less than 't_Co' are permitted (but they don't
mean the same everywhere: for instance 1 means red on the Linux console,
but blue on the Dos console), and also the names listed in that help topic.

For the GUI, the list can be obtained by looking at the file rgb.txt. On
Unix/Linux, you probably already have one but its location varies from
one distro to the next, you may have to search. On Windows, you may or
may not have one in $VIMRUNTIME for use by gvim. On Windows, OS-defined
names are also permitted, see
:help gui-colors
:help win32-colors
:help dos-colors
In addition, in the GUI, colors can be defined as #xxxxxx where xxxxxx
are six hex digits (no more, no less): two for the red component, then
two for the green component, then two for the blue component.
"Abbreviated" values with only three hex digits, as used in HTML and
CSS, are not accepted by Vim.


Best regards,
Tony.
--
Nihilism should commence with oneself.

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

To unsubscribe, reply using "remove me" as the subject.

Re: Why is there no :foldupdate?

On Wed, Mar 31, 2010 at 03:02:41PM +0200, Christian Brabandt wrote:
>But this looks so fundamental, that I am wondering, whether I am the
>only one who is missing :foldupdate. Does anybody else think so? Or am I
>missing something obvious?

You are not the only one. Every once in a while I will somehow see my folds messed up after some serious editing, when I know they are correct, and have to quit and re-edit the file in order to have them show correctly.

--

.

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

To unsubscribe, reply using "remove me" as the subject.

Re: How to remember end of line when quitting/reopening in insert mode

On Mar 31, 1:01 am, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:

>so Christian's observations leave
> me baffled.

Please find below a reproduceable situation where help side-effects of
Andy's code appear:

Use vimrc_example.vim completed with Andy's code as .vimrc
Go to home directory
rm .viminfo (DON'T FORGET)
gvim file1
:set insertmode
CTRL-O :h zR

Result: the help window opens at the beginning of fold.txt (not the
correct place)

If :set insertmode is not typed, the problem does not occur.

Do you reproduce that?

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

To unsubscribe, reply using "remove me" as the subject.

Re: Unexpected effect of "g:netrw_fastbrowse=2"

On Mar 31, 3:11 pm, Charles Campbell <Charles.E.Campb...@nasa.gov>
wrote:
>
> I do see the effect -- its on my todo list.  It might be awhile, though...

Thank you. Good luck.

Regards
Jean

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

To unsubscribe, reply using "remove me" as the subject.

Re: Unexpected effect of "g:netrw_fastbrowse=2"

Jean Johner wrote:
> Hi Chip!
>
> I had no answer for the above message.
>
> My version of netrw is v137l.
>
> With "let g:netrw_fastbrowse" absent, "let g:netrw_fastbrowse=0", "let
> g:netrw_fastbrowse=1", the netrw buffer is always marked unlisted (It
> appers with "u" when you type :ls!), so that it never shows when you
> use :bp. Which is in my opinion the expected behaviour.
>
> With "let g:netrw_fastbrowse=2", the netrw buffer is no longer
> unlisted after the second ":e." call, so that it shows when you
> use :bp. Can you reproduce that?
>

I do see the effect -- its on my todo list. It might be awhile, though...

Regards,
Chip Campbell

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

To unsubscribe, reply using "remove me" as the subject.

Why is there no :foldupdate?

Hi,

sometimes I am using fold expressions to simply hide away unwanted
parts. Usually this boils down to
:set fdm=expr fde=getline(v:lnum)!~getreg('/',1)

While this works fine, it is only limited to whatever was in register @/
when this setting was entered. Now this leaves an interesting question:
When are 'foldexpr' reevaluated (are they at all)? Reading :h fold.txt
does not mentioned when the fold expressions are reevaluated and folds
are updated (or I might have missed it).

Now the obvious cure to this is to reenter the foldexpression. So if I
am searching for a different term, I need to enter
:set fde=getline(v:lnum)!~getreg('/',1)
and the folds will be updated.

Of course, I could define my own :Foldupdate like this:
:com! Foldupdate :exe "set fde=".&fde

But this looks so fundamental, that I am wondering, whether I am the
only one who is missing :foldupdate. Does anybody else think so? Or am I
missing something obvious?

PS: Looking at the source, it does not seem too hard, to define an extra
:foldupdate command. Does that sound like a reasonable idea? I could
prepare a patch for this, if there is interest.

regards,
Christian

(Actually, I'd really like an RegisterChanged autocommand event, which
could trigger an :foldupdate)

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

To unsubscribe, reply using "remove me" as the subject.

Re: Unexpected effect of "g:netrw_fastbrowse=2"

Hi Chip!

I had no answer for the above message.

My version of netrw is v137l.

With "let g:netrw_fastbrowse" absent, "let g:netrw_fastbrowse=0", "let
g:netrw_fastbrowse=1", the netrw buffer is always marked unlisted (It
appers with "u" when you type :ls!), so that it never shows when you
use :bp. Which is in my opinion the expected behaviour.

With "let g:netrw_fastbrowse=2", the netrw buffer is no longer
unlisted after the second ":e." call, so that it shows when you
use :bp. Can you reproduce that?

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

To unsubscribe, reply using "remove me" as the subject.

Tuesday, March 30, 2010

Re: Why no window-local mapping?

Tony Mechelynck wrote:
> Benjamin Haskell told you, but you should have checked the date on line
> 1 of the file. Apparently not everyone keeps his Vim runtimes up-to-date
> as diligently as I do. ;-)

I'm not sure even *Bram* keeps his Vim runtimes as up-to-date as
diligently as you do... ;-)

-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

To unsubscribe, reply using "remove me" as the subject.

.vimrc colors ; highlight xxxxxx ctermfg=cccccc what xxxxxx and cccccc are OK?

I am running on a shared host

$TERM=xterm-color
vim version 7.0.237
i686-redhat-linux-gnu

I have added to my .vimrc file:

highlight comment ctermfg=darkgray
highlight constant ctermfg=darkblue
highlight Identifier ctermfg=black " html < and />
highlight search ctermbg=lightYellow ctermfg=black
highlight Special ctermfg=Gray
highlight Statment ctermfg=red ctermbg=yellow
highlight Function ctermfg=darkGray " begin tag wickets , =
highlight Type ctermfg=Darkgray
highlight Question ctermfg=red ctermbg=blue
highlight NonText ctermfg=darkGray
highlight PreProc ctermfg=darkGray
highlight htmlTitle ctermfg=DarkGray


The entire .vimrc is at http://www.Real-World-Systems.com/docs/vimrc


when editing an .html file

text is in black, that's good
wickets ( < and > ) are in black, that's ok
HTML tag names are in yellow (?) that's good
broken tag , (second < in a row ) is gray/red that's good

&amp; etc are shown in gray. that's Not Nice

keywords before = are blackBold
values after = are blue, that's ok

h3 is in violet(?)


1) what colornames are permitted, ( orange is not )

2) where is the list of keywords?

Thanks in advance

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

Re: Why no window-local mapping?

On 30/03/10 19:14, Jeenu wrote:
>
>
> On Mar 30, 10:04 pm, Tony Mechelynck<antoine.mechely...@gmail.com>
> wrote:
>> See line 2245 in $VIMRUNTIME/doc/todo.txt (:help todo.txt) dated 2010
>> Mar 02 as shown on its first line.
>
> Sorry. The said doc on my Vim (Ubuntu) doesn't have anything
> interesting at that line. What I've is:
>
> 2242 specific prefixes with suffixes.
> 2243 Alternative:
> 2244 PSFX {flag} {pchop} {padd} {pcond} {schop} {sadd}[/flags]
> {scond}
> 2245 We might not need this at all, you can use the NEEDAFFIX flag
> and the
> 2246 affix which is required.
> 2247 - When a suffix has more than one syllable, it may count as a
> word for
> 2248 COMPOUNDWORDMAX.
> 2249 - Add flags to count extra syllables in a word. SYLLABLEADD1
> SYLLABLEADD2,
> 2250 etc.? Or make it possible to specify the syllable count of a
> word
>
> Um, what's that you're pointing at?

Benjamin Haskell told you, but you should have checked the date on line
1 of the file. Apparently not everyone keeps his Vim runtimes up-to-date
as diligently as I do. ;-)

The latest version of that file is always available at
ftp://ftp.vim.org/pub/vim/runtime/doc/todo.txt so you could have done:

:sview +2245 ftp://ftp.vim.org/pub/vim/runtime/doc/todo.txt

(there is also an rsync server). Sorry I didn't think to mention this
command earlier.

>
> Thanks
> Jeenu
>

My pleasure.
Tony.
--
"My particular problem is with registry entries, which seem to just
accumulate
like plastic coffee cups..." -- Paul Moore

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

To unsubscribe, reply using "remove me" as the subject.

Re: Commnad over a window

On 03/02/10 01:27, JuanPablo wrote:
> and there is some way of listing the windows?
> similar to buffers
> ?

For buffers, it's easy: see :help :ls; but for use in a script see the
help links near the bottom of this message.

For windows, it's more involved: windows are defined by their number
(starting at 1 at top-left and with the highest number at bottom-right)
within their tabpages (which are also numbered starting at 1). Unlike
buffers, there is no "window identifier" which remains unchanged when
you move windows and tabpages around, or open and close them.

Now here we go:

tabpagenr()
the number of the current tab page
tabpagenr('$')
the total number of tab pages

winnr()
the number of the current window within the current tab page
winnr('$')
the number of windows within the current tab page
winnr('#')
the number of the latest window accessed in this tab
before the current one; or 0 if there was no previous window
or if it was in a different tabpage

tabpagewinnr(t)
the number of the current window in the t-th tab
tabpagewinnr(t,'$')
the total number of windows in the t-th tab
tabpagwinnr(t,'#')
the previous window for the t-th tab

tabpagebuflist()
a List whose items are the buffer numbers for the current tab
This is zero-based!
tabpagebuflist()[0] is the number of the buffer in window 1
tabpagebuflist(t)
the same for the t-th tab
Notes:
- In case of error (t < 1 || t > tabpagenr('$'),
the number 0 is returned.
- A buffer can be displayed in more than one window.

winbufnr(0)
the number of the buffer in the current window
(of the current tab)
winbufnr(w)
the number of the buffer in the w-th window
(of the current tab)
== tabpagebuflist()[w - 1]
Returns -1 if there is no w-th window

See also:
:help tabp*(<Ctrl-D>
:help win*(<Ctrl-D>
:help buf*(<Ctrl-D>

where <Ctrl-D> means: hit Ctrl-D (i.e. hit d while holding Ctrl).

And see ":help setting-tabline" for a couple of user-defined functions
which use these builtin functions in order to display the text-mode tab
line (showing the current buffer in each tab). See also the example
under tabpagebuflist() to get a List of all buffers in all tabs (some of
them may appear more than once, and hidden buffers, which are loaded but
not displayed, won't appear at all in that List). Either of these
examples can be expanded to get a two-level list of all buffers listed
per tab.

Best regards,
Tony.
--
Adore, v.:
To venerate expectantly.
-- Ambrose Bierce, "The Devil's Dictionary"

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

To unsubscribe, reply using "remove me" as the subject.

Re: How to remember end of line when quitting/reopening in insert mode

On 28/03/10 15:54, Andy Wokula wrote:
> Am 28.03.2010 15:00, schrieb Christian Brabandt:
>> Hi Andy!
>>
>> On So, 28 Mär 2010, Andy Wokula wrote:
>>
>>> Am 25.03.2010 16:52, schrieb Christian Brabandt:
>>>> BTW: I noticed some unpleasant side effects when playing around with
>>>> Andy's solution. The plugin seems to interfer with jumping to the
>>>> correct help section. Using :h topic this put me somewhere near the
>>>> topic,
>>>> but not at the right position. This does not happen everytime and I
>>>> assume
>>>> this only happens, when a help page is opened for the first(?) time.
>>>
>>> Maybe this has to do with updating the LOCAL ADDITIONS section in the
>>> main help page.
>>
>> I am sorry, but I don't understand.
>
> The main help page ('helpfile')
> :h
> has a section
> :h local-additions
> which collects the headlines of plugin docs (~/.vim/doc/*.txt, ...).
> Vim has to update it frequently, as $VIMRUNTIME/doc/help.txt is not
> changed.
> Maybe this process has influence on the cursor position.
>

This ought not to influence other helpfiles, and even in help.txt the
tags file for help contains search commands, not line numbers (see :help
help-tags; the single exception is the entry for help-tags itself, which
sends you to line 1 of the tags file), so I don't believe it would be
relevant either.

As for updating it "frequently", does Vim update it more often than (1)
at startup and (2) when :helptags is run? That should be enough,
shouldn't it?

OTOH, all helpfiles have 'nomodifiable' set, and IIRC you're setting the
cursor location at an InsertEnter autocommand, which ought not to be
triggered for a 'nomodifiable' file, so Christian's observations leave
me baffled.


Best regards,
Tony.
--
If anything can go wrong, it will.

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

To unsubscribe, reply using "remove me" as the subject.

Re: How to remember end of line when quitting/reopening in insert mode

On 25/03/10 15:13, Andy Wokula wrote:
[...]
> I think an example vimrc should be simple rather than 100% correct.
> Maybe the code is worth a tip on vim.wikia.com, and the example vimrc
> could then refer to it.
>

I think the vimrc_example.vim should set an example, and as such it
cannot afford to be sloppy. Anything in it which doesn't work as
intended should be corrected, if possible: that's why I recommend to
implement it by sourcing it from the user's vimrc (so the most recent
version is always used) rather than by copying it (which "freezes" the
version used) then more or less misguidedly adding the user's settings
in the same file. (I know Bram disagrees about this source-vs.-copyedit
preference, and I don't completely fathom his reasons for it.)


Best regards,
Tony.
--
default, n.:
[Possibly from Black English "De fault wid dis system is you,
mon."] The vain attempt to avoid errors by inactivity. "Nothing will
come of nothing: speak again." -- King Lear.
-- Stan Kelly-Bootle, "The Devil's DP Dictionary"

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

To unsubscribe, reply using "remove me" as the subject.

Re: gVim stripping diacritics not in keyboard charset

Thanks, but I'm sorry, your suggestions didn't help ... it really
doesn't matter which terminal or file encoding I have set, my font is
capable of displaying such characters (I can paste a "Å™"' through
clipboard or open any file that contains it all right) and that
character is present in my locale "Czech_Republic.1250".

I think it's got something to do with the way Vim handles Windows
input messages (since the console Windows version works OK).

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: Possible error with jumplist management in insert mode with

On Tue, Mar 30, 2010 at 05:22:11AM -0700, Jean Johner wrote:
>Conclusion: pattern2 has vanished from the jumplist in 2).

An AOL-like 'me too!'.

--

.

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: concatenate with '.' or without

On 31/01/10 18:12, Gary Johnson wrote:
> On 2010-01-30, Bee wrote:
>> On Jan 29, 10:52 am, "Benjamin R. Haskell"<v...@benizi.com> wrote:
>>> On Fri, 29 Jan 2010, Bee wrote:
>>>> On Jan 29, 7:43 am, "Benjamin R. Haskell"<v...@benizi.com> wrote:
>>>>> ...
>>>>> :redir @a
>>>>> ...
>>>> How to save directly to a filename?
>>>> [...]
>>>> But this creates a file named savevimrc in $HOME
>>>> redir> savevimrc
>>>> How to expand savevimrc to the file name?
>>> :exe "redir> " . savevimrc
>>
>> Will this always do the same?
>> :exe "redir>" savevimrc
>
> Yes.
>
>> From what I have read '.' concatenates without adding spaces,
>> whereas without using '.' a space will be added.
>
> '.' is an expression operator and will concatenate two strings in a
> context where an expression is allowed. Not having to use a '.'
> between arguments of an exe command is a property of the exe
> command, which concatenates all of its arguments with intervening
> spaces.
>
>> Is it just better to get the habit of using '.' ?
>
> No, not if you're paying attention to the context in which you're
> concatenating strings. I prefer not to use the '.' in exe arguments
> if I can avoid it because it looks less cluttered.
>
> Now that I look at them, the examples under ":help :exe" are
> confusing. The first two examples include spaces after the executed
> command names even though none are needed there.
>
> Regards,
> Gary
>
>

I agree: both "exe[cute]" and "echo" treat their arguments the same way:
any number of expressions are allowed, and their values are concatenated
space-separated into one long string before being further processed.
Then :echo displays the result while :exe treats it as an ex-command
line. IOW you can always use :echo instead of :exe to make sure which
ex-command :exe would generate.

Me too, I prefer using

:exe "command" variable1 variable2 variable3

rather than

:exe "command " . variable1 . " " . variable2 . " " . variable3

It's easier to type, and at least as easy to understand once you
remember that :echo and :exe both accept any number of arguments, which
they will concatenate in the same manner.

And indeed, that behaviour is not going to change: it would needlessly
break compatibility with uncounted existing scripts, something which
Bram would never accept (needlessly breaking, I mean: a compatibility
break is only accepted when there is an obvious advantage and no great
risk in doing so, for instance when 1.23 was redefined as the floating
number "one unit and twenty-three hundredths" where before it had been
the string expression 1 . 23, which evaluated to '123' [and with the
spaces it still does]).


Best regards,
Tony.
--
Experience is what you get when you don't get what you want.

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: Why no window-local mapping?

On Mar 30, 10:15 pm, "Benjamin R. Haskell" <v...@benizi.com> wrote:
> That was line 1722 on my system (Last change: 2009 Aug 09).  Might be
> hard to find, and it's short.  Reproduced here:
>
> In the section 'User Friendlier:'
> ...
> -   Add mappings local to a window: ":map <window> ..."?
>
> The '-' indicates 'unclassified' as to its priority (as seen at the top
> of that file)

That was 2148 on mine...

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

To unsubscribe, reply using "remove me" as the subject.

Re: Why no window-local mapping?

> mappings local to a specific syntax region (inspired by TextMate?).

In Emacs, you have overlays (arbitrary text regions) that can store
metadata about the text within that region and have special mappings.
IIRC this also makes it easy to define popup menus specific to that
region.

I don't think this would make things overly complicated. IMHO it would
rather simplify writing certain type of plugins that now have to store
that metadata someplace.

You could simplify window-local maps with buffer-local maps that
behave differently depending on the value of a window-local variable,
I guess.

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: Why no window-local mapping?

On Tue, 30 Mar 2010, Tony Mechelynck wrote:

> On 30/03/10 14:18, Jeenu wrote:
> > Hi,
> >
> > I know of<buffer> local mapping and global mapping. I wonder why
> > there isn't a<window>/<tab> local mapping option for Vim. I use
> > some Vim windows/tabs exclusively for navigating quick fix lists. On
> > those windows, I keep<C-N> nd<C-P> globally mapped to :lnext (or
> > :cnext) and :lprevious. The problem with buffer-local mappings here
> > is that every time the list will load a new buffer which might not
> > have this mapping set. Had the mappings been window- or tab-local, I
> > could have reused the same mappings on other windows for something
> > else - may be page navigation.
> >
> > Any reason why those are omitted, and any plans to have them in Vim?
> >
> > Thanks
> > Jeenu
> >
>
> See line 2245 in $VIMRUNTIME/doc/todo.txt (:help todo.txt) dated 2010
> Mar 02 as shown on its first line.

That was line 1722 on my system (Last change: 2009 Aug 09). Might be
hard to find, and it's short. Reproduced here:

In the section 'User Friendlier:'
...
- Add mappings local to a window: ":map <window> ..."?

The '-' indicates 'unclassified' as to its priority (as seen at the top
of that file)

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: Why no window-local mapping?

On Mar 30, 10:04 pm, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
> See line 2245 in $VIMRUNTIME/doc/todo.txt (:help todo.txt) dated 2010
> Mar 02 as shown on its first line.

Sorry. The said doc on my Vim (Ubuntu) doesn't have anything
interesting at that line. What I've is:

2242 specific prefixes with suffixes.
2243 Alternative:
2244 PSFX {flag} {pchop} {padd} {pcond} {schop} {sadd}[/flags]
{scond}
2245 We might not need this at all, you can use the NEEDAFFIX flag
and the
2246 affix which is required.
2247 - When a suffix has more than one syllable, it may count as a
word for
2248 COMPOUNDWORDMAX.
2249 - Add flags to count extra syllables in a word. SYLLABLEADD1
SYLLABLEADD2,
2250 etc.? Or make it possible to specify the syllable count of a
word

Um, what's that you're pointing at?

Thanks
Jeenu

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

To unsubscribe, reply using "remove me" as the subject.

Re: Why no window-local mapping?

On Mar 30, 6:37 pm, Andy Wokula <anw...@yahoo.de> wrote:
> Do you think of
>     :map <window>
>     :map <tabpage>
> next to
>     :map <buffer>
> ?

I'd write or script it as
:map <window> <C-N> :lnext
:map <window> <C-P> :lnext

when I'm at the required window

Thanks
Jeenu

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: Why no window-local mapping?

On 30/03/10 14:18, Jeenu wrote:
> Hi,
>
> I know of<buffer> local mapping and global mapping. I wonder why
> there isn't a<window>/<tab> local mapping option for Vim. I use some
> Vim windows/tabs exclusively for navigating quick fix lists. On those
> windows, I keep<C-N> nd<C-P> globally mapped to :lnext (or :cnext)
> and :lprevious. The problem with buffer-local mappings here is that
> every time the list will load a new buffer which might not have this
> mapping set. Had the mappings been window- or tab-local, I could have
> reused the same mappings on other windows for something else - may be
> page navigation.
>
> Any reason why those are omitted, and any plans to have them in Vim?
>
> Thanks
> Jeenu
>

See line 2245 in $VIMRUNTIME/doc/todo.txt (:help todo.txt) dated 2010
Mar 02 as shown on its first line.


Best regards,
Tony.
--
"Nuclear war would mean abolition of most comforts, and disruption of
normal routines, for children and adults alike."
-- Willard F. Libby, "You *Can* Survive Atomic Attack"

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: Vim on Snow Leopard

Hi Bob,

I use MacVim here on Snow Leopard and it works perfectly fine.
Is there any difference between MacVim and Vim?
I don't think so. If you want a commandline Vim and you have
MacVim installed you can simply run
/Applications/MacVim.app/Contents/MacOS/Vim.

It you need any more compiletime options you can simply compile MacVim
yourself which also works perfectly fine.

On 3/30/10 3:44 PM, Robert H wrote:
> I know there is MacVim but I want a stock Vim.
> [...]
> Bob

--
Viele Grüße,
Andreas Klein

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Vim on Snow Leopard

I know there is MacVim but I want a stock Vim. Does it still compile
cleanly? I ask because I tried and I got:

make[1]: *** [objects/gui_mac.o] Error 1
make: *** [first] Error 2

Plus a whole lot of gui_mac warnings....

I passed in via a sourced script:

export CONF_OPT_PERL='--enable-perlinterp'
export CONF_OPT_PYTHON='--enable-pythoninterp'
export CONF_OPT_TCL='--enable-tclinterp --with-tcl=tclsh8.5'
export CONF_OPT_MZSCHEME='--enable-mzschemeinterp'
export CONF_OPT_CSCOPE='--enable-cscope'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_FEAT='--with-features=huge'
export CONF_OPT_COMPBY='"--with-compiledby=my@address.com"'

Bob

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: Why no window-local mapping?

Am 30.03.2010 14:18, schrieb Jeenu:
> Hi,
>
> I know of<buffer> local mapping and global mapping. I wonder why
> there isn't a<window>/<tab> local mapping option for Vim. I use some
> Vim windows/tabs exclusively for navigating quick fix lists. On those
> windows, I keep<C-N> nd<C-P> globally mapped to :lnext (or :cnext)
> and :lprevious. The problem with buffer-local mappings here is that
> every time the list will load a new buffer which might not have this
> mapping set. Had the mappings been window- or tab-local, I could have
> reused the same mappings on other windows for something else - may be
> page navigation.
>
> Any reason why those are omitted, and any plans to have them in Vim?

Do you think of
:map <window>
:map <tabpage>
next to
:map <buffer>
?

Hmm, logic says using more modifiers is a bit wrong, as
<window>, <tabpage>, <buffer> cannot be combined in one mapping.

There have been similar requests for mappings local to the filetype
(why have duplicated mappings in all buffers sharing the same
filetype?), and mappings local to a specific syntax region (inspired
by TextMate?).

But I guess, all these will just make Vim overly complicated; and with
some scripting it is already possible.


Another problem:
how do you think windows should be identified -- by number?

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: How powerful is language build in vim compare with the language build in emacs?

* 2010-03-29 21:01 (+0100), Antony Scriven wrote:

> On 28 March 2010 09:25, Teemu Likonen <tlikonen@iki.fi> wrote:
>> DISCLAIMER: My tests may suck so I suggest everyone do better ones.
>> :-)
>
> :-). Well I think I should mention that GForth is VM based, or it was
> last I looked.

More accurately GForth uses GCC to compile direct or indirect threaded
code.

> A fast commercial Forth is probably pretty close to the optimised
> SBCL.

Yes, that's very likely. Here's an old comparison between Forth systems:

http://www.complang.tuwien.ac.at/forth/performance.html

GForth seems to be the fastest of those which do not produce pure native
code.

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Possible error with jumplist management in insert mode with

Hello,
Please do the following:
1)
gvim -u NONE file1 (cursor is on line1, column1)
/pattern1 (cursor at the beginning of pattern1)
/pattern2 (cursor at the beginning of pattern2)
CTRL-End (to go to end-of-file)

Now do CTRL-O several times. You go to pattern2, then to pattern1,
then to line1, column 1. All as expected.
CTRL-I goes to pattern1, pattern2, end-of-file (OK)

2) Now do the same in insert mode.
gvim -u NONE file1 (cursor is on line1, column1)
i (to go to insert mode)
<C-O>/pattern1 (cursor at the beginning of pattern1)
<C-O>/pattern2 (cursor at the beginning of pattern2)
CTRL-End (to go to end-of-file)

Now do "CTRL-O CRTL-O" several times. You go to pattern1, then to
line1, column1.
"CTRL-O CTRL-I" goes to pattern1, end-of-file.

Conclusion: pattern2 has vanished from the jumplist in 2).

NB: It does not occur if you repalce CTRL-End with <C-O>G in 2)
(this can be a work-around)

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Why no window-local mapping?

Hi,

I know of <buffer> local mapping and global mapping. I wonder why
there isn't a <window>/<tab> local mapping option for Vim. I use some
Vim windows/tabs exclusively for navigating quick fix lists. On those
windows, I keep <C-N> nd <C-P> globally mapped to :lnext (or :cnext)
and :lprevious. The problem with buffer-local mappings here is that
every time the list will load a new buffer which might not have this
mapping set. Had the mappings been window- or tab-local, I could have
reused the same mappings on other windows for something else - may be
page navigation.

Any reason why those are omitted, and any plans to have them in Vim?

Thanks
Jeenu

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: Unexpected behaviour of File browser in multi-windows environment

On Mar 29, 5:39 pm, Charles Campbell <Charles.E.Campb...@nasa.gov>
wrote:

> Please try netrw v137l.

Perfect!

> So you're a physicist -- are you working with the LHC?

I work in the French Thermonuclear Fusion lab (CEA/Cadarache) close to
future ITER site.

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: CTRL-C not working with gvim even after sourcing mswin.vim?!

On 30/03/10 12:21, Delyan Kalchev wrote:
> I have a bit strange problem. CTRL-C does nothing (just deselects the
> selected text and does not copy anything, and does not change the
> current content of the clipboard) when used in gvim, while CTRL-V and
> CTRL-X work just fine. When I had used gvim in the past I remember (or
> maybe I'm wrong) it has been working correctly.
> But when vim is executed in the gnome-terminal CTRL-C works perfectly
> and it is not because of any help form the gnome-terminal. I cannot
> explain it currently and can't solve it. So I need some help.
>
> I am using Ubuntu 9.10 with vim installed from the official repo:
> version 7.2.245 or as Ubuntu names it - 2:7.2.245-2ubuntu2
>
> Here is my .vimrc:
>
> set nocompatible
> source $VIMRUNTIME/mswin.vim
> behave mswin
>
> set tabstop=4
> set shiftwidth=4
> set expandtab
> set shiftround
> set hls
> set wildmenu
> set showcmd
> set showmatch
> set ignorecase
> set mouse=a
> set background=dark
>
> set list listchars=tab:»-,trail:·,extends:>,precedes:<
>
> match ErrorMsg '\%>80v.\+'
>
> let NERDTreeMouseMode=1
>
> let g:netrw_browse_split=4
> let g:netrw_hide=0
>
> And here is my .gvimrc:
>
> colorscheme desert
> set guifont=monospace\ 13
>
> Thanks
>

Using Ctrl-C, Ctrl-X and Ctrl-V for copy, cut and paste has nothing to
do with ":behave mswin" (which is just a kind of abbreviation for ":set
selectmode=mouse,key mousemodel=popup keymodel=startsel,stopsel
selection=exclusive"), it has everything to do with sourcing mswin.vim
(which you also do in your vimrc). It ought to work even in gvim, unless
something else is at work.

To see if something else is overriding mswin.vim's mapping, try

:verbose map <C-C>

in a running gvim.

In any case I don't recommend sourcing mswin.vim, which masks useful Vim
key bindings; instead, in Vim it helps to keep in mind that the
clipboard is "register-plus" and to use the following:

- To move data to and from the clipboard, for copy / cut / paste to and
from other applications:

Normal commands
"+x delete (cut) one character to the clipboard
"+d{motion} delete to the clipboard
"+dd delete <count> lines to clipboard
{Visual}"+d delete selection to clipboard
"+y{motion} yank (copy) to the clipboard
"+yy yank <count> lines to the clipboard
{Visual}"+y yank selection to clipboard
"+P put (paste) clipboard before cursor
"+p put clipboard after cursor
Ex-commands (always linewise)
:[range]yank +
:[range]delete +
:[range]put +
which can be abbreviated to :y :d and :pu respectively. For :d and :y
the [range] is the set of (consecutive) lines to be cut or copied, for
:put the [range] is the single line after which to paste (or $ for
"after last line" or 0 for "before first line" or omitted for "after
current line" etc.); or with bang (i.e. :put! +) it is the line before
which to paste.

In gvim you can also use the Edit=>Copy, Edit=>Cut and Edit=>Paste menu
items.

If you hit the colon key in Visual mode, Vim prefills the command-line
with :'<,'> which means "from first to last line of the latest Visual
selection" -- just the range that you need in this case.

To move data within a single Vim, the clipboard isn't needed (and then
it works even in the Linux console, which has no access to X): normally
one would use the "unnamed register" by omitting the "+ before Normal
commands or the + after Ex-commands. Or you can use any one of the 26
"letter registers" by replacing the plus sign by a lowercase letter, or,
for yank and delete, by an uppercase letter to append to the register
instead of replacing its contents.


Notes:
- This vimrc will give you errors if ever you try to use it in a Vim
version missing one or more of the +eval +mouse +wildmenu features, and
this gvimrc will give an error if used in a gvim with any GUI other than
GTK2; but I suppose you don't mind these limitations -- at least for now.
- If 7.2.245 is the "latest" Vim Ubuntu has to offer, then they are
taking their time upgrading: the latest "official" patchlevel is
currently 7.2.411 -- IOW you're missing almost half the bugfixes already
published for Vim 7.2; see http://ftp.vim.org/pub/vim/patches/7.2/README
for a list of what these patches are all about, and (if desired)
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm for a HowTo
page about compiling Vim on Unix/Linux. Also
http://vim.wikia.com/wiki/Build_Vim_with_your_name_included which is
less detailed than the above-mentioned HowTo but has a paragraph about
building Vim on Ubuntu.


Best regards,
Tony.
--
Unfair animal names:

-- tsetse fly -- bullhead
-- booby -- duck-billed platypus
-- sapsucker -- Clarence
-- Gary Larson

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: Unexpected behaviour of File browser in multi-windows environment

On Mar 29, 5:39 pm, Charles Campbell <Charles.E.Campb...@nasa.gov>
wrote:

> Please try netrw v137l.

Perfect!

> So you're a physicist -- are you working with the LHC?

I work in the French Thermonuclear Fusion lab (CEA/Cadarache) close to
the future ITER site.

Best regards
Jean

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

CTRL-C not working with gvim even with behave mswin?!

I have a bit strange problem. CTRL-C does nothing (just deselects the
selected text and does not copy anything, and does not change the
current content of the clipboard) when used in gvim, while CTRL-V and
CTRL-X work just fine. When I had used gvim in the past I remember (or
maybe I'm wrong) it has been working correctly.
But when vim is executed in the gnome-terminal CTRL-C works perfectly
and it is not because of any help form the gnome-terminal. I cannot
explain it currently and can't solve it. So I need some help.

I am using Ubuntu 9.10 with vim installed from the official repo:
version 7.2.245 or as Ubuntu names it - 2:7.2.245-2ubuntu2

Here is my .vimrc:

set nocompatible
source $VIMRUNTIME/mswin.vim
behave mswin

set tabstop=4
set shiftwidth=4
set expandtab
set shiftround
set hls
set wildmenu
set showcmd
set showmatch
set ignorecase
set mouse=a
set background=dark

set list listchars=tab:»-,trail:·,extends:>,precedes:<

match ErrorMsg '\%>80v.\+'

let NERDTreeMouseMode=1

let g:netrw_browse_split=4
let g:netrw_hide=0

And here is my .gvimrc:

colorscheme desert
set guifont=monospace\ 13

Thanks

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Monday, March 29, 2010

Re: No more 8-character limit?

On 29/03/10 20:30, Yakov wrote:
> On Mar 29, 5:46 pm, Tony Mechelynck<antoine.mechely...@gmail.com>
> wrote:
>> Even on later Windows systems, 8.3 names still exist because they are
>
> Are we going to rename vim to something like
> visualeditorcompatiblewithvi now ?
>
> I think the argument confuses two different things,
> (a) 8.3 limit of APIs or of filesystem, and
> (b) tendency of [unix] people to abbreviate filenames and variables
> *really short*.
>
> Beleive it or not, some people will abbreviate really short, no matter
> what's filename limit.
>

Hm, I think there's something in this argument. On Unix, long names have
been permitted since I don't know when, but what are the names used? ls
(not "directory_list": "list" would still be ambiguous), cat (not
"concat" and even less "concatenate"), mv (not "move" and even less
"rename"), cp (not "copy"), rm (not "remove" or "delete"), sed (not
"streamedit"), tar (not "tape_archiver" or even "archiver" for who uses
tapes nowadays, at least on Linux?), man (not "manual") and so on and so
forth. So Unix users have to commit to memory that, for instance, to
"rename" a file they must use the "mv" program. Now how can they
remember that? Yet they do.

On Dos/Windows, there are alias pairs: chdir = cd, mkdir = md, rmdir =
rd, del = erase, etc. So what do the overwhelming majority of the users
type in practice? Always the shorter member of the pair.

With Vim commands and options it is maybe less systematic; but after
some time, for the really much-used ones, the abbreviated name always
gets the upper hand: :e (not :edit), :w (not :write), :q (not :quit), :x
(not :exit), :au (not :autocmd), etc. For the options, which ones are
most used may vary somewhat from person to person, but when I'm typing
for myself I use gfn, enc, tenc, fenc, fencs, ff, ffs, imi, ..., even
though when I'm explaining I write about 'guifont', 'encoding',
'termencoding', 'fileencoding', 'fileencodings', 'fileformat',
'fileformats', 'iminsert', etc.


Best regards,
Tony.
--
"I had to censor everything my sons watched ... even on the Mary Tyler
Moore show I heard the word 'damn'!"
-- Mary Lou Bax

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

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.