[PATCH] more-prompt: PageDown should scroll an entire screen back, not only a half
--- src/message.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/message.c b/src/message.c index e0f2897..1cb7344 100644 --- a/src/message.c +++ b/src/message.c @@ -2504,7 +2504,6 @@ do_more_prompt(typed_char) break; case 'u': /* Up half a page */ - case K_PAGEUP: scroll = -(Rows / 2); break; @@ -2513,6 +2512,7 @@ do_more_prompt(typed_char) break; case 'b': /* one page back */ + case K_PAGEUP: scroll = -(Rows - 1); break; -- 1.6.2.rc0.93.g1228 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[PATCH] more-prompt: add 'f' for scrolling back a screen
After reaching the end of the more prompt, hitting SPACE jumps out of it. Add 'f' to avoid this problem and for consistency with 'b' in scroll down a screen. This also changes the help message to contain f instead of SPACE, I'm not sure about this. This change also adds a missing leading Space for fr.po and no.po and missing trailing spaces for most of the other languages. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- runtime/doc/message.txt |4 ++-- src/message.c |3 ++- src/po/ca.po|4 ++-- src/po/de.po|4 ++-- src/po/eo.po|4 ++-- src/po/fi.po|4 ++-- src/po/fr.po|4 ++-- src/po/ga.po|4 ++-- src/po/it.po|4 ++-- src/po/ja.po|4 ++-- src/po/ja.sjis.po |4 ++-- src/po/no.po|4 ++-- src/po/pl.UTF-8.po |4 ++-- src/po/pl.cp1250.po |4 ++-- src/po/pl.po|4 ++-- src/po/pt_BR.po |4 ++-- src/po/sk.cp1250.po |4 ++-- src/po/sk.po|4 ++-- src/po/sv.po|4 ++-- src/po/uk.cp1251.po |4 ++-- src/po/uk.po|4 ++-- src/po/zh_CN.UTF-8.po |4 ++-- src/po/zh_CN.cp936.po |4 ++-- src/po/zh_CN.po |4 ++-- 24 files changed, 48 insertions(+), 47 deletions(-) diff --git a/runtime/doc/message.txt b/runtime/doc/message.txt index dc772c7..12864f1 100644 --- a/runtime/doc/message.txt +++ b/runtime/doc/message.txt @@ -786,7 +786,7 @@ group. *more-prompt* *pager* -- More -- - -- More -- SPACE/d/j: screen/page/line down, b/u/k: up, q: quit + -- More -- f/d/j: screen/page/line down, b/u/k: up, q: quit This message is given when the screen is filled with messages. It is only given when the 'more' option is on. It is highlighted with the |hl-MoreMsg| @@ -795,7 +795,7 @@ group. Type effect ~ CR or NL or j or Down one more line d down a page (half a screen) - Space or PageDown down a screen + Space or f or PageDown down a screen G down all the way, until the hit-enter prompt diff --git a/src/message.c b/src/message.c index e0f2897..8dbfd8e 100644 --- a/src/message.c +++ b/src/message.c @@ -2517,6 +2517,7 @@ do_more_prompt(typed_char) break; case ' ': /* one extra page */ + case 'f': case K_PAGEDOWN: case K_LEFTMOUSE: scroll = Rows - 1; @@ -2840,7 +2841,7 @@ msg_moremsg(full) screen_puts(s, (int)Rows - 1, 0, attr); if (full) screen_puts((char_u *) - _( SPACE/d/j: screen/page/line down, b/u/k: up, q: quit ), + _( f/d/j: screen/page/line down, b/u/k: up, q: quit ), (int)Rows - 1, vim_strsize(s), attr); } diff --git a/src/po/ca.po b/src/po/ca.po index a4d80c2..1cb38da 100644 --- a/src/po/ca.po +++ b/src/po/ca.po @@ -3724,8 +3724,8 @@ msgstr %s l msgid -- More -- msgstr -- Més -- -msgid SPACE/d/j: screen/page/line down, b/u/k: up, q: quit -msgstr ESPAI/d/j: pantalla/pàgina/línia avall, b/u/k: amunt, q: sortir +msgid f/d/j: screen/page/line down, b/u/k: up, q: quit +msgstr f/d/j: pantalla/pàgina/línia avall, b/u/k: amunt, q: sortir msgid Question msgstr Pregunta diff --git a/src/po/de.po b/src/po/de.po index 1b3a0d7..f5c5270 100644 --- a/src/po/de.po +++ b/src/po/de.po @@ -3602,8 +3602,8 @@ msgstr %s Zeile %ld msgid -- More -- msgstr -- Mehr -- -msgid SPACE/d/j: screen/page/line down, b/u/k: up, q: quit -msgstr LEERZEICHEN/d/j: Seite/halbe Seite/Zeile vorwärts, b/u/k: rückwärts, q: Ende +msgid f/d/j: screen/page/line down, b/u/k: up, q: quit +msgstr f/d/j: Seite/halbe Seite/Zeile vorwärts, b/u/k: rückwärts, q: Ende msgid Question msgstr Frage diff --git a/src/po/eo.po b/src/po/eo.po index 78e1933..a871435 100644 --- a/src/po/eo.po +++ b/src/po/eo.po @@ -3811,8 +3811,8 @@ msgstr %s linio %ld msgid -- More -- msgstr -- Pli -- -msgid SPACE/d/j: screen/page/line down, b/u/k: up, q: quit -msgstr SPACETO/d/j: ekrano/paÄo/sub linio, b/u/k: supre, q: eliri +msgid f/d/j: screen/page/line down, b/u/k: up, q: quit +msgstr f/d/j: ekrano/paÄo/sub linio, b/u/k: supre, q: eliri msgid Question msgstr Demando diff --git a/src/po/fi.po b/src/po/fi.po index 8e4c8f1..7eb7892 100644 --- a/src/po/fi.po +++ b/src/po/fi.po @@ -3792,8 +3792,8 @@ msgstr %s rivi %ld msgid -- More -- msgstr -- Lisää -- -msgid SPACE/d/j: screen/page/line down, b/u/k: up, q: quit -msgstr SPACE/d/j: ruutu/sivu/rivi alas, b/u/k: ylös, q: lopeta +msgid f/d/j: screen/page/line down, b/u/k: up, q: quit +msgstr f/d/j: ruutu/sivu/rivi alas, b/u/k: ylös, q: lopeta msgid Question msgstr Kysymys diff --git a/src/po/fr.po b/src/po/fr.po index 7d163eb..055b339 100644 --- a/src/po/fr.po +++ b/src/po/fr.po @@ -4127,9 +4127,9 @@ msgstr %s, ligne %ld
Re: [PATCH] more-prompt: add 'f' for scrolling back a screen
Markus Heidelberg, 17.02.2009: After reaching the end of the more prompt, hitting SPACE jumps out of it. Add 'f' to avoid this problem and for consistency with 'b' in scroll down a screen. Of course here it should be scroll back a screen and in the subject scrolling down a screen. Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[PATCH] tips.txt: synchronize the order in the TOC with the order of the content
--- runtime/doc/tips.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/runtime/doc/tips.txt b/runtime/doc/tips.txt index fa03236..ea108b7 100644 --- a/runtime/doc/tips.txt +++ b/runtime/doc/tips.txt @@ -26,8 +26,8 @@ Change a name in multiple files |change-name| Speeding up external commands |speed-up| Useful mappings|useful-mappings| Compressing the help files |gzip-helpfile| -Hex editing|hex-editing| Executing shell commands in a window |shell-window| +Hex editing|hex-editing| Using notation in autocommands |autocmd-| Highlighting matching parens |match-parens| -- 1.6.2.rc0.93.g1228 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Crash caused by :call substitute('', '\(.\@=\)*', '\=submatch(1)', '')
This command causes crash.
:call substitute('', '\(.\@=\)*', '\=submatch(1)', '')
Here is backtrace.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb708fac0 (LWP 23440)]
0xb73f9939 in strncpy () from /lib/tls/i686/cmov/libc.so.6
(gdb) backtrace
#0 0xb73f9939 in strncpy () from /lib/tls/i686/cmov/libc.so.6
#1 0x0811df83 in vim_strnsave (string=0x0, len=165643352) at
/usr/include/bits/string3.h:122
#2 0x08159545 in reg_submatch (no=1) at regexp.c:7287
#3 0x08092808 in f_submatch (argvars=0xbfafe59c, rettv=0xbfafeaf0) at
eval.c:16552
#4 0x0809ddd0 in call_func (name=0x9df833a submatch, len=value optimized
out, rettv=0xbfafeaf0,
argcount=1,
argvars=0xbfafe59c, firstline=1, lastline=1, doesrange=0xbfafe784,
evaluate=1, selfdict=0x0) at
eval.c:8098
#5 0x080a14bc in get_func_tv (name=0x9df833a submatch, len=8,
rettv=0xbfafeaf0, arg=0xbfafea98,
firstline=1, lastline=1,
doesrange=0xbfafe784, evaluate=1, selfdict=0x0) at eval.c:7916
#6 0x0809f77a in eval7 (arg=0xbfafea98, rettv=0xbfafeaf0, evaluate=1,
want_string=0) at eval.c:5008
#7 0x080a00e5 in eval6 (arg=0xbfafea98, rettv=0xad052007, evaluate=0,
want_string=0) at eval.c:4675
#8 0x080a035f in eval5 (arg=0xbfafea98, rettv=0xad052007, evaluate=0) at
eval.c:4491
#9 0x080a06c2 in eval4 (arg=0xbfafea98, rettv=0xad052007, evaluate=0) at
eval.c:4186
#10 0x080a0ffc in eval3 (arg=0x277e116, rettv=0xad052007, evaluate=0) at
eval.c:4098
#11 0x080a112d in eval1 (arg=0x277e116, rettv=0xad052007, evaluate=0) at
eval.c:4027
#12 0x080a235e in eval0 (arg=0x9df833a submatch, rettv=0xbfafeaf0,
nextcmd=0x0, evaluate=1) at
eval.c:3909
#13 0x080a271d in eval_to_string (arg=0x9df833a submatch, nextcmd=0x0,
convert=1) at eval.c:1290
#14 0x0815a2ee in vim_regsub_both (source=0x9df8338 \\=submatch,
dest=0x9df8458 , copy=0,
magic=1, backslash=0)
at regexp.c:6946
#15 0x0808d141 in do_string_sub (str=0x9df8458 , pat=0x9df8468
\\(.\\@=\\)*, sub=0x9df8338
\\=submatch, flags=0x9df8350 )
at eval.c:22796
#16 0x0808e95c in f_substitute (argvars=0xbfafed7c, rettv=0xbfafeed4) at
eval.c:16577
#17 0x0809ddd0 in call_func (name=0x9ded770 substitute, len=value optimized
out,
rettv=0xbfafeed4, argcount=4,
argvars=0xbfafed7c, firstline=1, lastline=1, doesrange=0xbfafeee0,
evaluate=1, selfdict=0x0) at
eval.c:8098
#18 0x080a14bc in get_func_tv (name=0x9ded770 substitute, len=10,
rettv=0xbfafeed4,
arg=0xbfafeee8, firstline=1, lastline=1,
doesrange=0xbfafeee0, evaluate=1, selfdict=0x0) at eval.c:7916
#19 0x080a6d09 in ex_call (eap=0xbfafefc8) at eval.c:3331
#20 0x080c5f47 in do_one_cmd (cmdlinep=0xbfaff140, sourcing=0,
cstack=0xbfaff144, fgetline=0x80d5230
getexline, cookie=0x0)
at ex_docmd.c:2622
#21 0x080c436a in do_cmdline (cmdline=0x0, getline=0x80d5230 getexline,
cookie=0x0, flags=0) at
ex_docmd.c:1096
#22 0x08133430 in nv_colon (cap=0xbfaff4c8) at normal.c:5233
#23 0x08135130 in normal_cmd (oap=0xbfaff52c, toplevel=1) at normal.c:1200
#24 0x080f5367 in main_loop (cmdwin=0, noexmode=0) at main.c:1180
#25 0x080f8669 in main (argc=Cannot access memory at address 0x0
) at main.c:939
--
Yukihiro Nakadaira - yukihiro.nakada...@gmail.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Crash caused by :call substitute('', '\(.\@=\)*', '\=submatch(1)', '')
Yukihiro Nakadaira wrote:
This command causes crash.
:call substitute('', '\(.\@=\)*', '\=submatch(1)', '')
Confirmed for vim 7.2.108
(called as vim -u NONE)
--
Andreas.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: PATCH: dynamically load Python on Solaris
Hi Danek, 2009/2/15 Danek Duvall: And further down that road would be to experiment with whether multiple versions of Python can be loaded into memory at the same time. If that's the case, then you could have different scripts running with different versions in the same vim session. I don't know how useful that would be in practice, though. Hi Danek, This would be very useful for the Mac OS X port of Vim (MacVim) since 10.4 comes with Python 2.3 and 10.5 ships with Python 2.5. At the moment I link MacVim against 2.3 so that it works on both 10.4 and 10.5 but several users have requested 2.5. I actually implemented dynamic loading of Python for OS X but since there are Python API changes between 2.3 and 2.5 you get a warning when trying to run on 2.3 if the binary was built using 2.5 (even though the library itself is successfullly loaded dynamically). Anyway, if you get around to implementing this I would be very eager to test it and include it in MacVim. By the way, how exactly do you propose to do this? Looking at your latest patch I assume you'd build one if_python module for each version and then decide which one to load when python is first used? Björn --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: PATCH: dynamically load Python on Solaris
björn wrote: 2009/2/15 Danek Duvall: And further down that road would be to experiment with whether multiple versions of Python can be loaded into memory at the same time. If that's the case, then you could have different scripts running with different versions in the same vim session. I don't know how useful that would be in practice, though. This would be very useful for the Mac OS X port of Vim (MacVim) since 10.4 comes with Python 2.3 and 10.5 ships with Python 2.5. At the moment I link MacVim against 2.3 so that it works on both 10.4 and 10.5 but several users have requested 2.5. So that speaks for having multiple versions available, but not necessarily for having them all co-resident. I actually implemented dynamic loading of Python for OS X but since there are Python API changes between 2.3 and 2.5 you get a warning when trying to run on 2.3 if the binary was built using 2.5 (even though the library itself is successfullly loaded dynamically). Yup, I saw that as well when playing around. By the way, how exactly do you propose to do this? Looking at your latest patch I assume you'd build one if_python module for each version and then decide which one to load when python is first used? That's the idea. I'm just not sure how that decision should be made. I guess I'm looking for some guidance from Bram, though not being terribly familiar with the vim development model, I don't know if I should be looking elsewhere for that guidance. At any rate, if I were to hack something together right now, I'd probably introduce a new variable that would let you set the order: set pythonversions=2.3,2.4,2.5 with tags of oldest and newest available as well. The first module matching an element in the series that loaded properly would be the one used, defaulting to either oldest or newest if the variable isn't set (or if none of them match?). The modules would need to be named consistently -- if_pythonver.so -- and in a collatable order, though I suppose I could always try to query the module for the definitive version if the collation proves too difficult. But there might be some pitfalls behind that. Suggestions and guidance are welcomed. Thanks, Danek --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Crash caused by :call substitute('', '\(.\@=\)*', '\=submatch(1)', '')
On Feb 17, 9:47 am, Andreas Bernauer vim-de...@lysium.de wrote:
Yukihiro Nakadaira wrote:
This command causes crash.
:call substitute('', '\(.\@=\)*', '\=submatch(1)', '')
Confirmed for vim 7.2.108
(called as vim -u NONE)
Also on Windows gvim, 7.2.101.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
if {expr1}
Hello all,
I was working on my script when I ran across this unexpected behavior with the
if statement. The doc says:
:if {expr1} *:if* *:endif* *:en* *E171* *E579* *E580*
:en[dif]Execute the commands until the next matching :else
or :endif if {expr1} evaluates to non-zero.
I thought that meant that if {expr1} evaluated to anything other than zero
(such as a string) then the if statement passes, but it doesn't. It's simple
enough to reproduce:
if atoehu
echom pass
else
echom fail
endif
Always echo's: fail.
Is the bug in the doc, vim, or in my head? I have version 7.2.106.
Cheers,
David
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: PATCH: dynamically load Python on Solaris
2009/2/17 Danek Duvall: björn wrote: 2009/2/15 Danek Duvall: And further down that road would be to experiment with whether multiple versions of Python can be loaded into memory at the same time. If that's the case, then you could have different scripts running with different versions in the same vim session. I don't know how useful that would be in practice, though. This would be very useful for the Mac OS X port of Vim (MacVim) since 10.4 comes with Python 2.3 and 10.5 ships with Python 2.5. At the moment I link MacVim against 2.3 so that it works on both 10.4 and 10.5 but several users have requested 2.5. So that speaks for having multiple versions available, but not necessarily for having them all co-resident. Yes that is all I am after -- I can't see any particular use for having two or more co-resident. (?) By the way, how exactly do you propose to do this? Looking at your latest patch I assume you'd build one if_python module for each version and then decide which one to load when python is first used? That's the idea. I'm just not sure how that decision should be made. I guess I'm looking for some guidance from Bram, though not being terribly familiar with the vim development model, I don't know if I should be looking elsewhere for that guidance. At any rate, if I were to hack something together right now, I'd probably introduce a new variable that would let you set the order: set pythonversions=2.3,2.4,2.5 with tags of oldest and newest available as well. The first module matching an element in the series that loaded properly would be the one used, defaulting to either oldest or newest if the variable isn't set (or if none of them match?). The modules would need to be named consistently -- if_pythonver.so -- and in a collatable order, though I suppose I could always try to query the module for the definitive version if the collation proves too difficult. But there might be some pitfalls behind that. Suggestions and guidance are welcomed. I think this is overkill. Why not just see which modules are installed and try loading from newest to oldest? Well, maybe it isn't that simple since loading will probably work as long as the module is present even if the matching python version is not installed. But it provides pretty much the same functionality as the option you suggested (the user simply has to make sure that only the right module is installed) and it means less code. I'm pretty new to Vim development myself, but it seems the less new options you introduce the greater the chance that your patch will be accepted. Anyway, as far as OS X is concerned the best way would be if the most recent version of python installed was automatically used (judging from the requests I've had from users) without the need of user involvement. Would this be possible? (Assuming the user has the matching if_python modules installed...in the case of OS X these would be distributed with the Vim binary inside the so-called application bundle.) Björn --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: if {expr1}
On 2/17/09, Larson, DavidX S wrote:
Hello all,
I was working on my script when I ran across this unexpected behavior
with the if statement. The doc says:
:if {expr1} *:if* *:endif* *:en* *E171* *E579* *E580*
:en[dif]Execute the commands until the next matching :else
or :endif if {expr1} evaluates to non-zero.
I thought that meant that if {expr1} evaluated to anything other than
zero (such as a string) then the if statement passes, but it
doesn't. It's simple enough to reproduce:
It does - but a string, evaluated in a numeric context, evaluates to
zero, unless the string can be interpretted as a number.
:echo abcd / 1
0
:echo 256 / 1
256
:echo 0x10 / 1
16
:echo 010 / 1
8
:echo atoehu / 1
0
if atoehu
echom pass
else
echom fail
endif
Always echo's: fail.
Right. Because atoehu, as a Number, is 0.
Is the bug in the doc, vim, or in my head? I have version 7.2.106.
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: PATCH: dynamically load Python on Solaris
On Tue, Feb 17, 2009 at 07:32:35PM +0100, björn wrote: Yes that is all I am after -- I can't see any particular use for having two or more co-resident. (?) The use case would be if you had a script that could only run with 2.3 and another that could only run with 2.6, and you wanted to use both in the same vim process. I agree that it's all that worth worrying about, though. I think this is overkill. Why not just see which modules are installed and try loading from newest to oldest? Works for me. I can always change it later to be fancier if people find the simple method to not be enough. Well, maybe it isn't that simple since loading will probably work as long as the module is present even if the matching python version is not installed. That'll probably depend on the features of the dynamic linker. On Solaris, at least, the module will fail to load if a dependency it has isn't there. I may not get to it before this weekend, but I'll post another patch as soon as I have it. In the meantime, if you have a chance to try my latest patch out on OS X, I'd be curious to know if it works there. Thanks, Danek --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: PATCH: dynamically load Python on Solaris
2009/2/17 Danek Duvall:
I may not get to it before this weekend, but I'll post another patch as
soon as I have it. In the meantime, if you have a chance to try my latest
patch out on OS X, I'd be curious to know if it works there.
The following bit of configure.in looked a bit strange, so I changed
it. No idea what that special if for MACOSX does though.
diff --git a/src/configure.in b/src/configure.in
index b623c6f..bd32b12 100644
--- a/src/configure.in
+++ b/src/configure.in
@@ -742,16 +742,12 @@ eof
fi
PYTHON_SRC=if_python.c
dnl For Mac OSX 10.2 config.o is included in the Python library.
- if test x$MACOSX = xyes; then
- PYTHON_OBJ=objects/if_python.o
- else
- if test ${enable_pythoninterp} = dynamic; then
- PYTHON_OBJ=objects/if_python_stub.o
- PYTHON_SO_OBJ=objects/if_python.o objects/py_config.o
- else
- PYTHON_OBJ=objects/if_python_stub.o objects/if_python.o objects/py_
- fi
- fi
+if test ${enable_pythoninterp} = dynamic; then
+ PYTHON_OBJ=objects/if_python_stub.o
+ PYTHON_SO_OBJ=objects/if_python.o objects/py_config.o
+else
+ PYTHON_OBJ=objects/if_python_stub.o objects/if_python.o objects/py_c
+fi
if test ${vi_cv_var_python_version} = 1.4; then
PYTHON_OBJ=$PYTHON_OBJ objects/py_getpath.o
fi
With this change I did regenerated the configure script and tried
building but something's up but I haven't got time to investigate
right now. Probably just some flag to the compiler/linker that is
missing...but I get the following errors:
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall
-Wno-unknown-pragmas -pipe -I. -Iproto -DMACOS_X_UNIX -no-cpp-precomp
-I/Developer/Headers/FlatCarbon -g -O -D_FORTIFY_SOURCE=1
-DDYNAMIC_PYTHON
-I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-Kpic -o objects/if_python.o if_python.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall
-Wno-unknown-pragmas -pipe -I. -Iproto -DMACOS_X_UNIX -no-cpp-precomp
-I/Developer/Headers/FlatCarbon -g -O -D_FORTIFY_SOURCE=1
-DDYNAMIC_PYTHON-o objects/py_config.o
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/config.c
\
-I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-I/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config
-DHAVE_CONFIG_H -DNO_MAIN
gcc -o if_python.so objects/if_python.o objects/py_config.o
Undefined symbols:
_initimp, referenced from:
__PyImport_Inittab in py_config.o
_ml_get_buf, referenced from:
_RBSlice in if_python.o
_GetBufferLine in if_python.o
_u_savesub, referenced from:
_SetBufferLine in if_python.o
_PyInt_Type, referenced from:
_PyInt_Type$non_lazy_ptr in if_python.o
_ml_append, referenced from:
_RBAssSlice in if_python.o
_RBAppend in if_python.o
_RBAppend in if_python.o
_win_setwidth, referenced from:
_WindowSetattr in if_python.o
_init_symtable, referenced from:
__PyImport_Inittab in py_config.o
_curwin, referenced from:
_curwin$non_lazy_ptr in if_python.o
-snip-
I'll look into it later on, but the compilation at least worked
fine...I just have to get the dynamic library to work (any ideas?).
Björn
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: [PATCH] more-prompt: add 'f' for scrolling back a screen
Bram Moolenaar, 18.02.2009: Markus Heidelberg wrote: After reaching the end of the more prompt, hitting SPACE jumps out of it. Add 'f' to avoid this problem and for consistency with 'b' in scroll down a screen. This also changes the help message to contain f instead of SPACE, I'm not sure about this. This change also adds a missing leading Space for fr.po and no.po and missing trailing spaces for most of the other languages. I think the message should remain using SPACE, since that is the traditional way of going forward. OK. I'm actually not sure if adding f to go a screen down is helpful. For me at least it is. f is more universal, I'm used to use f in less/man and Ctrl-F in Vim. And as mentioned above, that SPACE closes the more prompt: I don't want to accidentally press the key once to often and get bounced out of the pager, which can especially happen when scrolling fast. I don't think this is user-friendly and with supporting f it could be avoided. Also, my SPACE key makes more noise :) Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] more-prompt: add 'f' for scrolling back a screen
On Tue, Feb 17, 2009 at 9:19 PM, Markus Heidelberg wrote: Bram Moolenaar, 18.02.2009: Markus Heidelberg wrote: After reaching the end of the more prompt, hitting SPACE jumps out of it. Add 'f' to avoid this problem and for consistency with 'b' in scroll down a screen. This also changes the help message to contain f instead of SPACE, I'm not sure about this. This change also adds a missing leading Space for fr.po and no.po and missing trailing spaces for most of the other languages. I think the message should remain using SPACE, since that is the traditional way of going forward. OK. I agree with this, leave the message as is. I'm actually not sure if adding f to go a screen down is helpful. For me at least it is. f is more universal, I'm used to use f in less/man and Ctrl-F in Vim. And as mentioned above, that SPACE closes the more prompt: I don't want to accidentally press the key once to often and get bounced out of the pager, which can especially happen when scrolling fast. I don't think this is user-friendly and with supporting f it could be avoided. It definitely is helpful, both for symmetry with other vim commands (C-f and C-b in normal mode, for instance), and for symmetry with other programs. Less to learn is always a nice thing. And, given that space leaves the more prompt (and no one will want that to change), this does provide a nice alternative. I'm definitely in favor of this change. Also, my SPACE key makes more noise :) :-) ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Race condition in vim_tempname() on Windows
src/fileio.c : vim_tempname() contains these lines: if (GetTempFileName(szTempFile, buf4, 0, itmp) == 0) return NULL; /* GetTempFileName() will create the file, we don't want that */ (void)DeleteFile(itmp); Is this really right? Is there any reason to call DeleteFile() here? On a quick glance, it seems that everyone who gets a name back is just doing an mch_open(tempname, w) on it, which doesn't care whether or not the file exists already. I ask because this seems to be causing a race condition: GetTempFileName() checks if a file exists, finds a name that doesn't exist, creates it, and returns the name back to the caller. It creates it so that future calls to GetTempFileName() won't choose the same file, since it now exists. But, deleting it before being done with it introduces a race condition: vim calls GetTempFileName(), then DeleteFile(), then another process calls GetTempFileName(), and now vim has the path to a file that didn't exist when it asked for a unique, non-existant file, but exists now, and is no longer safe for vim to use. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
