Re: mac guitabline v2

2006-06-27 Thread Nicolas Weber

Hi,

You probably already know, but when I patched my source and  
compiled it, I got these warnings:


gui.c: In function ‘gui_init_which_components’:
gui.c:3229: warning: implicit declaration of function  
‘gui_mch_showing_tabline’

gui.c: In function ‘gui_update_tabline’:
gui.c:3403: warning: implicit declaration of function  
‘gui_mch_show_tabline’
gui.c:3405: warning: implicit declaration of function  
‘gui_mch_update_tabline’

gui.c: In function ‘send_tabline_event’:
gui.c:3527: warning: implicit declaration of function  
‘gui_mch_set_curtab’


Not crucial, obviously, but should be fixed.


Hm. Do these warnings appear in win32/linux as well? I can't find  
prototypes for these functions anywhere in the code, so I guess this  
is a general problem...can someone comment on this?


Thanks,
Nico



Re: mac guitabline v2

2006-06-27 Thread A.J.Mechelynck

Nicolas Weber wrote:

Hi,

You probably already know, but when I patched my source and compiled 
it, I got these warnings:


gui.c: In function ‘gui_init_which_components’:
gui.c:3229: warning: implicit declaration of function 
‘gui_mch_showing_tabline’

gui.c: In function ‘gui_update_tabline’:
gui.c:3403: warning: implicit declaration of function 
‘gui_mch_show_tabline’
gui.c:3405: warning: implicit declaration of function 
‘gui_mch_update_tabline’

gui.c: In function ‘send_tabline_event’:
gui.c:3527: warning: implicit declaration of function 
‘gui_mch_set_curtab’


Not crucial, obviously, but should be fixed.


Hm. Do these warnings appear in win32/linux as well? I can't find 
prototypes for these functions anywhere in the code, so I guess this is 
a general problem...can someone comment on this?


Thanks,
Nico






No messages whatsoever, building gui.o on Linux with:

gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


:version text of corresponding executable is:

VIM - Vi IMproved 7.0 (2006 May 7, compiled Jun 23 2006 22:12:23)
Included patches: 1-35
Compiled by [EMAIL PROTECTED]
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 +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_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/local/share/vim
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK 
-DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/opt/gnome/include/gtk-2.0 
-I/opt/gnome/lib/gtk-2.0/include -I/usr/X11R6/include 
-I/opt/gnome/include/atk-1.0 -I/opt/gnome/include/pango-1.0 
-I/usr/include/freetype2 -I/usr/include/freetype2/config 
-I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include 
-DORBIT2=1 -pthread -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API 
-I/usr/include/libart-2.0 -I/usr/include/libxml2 
-I/opt/gnome/include/libgnomeui-2.0 -I/opt/gnome/include/libgnome-2.0 
-I/opt/gnome/include/libgnomecanvas-2.0 -I/opt/gnome/include/gtk-2.0 
-I/opt/gnome/include/gconf/2 -I/opt/gnome/include/libbonoboui-2.0 
-I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include 
-I/opt/gnome/include/orbit-2.0 -I/opt/gnome/include/libbonobo-2.0 
-I/opt/gnome/include/gnome-vfs-2.0 
-I/opt/gnome/lib/gnome-vfs-2.0/include 
-I/opt/gnome/include/bonobo-activation-2.0 
-I/opt/gnome/include/pango-1.0 -I/usr/include/freetype2 
-I/opt/gnome/lib/gtk-2.0/include -I/usr/X11R6/include 
-I/opt/gnome/include/atk-1.0 -I/usr/include/freetype2/config -O2 
-fno-strength-reduce -Wall  -I/usr/X11R6/include   -D_REENTRANT 
-D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING  -pipe -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 
-I/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE   -I/usr/include 
-D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i686-linux
Linking: gcc -L/opt/gnome/lib   -L/usr/X11R6/lib   -rdynamic  -Wl,-E 
-Wl,-rpath,/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE 
-L/usr/local/lib -o vim   -L/opt/gnome/lib -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 
-lgobject-2.0 -lgmodule-2.0 -lglib-2.0   -L/opt/gnome/lib 
-L/usr/X11R6/lib   -lgnomeui-2 -lbonoboui-2 -lxml2 -lz -lgnomecanvas-2 
-lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 
-lgobject-2.0 -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lbonobo-activation 
-lORBit-2 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0   -lXt -lncurses -lgpm 
-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE 
/usr/lib/perl5/5.8.6/i586-linux-thread-multi/auto/DynaLoader/DynaLoader.a 

mac guitabline v3

2006-06-27 Thread Nicolas Weber

Hi,

this fixes the warnings. Apply with -p0 (NOT -p1).

Bye,
Nico

macguitab.v3.patch.1
Description: Binary data


Re: Matchparen highlight bug

2006-06-27 Thread A.J.Mechelynck

Ilya wrote:

gvim –u NONE –U NONE

Create file with 100 empty lines, line with {, 20 empty lines and line 
with }:


:exe normal i{\CR}\Esc20O\Escj%100O\Escj%

Turn on matchparen plugin:

:set nocp
:source $VIMRUNTIME/plugin/matchparen.vim

Now cursor should be on the }, this line is the lowest line in the vim 
window and both braces should be highlighted.  Use mouse wheel to scroll 
buffer down a bit, so that the line with } would disappear and cursor 
would move several lines up.


Cursor is now on an empty line, but braces are still highlighted.


VIM - Vi IMproved 7.0 (2006 May 7, compiled Jun 24 2006 14:17:06)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-35





On the corresponding Unix version

