Patch 7.0.159

2006-11-07 Thread Bram Moolenaar

Patch 7.0.159
Problem:When there is an I/O error in the swap file the cause of the error
cannot be seen.
Solution:   Use PERROR() instead of EMSG() where possible.
Files:  src/memfile.c


*** ../vim-7.0.158/src/memfile.cWed Nov  1 18:10:36 2006
--- src/memfile.c   Wed Nov  1 21:38:59 2006
***
*** 1028,1039 
  size = page_size * hp-bh_page_count;
  if (lseek(mfp-mf_fd, offset, SEEK_SET) != offset)
  {
!   EMSG(_(E294: Seek error in swap file read));
return FAIL;
  }
  if ((unsigned)vim_read(mfp-mf_fd, hp-bh_data, size) != size)
  {
!   EMSG(_(E295: Read error in swap file));
return FAIL;
  }
  return OK;
--- 1028,1039 
  size = page_size * hp-bh_page_count;
  if (lseek(mfp-mf_fd, offset, SEEK_SET) != offset)
  {
!   PERROR(_(E294: Seek error in swap file read));
return FAIL;
  }
  if ((unsigned)vim_read(mfp-mf_fd, hp-bh_data, size) != size)
  {
!   PERROR(_(E295: Read error in swap file));
return FAIL;
  }
  return OK;
