gmane.editors.vim.devel

Re: InsertEnter cursor position related

troydm — 2013-05-18T21:57:20

Wait, isn't check_cursor_col() called only when line number hasn't changed, and that is when cursor's position is resetted to value before event call

Re: InsertEnter cursor position related

troydm — 2013-05-18T21:53:16

You mean check_cursor_col() call is to check for the line to avoid going outside of the available lines when text has changed i presume?
So what is the proposed fix?

commenting/removing this line?
curwin->w_cursor = save_cursor;

Re: runtime/doc/tags under Mercurial control

Tony Mechelynck — 2013-05-18T21:33:26

Adding runtime/doc/tags to .hgignore (plus hg rm runtime/doc/tags and hg 
commit) will make the tags file untracked on your clone. Every time it 
is modified on Bram's repository you'll get a message on the next update 
or fetch:

remote changed runtime/doc/tags which local deleted
use (c)hanged version or leave (d)eleted?

to which you'll answer d to keep it untracked. If you are logging the 
output of Mercurial (using, for instance, 2>&1 | tee -a vim.log) you 
should set $PYTHONUNBUFFERED to something other than the empty string (I 
use "export PYTHONUNBUFFERED='unbuffered'") or you won't see the prompt 
until after you've typed the answer.

That's what I do, and it works.


Best regards,
Tony.

Build failure on CentOS 5.9

Christian J. Robinson — 2013-05-18T21:32:38

I think reported this before, so it's been around for many 
patchlevels, but it's still outstanding. During linking:

