Place the following in the autoload path:
function dictautotest#doit() dict
endfunction
And the following in a separate test script:
let mydict = { 'doit': function('dictautotest#doit') }
let Mypartial = mydict.doit
call Mypartial()
This script will fail first time it is run. The reason is at
vim --cmd "$(printf 'func! XX()\nechomsg "aa"\nendfunc')"
works fine but
vim --cmd "$(printf 'func! XX()\nechomsg "aa"\nendfunc\ncall XX()')"
does not. One would expect at least an error about 'trailing characters' as
vim does in some similar situations, expect for 'endfunc "comment' (and perha
On Saturday, April 8, 2017 at 7:12:29 PM UTC+2, Bram Moolenaar wrote:
> Björn Linse wrote:
>
> > start vim 8.0.550 with "LANG=tr_TR.UTF-8" (tested on Linux). Type "iI"
> > on a line and do gu/gU
> >
> > Expected behavior:
> > with casemap
start vim 8.0.550 with "LANG=tr_TR.UTF-8" (tested on Linux). Type "iI" on a
line and do gu/gU
Expected behavior:
with casemap=keepascii,internal (default) it should behave like C or English
locale
with casemap= it should use the Turkish dotted uppercase and dotless lowercase
variants
Actual be
On Monday, September 12, 2016 at 10:57:39 AM UTC+2, Christian Brabandt wrote:
> Hi Björn!
>
> On So, 11 Sep 2016, Björn Linse wrote:
>
> > On Sunday, September 11, 2016 at 6:14:14 PM UTC+2, Björn Linse wrote:
> > > 615351832d75df3dfbc3f22694e675583e0b325d
> >
On Sunday, September 11, 2016 at 6:14:14 PM UTC+2, Björn Linse wrote:
> 615351832d75df3dfbc3f22694e675583e0b325d
>
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
BTW, something is wrong with the github <-> vim-
vim version: 7.4.2066
vim -u NORC, set nocompatible
Setup:
i1
o2u
o3
o4u
:%s/1/5/u
Now the buffer contents is 1,3. Now when pressing g- nothing happens. Even
pressing g- multiple times 1,3 is still shown, instead of going back through
time to 1,2, just 1 and then the empty buffer, as expected.
> Really.
These are good points. I was going to suggest job_stop("3") is ok but not
job_stop("SomeString") but then again 3+"somestring"==3 so it is probably a
lost cause.
> Worst of the valid choices if you want.
You may be right. I just found it unhelpful to say something (that already is
> No. It is the usualy automatic string-to-number conversion,
> timer_stop("2") is not expected to be an error.
really? the argument here is not "some random number the user wants" but the
retval of timer_start which is always a number. The user could specify the
callback name here as a mistake
timer_stop("some string") etc should probably be an error.
--- a/src/eval.c
+++ b/src/eval.c
@@ -20733,6 +20733,11 @@ f_timer_start(typval_T *argvars, typval_T *rettv)
static void
f_timer_stop(typval_T *argvars, typval_T *rettv UNUSED)
{
+if (argvars[0].v_type != VAR_NUMBER)
+{
+
When entering visual mode from insert mode v vim is in "(insert) VISUAL"
mode and will reenter insert mode after a finished operator. However there
seems to be another "INSERT VISUAL" mode that can be entered like so:
let g:modal = ""
function! Modal()
if g:modal != ""
execute "norm
> OK, yes, in that case it is different from a real empty list.
> Do we really case about that?
Anyway, the fix is simple:
--- a/eval.c
+++ b/eval.c
@@ -10096,9 +10096,10 @@ static void f_getreg(typval_T *argvars, typval_T
*rettv)
rettv->v_type = VAR_LIST;
rettv->vval.v_list =
> The NULL is supposed to be the same as an empty, mutable list. This is
> tricky, because code that expects a list needs to check for the NULL and
> create the list if needed.
how could this be possible?
let x = getreg("a",1,1) " returns NULL
let y = x
call add(x, "text")
now x is created, bu
> Internally a list with a NULL pointer is supposed to be handled like an
> empty list. This is efficient, but tricky. Nikolai just sent a patch,
> hopefully that helps.
Good, but I wonder if it is not better for getreg("a",1,1) to always return a
mutable list (an empty mutable list in this cas
To reproduce:
vim -u NONE -i NONE
:let x = getreg("a",1,1)
:call setreg("0",x)
gives SIGSEGV on master vim (huge build). "-i NONE" is needed to make sure
registers are undefined.
it seems like getreg returns a NULL list (I don't know if that is supposed to
be a thing) for an undefined registe
For the record, a version of this was merged into neovim:
https://github.com/neovim/neovim/pull/4304
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
On Sunday, February 7, 2016 at 9:19:50 PM UTC+1, Bram Moolenaar wrote:
> Björn Linse wrote:
>
> I didn't spend much time on it, but I failed to see what messages are
> exchanged between NeoVim and a plugin. It mentions using an API and
> generating docs for that... Since the
On Sunday, February 7, 2016 at 4:18:38 PM UTC+1, Bram Moolenaar wrote:
> Now that the basic channel and job support is there, I would like to
> invite plugin writers to give feedback. We probably need some more
> features and/or change how things work.
>
> NeoVim is free to follow. It appears Ne
On Sunday, August 23, 2015 at 10:08:41 PM UTC+2, Björn Linse wrote:
> On Saturday, August 22, 2015 at 4:04:57 PM UTC+2, Bram Moolenaar wrote:
> > ...
>
> Similar issue with laststatus. `:set ls=2` and then `set all&` now `set ls`
> gives 1 but vim still behaves as if `&
On Saturday, August 22, 2015 at 4:04:57 PM UTC+2, Bram Moolenaar wrote:
> Björn Linse wrote:
>
> > ":set all&" might change &encoding without reexecuting "mb_init()", if
> > encoding was changed earlier from the locale default, leaving multibyte
&
":set all&" might change &encoding without reexecuting "mb_init()", if encoding
was changed earlier from the locale default, leaving multibyte handling in
inconsistent state.
To reproduce (assuming utf-8 locale):
vim -u NONE --cmd "set enc=latin1"
Inside vim, type ":set all&", now ":set enc" sh
v+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
# HG changeset patch
# User Björn Linse
# Date 1426940661 -3600
# Sat Mar 21 13:24:21 2015 +0100
# Node ID 4fcab61b53d61a69a78d08cc64c24aefce2e7cb7
# Parent c8ea399de9be53d8b26745744b92d93dad90eeb8
beg
ing the
present behaviour)
systemlist("cat", "aa\nbb",1) ==> ['aa', 'bb']
systemlist("cat", "aa\nbb\n",1) ==> ['aa', 'bb','']
This would have the nice property that systemlist("cat", somelist)
am I missing something?
Is the problem localized to Mac OS X or is anybody else experiencing the
same problem?
Björn
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.
On 17 December 2011 21:49, Bram Moolenaar wrote:
>
> Björn Winckler wrote:
>
>> I received a report on Vim crashing on the MacVim issue tracker [1]
>> and since I could reproduce the problem I decided to try to track it
>> down.
>>
>> The problem i
to do
about this: revert 7.3.306 or try to fix all places in the code that
it breaks?
For reference I've pasted the backtrace from the crash below.
Björn
[1] http://code.google.com/p/macvim/issues/detail?id=395
#0 ml_get_buf (buf=0x0, lnum=1, will_change=0) at memline.c:2429
#1 0x00010009d
ned).
I had a quick look at what's going on but I have yet to find the code
that waits for a mapping to timeout. Any pointers to where this
happens would be appreciated (e.g. how does a mouse move event cancel
the timeout?).
Thanks,
Björn
--
You received this message from the "vim_dev
earch did not reveal anything useful.
Thanks,
Björn
--
Here's a sample gdb backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0001
0x000100324c58 in PyEval_EvalFrameEx ()
(gdb) bt
plaints about this. I propose applying the
patch in [4] to get rid of beval altogether.
Thanks,
Björn
[1] http://code.google.com/p/macvim/issues/detail?id=342
[2] https://groups.google.com/forum/#!topic/vim_dev/2lEb8Dt6ttc
[3] http://icy.io/misc/latest-macvim-ruby-annoying-ri-balloon-issue/
[4]
h
o try and
allocate 0 bytes in the first place so all platforms are covered by the patch.
Björn
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
00
ver heard of this problem occurring on the very specific
combination of OS X 10.7/zsh/gvim. Hence this patch is only for Mac OS X at
the moment, but perhaps it should be expanded to include other OSs? I'm no
expert on this issues which is why I'm phrasing that as a question.
Björn
--
On 2011.06.19 04:54:36 +0200, Bram Moolenaar wrote:
> Björn Steinbrink wrote:
> > The patch below[2] is a quick hack that eliminates the problem, but
> > spreads knowledge about the MAXLNUM "shortcut" for the fromstart syncing
> > through the code, so IMHO that'
ugh the code, so IMHO that's not an acceptable solution, but I
currently lack time and knowledge to come up with anything more useful.
Regards,
Björn
[1] AFAIK, signed integer overflow is undefined in standard C. So while
you could just adjust MAXLNUM to be 2^63-1 for 64bit longs, that's
that it works), but I
do not know if it breaks other platforms. Can somebody please test
this?
Björn
diff --git a/src/configure.in b/src/configure.in
index 7b5e08f..ddcebd1 100644
--- a/src/configure.in
+++ b/src/configure.in
@@ -1387,10 +1387,10 @@ AC_ARG_ENABLE(rubyinterp,
AC_MSG_RESULT($en
ubypath
Line 628 is similar:
exe "syn include @vimPythonScript ".s:pythonpath
Can runtime/vim.vim be fixed or is there some rule against having the
runtime folder in a path with spaces?
Björn
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your
On 17 August 2010 20:42, Jjgod Jiang wrote:
> On Tue, Aug 17, 2010 at 8:38 PM, björn wrote:
>> Hi,
>>
>> This is most likely a complete newbie problem, but ever since the
>> branch renaming business I get warnings when I pull from the Mercurial
>> repo. I did a
assume hg would just pull the changesets and "fast
forward" (and here you see my problem, I have a basic of understanding
of Git but am completely bewildered by Mercurial).
I used to be able to "hg fetch" ("fetch" is an extension, btw) with no problems.
Thanks,
B
update default' now (without forgetting to do
> first a 'hg pull'), once the vim73 release is done
>
> What are the drawbacks of the above scheme ?
It would have made life easier for me with maintaining the Git
repository. Renaming the "vim73" branch "
h (you shouldn't have!)
then I'd suggest you create a new branch ("git checkout -b mystuff
master"), do the above, then cherry-pick the commits back.
You only need to do this once. The next time you update you can use
"git pull" as usual.
Björn
[1] http://github.com
On 17 August 2010 12:27, Bram Moolenaar wrote:
>
> Björn Winckler wrote:
>
>> Looking at the Mercurial repo I see 7.3.002 applied twice, but I can't
>> see 7.3.001 anywhere. At first I suspected only the commit messages
>> were wrong but it looks like 7.3.0
Hi,
Looking at the Mercurial repo I see 7.3.002 applied twice, but I can't
see 7.3.001 anywhere. At first I suspected only the commit messages
were wrong but it looks like 7.3.002 really has been applied twice.
Björn
--
You received this message from the "vim_dev" maillist.
On 5 August 2010 20:43, björn wrote:
> On 5 August 2010 19:24, Michael Trim wrote:
>>
>> The Ctrl key functionality is part of the existing code, and is not
>> relied on or provided by this patch. The Ctrl modifier just allows
>> the user to force the opposite behaviour
ould make use of it. On platforms where modifiers
are supported they can modify the drop behavior similarly to how they
do now...)
Björn
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
ier keys when dropping files,
so I will withdraw from this thread...
Björn
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
nce in the MacVim
app and not as a Vim option).
I haven't looked at the patch but if implemented as one option (as
Lech suggested) then I'd support the inclusion of such a patch.
(Which would mean I could get rid of my hack in MacVim to support this
behavior.)
Björn
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
e the full path
when setting DYNAMIC_PERL_DLL instead of just "libperl.dylib", but I
don't know how to get the path. Is there some "Perl-way" of doing
this? (I tried using $vi_cv_perllib but it points to the wrong
directory.)
Björn
--
You received this message from
e attached patch to configure.in strips these flags in the same way
as we already do for Ruby. I also updated the Ruby portion to strip
"-arch x86_64" in addition to "ppc" and "i386". This patch only
affects the configure script on Mac OS X.
Björn
--
You received this
On 21 July 2010 21:36, Bram Moolenaar wrote:
>
> Björn wrote:
>>
>> Bram: could you indicate if there is any chance this is making it for
>> 7.3 (or at all)? It seems this feature would mostly be used by Mac
>> users (since "all" Macs have horizontal scro
On 19 July 2010 15:45, Benjamin R. Haskell wrote:
> On Sun, 18 Jul 2010, björn wrote:
>>
>> Ok, here is the updated patch. I've renamed the keys as follows:
>>
>>
>>
>>
>>
>>
>> These all scroll the _window_ in the direction indic
On 20 July 2010 13:10, Nazri Ramliy wrote:
> On Tue, Jul 20, 2010 at 8:06 AM, Nazri Ramliy wrote:
>> On Tue, Jul 20, 2010 at 12:47 AM, björn wrote:
>>> Oh, I didn't realize that. Well, I can confirm that ":fin" behaves
>>> identical to ":tabf&
On 19 July 2010 18:28, Bram Moolenaar wrote:
> Björn Winckler wrote:
>> On 19 July 2010 16:59, björn wrote:
>> >
>> > There's only one file. To double check I renamed the file
>> > "appkitborkborkbork.h" (I know for sure there is no othe
On 19 July 2010 16:59, björn wrote:
>
> There's only one file. To double check I renamed the file
> "appkitborkborkbork.h" (I know for sure there is no other file called
> that on my filesystem) and I get
>
> :tabf ap
> apache2/ a
On 19 July 2010 03:14, Nazri Ramliy wrote:
> On Mon, Jul 19, 2010 at 6:11 AM, Bram Moolenaar wrote:
>> Björn Winckler wrote:
>>
>>> I built a new (MacVim) binary using the latest source and noticed that
>>> command autocompletion is behaving strangely.
>
&g
applicatives.hs)
I cannot begin to guess what is going on here. I have tried getting
rid of my .vim folder and .vimrc/.gvimrc files with no change. Same
behavior in console mode as in GUI mode.
Any ideas what's going here?
Björn
--
You received this message from the "vim_dev&q
On 16 July 2010 21:03, björn wrote:
> On 16 July 2010 14:52, Benjamin R. Haskell wrote:
>> On Fri, 16 Jul 2010, björn wrote:
>>
>> As long as you're adding MouseScroll{Left,Right,Up,Down}, would this be
>> a good time to reverse the naming? (The oddity that indi
On 16 July 2010 14:52, Benjamin R. Haskell wrote:
> On Fri, 16 Jul 2010, björn wrote:
>
> As long as you're adding MouseScroll{Left,Right,Up,Down}, would this be
> a good time to reverse the naming? (The oddity that indicates
> pushing the scrollwheel toward the bottom of t
On 16 July 2010 06:27, Christian J. Robinson wrote:
> On Wed, Jun 30, 2010 at 12:21 PM, björn wrote:
>>
>> I agree that is also confusing but unfortunately that
>> can't be changed since it will break backward compatibility (it is
>> possible to bind to ). Using
On 14 July 2010 17:08, Bram Moolenaar wrote:
>
> Björn Winckler wrote:
>
>> On 14 July 2010 14:27, Bram Moolenaar wrote:
>> >
>> > Looking at os_macosx.m, it appears these functions are not used:
>> > mch_gettext()
>> > mch_bindtext
no idea what this has been used for (if anything). I'd say it
is safe to delete (I started working on localizing MacVim a while ago
and for that patch I would not have any use for these functions).
Björn
--
You received this message from the "vim_dev" maillist.
Do not top-post! Ty
On 14 July 2010 14:52, Bram Moolenaar wrote:
>
> I wrote:
>
>> Björn Winckler wrote:
>>
>> > On 12 July 2010 21:04, björn wrote:
>> > >
>> > > I looked into this issue carefully now and decided it is best to
>> > > con
gt;> > When going with Objective-C, would there be disadvantages? Some people
>> > who can't build the binary? Does the executable become bigger? More
>> > dependencies on libraries?
>>
>> What would be the advantage over using:
>>
>> vmap ,y
to merge this
patch (here is one of the problems though: since the patch renames a
whole file it is a bit tricky to review -- I believe it is fine but
have not checked it myself). If you would prefer not to use
Objective-C then it is possible to rewrite it using only C.
What would you prefer Bram?
Bjö
ill differ. The offending line looks like this:
if test -z "$SKIP_ATHENA" -o -z "$SKIP_NEXTAW" -o -z "$SKIP_MOTIF" -o
-z "$SKIP_GTK"; then
Björn
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below th
On 30 June 2010 19:53, Jordan Lewis wrote:
> On Wed, Jun 30, 2010 at 12:43 PM, björn wrote:
>>
>> ...
>>
>> One comment regarding the code: since vertical movement uses
>> and I named the horizontal keys and
>> but I realize that this can be kind
ing (e.g. trackpads on MacBooks or the Apple Magic Mouse) so
this patch is at least useful for MacVim users. (I'd be happy if this
makes it into 7.3 -- in any case I will add it to MacVim 7.3 when I
release that)
Björn
--
You received this message from the "vim_dev" maillist.
Do not
On 9 June 2010 17:10, James Vega wrote:
> On Wed, Jun 9, 2010 at 4:41 AM, björn wrote:
>> On 8 June 2010 23:05, James Vega wrote:
>>> On Sun, Jun 6, 2010 at 1:42 PM, björn wrote:
>>>
>>>> My config.log looks like this:
>>>>
>>>> confi
2010/6/9 Dominique Pellé:
> björn wrote:
>
>> $ gcc --version
>> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)
>>
>> All I can say is that if you want to print an off_t value on OS X 10.6
>> then "%lld" must be used or that w
On 9 June 2010 18:42, James Vega wrote:
>
> Are you using the latest code from Mercurial? Bram committed a fix for
> a similar crash on Monday:
My source was a day too old. That patch did indeed fix this problem.
Thanks,
Björn
--
You received this message from the "vim_dev&quo
ader curwin->w_s often points to
curbuf->b_s, but the latter is non-NULL (if that is of any help).
Let me know if I can provide any more info.
Björn
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
F
On 8 June 2010 23:05, James Vega wrote:
> On Sun, Jun 6, 2010 at 1:42 PM, björn wrote:
>
>> My config.log looks like this:
>>
>> configure:11865: checking for off_t
>> configure:11895: gcc -c -O2 -fno-strength-reduce -Wall -DMACOS_X_UNIX
>> -no-cpp-preco
On 8 June 2010 23:32, Tony Mechelynck wrote:
> On 06/06/10 19:42, björn wrote:
>
>> On 6 June 2010 18:23, Tony Mechelynck wrote:
>>>
>>> On 06/06/10 15:12, björn wrote:
>>>>
>>>> configure:11492: checking size of off_t
>>>&g
On 6 June 2010 18:23, Tony Mechelynck wrote:
> On 06/06/10 15:12, björn wrote:
>>
>> Hi,
>>
>> Lately I've been getting the following warning (on Mac OS X 10.6, 64 bit):
>>
>> fileio.c: In function ‘msg_add_lines’:
>> fileio.c:5230: warning: forma
but I don't know which exactly. Does anybody else have
any ideas?
Björn
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
On 30 May 2010 20:09, björn wrote:
> Hi,
>
> Over the last few weeks I've been going over what options I have
> regarding the new Vim Mercurial repository. I debated switching to
> Mercurial for MacVim and how I would move the current MacVim history,
> etc. Well, a
w to build MacVim using the Vim 7.3 BETA
code here [4].
When Bram releases Vim 7.3 I will (hopefully the same day) build a new
stable MacVim binary (based on snapshot 52).
Björn
[1] http://github.com/b4winckler/vim
[2] http://github.com/b4winckler/macvim
[3] http://wiki.github.com/b4winckle
On 29 May 2010 22:37, björn wrote:
>
> I'm in the process of merging the vim73 branch with MacVim and I keep
> getting the following line in my auto/config.mk:
>
> PYTHON_NOPROTO = @PYTHON_NOPROTO@
>
> When I try to compile the string "@PYTHON_NOPROTO@" is ad
ody tell me why
this flag gets set to this nonsense string?
Looking at configure.in this flag should be empty (at least if I don't
ask for the Python interpreter) but regardless whether I call
configure with or without --enable-pythoninterp this string pops up.
Thanks,
Björn
--
You received t
On 26 May 2010 23:08, Fredrik Gustafsson wrote:
>
> On Wed, May 26, 2010 at 10:41:22PM +0200, björn wrote:
>> I have noticed that the Git clone of Vim's Mercurial repository that I
>> set up is substantially larger than the original (original's .hg
>> folder ~ 45M
tly to let people know that I am aware of the
situation and also to ask if anybody else on this list has any
experience using hg-git, or who can explain this discrepancy in sizes?
(I've asked on the hg-git Google group as well and I'll report back
here if I get any response from them.)
Bjö
On 24 May 2010 11:52, Bram Moolenaar wrote:
>
> Björn Winckler wrote:
>
>> I have set up a Git clone of the Vim Mercurial repo here [1] (complete
>> with instructions on how this was done [2]).
>
> Nice. Do you also have a page for how to use this? I could link that
from other people's Git clones even
if they've set up their own.
I hope some other people will find this information useful.
Björn
P.S. If somebody on this list knows a better way to update the repo
than the method outlined in [2] please let me know (as it is I have to
manually dele
On 23 May 2010 12:38, Bram Moolenaar wrote:
>
> Björn Winckler wrote:
>
>> I was wondering what the plans for the Mercurial branches are once 7.3
>> is finished. Will "vim73" be merged into "default" at some point, or
>> will there be one giant
branch into a patch) and "vim73" will be
left, or ...?
I am wondering because I am in the process of changing the MacVim repo
to use the Vim Mercurial repo as upstream instead of the svn repo.
This is to allow me to make an informed decision as to which branch to
merge my own "macvim&qu
endif
retval = mch_get_shellsize();
This problem does not seem to affect the other functions in ui.c that
check "gui.in_use" since they are not call this early in the
initialization (as far as I can tell). This change may affect the
initializations of the other GUIs, hence this
2009/8/1 Jjgod Jiang:
>
> On Sat, Aug 1, 2009 at 10:45 PM, björn wrote:
>> A few comments on this patch:
>>
>> 1. Why have you not included the code that handles block-wise copy in
>> clip_mch_request_selection() from the MacVim sources? This is a bad
>> ide
n effort, but then again the current MacVim clipboard code works and
has been in use for quite some time so it is maybe a better idea to
just include it verbatim.
Björn
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
.c:1005
>
> Hopefully this is fixed by this pending patch:
>
>
> *** ../vim-7.2.239/src/fileio.c 2009-07-01 17:11:40.0 +0200
> --- src/fileio.c 2009-07-22 19:08:55.0 +0200
> ***
Repeating the steps I outlined above with this patch applied I can no
longer reproduce the crash. So as far as I can tell this patch fixes
the problem.
Thanks,
Björn
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
2009/7/24 Dominique Pellé:
>
> Hi Björn
>
> This looks similar to the issue reported recently by Yukihiro Nakadaira
> on 2009/07/17 in vim_dev and which started to appear in 7.2.203:
>
> http://groups.google.com/group/vim_dev/tree/browse_frm/month/2009-07/a197ee32e8745769?rn
:5252
#6 0x000e4d30 in normal_cmd (oap=0xb534, toplevel=1) at normal.c:1188
#7 0x0009fc4f in main_loop (cmdwin=0, noexmode=0) at main.c:1261
#8 0x0009f742 in main (argc=3, argv=0xbffff700) at main.c:1005
Björn
--~--~-~--~~~---~--~~
You received this message from
etween these.
Furthermore, there are various structs in term.c where K_KPLUS is
represented by strings like "\316N" etc. -- what should go in here?
The termcap jungle seems a bit dense to enter unguided, hence the
(hopefully) simple questions before I get hopelessly lost.
Thanks,
Björn
From what I can tell it may be hard to reproduce this bug (I never
managed myself) so it will be difficult to see if 7.2.192 fixes the
problem but the next snapshot I build will include this patch. I'll
report back if there are any further comments on this issue report
after I've released the new
l). It it is probably a bit far fetched to ask, but maybe somebody
with a bit more insight into the garbage collecting routines will have
an idea as to why this may be happening?
Björn
--~--~-~--~~~---~--~~
You received this message from the "vim_dev&q
s with it.
Without this patch you had to manually remove the -arch flags from
src/auto/config.mk before calling make (unless you were compiling a
universal binary). With this patch you can compile both a native and
universal binary (the -arch flags are added by the --with-mac-arch
switch).
Björn
that it didn't seem to matter too much).
Björn
diff --git a/src/os_mac.h b/src/os_mac.h
index 7a54ee5..aae08bf 100644
--- a/src/os_mac.h
+++ b/src/os_mac.h
@@ -268,9 +268,6 @@
*/
#ifdef MACOS_X_UNIX
-# define SIGPROTOARG (int)
-# define SIGDEFARG(s) (s) int s;
-# define SIGDUMMYAR
#x27;t think anybody is particularly interested in
patching Carbon Vim though so if you want this fixed I think you'll
have to edit the source (in main.c) yourself (or delete/empty the
macmap.vim file from the runtime folder).
Björn
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
onds.
> Files: src/os_unix.c
Thanks for this patch Bram -- I can confirm that it fixes the problem
on Mac OS X.
Björn
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
ing forward to a patch with dynamic loading of the most recent
Python version! I know that a lot of MacVim users will appreciate
this feature.
Björn
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
2009/2/17 Danek Duvall:
>
> On Tue, Feb 17, 2009 at 10:42:00PM +0100, björn wrote:
>
>> The following bit of configure.in looked a bit strange, so I changed
>> it. No idea what that special "if" for MACOSX does though.
>
> Well, there's that commen
2009/2/20 Tony Mechelynck:
>
> On 20/02/09 13:53, björn wrote:
>> Hi,
>>
>> For the last two weeks or so I've been getting this warning when
>> compiling Vim (on Mac OS X):
>>
>> ex_docmd.c: In function 'do_one_cmd':
>> ex_docmd.c:
.c:5937: warning: 'end' may be used uninitialized in this function
I searched the archives but found no mention of it, so perhaps this is
only happening on OS X?
Björn
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" m
1 - 100 din 149 matches
Mail list logo