VIM - Vi IMproved 7.0 (2006 May 7, compiled Jun 23 2006 22:12:23)
Included patches: 1-35
Compiled by [EMAIL PROTECTED]
Huge version with GTK2-GNOME GUI.  Features included (+) or not (-):
[...]

I see it when scrolling by means of the scrollbar but _not_ when I do it 
by means of the mouse wheel. In the latter case, the top brace loses its 
cyan background as soon as the bottom one is pushed offscreen. In the 
former case, an additional Ctrl-L is necessary.



Best regards,
Tony.


vim7 repeats ';' and ',' not working for till 't' and 'T'

2006-06-27 Thread Mike Li

in normal mode, ';' and ',' are not working to repeat the last till
commands (i.e. 't' and 'T'), though they do seem to work for find
commands (i.e. 'f' and 'F'). i see this for both the win32 vim7
binaries and FC5 builds from vim7 svn source.

-x


should :silent be suppressing autocmds?

2006-06-27 Thread Eric Van Dewoestine

Should prepending :silent to a command be suppressing an autocommand?

Neither the docs for autocommands nor the docs for :silent indicate
this is the intended behavior.

For example:

using the following the autocommand is executed as expected with the
desired output

vim -u NONE -c set nocompatible | set verbose=10 | autocmd
BufWinEnter test_file echom 'Test file opened.' -c edit test_file

however, after adding :silent, the autocommand does not fire and there
is no output

vim -u NONE -c set nocompatible | set verbose=10 | autocmd
BufWinEnter test_file echom 'Test file opened.' -c silent edit
test_file

--
eric


Re: should :silent be suppressing autocmds?

2006-06-27 Thread A.J.Mechelynck

Eric Van Dewoestine wrote:

Should prepending :silent to a command be suppressing an autocommand?

Neither the docs for autocommands nor the docs for :silent indicate
this is the intended behavior.

For example:

using the following the autocommand is executed as expected with the
desired output

vim -u NONE -c set nocompatible | set verbose=10 | autocmd
BufWinEnter test_file echom 'Test file opened.' -c edit test_file

however, after adding :silent, the autocommand does not fire and there
is no output

vim -u NONE -c set nocompatible | set verbose=10 | autocmd
BufWinEnter test_file echom 'Test file opened.' -c silent edit
test_file



The purpose of :silent is to suppress output to the display, to 
sysout/syserr and to the message history. What it does _not_ suppress is 
output by :redir or (for version 7) logging to a 'verbosefile'. Try 
(vim 7 only):


  vim -N -u NONE -c set verbosefile=vim.log -c au BufWinEnter 
test_file echom 'Test file opened.' -c silent e test_file -c q


(all on one line) followed (on Unix) by

  cat vim.log

or (on Windows) by

  type vim.log

If it displays Test file opened., then the autocommand _has_ fired; 
but :silent has suppress all its output except to the verbosefile.



Best regards,
Tony.


Re: Change wildmode w/ 'longest' to be behave like completeopt w/ 'longest'

2006-06-27 Thread A.J.Mechelynck

Eric Van Dewoestine wrote:

Any thoughts on this?

Bram?

For the most part I've gotten use to the behavior, but I still
occassionaly find my self hitting enter when I see the first entry
highlighted, and receive an ambiguous use error because the
highlighted entry isn't actually in the command line, only the longest
completion portion.


On 6/27/06, ervandew [EMAIL PROTECTED] wrote:

--- In [EMAIL PROTECTED], Eric Van Dewoestine [EMAIL PROTECTED]
wrote:

When starting vim as follows
  vim -u NONE -c set nocompatible | set wildmenu | set
wildmode=longest:full,full

if you perform
  :eTab
you get a list of commands starting with 'e' and the command line is
unchanged (still only contains 'e').

The only issue, is that the first entry in the list is highlighted,
but the command line does not contain that text.  The fact that the
entry is highlighted should indicate that the text is on the command
line and a cr will execute that command (like how ins-completion
works).

--
eric

--- End forwarded message ---


The default setting, wildmode=full , highlights (if anything) what it 
actually completes. If you repeatedly hit the right-arrow key, it will 
cycle through all full matches and what you had typed. See :help 
'wildmode' for the various other possibilities. Whatever you see 
highlighted on the statusline, what is filled-in is what you see on the 
command-line. If longest is included, it's not necessarily a full 
match. The purpose of that is to allow incremental completion.



Best regards,
Tony.


Re: Change wildmode w/ 'longest' to be behave like completeopt w/ 'longest'

2006-06-27 Thread Eric Van Dewoestine

The default setting, wildmode=full , highlights (if anything) what it
actually completes. If you repeatedly hit the right-arrow key, it will
cycle through all full matches and what you had typed. See :help
'wildmode' for the various other possibilities. Whatever you see
highlighted on the statusline, what is filled-in is what you see on the
command-line. If longest is included, it's not necessarily a full
match. The purpose of that is to allow incremental completion.


Yes, I understand the purpose and usage of wildmode.  My suggestion is
that the wildmode 'longest' should behave like the completeopt
'longest' where an entry is only highlight if that highlighted text is
actually inserted into the buffer, or command line in this case.

As of now , the behavior of 'longest' is inconsistent across the two
vim options ('completeopt' and 'wildmenu').

--
eric


Re: Windows, 'path', and ~/$HOME

2006-06-27 Thread A.J.Mechelynck

Maciej Kalisiak wrote:

I'm under Windows XP, and I'm having a devil of a time trying to set
'path' to a bunch of directories in my home directory.  My $HOME (and
thus presumably ~) point at c:\Documents and Settings\User\My
Documents\Home.  Doing something like
 set path=$HOME/src
does not work (e.g., :find does not find files that are there).
I've tried many variations, even expanding out $HOME in various forms,
and the single variation I have gotten to work was
 let path='c:\Documents\ and\ Settings\User\My\ Documents\Home\src\'