[..]/vim73/src/if_ruby.c:739: undefined reference to `ruby_init_stack'
collect2: ld returned 1 exit status
link.sh: Linking failed
make: *** [vim] Error 1

Re: InsertEnter cursor position related

Bram Moolenaar — 2013-05-18T21:23:24

Troydm (?) wrote:


You can use the CursorMovedI event instead.  If it's slow you can set a
flag in InsertEnter and only do something in CursorMovedI when it' set.
Hmm, I suppose it doesn't work for the "i" command, the cursor doesn't
move then.  You would have to map it.

Re: On the runtime files shipped with Vim

Bram Moolenaar — 2013-05-18T21:23:23

Patrick wrote:


Ask me to include it.  Send it by email as an attachment.

Re: To all syntax file maintainers: examples needed

Bram Moolenaar — 2013-05-18T21:23:22

I wrote:


With the few files I received I already found two bugs in the new regexp
engine.

But I received only 7 files. I need many more!  So now asking everyone,
not just syntax file maintainers, to send me files for testing.  Please
read the quoted text above for what the file should contain.

Re: InsertEnter cursor position related

Bram Moolenaar — 2013-05-18T21:23:23

Troydm (?) wrote:


That's a bug.  The check for the line is to avoid going outside of the
available lines when the text has changed.

On the runtime files shipped with Vim

parcs — 2013-05-18T17:03:36

Hi,

I noticed that Vim ships with many runtime files which are maintained by third parties. Is there an official procedure for requesting that a particular third-party plugin get shipped with Vim?

Patrick

statusline and %!Func() its context, seems like bad behaviour to me

meh. — 2013-05-18T18:27:02

I'm writing a fairly complex statusline and using %!Func() as
statusline, everything was good until I started using my new shiny
statusline and I realized the context it's run in is the current
window and not the context %{} would use, so the one the statusline
belongs to.

Is this intended? Because it makes doing what I want to do basically
impossible.

Re: InsertEnter cursor position related

troydm — 2013-05-18T20:18:37

Also as it is now i can move a cursor from InsertEnter as long as it's moved on a different line (not the same line)

for example open some multi line file

do

:au InsertEnter <buffer> normal! 3jl

try entering insert mode on the first line (it works)

now reopen some other multiline file and do

:au InsertEnter <buffer> normal! 3l

And it doesn't works

Re: InsertEnter cursor position related

troydm — 2013-05-18T20:09:55

Well for example one of my plugins includes bash shell emulation inside a vim buffer, it's called shellasync.vim and it's source code is at https://github.com/troydm/shellasync.vim, it uses InsertEnter to check if user went into insert mode while his cursor was on prefix of shell e.g. '$' symbol and if it does it just automaticly moves cursor on 3rd col instead. For a user of my plugin (atleast for me) this is an expected behaviour

Re: [PATCH] Refactoring: less type casts and less magic variables

ZyX — 2013-05-18T20:09:23

I meant “magic numbers”.

Patch 7.3.969

Bram Moolenaar — 2013-05-18T18:55:54

Patch 7.3.969
Problem:    Can't built with Python 3 and without Python 2.
Solution:   Adjust #ifdef. (Xavier de Gaye)
Files:    src/window.c


*** ../vim-7.3.968/src/window.c2013-05-17 16:03:53.000000000 +0200
--- src/window.c2013-05-18 20:53:21.000000000 +0200
***************
*** 4058,4064 ****
  }
  #endif
  
! #if (defined(FEAT_WINDOWS) && defined(FEAT_PYTHON)) || defined(PROTO)
  /*
   * Find the tabpage for window "win".
   */
--- 4058,4065 ----
  }
  #endif
  
! #if (defined(FEAT_WINDOWS) && (defined(FEAT_PYTHON) || defined(FEAT_PYTHON3))) \
! || defined(PROTO)
  /*
   * Find the tabpage for window "win".
   */
*** ../vim-7.3.968/src/version.c2013-05-18 20:45:51.000000000 +0200
--- src/version.c2013-05-18 20:54:16.000000000 +0200
***************
*** 730,731 ****
--- 730,733 ----
  {   /* Add new patch number below this line */
+ /**/
+     969,
  /**/

Re: [PATCH] Refactoring: less type casts and less magic variables

Bram Moolenaar — 2013-05-18T18:55:53

ZyX wrote:


I like it.

Re: linking failure when attempting to build with python3 on version 7.3.967

Bram Moolenaar — 2013-05-18T18:55:54

Xavier de Gaye wrote:


Thanks!

Patch 7.3.968

Bram Moolenaar — 2013-05-18T18:46:18

Patch 7.3.968
Problem:    Multi-byte support is only available when compiled with "big"
    features.
Solution:   Include multi-byte by default, with "normal" features.
Files:    src/feature.h


*** ../vim-7.3.967/src/feature.h2013-05-06 04:21:35.000000000 +0200
--- src/feature.h2013-05-18 20:18:20.000000000 +0200
***************
*** 638,644 ****
   * Disabled for EBCDIC:
   * Multibyte support doesn't work on z/OS Unix currently.
   */
! #if (defined(FEAT_BIG) || defined(FEAT_GUI_GTK) || defined(FEAT_ARABIC)) \
  && !defined(FEAT_MBYTE) && !defined(WIN16) \
  && SIZEOF_INT >= 4 && !defined(EBCDIC)
  # define FEAT_MBYTE
--- 638,644 ----
   * Disabled for EBCDIC:
   * Multibyte support doesn't work on z/OS Unix currently.
   */
! #if (defined(FEAT_NORMAL) || defined(FEAT_GUI_GTK) || defined(FEAT_ARABIC)) \
  && !defined(FEAT_MBYTE) && !defined(WIN16) \
  && SIZEOF_INT >= 4 && !defined(EBCDIC)
  # define FEAT_MBYTE
*** ../vim-7.3.967/src/version.c2013-05-17 21:20:13.000000000 +0200
--- src/version.c

Re: Python items in the todo list

ZyX — 2013-05-18T18:01:47

There are two other big advantages of this “magic”: user did not loose control 
over `sys.path` and it can be written in pure python. All advantages in a list: 
it …

1. makes it possible to specify which directories should be searched before 
   plugin ones and which after;
2. makes it possible to remove vim paths from sys.path completely and not ever 
   have problems with vim adding them again;
3. can be written in pure python and fallback implementation for old vims (the 
   ones even without vim.eval) can be created;
4. makes hacking non-if_py* C files not needed.

There is a reason for coding it in C though (and porting < at >Xavier de Gaye file to C as well): this makes vim core functionality independent of presence of runtime files. There is a reason for not coding it in C as well: it is faster to write in python and even being written in python this will not have problems with performance (it’ll in any case waste much time on IO).

Re: [RFC] Enhance syntax support

Ben Fritz — 2013-05-18T15:09:58

You say "decouple" which means "make them less dependent on each other". But your examples seem to be asking for making various commands more context-aware, which would probably be *more* coupled to syntax, not less. Which do you want?

[PATCH] Refactoring: less type casts and less magic variables

ZyX — 2013-05-18T14:21:18

# HG changeset patch
# User ZyX <kp-pav< at >ya.ru>
# Date 1368866112 -14400
# Branch python-extended-2
# Node ID 97bbb36fe75d0842ada71d0e62eca7ca411072a6
# Parent  a682902e547d02c97e816ec52a34e257582662d7
Refactoring: replace a big bunch of type casts with proper argument types

Implies type casts when initializing structures.

diff -r a682902e547d -r 97bbb36fe75d src/if_py_both.h
--- a/src/if_py_both.hSat May 18 01:47:01 2013 +0400
+++ b/src/if_py_both.hSat May 18 12:35:12 2013 +0400
< at >< at > -76,7 +76,7 < at >< at >
 } OutputObject;
 
     static int
-OutputSetattr(PyObject *self, char *name, PyObject *val)
+OutputSetattr(OutputObject *self, char *name, PyObject *val)
 {
     if (val == NULL)
     {
< at >< at > -93,7 +93,7 < at >< at >
     return -1;
 }
 
-((OutputObject *)(self))->softspace = PyInt_AsLong(val);
+self->softspace = PyInt_AsLong(val);
 return 0;
     }
 
< at >< at > -152,11 +152,11 < at >< at >
 }
 
     static PyObject *
-OutputWrite(PyObject *self, PyObject *args)
+OutputWrite(OutputObject *self, PyObject *args)
 {
     Py_ssize_t len = 0

Re: Python items in the todo list

ZyX — 2013-05-18T14:12:28

This does not matter. When you assign to `os.chdir` they are no longer 
identical.


libcall() can use the same function for checking for os.chdir.


`os` seems to be safe regarding the issue.


Yes, I changed the implementation immediately after I found that removing from 
`sys.modules` may introduce strange TypeErrors (objects in module got assigned 
None). I have never seen such behavior for C modules though, only for python 
ones.