***
*** 1085,1091 
offset = (off_t)page_size * nr;
if (lseek(mfp-mf_fd, offset, SEEK_SET) != offset)
{
!   EMSG(_(E296: Seek error in swap file write));
return FAIL;
}
if (hp2 == NULL)/* freed block, fill with dummy data */
--- 1085,1091 
offset = (off_t)page_size * nr;
if (lseek(mfp-mf_fd, offset, SEEK_SET) != offset)
{
!   PERROR(_(E296: Seek error in swap file write));
return FAIL;
}
if (hp2 == NULL)/* freed block, fill with dummy data */
*** ../vim-7.0.158/src/version.cWed Nov  1 21:24:58 2006
--- src/version.c   Tue Nov  7 17:58:58 2006
***
*** 668,669 
--- 668,671 
  {   /* Add new patch number below this line */
+ /**/
+ 159,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
171. You invent another person and chat with yourself in empty chat rooms.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///


Patch 7.0.160

2006-11-07 Thread Bram Moolenaar

Patch 7.0.160
Problem::@a echoes the command, Vi doesn't do that.
Solution:   Set the silent flag in the typeahead buffer to avoid echoing the
command.
Files:  src/ex_docmd.c, src/normal.c, src/ops.c, src/proto/ops.pro


*** ../vim-7.0.159/src/ex_docmd.c   Tue Oct 24 13:02:27 2006
--- src/ex_docmd.c  Tue Nov  7 17:42:52 2006
***
*** 8219,8226 
  c = *eap-arg;
  if (c == NUL || (c == '*'  *eap-cmd == '*'))
c = '@';
! /* put the register in mapbuf */
! if (do_execreg(c, TRUE, vim_strchr(p_cpo, CPO_EXECBUF) != NULL) == FAIL)
  {
beep_flush();
  }
--- 8219,8227 
  c = *eap-arg;
  if (c == NUL || (c == '*'  *eap-cmd == '*'))
c = '@';
! /* Put the register in the typeahead buffer with the silent flag. */
! if (do_execreg(c, TRUE, vim_strchr(p_cpo, CPO_EXECBUF) != NULL, TRUE)
! == FAIL)
  {
beep_flush();
  }
*** ../vim-7.0.159/src/normal.c Tue Oct 17 22:40:14 2006
--- src/normal.cTue Nov  7 17:42:59 2006
***
*** 8860,8866 
  #endif
  while (cap-count1--  !got_int)
  {
!   if (do_execreg(cap-nchar, FALSE, FALSE) == FAIL)
{
clearopbeep(cap-oap);
break;
--- 8860,8866 
  #endif
  while (cap-count1--  !got_int)
  {
!   if (do_execreg(cap-nchar, FALSE, FALSE, FALSE) == FAIL)
{
clearopbeep(cap-oap);
break;
*** ../vim-7.0.159/src/ops.cTue Oct 17 16:26:52 2006
--- src/ops.c   Tue Nov  7 17:52:30 2006
***
*** 95,102 
  static void block_insert __ARGS((oparg_T *oap, char_u *s, int b_insert, 
struct block_def*bdp));
  #endif
  static intstuff_yank __ARGS((int, char_u *));
! static void   put_reedit_in_typebuf __ARGS((void));
! static intput_in_typebuf __ARGS((char_u *s, int colon));
  static void   stuffescaped __ARGS((char_u *arg, int literally));
  #ifdef FEAT_MBYTE
  static void   mb_adjust_opend __ARGS((oparg_T *oap));
--- 95,102 
  static void block_insert __ARGS((oparg_T *oap, char_u *s, int b_insert, 
struct block_def*bdp));
  #endif
  static intstuff_yank __ARGS((int, char_u *));
! static void   put_reedit_in_typebuf __ARGS((int silent));
! static intput_in_typebuf __ARGS((char_u *s, int colon, int silent));
  static void   stuffescaped __ARGS((char_u *arg, int literally));
  #ifdef FEAT_MBYTE
  static void   mb_adjust_opend __ARGS((oparg_T *oap));
***
*** 1120,1129 
   * return FAIL for failure, OK otherwise
   */
  int
! do_execreg(regname, colon, addcr)
  int   regname;
  int   colon;  /* insert ':' before each line */
  int   addcr;  /* always add '\n' to end of line */
  {
  static intlastc = NUL;
  long  i;
--- 1120,1130 
   * return FAIL for failure, OK otherwise
   */
  int
! do_execreg(regname, colon, addcr, silent)
  int   regname;
  int   colon;  /* insert ':' before each line */
  int   addcr;  /* always add '\n' to end of line */
+ int   silent; /* set silent flag in typeahead 
buffer */
  {
  static intlastc = NUL;
  long  i;
***
*** 1173,1181 
/* When in Visual mode ',' will be prepended to the command.
 * Remove it when it's already there. */
if (VIsual_active  STRNCMP(p, ',', 5) == 0)
!   retval = put_in_typebuf(p + 5, TRUE);
else
!   retval = put_in_typebuf(p, TRUE);
}
vim_free(p);
  }
--- 1174,1182 
/* When in Visual mode ',' will be prepended to the command.
 * Remove it when it's already there. */
if (VIsual_active  STRNCMP(p, ',', 5) == 0)
!   retval = put_in_typebuf(p + 5, TRUE, silent);
else
!   retval = put_in_typebuf(p, TRUE, silent);
}
vim_free(p);
  }
***
*** 1186,1192 
p = get_expr_line();
if (p == NULL)
return FAIL;
!   retval = put_in_typebuf(p, colon);
vim_free(p);
  }
  #endif
--- 1187,1193 
p = get_expr_line();
if (p == NULL)
return FAIL;
!   retval = put_in_typebuf(p, colon, silent);
vim_free(p);
  }
  #endif
***
*** 1198,1204 
EMSG(_(e_noinstext));
return FAIL;
}
!   retval = put_in_typebuf(p, colon);
vim_free(p);
  }
  else
--- 1199,1205 
EMSG(_(e_noinstext));
return FAIL;
}
!   retval = put_in_typebuf(p, colon, silent);
vim_free(p);
  }
  else
***
*** 1213,1232 
/*
 * Insert lines into typeahead buffer, from last one to first one.
 */
!   

Flickering of completion menu

2006-11-07 Thread Nikolai Weibull

Hi!

As you've probably all noticed the completion menu flickers when you
move through the items rapidly.  Why is this?  Is it really necessary
to redraw the whole completion menu when it really only should require
redrawing the item previously selected and the item selected now [1]?

Anyway, would this be possible to implement?

Also, here's a set of mappings that make the digits move their value
number of items down the completion list (if displayed):

for digit in [1, 2, 3, 4, 5, 6, 8, 9]
 execute 'inoremap silent ' . digit . ' C-R=pumvisible() ? ' .