IIRC, using forward slashes breaks this, using :set path instead of
:let path breaks this, using ~ or $HOME breaks this, etc.  Also,
with this form I can't seem to be able to later do let
path+='c:\'. (I get E734)  Is there an easier way to set 'path'
in Windows??  I'd like to add something like 5 to 10 directories to
path, and this form is s unwieldly and ugly...




:let escaped_home = escape(substitute($HOME,'/','\\',''),' ')
:let path = escaped_home . '\src'
:let path .= ',' . escaped_home . '\include'
etc.

See under :help 'path', the paragraph starting Spaces can also about 
using the :set command to set a 'path' with spaces in it. :set 
option=foo\\\ bar is equivalent to :let option = 'foo\ bar'. If 
$HOME contains spaces, you must backslash-escape them, either manually 
like you did, or by using the escape() function as shown above.


Alternately, you can use the short name of the $HOME directory, which 
has no spaces in it (because spaces are forbidden in short names):


:let short_home = 'C:\DOCUME~1\User\MYDOCU~1\Home'
:exe set path= . short_home . '\src'
:exe set path+= . short_home . '\include'
etc.

Note the difference between single and double quotes in Vim: 'foo\ bar' 
is equivalent to foo\\ bar and its value has one backslash in it.



Best regards,
Tony.


Re: How to recognize different matching classes

2006-06-27 Thread Peter Slizik

 To check if the cursor is within a comment or string context:

synIDattr(synID(line(.), col(.), 1), name) =~? 'comment\|string'

 Syntax has to be enabled.

Thanks, Gerald,

this is exactly what I needed. Thanks also to the others, for useful hints.

-- Peter


Re: Possible bug in window placement after changing buffers

2006-06-27 Thread Thomas Mellman
--- A.J.Mechelynck [EMAIL PROTECTED] wrote:
 Thomas Mellman wrote:
When moving from buffer to buffer using
the :bp and :bn commands, vim normally positions the file and cursor
such that the last line visited is presented in the middle of the
screen and the cursor is on that line.
  
In certain circumstances, however, it does not do this.  In those
circumstances, when one opens the file, the cursor is indeed placed
on the last line visited - but that line is positioned at the bottom
of the window.
  
This apparently only happens when syntax is on - but for all (tested)
syntaxes.
  
Now, in particular, this happens if the cursor is positioned on the
line of the file that falls within a range starting at the window
height.  The extent of this range appears to be a function of the file
length - for example, in one case, the window height is 70 lines.  The
range causing the problem starts at line 70 of the file and - for very
long files - extents to line 104.  When the cursor is place on line 105,
moving into the buffer causes the last line to be positioned in the
middle of the window.  When the cursor is placed on line 104, reentering
the buffer puts the line at the bottom of the window.
  
In this particular case, if the file is longer than 104
lines but shorter than 139 lines, the event happens anywhere after
line 69 - but note that only lines 35-104 would be required to display
line 70 in the middle of the window.
 
 See :help 'scrolloff'.
 
 Setting 'scrolloff' to a large number (large enough to always be larger 
 than half the value of 'lines') will always keep the cursor line near 
 the middle of the screen, except when it is in the very first or last 
 few lines of the file (e.g., the first line of the file will never start 
 lower than the first line of the window).

This method seems to change the behaviour of the cursor so that cursor stays
in middle of the screen and the file moves.  That's something different.

What I'm seeing is clearly a bug, because vim behaves in a non-logical
manner.  There's some problem with the positioning algorithm with respect
to window and file boundaries.

There's no reason for the cursor to dive to the bottom of the window in
certain positional situations and not in others.

Now, it's clear - if there's not enough lines to position the cursor in
the center of the screen, it would be logical that the line couldn't be
positioned in the middle.  But that's not the problem.
The problem happens when there *are* enough lines.


 You could also use z. (zed-fullstop or zee-period depending on your 
 flavour of English) in Normal mode, to move just once the cursor line 
 to the middle.


Ah, what do you mean with just once?  That's exactly the problem: I
have to z. everytime I visit the file.  If I'm comparing a pivot spot
in 5 files (the source code, the data output, the include file definition,
the specification document, and my notes file, for example), certain files
- at certain positions - will have to be z.-ed every time they're revisited.



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


Re: How to replace CR with LF

2006-06-27 Thread Kai Weber
* Michael Naumann [EMAIL PROTECTED]:

 I'm curious though - is there any way to substitute CR with LF using
 regexp's?

 Yes there is, strange as it may seem:
 
 s/\r/\r/
 
 does it

Can somebody enlighten me why this works? Does vim replace wrong \r
with corrent \r?

Kai
-- 
* http://www.glorybox.de/
  PGP 1024D/594D4132 B693 5073 013F 7F56 5DCC  D9C2 E6B5 448C 594D 4132


Re: How to replace CR with LF

2006-06-27 Thread Eric Arnold

See Vim tip #1266:

http://www.vim.org/tips/tip.php?tip_id=1266

Note that Vim isn't replaced 'wrong' \r with 'correct' \r.  It is
replacing it with a linebreak, which is then interpreted as  a \n for
unix and a \r\n for dos by the   s///  command.  It is just one of
many odd cases.


On 6/27/06, Kai Weber [EMAIL PROTECTED] wrote:

* Michael Naumann [EMAIL PROTECTED]:

 I'm curious though - is there any way to substitute CR with LF using
 regexp's?

 Yes there is, strange as it may seem:

 s/\r/\r/

 does it

Can somebody enlighten me why this works? Does vim replace wrong \r
with corrent \r?

