Hiroshi Shirosaki wrote:
This is originally reported here.
https://bugs.ruby-lang.org/issues/8364
Ruby crashes due to GC failure on mac osx. It seems ruby
initialization in if_ruby.c is not a portable way.
Stack start address should be prior to ruby stack region of every ruby
eval for GC
Patch 7.3.932
Problem:Compiler warning for uninitialized variable. (Tony Mechelynck)
Solution: Initialize the variable.
Files: src/option.c
*** ../vim-7.3.931/src/option.c 2013-05-06 06:45:42.0 +0200
--- src/option.c2013-05-08 01:32:25.0 +0200
***
Chiel Tenbrinke wrote:
The current C# compiler plugin, tries to compile the current file with
`csc`, the microsoft C# compiler.
This has two disadvantages.
* It is not possible to compile the file with mono.
* You can only compile single files, which is something you usually
don't do in
Christian Brabandt wrote:
Bram,
the help states:
,
| When :colder has been used and :make or :grep is used to add a new
error
| list, one newer list is overwritten. This is especially useful if you are
| browsing with :grep |grep|. If you want to keep the more recent error
|
Patch 7.3.933
Problem:Ruby on Mac crashes due to GC failure.
Solution: Init the stack from main(). (Hiroshi Shirosaki)
Files: src/main.c, src/if_ruby.c, src/proto/if_ruby.pro
*** ../vim-7.3.932/src/main.c 2013-03-19 13:33:18.0 +0100
--- src/main.c 2013-05-11
On Sat, May 11, 2013 at 8:47 PM, Bram Moolenaar b...@moolenaar.net wrote:
Hiroshi Shirosaki wrote:
This is originally reported here.
https://bugs.ruby-lang.org/issues/8364
Ruby crashes due to GC failure on mac osx. It seems ruby
initialization in if_ruby.c is not a portable way.
On Sat, May 11, 2013 at 9:49 PM, Yukihiro Nakadaira
yukihiro.nakada...@gmail.com wrote:
On Sat, May 11, 2013 at 8:47 PM, Bram Moolenaar b...@moolenaar.netwrote:
Hiroshi Shirosaki wrote:
This is originally reported here.
https://bugs.ruby-lang.org/issues/8364
Ruby crashes due to GC
On Fri, May 10, 2013 at 10:54 AM, Jan Pobrislo wrote:
I'm quite curious what is meant by IDE-like features. From my experience
most of that is covered by plugins already, except for one significant
roadblock: inability to communicate with external processes without blocking
whole UI. There
Patch 7.3.934
Problem:E381 and E380 make the user think nothing happened.
Solution: Display the message indicating what error list is now active.
(Christian Brabandt)
Files: src/quickfix.c
*** ../vim-7.3.933/src/quickfix.c 2013-05-06 04:21:35.0 +0200
---
Dominique Pelle wrote:
Attached patch fixes 2 typos in help files.
Thanks!
--
A real patriot is the fellow who gets a parking ticket and rejoices
that the system works.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features --
Dominique Pelle wrote:
mattn mattn...@gmail.com wrote:
On Thursday, May 9, 2013 1:26:40 PM UTC+9, Bram Moolenaar wrote:
Taro Muraoka wrote:
2. Include the fast regexp engine patch that has been floating around
for a long time. With some clever logic to fall back to the old
Hayaki Saito wrote:
Hi, lists
These days ago, Yukihiro Nakadaira found garbage output problem in
gnome-terminal. Here are some reproducing examples:
$ cd /path/to/vim/src/testdir
$ ../vim -u unix.vim -U NONE --noplugin -s dotest.in test85.in
$ 1;3400;0c - response for T_CRV
$ vim
ZyX wrote:
Well, that's a very long list. Do we really need all of this?
Let's at least order by usefulness. First add things that help
plugin writers most. I'm assuming that very few users will type
Python commands, I expect them to be used in scripts.
We could lower priority for
On Saturday, May 11, 2013 10:11:27 PM UTC+9, Yukihiro Nakadaira wrote:
ruby_init_stack() is also required for static linked version.
And ruby_init_stack() is defined as
ruby-2.0-0-p0:
#ifdef __ia64
void ruby_init_stack(volatile VALUE*, void*);
#define ruby_init_stack(addr)
Yukihiro Nakadaira wrote:
On Sat, May 11, 2013 at 8:47 PM, Bram Moolenaar b...@moolenaar.net wrote:
Hiroshi Shirosaki wrote:
This is originally reported here.
https://bugs.ruby-lang.org/issues/8364
Ruby crashes due to GC failure on mac osx. It seems ruby
initialization in
Hi list.
If 'runtimepath' string exceeds 1024 bytes,
'set rtp' output is truncated to 1023 bytes.
Although 'runtimepath' value seems to have complete string value
which exceeds 1024 bytes.
I could see the complete string value by 'C-r=rtpCR' in insert mode.
Hirohito Higashi(a.k.a. h_east)
Hi vimmers!
On Sat, May 11, 2013 at 11:45 AM, Tony Mechelynck
antoine.mechely...@gmail.com wrote:
On 10/05/13 10:54, Jan Pobrislo wrote:
On Thu, 09 May 2013 05:51:48 +0200, Bram Moolenaar b...@moolenaar.net
wrote:
The top five of the voting list:
http://www.vim.org/sponsor/vote_results.php
On Sat, May 11, 2013 at 10:58 PM, Hiroshi Shirosaki
h.shiros...@gmail.comwrote:
Thank you. I don't have __ia64 environment, but I think this would work.
Could you review the following?
Thank you.
Here is small fix for dynamic load.
I don't have ia64 machine, too.
diff -r d73a4a163202
Hi list.
I wrote a patch to add mapadd(), mapdelete() functions,
which adds a new mapping, or deletes existing mapping.
https://gist.github.com/tyru/5460911
current revision:
https://gist.github.com/tyru/5460911/6ecfa0509c0679469d6843026ed08280ef1260c1
test script(it can't be placed in
Hi list.
I have read a blog post about gcc extension.
http://mkosaki.blog46.fc2.com/blog-entry-1228.html (Japanese)
The blog title says _FORTIFY_SOURCE without
__attribute__((alloc_size)) doesn't make sense .
I've seen some _FORTIFY_SOURCE outputs while compiling Vim.
Should we add
Yukihiro Nakadaira wrote:
On Sat, May 11, 2013 at 10:58 PM, Hiroshi Shirosaki
h.shiros...@gmail.comwrote:
Thank you. I don't have __ia64 environment, but I think this would work.
Could you review the following?
Thank you.
Here is small fix for dynamic load.
I don't have ia64
Patch 7.3.935 (after 7.3.933)
Problem:Init stack works differently on 64 bit systems.
Solution: Handle 64 bit systems and also static library. (Yukihiro
Nakadaira)
Files: src/if_ruby.c
*** ../vim-7.3.934/src/if_ruby.c2013-05-11 13:56:12.0 +0200
---
The plan is to include a new regexp engine in Vim 7.4. For testing
I would like to get a lot of files for which we have syntax
highlighting. I can then compare the highlighting of these files with
the old and the new engine to find anything that is not compatible.
Please send me a file that
I maintain the freebasic.vim and ibasic.vim files. They are already a
part of the vim release. No changes have been made to them. Do I need
to resend them to you?
TIA!
Mark Manning
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text
That is an option I think, yes. But in that case, I think that the current
cs.vim should be improved to be able to use mcs (mono equivalent of csc) as
well.
On Sat, May 11, 2013 at 1:47 PM, Bram Moolenaar b...@moolenaar.net wrote:
Chiel Tenbrinke wrote:
The current C# compiler plugin,
On Sat, May 11, 2013 at 03:50:50PM +0200, Bram Moolenaar wrote:
[...]
If most things are already possible, then it should be possible to write
Python functions that work as a nice interface for the functionality.
Thus not change the C implementation of the Python interface.
Where it is feasible
Where it is feasible to implement it directly in python that sounds like
a good idea to me since it would probably ease the future maintenance
and allow more people to contribute to it.
Though for some of the suggested additions I imagine that it will
negatively impact the performance
Negative impact to the performance will be there, but nothing as critical as
fallback implementation for vim.bindeval would show.
* Negative impact will not be that great only in absolute measures and because
I don’t need to pass about a hundred KiBs with these new interfaces like I
needed
Hi Bram.
A random thought floated in my mind,
that checking :TOHtml output between new/old regexp engines can
automate output checking?
On Sun, May 12, 2013 at 1:16 AM, Mark Manning mar...@sim1.us wrote:
I maintain the freebasic.vim and ibasic.vim files. They are already a part
of the vim
Created a gist with suggestions:
https://gist.github.com/ZyX-I/5561409#file-rfc-rst.
--
--
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
---
You received
Note: currently my syntax file cannot handle all what is there correctly,
neither can indentation script. I will eventually send patches for both of them.
--
--
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
Bram,
here is a patch, that returns the complete quickfix/location list stack.
This is needed, so plugin writers can correctly handle quickfix and
location lists.
Currently, there is no way, to set the quickfix lists back to their
original values (without running through the complete stack
On Mi, 08 Mai 2013, Christian Brabandt wrote:
Updated patch attached. Includes documentation and fixes the issue
mentioned so far plus allows setting the w:quickfix_title using
setwinvar().
Another update, that fixes failure of test10.
regards,
Christian
--
Die Managerkrankheit ist eine
Hi list,
2013/05/12 Sun 0:36:43 UTC+9 tyru wrote:
Hi list.
I have read a blog post about gcc extension.
http://mkosaki.blog46.fc2.com/blog-entry-1228.html (Japanese)
The blog title says _FORTIFY_SOURCE without
__attribute__((alloc_size)) doesn't make sense .
I've seen some
Mark Manning wrote:
I maintain the freebasic.vim and ibasic.vim files. They are already a
part of the vim release. No changes have been made to them. Do I need
to resend them to you?
I don't want the syntax file plugin, as you mention I already have it.
I want a file that gets
Tyru wrote:
A random thought floated in my mind,
that checking :TOHtml output between new/old regexp engines can
automate output checking?
That is one of the ways. It might be a bit difficult to find out where
a difference comes from though. Directly using the method that TOHtml
uses to
Chiel ten Brinke wrote:
[rearranged, please don't use top-posting!]
On Sat, May 11, 2013 at 1:47 PM, Bram Moolenaar b...@moolenaar.net wrote:
Chiel Tenbrinke wrote:
The current C# compiler plugin, tries to compile the current file with
`csc`, the microsoft C# compiler.
This
ZyX wrote:
We also need to keep in mind that all the Vim functionality is nicely
documented and there are examples, while if we add a different way to do
this in Python this requires documenting how that works. Thus a script
writer will have two sets of functionality to learn to use.
On Sunday, May 12, 2013 12:46:06 AM UTC+9, Bram Moolenaar wrote:
Patch 7.3.935 (after 7.3.933)
Problem:Init stack works differently on 64 bit systems.
Solution: Handle 64 bit systems and also static library. (Yukihiro
Thank you for quick work!
It seems this part of patch is
ZyX wrote:
Note: currently my syntax file cannot handle all what is there
correctly, neither can indentation script. I will eventually send
patches for both of them.
The file is a bit short, but so long as it exercises most of the
patterns in the syntax file it's still good for testing.
--
Hiroshi Shirosaki wrote:
On Sunday, May 12, 2013 12:46:06 AM UTC+9, Bram Moolenaar wrote:
Patch 7.3.935 (after 7.3.933)
Problem:Init stack works differently on 64 bit systems.
Solution: Handle 64 bit systems and also static library. (Yukihiro
Thank you for quick work!
Christian Brabandt wrote:
On Mi, 08 Mai 2013, Christian Brabandt wrote:
Updated patch attached. Includes documentation and fixes the issue=20
mentioned so far plus allows setting the w:quickfix_title using=20
setwinvar().
Another update, that fixes failure of test10.
Thanks.
--
Christian Brabandt wrote:
Bram,
here is a patch, that returns the complete quickfix/location list stack.
This is needed, so plugin writers can correctly handle quickfix and
location lists.
Currently, there is no way, to set the quickfix lists back to their
original values (without
I am trying to build windows binary using cygwin. The command line and the
error I get is bellow.
make -f Make_cyg.mak SHELL=bash CC=i686-pc-cygwin-gcc CXX=i686-pc-cygwin-g++
RC=windres ARCH=i686 CROSS_COMPILE=x86_64-w64-mingw32- USEDLL=no
PYTHON=/cygdrive/c/Python27 PYTHON_VER=27
_MAX_PATH is actually defined (rather exclusively) in Make_cyg.mak
(line 438) and reused subsequently. As a quick workaround, you could
just specify its actual value. But I'd bet something in the compiler
call is wrong for you.
--
--
You received this message from the vim_dev maillist.
Do not
Hi,
2013/05/12 Sun 8:28:51 UTC+9 skeept wrote:
I am trying to build windows binary using cygwin. The command line and the
error I get is bellow.
make -f Make_cyg.mak SHELL=bash CC=i686-pc-cygwin-gcc CXX=i686-pc-cygwin-g++
RC=windres ARCH=i686 CROSS_COMPILE=x86_64-w64-mingw32- USEDLL=no
That is impossible. You may skip some of the list, dict and other Vim
language features, but when it comes to options, regexp, autocommands
and many, many other things you need to know how Vim works. Making a
Python interface for them won't change how Vim works.
For example, you can make some
Hello,
I added a Ctrl key to iOS version, and tried to modify the code for iOS to add
the touch for shift-tab, (I use shift-Ctrl-I touches combination). For sending
the touches to vim it is used the add_to_input_buf function, in insertText
function, the code source example is in file link:
48 matches
Mail list logo