repeat('\ltC-N', digit) . ' : ' . digit . 'CR'
endfor

(I guess this could be extended to include -n, for 1 = n = 9, which
would move n number of items upward.  Any takers?)

It flickers like mad, but at least it goes a lot faster than holding
down CTRL-N or CTRL-P.

 nikolai

[1] Excepting the case where one begins to scroll in the menu, when
all items need to be redrawn, as they move up or down one step - which
leads to a second question, wouldn't it be a lot more economical to
scroll like half a menu or something, so that scrolling wouldn't
require so many redraws?  Or at least utilize the terminal codes that
enable scrolling in a buffer to be done with only redrawing the first
or last line when scrolling by a single line in a buffer?


Patch 7.0.161

2006-11-07 Thread Bram Moolenaar

Patch 7.0.161
Problem:Win32: Tab pages line popup menu isn't using the right encoding.
(Yongwei Wu)
Solution:   Convert the text when necessary.  Also fixes the Find/Replace
dialog title. (Yegappan Lakshmanan)
Files:  src/gui_w48.c


*** ../vim-7.0.160/src/gui_w48.cTue Aug 29 21:30:15 2006
--- src/gui_w48.c   Tue Nov  7 19:03:52 2006
***
*** 2217,2226 
  
  #if defined(FEAT_GUI_TABLINE) || defined(PROTO)
  static void
  show_tabline_popup_menu(void)
  {
  HMENU tab_pmenu;
- MENUITEMINFOminfo;
  long  rval;
  POINT pt;
  
--- 2217,2270 
  
  #if defined(FEAT_GUI_TABLINE) || defined(PROTO)
  static void
+ add_tabline_popup_menu_entry(HMENU pmenu, UINT item_id, char_u *item_text)
+ {
+ #ifdef FEAT_MBYTE
+ WCHAR *wn = NULL;
+ int   n;
+ 
+ if (enc_codepage = 0  (int)GetACP() != enc_codepage)
+ {
+   /* 'encoding' differs from active codepage: convert menu name
+* and use wide function */
+   wn = enc_to_ucs2(item_text, NULL);
+   if (wn != NULL)
+   {
+   MENUITEMINFOW   infow;
+ 
+   infow.cbSize = sizeof(infow);
+   infow.fMask = MIIM_TYPE | MIIM_ID;
+   infow.wID = item_id;
+   infow.fType = MFT_STRING;
+   infow.dwTypeData = wn;
+   infow.cch = (UINT)wcslen(wn);
+   n = InsertMenuItemW(pmenu, item_id, FALSE, infow);
+   vim_free(wn);
+   if (n == 0  GetLastError() == ERROR_CALL_NOT_IMPLEMENTED)
+   /* Failed, try using non-wide function. */
+   wn = NULL;
+   }
+ }
+ 
+ if (wn == NULL)
+ #endif
+ {
+   MENUITEMINFOinfo;
+ 
+   info.cbSize = sizeof(info);
+   info.fMask = MIIM_TYPE | MIIM_ID;
+   info.wID = item_id;
+   info.fType = MFT_STRING;
+   info.dwTypeData = item_text;
+   info.cch = (UINT)STRLEN(item_text);
+   InsertMenuItem(pmenu, item_id, FALSE, info);
+ }
+ }
+ 
+ static void
  show_tabline_popup_menu(void)
  {
  HMENU tab_pmenu;
  long  rval;
  POINT pt;
  
***
*** 2236,2256 
  if (tab_pmenu == NULL)
return;
  
! minfo.cbSize = sizeof(MENUITEMINFO);
! minfo.fMask = MIIM_TYPE|MIIM_ID;
! minfo.fType = MFT_STRING;
! 
! minfo.dwTypeData = _(Close tab);
! minfo.wID = TABLINE_MENU_CLOSE;
! InsertMenuItem(tab_pmenu, TABLINE_MENU_CLOSE, FALSE, minfo);
! 
! minfo.dwTypeData = _(New tab);
! minfo.wID = TABLINE_MENU_NEW;
! InsertMenuItem(tab_pmenu, TABLINE_MENU_NEW, FALSE, minfo);
! 
! minfo.dwTypeData = _(Open tab...);
! minfo.wID = TABLINE_MENU_OPEN;
! InsertMenuItem(tab_pmenu, TABLINE_MENU_OPEN, FALSE, minfo);
  
  GetCursorPos(pt);
  rval = TrackPopupMenuEx(tab_pmenu, TPM_RETURNCMD, pt.x, pt.y, s_tabhwnd,
--- 2280,2289 
  if (tab_pmenu == NULL)
return;
  
! add_tabline_popup_menu_entry(tab_pmenu, TABLINE_MENU_CLOSE, _(Close 
tab));
! add_tabline_popup_menu_entry(tab_pmenu, TABLINE_MENU_NEW, _(New tab));
! add_tabline_popup_menu_entry(tab_pmenu, TABLINE_MENU_OPEN,
!_(Open tab...));
  
  GetCursorPos(pt);
  rval = TrackPopupMenuEx(tab_pmenu, TPM_RETURNCMD, pt.x, pt.y, s_tabhwnd,
***
*** 2455,2460 
--- 2488,2517 
  }
  #endif
  
+ static void
+ set_window_title(HWND hwnd, char *title)
+ {
+ #ifdef FEAT_MBYTE
+ if (title != NULL  enc_codepage = 0  enc_codepage != (int)GetACP())
+ {
+   WCHAR   *wbuf;
+   int n;
+ 
+   /* Convert the title from 'encoding' to ucs2. */
+   wbuf = (WCHAR *)enc_to_ucs2((char_u *)title, NULL);
+   if (wbuf != NULL)
+   {
+   n = SetWindowTextW(hwnd, wbuf);
+   vim_free(wbuf);
+   if (n != 0 || GetLastError() != ERROR_CALL_NOT_IMPLEMENTED)
+   return;
+   /* Retry with non-wide function (for Windows 98). */
+   }
+ }
+ #endif
+ (void)SetWindowText(hwnd, (LPCSTR)title);
+ }
+ 
  void
  gui_mch_find_dialog(exarg_T *eap)
  {
***
*** 2470,2477 
s_findrep_hwnd = FindText((LPFINDREPLACE) s_findrep_struct);
}
  
!   (void)SetWindowText(s_findrep_hwnd,
!  (LPCSTR)_(Find string (use '' to find  a '\\')));
(void)SetFocus(s_findrep_hwnd);
  
s_findrep_is_find = TRUE;
--- 2527,2534 
s_findrep_hwnd = FindText((LPFINDREPLACE) s_findrep_struct);
}
  
!   set_window_title(s_findrep_hwnd,
!  _(Find string (use '' to find  a '\\')));
(void)SetFocus(s_findrep_hwnd);
  
s_findrep_is_find = TRUE;
***
*** 2495,2502 
s_findrep_hwnd = ReplaceText((LPFINDREPLACE) s_findrep_struct);
}
  
!   (void)SetWindowText(s_findrep_hwnd,
!   (LPCSTR)_(Find  Replace 

Current buffer name after :python os.chdir()

2006-11-07 Thread Xavier de Gaye

Assuming the current buffer is the file 'foobar' in the current
directory. After running the following Vim commands:

:python import os
:python os.chdir(subdir)

the current buffer name is not changed as it is when you run
the Vim command ':cd subdir' (but the output of ':pwd' is Ok),
and when the following command is run afterwards:

:write

Vim writes the buffer to the file 'subdir/foobar', instead of the
original file.

This happens with Vim 7.0 compiled with Python 2.5.

Xavier

--
http://clewn.sourceforge.net   gdb support in Vim


[RFC] Add a new getAnno function to the netbeans protocol

2006-11-07 Thread Xavier de Gaye

During the compile-debug-edit development cycle, the signs placed in
the Vim buffers by the IDE with the netbeans protocol can have their
line numbers changed when the buffers are edited (a Vim sign sticks with
the line it has been set upon, and moves with it).

It would be nice to allow the IDE to query Vim for these updated line
numbers, so that when the IDE restarts gdb after a new make and the IDE
is capable of restoring the breakpoints set on a previous session, the
breakpoints and their corresponding signs can be automatically set by
the IDE to their new position.

The netbeans function documentation can be:

===
10.4 Functions and Replies  *nb-functions*

getAnno serNum  Return the line number of the annotation in the buffer
Arguments:
   serNum  serial number of this placed annotation
The reply is:
lnum = line number of the annotation
===


The implementation can be based on the existing sign_list_placed()
function in buffer.c. I can propose a patch if this request for change
is acceptable.

Xavier


--
http://clewn.sourceforge.net   gdb support in Vim


Re: Current buffer name after :python os.chdir()

2006-11-07 Thread Bram Moolenaar

Xavier de Gaye wrote:

 Assuming the current buffer is the file 'foobar' in the current
 directory. After running the following Vim commands:
 
 :python import os
 :python os.chdir(subdir)
 
 the current buffer name is not changed as it is when you run
 the Vim command ':cd subdir' (but the output of ':pwd' is Ok),
 and when the following command is run afterwards:
 
 :write
 
 Vim writes the buffer to the file 'subdir/foobar', instead of the
 original file.
 
 This happens with Vim 7.0 compiled with Python 2.5.

Well, you should not use Python to change directory.  But it may happen
unintentionally...  Checking the current directory after each :python
command is a bit inefficient, but that's probably what needs to be done
then.  An alternative is to always chdir back to where we were to undo
the side effect of the Python command.

-- 
If Apple would build a car...
... it would be powered by the sun, be reliable, five times
as fast and twice as easy to drive; but would only run on
five percent of the roads.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///


Re: [RFC] Add a new getAnno function to the netbeans protocol

2006-11-07 Thread Bram Moolenaar

Xavier de Gaye wrote:

 During the compile-debug-edit development cycle, the signs placed in
 the Vim buffers by the IDE with the netbeans protocol can have their
 line numbers changed when the buffers are edited (a Vim sign sticks with
 the line it has been set upon, and moves with it).
 
 It would be nice to allow the IDE to query Vim for these updated line
 numbers, so that when the IDE restarts gdb after a new make and the IDE
 is capable of restoring the breakpoints set on a previous session, the
 breakpoints and their corresponding signs can be automatically set by
 the IDE to their new position.
 
 The netbeans function documentation can be:
 
 ===
 10.4 Functions and Replies  *nb-functions*
 
 getAnno serNum  Return the line number of the annotation in the buffer
 Arguments:
serNum  serial number of this placed annotation
 The reply is:
 lnum = line number of the annotation
 ===
 
 
 The implementation can be based on the existing sign_list_placed()
 function in buffer.c. I can propose a patch if this request for change
 is acceptable.

It makes sense.  The only alternative is to listen to insert and
delete messages to keep track of the position, which probably requires
keeping a copy of the text.

-- 
If Microsoft would build a car...
... the oil, water temperature, and alternator warning lights would
all be replaced by a single General Protection Fault warning light.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///


Patch 7.0.162

2006-11-07 Thread Bram Moolenaar

Patch 7.0.162
Problem:vim -o a b when file a triggers the ATTENTION dialog,
selecting Quit exits Vim instead of editing b only.
When file b triggers the ATTENTION dialog selecting Quit or
Abort results in editing file a in that window.
Solution:   When selecting Abort exit Vim.  When selecting Quit close the
window.  Also avoid hit-enter prompt when selecting Abort.
Files:  src/buffer.c, src/main.c


*** ../vim-7.0.161/src/buffer.c Fri Oct 20 20:15:05 2006
--- src/buffer.cTue Nov  7 21:08:02 2006
***
*** 4220,4226 
  
  /* Use the name from the associated buffer if it exists. */
  bp = buflist_findnr(aep-ae_fnum);
! if (bp == NULL)
return aep-ae_fname;
  return bp-b_fname;
  }
--- 4222,4228 
  
  /* Use the name from the associated buffer if it exists. */
  bp = buflist_findnr(aep-ae_fnum);
! if (bp == NULL || bp-b_fname == NULL)
return aep-ae_fname;
  return bp-b_fname;
  }
*** ../vim-7.0.161/src/main.c   Tue Sep  5 12:57:14 2006
--- src/main.c  Tue Nov  7 22:35:49 2006
***
*** 2392,2398 
(void)open_buffer(FALSE, NULL); /* create memfile, read file */
  
  #if defined(HAS_SWAP_EXISTS_ACTION)
!   check_swap_exists_action();
  #endif
  #ifdef FEAT_AUTOCMD
dorewind = TRUE;/* start again */
--- 2392,2414 
(void)open_buffer(FALSE, NULL); /* create memfile, read file */
  
  #if defined(HAS_SWAP_EXISTS_ACTION)
!   if (swap_exists_action == SEA_QUIT)
!   {
!   if (got_int || only_one_window())
!   {
!   /* abort selected or quit and only one window */
!   did_emsg = FALSE;   /* avoid hit-enter prompt */
!   getout(1);
!   }
!   /* We can't close the window, it would disturb what
!* happens next.  Clear the file name and set the arg
!* index to -1 to delete it later. */
!   setfname(curbuf, NULL, NULL, FALSE);
!   curwin-w_arg_idx = -1;
!   swap_exists_action = SEA_NONE;
!   }
!   else
!   handle_swap_exists(NULL);
  #endif
  #ifdef FEAT_AUTOCMD
dorewind = TRUE;/* start again */
***
*** 2432,2437 
--- 2448,2455 
  {
  int   arg_idx;/* index in argument list */
  int   i;
+ int   advance = TRUE;
+ buf_T *old_curbuf;
  
  # ifdef FEAT_AUTOCMD
  /*
***
*** 2440,2470 
  ++autocmd_no_enter;
  ++autocmd_no_leave;
  # endif
  arg_idx = 1;
  for (i = 1; i  parmp-window_count; ++i)
  {
!   if (parmp-window_layout == WIN_TABS)
{
!   if (curtab-tp_next == NULL)/* just checking */
!   break;
!   goto_tabpage(0);
}
!   else
{
!   if (curwin-w_next == NULL) /* just checking */
!   break;
!   win_enter(curwin-w_next, FALSE);
}
  
/* Only open the file if there is no file in this window yet (that can
!* happen when .vimrc contains :sall) */
if (curbuf == firstwin-w_buffer || curbuf-b_ffname == NULL)
{
curwin-w_arg_idx = arg_idx;
!   /* edit file from arg list, if there is one */
(void)do_ecmd(0, arg_idx  GARGCOUNT
  ? alist_name(GARGLIST[arg_idx]) : NULL,
  NULL, NULL, ECMD_LASTL, ECMD_HIDE);
if (arg_idx == GARGCOUNT - 1)
arg_had_last = TRUE;
++arg_idx;
--- 2458,2522 
  ++autocmd_no_enter;
  ++autocmd_no_leave;
  # endif
+ 
+ /* When w_arg_idx is -1 remove the window (see create_windows()). */
+ if (curwin-w_arg_idx == -1)
+ {
+   win_close(curwin, TRUE);
+   advance = FALSE;
+ }
+ 
  arg_idx = 1;
  for (i = 1; i  parmp-window_count; ++i)
  {
!   /* When w_arg_idx is -1 remove the window (see create_windows()). */
!   if (curwin-w_arg_idx == -1)
{
!   ++arg_idx;
!   win_close(curwin, TRUE);
!   advance = FALSE;
!   continue;
}
! 
!   if (advance)
{
!   if (parmp-window_layout == WIN_TABS)
!   {
!   if (curtab-tp_next == NULL)/* just checking */
!   break;
!   goto_tabpage(0);
!   }
!   else
!   {
!   if (curwin-w_next == NULL) /* just checking */
!   break;
!   win_enter(curwin-w_next, FALSE);
!   }
}
+   advance = TRUE;
  
/* Only open the file if there is no file in this window yet (that can
!* happen when .vimrc contains :sall). */

Re: Current buffer name after :python os.chdir()

2006-11-07 Thread Xavier de Gaye

--- Bram Moolenaar [EMAIL PROTECTED] wrote:

 Xavier de Gaye wrote:

  Assuming the current buffer is the file 'foobar' in the current
  directory. After running the following Vim commands:
 
  :python import os
  :python os.chdir(subdir)
 
  the current buffer name is not changed as it is when you run
  the Vim command ':cd subdir' (but the output of ':pwd' is Ok),
  and when the following command is run afterwards:
 
  :write
 
  Vim writes the buffer to the file 'subdir/foobar', instead of the
  original file.
 
  This happens with Vim 7.0 compiled with Python 2.5.

 Well, you should not use Python to change directory.  But it may happen
 unintentionally...  Checking the current directory after each :python
 command is a bit inefficient, but that's probably what needs to be done
 then.  An alternative is to always chdir back to where we were to undo
 the side effect of the Python command.


I am trying to use Vim as a python interpreter. So, I have mapped:

:map F4 :exe pyfile  . expand(%)CR

I edit some python stuff in a foobar file, and hit F4 to run it.

When the foobar file content is:

import os
os.chdir(subdir)

I run into the above problem.

It is probably safer to run python as:

:map F4 :exe !python  . expand(%)CR

But you lose the capability to do some investigation on the variables
contents after the script has run.

Xavier

--
http://clewn.sourceforge.net   gdb support in Vim


Re: Flickering of completion menu

2006-11-07 Thread mzyzik
I would also love a flicker-less popup menu. I use the completion
excessively, since I've found it makes coding faster and less error
prone. I noticed the menu only flickers in some cases.

--Matt

On Wed, Nov 08, 2006 at 10:10:09AM +1100, Peter Hodge wrote:
 Hello,
 
 I agree, it would be great if the popup-menu could be optimized.  One of the
 best features of Vim is that is fast enough to keep up with my keystrokes 
 (many
 editors will begin to 'lag' when given commands too rapidly, and I have to 
 stop
 and wait for them).  I often have to slacken my pace when it comes to Vim's
 popup-menu, because it takes at least .2 seconds to redraw each time I press
 CTRL-N.
 
 regards,
 Peter
 
 
 
 
 
 --- Nikolai Weibull [EMAIL PROTECTED] wrote:
 
  Hi!
  
  As you've probably all noticed the completion menu flickers when you
  move through the items rapidly.  Why is this?  Is it really necessary
  to redraw the whole completion menu when it really only should require
  redrawing the item previously selected and the item selected now [1]?
  
  Anyway, would this be possible to implement?
  
  Also, here's a set of mappings that make the digits move their value
  number of items down the completion list (if displayed):
  
  for digit in [1, 2, 3, 4, 5, 6, 8, 9]
execute 'inoremap silent ' . digit . ' C-R=pumvisible() ? ' .
  repeat('\ltC-N', digit) . ' : ' . digit . 'CR'
  endfor
  
  (I guess this could be extended to include -n, for 1 = n = 9, which
  would move n number of items upward.  Any takers?)
  
  It flickers like mad, but at least it goes a lot faster than holding
  down CTRL-N or CTRL-P.
  
nikolai
  
  [1] Excepting the case where one begins to scroll in the menu, when
  all items need to be redrawn, as they move up or down one step - which
  leads to a second question, wouldn't it be a lot more economical to
  scroll like half a menu or something, so that scrolling wouldn't
  require so many redraws?  Or at least utilize the terminal codes that
  enable scrolling in a buffer to be done with only redrawing the first
  or last line when scrolling by a single line in a buffer?
  
 
 
 Send instant messages to your online friends http://au.messenger.yahoo.com 


vimtutor bug

2006-11-07 Thread Shannon -jj Behrens

In vimtutor, I see:

   NOTE:  A count between the operator  d  and the motion works similar to
  using the motion without an operator.

However, it seems that 2dw works the same as d2w.  I think the tutor
needs to be updated.

I'm using Vim 7.0.35.

Thanks!
-jj

--
http://jjinux.blogspot.com/