Kai
--
* http://www.glorybox.de/
  PGP 1024D/594D4132 B693 5073 013F 7F56 5DCC  D9C2 E6B5 448C 594D 4132



Re: Windows, 'path', and ~/$HOME

2006-06-27 Thread Maciej Kalisiak

Thanks for a meaty reply Tony, plenty for me to read up on.

Just one minor related issue: what is the convention of handling ~
in Vim under Windows?  The problem is that under WinXP, when I use
$HOME in Vim, it gets translated to ~ (i.e., the Unix convention for
home directory), rather than the full absolute path.  Yet at the same
time it seems to me that Vim does not treat ~ as a home directory
here, as :find does not find stuff if my path is set to ~/src (which
I originally set to $HOME/src).  Since there are no spaces in
~/src, I don't think there's any escaping to do, hence this
should've worked if Vim internally expanded out the tilde.

Oh, one other minor one: under Windows, are \ and / *always*
interchangeable in Vim as path seperators, or are there instances
where you must use the Windows backslash convention? I ask because I
thought I read in the manual that they are interchangeable, yet having
exchanged them I was seeing different results.  I suspect the issue
was my improper escaping of the backslashes, but I'd like to eliminate
this one potential source of error before going on to debug...

On 27/06/06, A.J.Mechelynck [EMAIL PROTECTED] wrote:

:let escaped_home = escape(substitute($HOME,'/','\\',''),' ')
:let path = escaped_home . '\src'
:let path .= ',' . escaped_home . '\include'
etc.

See under :help 'path', the paragraph starting Spaces can also about
using the :set command to set a 'path' with spaces in it. :set
option=foo\\\ bar is equivalent to :let option = 'foo\ bar'. If
$HOME contains spaces, you must backslash-escape them, either manually
like you did, or by using the escape() function as shown above.

Alternately, you can use the short name of the $HOME directory, which
has no spaces in it (because spaces are forbidden in short names):

:let short_home = 'C:\DOCUME~1\User\MYDOCU~1\Home'
:exe set path= . short_home . '\src'
:exe set path+= . short_home . '\include'
etc.

Note the difference between single and double quotes in Vim: 'foo\ bar'
is equivalent to foo\\ bar and its value has one backslash in it.


copy highlighted text to a temporary file

2006-06-27 Thread Dimitriy V. Masterov

I am trying to find a way to copy text that I've highlighted with the
mouse to a temporary file with a .do extension, so that I might use it
in the script below, and then delete it. I am not sure how to proceed
from here. Any advice would be greatly appreciated.

fun! RunLines()
 !start C:\Program Files\Scripts\rundo.exe C:/.../tempfile.doEnter
endfun

:map F9 :C-Ucall RunLines() Enter
:imap F9 Esc:C-Ucall RunLines() Enter


Re: HOWTO: store option settings in a variable

2006-06-27 Thread Jason Aeschilman



Gary Johnson wrote:

On 2006-06-27, Jason Aeschilman [EMAIL PROTECTED] wrote:
  
I wanted to save the current setting for an option so I could change 
that option temporarily then set it back to what it was.  Specifically, 
I'm using the Cfname.vim plugin and it hard sets the statusline option 
then hard sets it back.  I already improved it to work on demand by 
creating a toggle to turn it on and off.  I wanted to improve it further 
by storing the user's current statusline setting when toggling it on 
then restoring the statusline setting when toggling it off.  I was going 
to ask in this list how to do this but I ended up figuring it out on my 
own.  I'll go ahead and post my solution in case someone finds it 
useful.  This seems to work but if anyone can see any problems with this 
or a better way to do it, please let me know.


save user's current statusline option
let g:CF_statusline=escape(getbufvar(1, statusline),  )

set statusline back to previous setting
execute 'set statusline=' . g:CF_statusline



Here's the standard way of doing that:

save user's current statusline option
let g:CF_statusline=statusline

set statusline back to previous setting
let statusline=g:CF_statusline

Further, if there is no need to access CF_statusline outside the 
script in which 'statusline' is saved and restored, a script 
variable is often used instead of a global variable to avoid 
polluting the global name space.  So you might consider using 
s:CF_statusline instead of g:CF_statusline.


Gary
  
Well that looks like a much cleaner way to do it.  I just did what I did 
based on the only examples I could find online.  As for scope, you're 
right, the variable needn't be global, I was just being lazy while 
getting it to work.


It actually turns out there is a 3.0a version of Cfname.vim that retains 
the user's statusline and fixes the slowdown problems with the script so 
I don't even need my toggle.  The author didn't list it as the latest 
version, I guess because he didn't make the changes.  It performs much 
better than the author's 3.0 version.  Oh and it does save and restore 
statusline just the way you mention. :-)


Jason Aeschilman


Re: copy highlighted text to a temporary file

2006-06-27 Thread A.J.Mechelynck

Dimitriy V. Masterov wrote:

I am trying to find a way to copy text that I've highlighted with the
mouse to a temporary file with a .do extension, so that I might use it
in the script below, and then delete it. I am not sure how to proceed
from here. Any advice would be greatly appreciated.

fun! RunLines()
 !start C:\Program Files\Scripts\rundo.exe C:/.../tempfile.doEnter
endfun

:map F9 :C-Ucall RunLines() Enter
:imap F9 Esc:C-Ucall RunLines() Enter




The quick-and-dirty solution would be to yank the highlighted text, then 
put it in the new file. Example:


y
:let tempfile = $TEMP . /tempname.do
:exe new tempfile
:0put
:x

 define a command to run the script
command -nargs=0 -bar RunLines
\ exe   !start C:\PROGRA~1\Scripts\rundo.exe
\ . g:tempfile
 define mappings to run the command
