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:
https
>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 s
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=
_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
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 DYNAMIC_PYTH
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
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
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
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.
-
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 mi
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 f
Chiel ten Brinke wrote:
[rearranged, please don't use top-posting!]
> On Sat, May 11, 2013 at 1:47 PM, Bram Moolenaar wrote:
>
> >
> > Chiel Tenbrinke wrote:
> >
> > > The current C# compiler plugin, tries to compile the current file with
> > > `csc`, the microsoft C# compiler.
> > > This has
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
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 highlig
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 "
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
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 (usin
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 i
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 t
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 wrote:
> I maintain the freebasic.vim and ibasic.vim files. They are already a part
> of the vim release. No cha
> 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
> 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 performan
> 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. It will be
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 t
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 wrote:
>
> Chiel Tenbrinke wrote:
>
> > The current C# compiler plugin, tries to compile t
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
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 exe
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
--- src/if_r
Yukihiro Nakadaira wrote:
> On Sat, May 11, 2013 at 10:58 PM, Hiroshi Shirosaki
> wrote:
>
> > 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.
It
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 __attribu
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 src/testdi
On Sat, May 11, 2013 at 10:58 PM, Hiroshi Shirosaki
wrote:
> 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 src/if_ruby.c
--- a/src/if
Hi vimmers!
On Sat, May 11, 2013 at 11:45 AM, Tony Mechelynck
wrote:
> On 10/05/13 10:54, Jan Pobrislo wrote:
>>
>> On Thu, 09 May 2013 05:51:48 +0200, Bram Moolenaar
>> wrote:
>>>
>>> The top five of the voting list:
>>> http://www.vim.org/sponsor/vote_results.php
>>>
>>> 1. add IDE features
>>
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 '=&rtp' in insert mode.
Hirohito Higashi(a.k.a. h_east) checked Vi
Yukihiro Nakadaira wrote:
> On Sat, May 11, 2013 at 8:47 PM, Bram Moolenaar 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
> > > initializatio
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) ruby_in
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_CR
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 prior
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
--- src/
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 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
> >> >
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. Ther
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 wrote:
>
>>
>> Hiroshi Shirosaki wrote:
>>
>> > This is originally reported here.
>> > https://bugs.ruby-lang.org/issues/8364
>> >
>> > Ruby crashes due to G
On Sat, May 11, 2013 at 8:47 PM, Bram Moolenaar 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.
> > Stack
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 13:37:23.00
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
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
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
49 matches
Mail list logo