map F9 :RunLinesCR
imap F9 C-O:RunLinesCR
 (optional) setup an autocmd for shutdown cleanup
au VimLeave * exe !del -y tempfile


Best regards,
Tony.


Re: copy highlighted text to a temporary file

2006-06-27 Thread A.J.Mechelynck

Dimitriy V. Masterov wrote:

Thank you very much for your suggestion. I'm still having trouble
yanking the highlighted text instead of the line the cursor was on.

I was able to do something like this in jEdit using
textArea.getSelectedText(). Is there something analogous for Vim?

My jEdit code is here:

rundolines() {
 // Copy selected text
 String text = textArea.getSelectedText();

 // Create a temp file
 File temp = File.createTempFile(dofilelines, .do);

 // Delete temp file when program exits.
 temp.deleteOnExit();

 // Write to temp file
 BufferedWriter out = new BufferedWriter(new FileWriter(temp));
 out.write(text);
 out.close();

 // Run the temporary file in Stata
 String command=C:\\Program Files\\Scripts\\rundo.exe  + \ +
temp + \;
 exec(command);
}

rundolines();




In --VISUAL-- (not --SELECT-- mode), hitting y should yank the 
highlighted text into the unnamed register. (In Select mode it replaces 
the highlighted text by the letter y).


- To go from Normal to Visual: hit v
Then extend the selection by moving the cursor.

- To go from Select to Visual: hit Ctrl-G


Best regards,
Tony.


Re: Trouble getting the backupskip option to work

2006-06-27 Thread Tom Purl
I believe that this may be a bug.  I hope that this is the proper way of
opening a new one.

I've poured over the documentation and asked the mailing list gods for
help, and this basic feature still does not work.  Here's the use case:

I have tried this on both Windows and Linux.  I'm certain that my
`vimrc` is being read.

Here's what I have in my `vimrc` file:

set backup
set backupskip=$HOME/gtd/wiki/*   # tried both with and without
# quotes

And here's how you too can recreate the bug:

1. I opened my $HOME/gtd/wiki directory within Vim using netrw.
2. I deleted the FrontPage~ doc using netrw
3. I then opened my FrontPage doc, edited it and saved it.
4. I then opened my $HOME/gtd/wiki directory again within Vim using netrw.

Unfortunately, the FrontPage~ doc was created again.  I have the potwiki
plugin installed, but I also tested this without any extra plugins and got
the same result.

Thanks!

Tom Purl



Quickfix/errorformat setting

2006-06-27 Thread Howard Jess

Hi --

[Please excuse me if you've already seen this; I posted this to
comp.editors before I found this list.]


After reading the docs many times and searching comp.editorsfor help, I
admit I'm stumped -- I simply don't know how to set errorformat properly
to recognize my messages. Here's what I've got:

1.  Error/Warning/Information messages may be either one or several
lines.

2.  There may be zero, one or more locations in the code pointed to
by a message; but no more than one location per line in a multiline
message.

3.  Locations are (literally; including brackets): [filename:line:column]

Sample output is:

Warning [flip.jss:7:10]: type mismatch:
conflict between boolean [flip.jss:4:19]
and string [flip.jss:7:10]
Warning [flip.jss:18:5]: different argument counts:
conflict between 2 arguments [flip.jss:18:9]
and 1 argument [flip.jss:3:14]
Warning [flip.jss:20:7]: invalid + usage:
boolean [flip.jss:4:16]
+ undetermined type [flip.jss:20:9]
= undetermined type

The simplest way (for me) to treat these is that each line is a
separate message, with an error location within brackets. So, the
errorformat should specify:

- any non-'[' characters
- a '['
- the filename
- a ':'
- the linenumber
- a ':'
- the column
- a ']'
- the message

which I think means:

set errorformat=%[^[][%f:%l:%v]%m

However, in the quickfix window (:copen), the only lines that are
handled as messages are those with Warning; others are unrecognized.
The quickfix window looks like:

flip.jss|7 col 10| : type mismatch:
|| conflict between boolean [flip.jss:4:19]
|| and string [flip.jss:7:10]
flip.jss|18 col 5| : different argument counts:
|| conflict between 2 arguments [flip.jss:18:9]
|| and 1 argument [flip.jss:3:14]
flip.jss|20 col 7| : invalid + usage:
|| boolean [flip.jss:4:16]
|| + undetermined type [flip.jss:20:9]
|| = undetermined type

I said aha! and rewrote the error messages without leading spaces.
This had no effect, though ... the lines unlabeled with Warning
still were not recognized.

I've tried a lot of other errorformat values, none of which work any
better (most are worse). At this point I feel like I'm reduced to trying
to find a working magical incantation, rather than understanding and
applying a proper errorformat syntax.

I would *really* appreciate any help. Thanks!


Howard
[EMAIL PROTECTED]


Re: copy highlighted text to a temporary file

2006-06-27 Thread Benji Fisher
On Tue, Jun 27, 2006 at 03:56:22PM -0400, Dimitriy V. Masterov wrote:
 Thank you very much for your suggestion. I'm still having trouble
 yanking the highlighted text instead of the line the cursor was on.
 
 I was able to do something like this in jEdit using
 textArea.getSelectedText(). Is there something analogous for Vim?
 
 My jEdit code is here:
 
 rundolines() {
  // Copy selected text
  String text = textArea.getSelectedText();
 
  // Create a temp file
  File temp = File.createTempFile(dofilelines, .do);
 
  // Delete temp file when program exits.
  temp.deleteOnExit();
 
  // Write to temp file
  BufferedWriter out = new BufferedWriter(new FileWriter(temp));
  out.write(text);
  out.close();
 
  // Run the temporary file in Stata
  String command=C:\\Program Files\\Scripts\\rundo.exe  + \ +
 temp + \;
  exec(command);
 }
 
 rundolines();

 Are you having trouble yanking the text manually or from a
script?  If you are in Visual mode, then change to Command-Line mode to
execute a :command or a Function(), then you have to get back into
Visual mode in order to yank the text you want.  Based on your jEdit
code above, I am guessing you want something like this:

fun! Rundolines()
   Copy Visual text into register a
  normal! gvay
  let temp = tempname() . .do
  execute split temp
   or :edit or :tabedit instead of :split
  put a
  let command = ...
  execute command
   I assume we are still editing the temp file now.
  q!
endfun

Most users seem to forget that :execute can take more than one argument.
Thus my first :execute line should do the same as

  execute split  . temp

Disclaimer:  the entire function is untested.  (Just in case it is not
clear that the last :let line is incomplete.)

HTH --Benji Fisher


Re: Quickfix/errorformat setting

2006-06-27 Thread A.J.Mechelynck

Howard Jess wrote:

Hi --

[Please excuse me if you've already seen this; I posted this to
comp.editors before I found this list.]


After reading the docs many times and searching comp.editorsfor help, I
admit I'm stumped -- I simply don't know how to set errorformat properly
to recognize my messages. Here's what I've got:

1.  Error/Warning/Information messages may be either one or several
lines.

2.  There may be zero, one or more locations in the code pointed to
by a message; but no more than one location per line in a multiline
message.

3.  Locations are (literally; including brackets): [filename:line:column]

Sample output is:

Warning [flip.jss:7:10]: type mismatch:
conflict between boolean [flip.jss:4:19]
and string [flip.jss:7:10]
Warning [flip.jss:18:5]: different argument counts:
conflict between 2 arguments [flip.jss:18:9]
and 1 argument [flip.jss:3:14]
Warning [flip.jss:20:7]: invalid + usage:
boolean [flip.jss:4:16]
+ undetermined type [flip.jss:20:9]
= undetermined type

The simplest way (for me) to treat these is that each line is a
separate message, with an error location within brackets. So, the
errorformat should specify:

- any non-'[' characters
- a '['
- the filename
- a ':'
- the linenumber
- a ':'
- the column
- a ']'
- the message

which I think means:

set errorformat=%[^[][%f:%l:%v]%m

However, in the quickfix window (:copen), the only lines that are
handled as messages are those with Warning; others are unrecognized.
The quickfix window looks like:

flip.jss|7 col 10| : type mismatch:
|| conflict between boolean [flip.jss:4:19]
|| and string [flip.jss:7:10]
flip.jss|18 col 5| : different argument counts:
|| conflict between 2 arguments [flip.jss:18:9]
|| and 1 argument [flip.jss:3:14]
flip.jss|20 col 7| : invalid + usage:
|| boolean [flip.jss:4:16]
|| + undetermined type [flip.jss:20:9]
|| = undetermined type

I said aha! and rewrote the error messages without leading spaces.
This had no effect, though ... the lines unlabeled with Warning
still were not recognized.

I've tried a lot of other errorformat values, none of which work any
better (most are worse). At this point I feel like I'm reduced to trying
to find a working magical incantation, rather than understanding and
applying a proper errorformat syntax.

I would *really* appreciate any help. Thanks!


Howard
[EMAIL PROTECTED]




What about

:set errorformat=%m[%f:%l:%v]%r

?


Best regards,
Tony.


Re: Trouble getting the backupskip option to work

2006-06-27 Thread A.J.Mechelynck

Bram Moolenaar wrote:

Tom Purl wrote:


I believe that this may be a bug.  I hope that this is the proper way of
opening a new one.

I've poured over the documentation and asked the mailing list gods for
help, and this basic feature still does not work.  Here's the use case:

I have tried this on both Windows and Linux.  I'm certain that my
`vimrc` is being read.

Here's what I have in my `vimrc` file:

set backup
set backupskip=$HOME/gtd/wiki/*   # tried both with and without
# quotes

And here's how you too can recreate the bug:

1. I opened my $HOME/gtd/wiki directory within Vim using netrw.
2. I deleted the FrontPage~ doc using netrw
3. I then opened my FrontPage doc, edited it and saved it.
4. I then opened my $HOME/gtd/wiki directory again within Vim using netrw.

Unfortunately, the FrontPage~ doc was created again.  I have the potwiki
plugin installed, but I also tested this without any extra plugins and got
the same result.


Environment variables are not expanded for the 'backupskip' option.  You
must replace $HOME with its expanded value, or use:

:let backupskip = expand($HOME) . /gtd/wiki/*



... and in addition, since spaces in directory names in 'backupskip' 
must be escaped, use


:let backupskip = escape(expand('$HOME'),' ') . '/gtd/wiki/*'


Best regards,
Tony.


Re: Trouble getting the backupskip option to work

2006-06-27 Thread Tom Purl
 Environment variables are not expanded for the 'backupskip' option.  You
 must replace $HOME with its expanded value, or use:

  :let backupskip = expand($HOME) . /gtd/wiki/*

 ... and in addition, since spaces in directory names in 'backupskip'
 must be escaped, use

   :let backupskip = escape(expand('$HOME'),' ') . '/gtd/wiki/*'

That worked!  Thanks a ton for the help.  Also, the first option
mentioned by Bram worked (I didn't need the escape function) even though
my $HOME dir on Windows has spaces in it.

Thanks again Bram and Tony!  This is a very handy line to have your vimrc
if you want to keep a potwiki and do easy full-text searches with
vimgrep.

Tom Purl



Re: Man command not working with Vim 7

2006-06-27 Thread Benji Fisher
On Mon, Jun 26, 2006 at 10:56:48PM -0600, Trent Michael Gamblin wrote:
 Benji Fisher wrote:
 
 I think this is important, but I do not understand it completely.
 When I try
 
 $ man cvs | col -b | less
 
 or simply
 
 $ man cvs | less
 
 I get a similar error message, Error executing formatting or display
 command ...  after I exit less.  I guess that was sent to stderr?  (I
 am pretty sure that man is /usr/bin/man .)  So somehow vim is reading
 stderr into your buffer instead of stdout?
 
[snip]
 This will start up vim without your usual vimrc file.  Is the problem
 still there?  
 
 Almost the same thing. It first says Output is not a terminal then 
 when I type something
 it shows the same ugly buffer from my first post.
 
 If the problem goes away, maybe you have some weird
 setting for your 'shellredir' option or something.  What does
[snip]
 
 shell=/bin/bash
 shellredir=%s 21
 /bin/bash

 Well, that looks normal.  Eric Arnold's problem was along these
lines.

 Next, you can try (from an empty buffer)
 
 :r! man cvs
 
 or
 
 :r! man cvs | col -b
 
 Do you get the same error message, or do you get the man page?
  
 
 I get the same error messages and partial unformatted man page.
 
 Part of the error message is:
 Error executing formatting or display command.
 System command (cd /usr/share/man  (echo .pl 11i; /usr/bin/gunzip -c 
 '/usr/share/man/man1/cvs.1.gz') | /usr/bin/gtbll | /usr/bin/nroff -c 
 --legacy ISO-8859-1 -mandoc 2/dev/null | col -b | view -c 'set ft=man 
 nomod nolist' -) exited with status 256.
 No manual entry for cvs
 
 When I run that command from the shell I get the man page formatted 
 perfectly. So I wonder what program is exiting with status 256 and what 
 that particular error code means.
 
 BTW, I had to make a symbol link from gtbl to gtbll, since I didn't have 
 gtlbll.

 We are making progress:  the ftplugin/man.vim script is not the
culprit, there is something wrong with :r! .

 BTW, I am using FC2, so my system should be similar to yours.

 I get a similar error message to the one you quote when, from a
shell, I try

$ man cvs | less

but I only see the error after I quit less.  Do you *not* see it in this
context?  Not that I know what to do with the answer, but I am hoping
that our systems will work the same way and that we can narrow down
where that error message comes from.

 I do not have any great ideas at the moment (and in fact I am
pressed for time) but this might be worth trying:

$ vim -u NONE
:r! man cvs

:set shllquote? shellxquote?

HTH --Benji Fisher


Re: copy highlighted text to a temporary file

2006-06-27 Thread Hari Krishna Dara

On Tue, 27 Jun 2006 at 4:51pm, Benji Fisher wrote:

 On Tue, Jun 27, 2006 at 03:56:22PM -0400, Dimitriy V. Masterov wrote:
  Thank you very much for your suggestion. I'm still having trouble
  yanking the highlighted text instead of the line the cursor was on.
 
  I was able to do something like this in jEdit using
  textArea.getSelectedText(). Is there something analogous for Vim?
 
  My jEdit code is here:
 
  rundolines() {
   // Copy selected text
   String text = textArea.getSelectedText();
 
   // Create a temp file
   File temp = File.createTempFile(dofilelines, .do);
 
   // Delete temp file when program exits.
   temp.deleteOnExit();
 
   // Write to temp file
   BufferedWriter out = new BufferedWriter(new FileWriter(temp));
   out.write(text);
   out.close();
 
   // Run the temporary file in Stata
   String command=C:\\Program Files\\Scripts\\rundo.exe  + \ +
  temp + \;
   exec(command);
  }
 
  rundolines();

  Are you having trouble yanking the text manually or from a
 script?  If you are in Visual mode, then change to Command-Line mode to
 execute a :command or a Function(), then you have to get back into
 Visual mode in order to yank the text you want.  Based on your jEdit
 code above, I am guessing you want something like this:

 fun! Rundolines()
Copy Visual text into register a
   normal! gvay
   let temp = tempname() . .do
   execute split temp
or :edit or :tabedit instead of :split
   put a
   let command = ...
   execute command
I assume we are still editing the temp file now.
   q!
 endfun

 Most users seem to forget that :execute can take more than one argument.
 Thus my first :execute line should do the same as

   execute split  . temp

 Disclaimer:  the entire function is untested.  (Just in case it is not
 clear that the last :let line is incomplete.)

 HTH   --Benji Fisher


You can do this more elegantly using the new Vim7 features (again
untested):

function! Rundolines()
  let selectedLines = getbufline('%', line('), line('))
  if col(')  strlen(getline(line(')))
let selectedLines[-1] = strpart(selectedLines[-1], 0, col('))
  endif
  if col(') != 1
let selectedLines[0] = strpart(selectedLines[0], col(')-1)
  endif
  let temp = tempname() . .do
  call writefile(selectedLines, temp)
   Do something with temp file.
  call delete(temp)
endfunction

Of course, you can also mix the normal command and still use the
writefile() like this (note, unlike the getbuflist() you have to be
in the buffer before you use this approach):

function! Rundolines()
  normal! gvay
  let selectedLines = split(@a, \n)
  let temp = tempname() . .do
  call writefile(selectedLines, temp)
   Do something with temp file.
  call delete(temp)
endfunction

It is better to save and restore the @a value though. Considering your
jEdit code, you would probably prefer the first approach.

-- 
HTH,
Hari

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


Re: Quickfix/errorformat setting

2006-06-27 Thread A.J.Mechelynck

Howard Jess wrote:

A.J.Mechelynck wrote:

Howard Jess wrote:

Sample output is:

Warning [flip.jss:7:10]: type mismatch:
conflict between boolean [flip.jss:4:19]
and string [flip.jss:7:10]

[ and more like that ]


which I think means:

set errorformat=%[^[][%f:%l:%v]%m

[ but that didn't work ]


What about

:set errorformat=%m[%f:%l:%v]%r


Sorry; I'm using Vim 6.3; it says:

E373: Unexpected %r in format string

Perhaps this is a new feature in 7.0??

hj







I dunno. I've junked 6.3 when 6.4 came around, and though I maintained 
6.4 and 7.0 alpha in parallel, now that the 7.0 release is out (with 
already 35 bugfixes) I've junked 6.4 too. Here's the paragraph about %r 
in 'errorformat' in the 7.0 help (quickfix.txt fot Vim 7.0, last change 
2006 Apr 30):


%r  matches the rest of a single-line file message %O/P/Q

Maybe it isn't appropriate (%O, %P and %Q refer to how to handle 
errorfiles where the filename is given once followed by several errors 
with line/col without filename). Is it allowable to have %m more than 
once in the format? Try


:set efm=%m[%f:%l:%v]%m

If it doesn't work, you could pre-process the errorfile so as to move 
the [filename:123:45] part to the end of its line, and then match it 
with %m[%f:%l:%v] on the modified errorfile. Vim could do the 
preprocessing: (assuming the errorfile is called make.log)


:new make.log
:1,$s/^\([^\[]*\)\(\[[^\]]*\]\)\(.*\)$/\1\3\2
:x

explanation:
1,$ from first to last line
s/  substitute from
^   start-of-line
\(  start of subpart 1
[^\[]   not a [
*   repeated zero or more times (as many as possible)
\)  end of subpart 1
\(  start of subpart 2
\[  [
[^\]]   not ]
*   repeated zero or more times (as many as possible)
\]  ]
\)  end of subpart 2
\(  start of subpart 3
.*  zero or more of anything except a line break
\)  end of subpart 3
$   end of line
/   replace by
\1  subpart 1
\3  subpart 3
\2  subpart 2

Lines (if any) where there is no [] bracket pair are left unchanged. If 
there is more than one bracket pair in a line, the above moves the 
_first_ [] block to the end of the line.


Disclaimer: This is UNTESTED. Maybe I made a typo. It wouldn't be the 
first time ;-)



Best regards,
Tony.


Re: copy highlighted text to a temporary file

2006-06-27 Thread Dimitriy V. Masterov

Many thanks for all your attention. This was awesomely educational. I
had to delay the deletion of the file so that Stata would have it to
work on. In the end, I wound up with the following script:

fun! RunDoLines()
let selectedLines = getbufline('%', line('), line('))

if col(')  strlen(getline(line(')))
  let selectedLines[-1] = strpart(selectedLines[-1], 0, col('))
endif
if col(') != 1
  let selectedLines[0] = strpart(selectedLines[0], col(')-1)
endif

let temp = tempname() . .do
call writefile(selectedLines, temp)

exec !start C:\\Program Files\\Scripts\\rundo.exe  . temp

 Delete the temp file after Vim closes
au VimLeave * exe !del -y temp
endfun

DVM


Going on holiday

2006-06-27 Thread A.J.Mechelynck
Hello all! I'll be away from my computer from 29 June to 13 July 
inclusive. This time it's intentional (I'll be in the French Pyrenees 
above Amélie-les-Bains, nearer to the Spanish border than to the nearest 
neighbour); I'm telling you so you won't be thinking I suddenly fell 
dead, ha ha. On Bastille Day I'll be back. Have a nice fortnight.



Happy Vimming!
Tony.


paste formatting

2006-06-27 Thread Bill Pursell


Yesterday, a bizarre thing happened that I have not
been able to replicate, and I'm hoping someone can
tell me a) exactly what I might have done, and b) how
to avoid it in the future.

I had a mostly empty function definition:

void
foo(void)
{
   return;
}

I selected a bunch of code from a fully written function,
by doing 'y%' with the cursor on the open brace of the function,
and then went into foo and pasted with 'p'.  The text pasted
fine, but all of the functions in the file below foo were
re-formatted so that the return type was indented:

  type
baz (void)
{

Why did the re-format happen?  I probably had paste set, but
can't think of anything else that was different than my normal
settings, and as I said I can't replicate the behavior.

Any help appreciated.


problem in understading 0tag usage

2006-06-27 Thread SHANKAR R-R66203
Hi All,

I am using tags heavily.

0tags command seems to not work properly.

Let me explain the problem:

When I type tags, the following is printed by VIM.

  # TO tag FROM line  in file/text
  1  1 mcu_mac7201 1  \Profiles\r66203\_tags\LF\harlech.hier
  2  1 core_mac7201 1017
~\..\..\Projects\Harlech\verilog\mcu_mac7201.v
  3  1 ipss_mac7201 1696
~\..\..\Projects\Harlech\verilog\core_mac7201.v
 4  1 crg_arm  1908  crg_arm #(MOD_EN_WIDTH) crg_arm (
  5  1 crg_core  472  ~\..\..\Projects\Harlech\verilog\crg_arm.v
  6  1 crg_cgen  448
~\..\..\Projects\Harlech\verilog\crg_core.v


I am currently at tag#4 i.e. crg_arm
I want to go to tag#5, i.e. crg_core

So, I type the following in the command line
:0tag
As per my understanding with the 0tag documentation, this command takes
to the last used tag. 
This does not work.
VIM reports an error message.

How do I go to tag#5, without typing
:tag crg_core

Best Regards,
Shankar