Plans for Vim 7.4

[Bram Moolenaar]

Hello Vim users,

We are now at patch level 7.3.931. In a few weeks we would reach 999. I
don't want to find out what happens if we go over that, so it's time for
Vim 7.4!

The top five of the voting list:
http://www.vim.org/sponsor/vote_results.php

1. add IDE features
2. add integration with Python instead of inventing more Vim script
3. fix all problems, big and small; make Vim more robust
4. improve syntax highlighting speed
5. add collaborative editing

I can't possibly do all of that in a few weeks, but this is what I can do:

1. Include the Python patches that ZyX has created. This improves the
Vim API from the Python interface.
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
regexp engine for patterns that might not work with the new one.
3. Include lots of pending patches for bug fixes.

Besides that, if you are maintaining runtime files, please send me any
pending updates. I will not make big changes just before the release,
everything needs some time for testing. Let's set a deadline at the end
of May.

I don't have a date set for the release. I'll include the mentioned
changes and then we need some time for testing until it looks stable.
And hopefully we don't go past 999 before that...

--
E M A C S
s e l o h
c t t n i
a a t f
p r t
e o
l

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Christian J. Robinson]

[Replied only to the Vim Developers' list.]

On Thu, 9 May 2013, Bram Moolenaar wrote:

> it's time for Vim 7.4!

[...]

> 1. Include the Python patches that ZyX has created. This improves
> the Vim API from the Python interface.

I know you cannot possibly be expected to add similar support for the
other scripting interfaces yourself, but I am hoping someone is
willing to add some of these extras to the Perl interface.

- Christian

--
Knowledge is knowing that a tomato is a fruit.
Wisdom is not putting it in a fruit salad.
Christian J. Robinson <hep...@gmail.com> http://christianrobinson.name/

[Taro MURAOKA]

> 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
> regexp engine for patterns that might not work with the new one.

I want to look into this patch from view point of multibyte characters.
Where can I get it?

[Bram Moolenaar]

Christian J. Robinson wrote:

> [Replied only to the Vim Developers' list.]
>
> On Thu, 9 May 2013, Bram Moolenaar wrote:
>
> > it's time for Vim 7.4!
>
> [...]
>
> > 1. Include the Python patches that ZyX has created. This improves
> > the Vim API from the Python interface.
>
> I know you cannot possibly be expected to add similar support for the
> other scripting interfaces yourself, but I am hoping someone is
> willing to add some of these extras to the Perl interface.

There clearly is much more support for using Python. I'm not going to
have a discussion about this, Python vs. Perl is very much a personal
preference. And Vim users have given more votes to Python, so let's
settle on that.

--
TALL KNIGHT OF NI: Ni!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Bram Moolenaar]

There is this site: https://code.google.com/p/vim-soc2008-regexp/

Was there a version after this?

--
Experience is what you get when you don't get what you want.

[Suresh Govindachar]

--- On Wed, 5/8/13, Christian J. Robinson <hep...@gmail.com> wrote:

> From: Christian J. Robinson <hep...@gmail.com>
> Subject: Re: Plans for Vim 7.4
> To: vim...@googlegroups.com
> Date: Wednesday, May 8, 2013, 9:01 PM
>
> [Replied only to the Vim Developers' list.]
>
> On Thu, 9 May 2013, Bram Moolenaar wrote:
>
> > it's time for Vim 7.4!
>
> [...]
>
> > 1. Include the Python patches that ZyX has
> created.  This improves the Vim API from the Python
> interface.
>
> I know you cannot possibly be expected to add similar
> support for the other scripting interfaces yourself, but I
> am hoping someone is willing to add some of these extras to
> the Perl interface.
>

What are these "extras" Christian is referring to?

[Christian J. Robinson]

On Wed, 8 May 2013, Suresh Govindachar wrote:

> What are these "extras" Christian is referring to?

Mostly it's just been a case of occasionally seeing a new Python→Vim
integration feature added and I have thought, "Oh, I wish the
Python→Perl interface had that too. Oh well."

Among them, I believe it's easier to access and modify Vim data
(options, variables, buffers, etc.) through objects in Python than it
is in Perl, where it mostly has to be done with special, more limited
function calls.

I wasn't expecting Bram's...overly blunt response to my almost wistful
request, especially since I was suggesting that in the admittedly
unlikely event that someone _else_ created a patch, I hoped Bram would
accept it.

- Christian

--
Handkerchief: Cold Storage.

[Ron Aaron]

On Thursday, May 9, 2013 6:51:48 AM UTC+3, Bram Moolenaar wrote:
> don't want to find out what happens if we go over that, so it's time for
> Vim 7.4!

That's very exciting!

> 2. add integration with Python instead of inventing more Vim script

I hope this doesn't mean Python will be *required*. That would be a badness.

[Ron Aaron]

On Thursday, May 9, 2013 6:51:48 AM UTC+3, Bram Moolenaar wrote:

> Hello Vim users,
> ... so it's time for Vim 7.4!

Wonderful news!

> 2. add integration with Python instead of inventing more Vim script

I hope this doesn't mean Python will be required, that would be a badness.

[陈世用]

What about support fuzzy matching?

2013/5/9 Bram Moolenaar <Br...@moolenaar.net>

--
--
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 this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[mattn]

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
> > > regexp engine for patterns that might not work with the new one.
> > I want to look into this patch from view point of multibyte characters.
> > Where can I get it?
>
> There is this site: https://code.google.com/p/vim-soc2008-regexp/
>
> Was there a version after this?

New regexp NFA engine isn't work with multi-byte characters.

https://code.google.com/p/vim-soc2008-regexp/wiki/nfa_bugs

[Christian Brabandt]

Hi Ron!

On Mi, 08 Mai 2013, Ron Aaron wrote:

> > 2. add integration with Python instead of inventing more Vim script
>
> I hope this doesn't mean Python will be *required*. That would be a badness.

Pretty sure not. I think the python interpreter will always be optional.

regards,
Christian
--
Wie viel Unsinn ist im Laufe der Zeit von Professoren gesagt worden!
Warum sollen Studenten nicht auch einmal dummes Zeug reden.
-- Alexander Mitscherlich

[Christian Brabandt]

Hi Bram!

On Do, 09 Mai 2013, Bram Moolenaar wrote:

>
> Hello Vim users,
>
> We are now at patch level 7.3.931. In a few weeks we would reach 999. I
> don't want to find out what happens if we go over that, so it's time for
> Vim 7.4!
>
> The top five of the voting list:
> http://www.vim.org/sponsor/vote_results.php
>
> 1. add IDE features
> 2. add integration with Python instead of inventing more Vim script
> 3. fix all problems, big and small; make Vim more robust
> 4. improve syntax highlighting speed
> 5. add collaborative editing
>
> I can't possibly do all of that in a few weeks, but this is what I can do:
>
> 1. Include the Python patches that ZyX has created. This improves the
> Vim API from the Python interface.
> 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
> regexp engine for patterns that might not work with the new one.
> 3. Include lots of pending patches for bug fixes.

I'd like to see the breakindent patch included.

regards,
Christian

[cptstubing]

Can you elaborate on the IDE features that you have planned?

[tux-]

Yay - time for a new branch! Thanks, Bram. :)

[ZyX]

> 1. Include the Python patches that ZyX has created. This improves the
> Vim API from the Python interface.

I just wanted to write an RFC with new interfaces. These are even bigger changes, so it would be bad idea to start writing them without discussion. But these are unlikely to be written before the end of May.

[Andy Wokula]

Am 09.05.2013 05:51, schrieb Bram Moolenaar:
> Hello Vim users,
>
> We are now at patch level 7.3.931. In a few weeks we would reach 999.
> I don't want to find out what happens if we go over that, so it's time
> for Vim 7.4!

Wish:

Vim 7.4 becomes a release with all current patches and no new features
(beyond the patches)

Vim 7.5 will be like Vim 7.4 and contains new "big" features.

--
Andy

[lith]

> I'd like to see the breakindent patch included.

Yes, please!!!!!

[Bram Moolenaar]

Not required for Vim itself, but there can be plugins that require it.

--
An extraordinary TALL KNIGHT in all black (possibly John with Mike on his
shoulders) walks out from the dark trees. He is extremely fierce and
gruesome countenance. He walks towards KING ARTHUR and PATSY, who are
wazzing like mad. (Salopian slang, meaning very scared. almost to the
point of wetting oneself, e.g. before an important football match or
prior to a postering. Salopian slang meaning a beating by the school
praeposters. Sorry about the Salopian slant to this stage direction - Ed.)

[Bram Moolenaar]

Andrei (the student who worked on this) does mention multi-byte. He
says it slows down the execution, thus the multi-byte support should be
there. We need to find the latest version of the code.

--
"Never be afraid to tell the world who you are."
-- Anonymous

[Bram Moolenaar]

Sorry, that is not a bug fix patch.

I'm sure everybody has their favorite patch that he would like to see
included. And eventually they might get included, but for 7.4 I have to
set priorities to get it done in a reasonable amount of time.

--
Back up my hard drive? I can't find the reverse switch!

[mattn]

On Friday, May 10, 2013 3:55:02 AM UTC+9, Bram Moolenaar wrote:
> > https://code.google.com/p/vim-soc2008-regexp/wiki/nfa_bugs
>
> Andrei (the student who worked on this) does mention multi-byte. He
> says it slows down the execution, thus the multi-byte support should be
> there. We need to find the latest version of the code.

vim72-re ?

BTW, I hope to include vim-cmdsrv-nox to vim74.

https://code.google.com/r/yukihironakadaira-vim-cmdsrv-nox/
https://groups.google.com/d/msg/vim_dev/JI4p9_fgQUw/nCRaqD2T1IUJ

[Andy Spencer]

On 2013-05-09 05:51, Bram Moolenaar wrote:
> Hello Vim users,
>
> We are now at patch level 7.3.931. In a few weeks we would reach 999. I
> don't want to find out what happens if we go over that, so it's time for
> Vim 7.4!

How about the gvim port to GTK 3? I'll see if I can get that working if
there's a chance it'll be merged.

[h_east]

Hi, Bram and list

2013/5/9(Thu) 12:51:48 UTC+9 Bram Moolenaar:

> Hello Vim users,
>
> We are now at patch level 7.3.931. In a few weeks we would reach 999. I
>
> don't want to find out what happens if we go over that, so it's time for
>
> Vim 7.4!

In recent years, the resolution of the display device is up. But the statusline of Vim will remains 1 line.
So, I wrote multi-lined statusline patch.
But it has not been completed. (80% complete)
Patch:
https://gist.github.com/h-east/3158492/raw/97f28a9db549e6ac1a33eb4b9903c24795c14d68/vim_multi_statusline.patch
Specification:
English (See the patch of runtime/doc/options.txt)
Add 'statuslineheight' option. (global or local to window option)
Add '@' item to 'statusline' option.
Add has('multi_statusline') for Vim script
Japanese
https://github.com/vim-jp/issues/issues/225#issuecomment-8045983

Remaining works:
- Write more document for ':help'.
- When global and local option mixed use, often crashes Vim.
- <C-W>= is not equals window height.
- Add more test.
- Add feature to multi-lined tabline. (Optional)

Are you getting interested?

Best regards,
Hirohito Higashi

[h_east]

Ah, Sample screenshot attached.

Best regards,
Hirohito Higashi

[Linda W]

Bram Moolenaar wrote:
>
> Not required for Vim itself, but there can be plugins that require it.
>

There has been a interest in a pluggable RE engine like grep has --

Specifically, the perl RE is best in breed by almost independent
evaluation --
it even includes python additions.

It' also also has the most complete and update unicode interface.

I'd like to see the RE engine improved before adding language specific
features...

[Jan Pobrislo]

On Thu, 09 May 2013 05:51:48 +0200, Bram Moolenaar <Br...@moolenaar.net> wrote:
> The top five of the voting list:
> http://www.vim.org/sponsor/vote_results.php
>
> 1. add IDE features
> 2. add integration with Python instead of inventing more Vim script
> 3. fix all problems, big and small; make Vim more robust
> 4. improve syntax highlighting speed
> 5. add collaborative editing

Hello

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 are hacks to get around it crudely, but they break other
stuff.

To allow really complex interactions from vim plugins, one "simple" change
needs to be done: allow plugins to hook into vim's eventloop. Given
interface to add and remove filedescriptors being watched with custom
callbacks and possibly a timeout callback would be all that's needed.

To actually implement that there are some options. Currently vim has several
system-specific and UI-specific eventloop implementations. So we can:

1) Add VimL api to hook into the eventloops. The unix poll() eventloop seems
simple enough to start with.

1a) Use it from other languages, which will be awkward, since one has to
generate vim code to run.

1b) Write vim wrappers for functions like popen(), socket(), connect()...
so pure-VimL scripting will be possible.

2) Add support for some established eventloop that is already pluggable. I
suspect glib can already be accessed inside gvim. My choice for terminal
vim would probably be libevent which is highly portable and supported by
libraries of most scripting languages out there (I know of gevent for
python. Perl, lua and ruby should also have one). That way we can have
features working those languages first and then go on with VimL api
as for 1)

My main issue so far was not knowing enough of C interfaces in vim to code
an actual api. I want to go on with 2) when I have spare time, which I sadly
can't guarantee right now, but I wanted to atleast to bring up this
question.

Footnotes:
- I know of the netbeans protocol. It's old and clunky and I don't believe
it lives up to this task.
- I've seen some patch for this several years back in the archives of the
mailing list, no further work has been done on this from what I found.

Thanks for great editor btw! :-)

[Ken Takata]

Hi,

2013/05/10 Fri 10:21:37 UTC+9 mattn wrote:
> On Friday, May 10, 2013 3:55:02 AM UTC+9, Bram Moolenaar wrote:
> > > https://code.google.com/p/vim-soc2008-regexp/wiki/nfa_bugs
> >
> > Andrei (the student who worked on this) does mention multi-byte. He
> > says it slows down the execution, thus the multi-byte support should be
> > there. We need to find the latest version of the code.
>
> vim72-re ?

I have updated Andrei's patch for 7.3.929.
https://bitbucket.org/k_takata/vim-soc2008-regexp-mq/src/438636dfa7c6faa41b5f1281c7a931f6938c64df/vim-soc2008-regexp.diff?at=default

I also fixed the following:
* Couldn't compile with VC10.
* Update makefiles for Windows. (Make_cyg.mak, Make_ming.mak and Make_mvc.mak)
* Some typos.
* Indents.

Maybe we need more work and testing...

Best regards,
Ken Takata

[lith]

> I'm sure everybody has their favorite patch that he would like to see
> included.

Maybe one should rather think of the breakindent patch as a basic feature of a modern text editors that fully supports "soft" word wrap.

[Bram Moolenaar]

That sounds like something for after 7.4.

--
** Hello and Welcome to the Psychiatric Hotline **
If you are obsessive-compulsive, please press 1 repeatedly.
If you are co-dependent, please ask someone to press 2.
If you have multiple personalities, please press 3, 4, 5 and 6.
If you are paranoid-delusional, we know who you are and what you want
- just stay on the line so we can trace the call.
If you are schizophrenic, listen carefully and a little voice will
tell you which number to press next.
If you are manic-depressive, it doesn't matter which number you press
- no one will answer.
If you suffer from panic attacks, push every button you can find.
If you are sane, please hold on - we have the rest of humanity on the
other line and they desparately want to ask you a few questions.

[Bram Moolenaar]

Thanks!

> Maybe we need more work and testing...

Definitely. My plan is to collect a large number of files for supported
syntax. Then compare the highlighting with the old and the new engine.
I expect this the toughest way to verify regexp patterns work properly.

Another thing to do is checking performance. Andrei already noticed
that the new engine can be twice as slow as the old one. We either need
to make it faster or use the old engine where it is faster.

--
FATHER: Did you kill all those guards?
LAUNCELOT: Yes ... I'm very sorry ...
FATHER: They cost fifty pounds each!

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Dominique Pellé]

No support for multibytes?
Isn't this a blocker issue for integrating the regexp NFA engine in Vim-7.4?

Regards
Dominique

[Tony Mechelynck]

If this issue hasn't been corrected since then, then there should be a
way to decide ahead of time that the new engine can't be used because
multibyte characters will have to be processed.

Of course, if that means not using the new engine whenever 'encoding' is
a multibyte charset (utf-8, sjis, GB18030, euc-kr, etc.), then the new
engine would lose much of its utility.

>
> Regards
> Dominique
>
Best regards,
Tony.
--
ARTHUR: It is I, Arthur, son of Uther Pendragon, from the castle of Camelot.
King of all Britons, defeator of the Saxons, sovereign of all
England!
[Pause]
SOLDIER: Get away!

[Tony Mechelynck]

On 10/05/13 10:54, Jan Pobrislo wrote:
> On Thu, 09 May 2013 05:51:48 +0200, Bram Moolenaar <Br...@moolenaar.net> wrote:
>> The top five of the voting list:
>> http://www.vim.org/sponsor/vote_results.php
>>
>> 1. add IDE features
>> 2. add integration with Python instead of inventing more Vim script
>> 3. fix all problems, big and small; make Vim more robust
>> 4. improve syntax highlighting speed
>> 5. add collaborative editing
>
> Hello
>
> 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 are hacks to get around it crudely, but they break other
> stuff.
>
> To allow really complex interactions from vim plugins, one "simple" change
> needs to be done: allow plugins to hook into vim's eventloop. Given
> interface to add and remove filedescriptors being watched with custom
> callbacks and possibly a timeout callback would be all that's needed.
>
> To actually implement that there are some options. Currently vim has several
> system-specific and UI-specific eventloop implementations. So we can:
>
> 1) Add VimL api to hook into the eventloops. The unix poll() eventloop seems
> simple enough to start with.

Is it guaranteed to be available? Think MS-Windows or IBM-mainframe.

>
> 1a) Use it from other languages, which will be awkward, since one has to
> generate vim code to run.
>
> 1b) Write vim wrappers for functions like popen(), socket(), connect()...
> so pure-VimL scripting will be possible.
>
> 2) Add support for some established eventloop that is already pluggable. I
> suspect glib can already be accessed inside gvim. My choice for terminal

glib inside Vim? Again, even when compiled on MS Visual C or on some
z390 compiler? Don't forget that Vim is multi-platform, and that we're
proud of that.

> vim would probably be libevent which is highly portable and supported by
> libraries of most scripting languages out there (I know of gevent for
> python. Perl, lua and ruby should also have one). That way we can have
> features working those languages first and then go on with VimL api
> as for 1)
>
> My main issue so far was not knowing enough of C interfaces in vim to code
> an actual api. I want to go on with 2) when I have spare time, which I sadly
> can't guarantee right now, but I wanted to atleast to bring up this
> question.
>
> Footnotes:
> - I know of the netbeans protocol. It's old and clunky and I don't believe
> it lives up to this task.
> - I've seen some patch for this several years back in the archives of the
> mailing list, no further work has been done on this from what I found.
>
> Thanks for great editor btw! :-)
>

Yes, a great editor for sure.

Best regards,
Tony.
--
"You can bring any calculator you like to the midterm, as long as it
doesn't dim the lights when you turn it on."
-- Hepler, Systems Design 182

[Tony Mechelynck]

Here's a screenshot of my gvim instance, with single-line status lines
but many of them. I suppose that many will be seen as overkill by many
people ;-) but as you see a single line can already hold a lot of
information, and with more than one status line I would have to
drastically reduce the number of windows in that tab page.


Best regards,
Tony.
--
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers

[Tony Mechelynck]

On 09/05/13 05:51, Bram Moolenaar wrote:
>
> Hello Vim users,
>
> We are now at patch level 7.3.931. In a few weeks we would reach 999. I
> don't want to find out what happens if we go over that, so it's time for
> Vim 7.4!

[...]

Maybe we could decide that Vim 7.3.999 + 1 will be 7.4.000, and make
plans for an alpha or beta for 7.5 or even 8.0 ;-) That would give more
leeway for testing the future release before retiring 7.3. (I'm only
half serious here.)


Best regards,
Tony.
--
Sanity is the trademark of a weak mind.
-- Mark Harrold

[Xavier de Gaye]

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 are hacks to get around it crudely, but they break other
> stuff.
>
> To allow really complex interactions from vim plugins, one "simple" change
> needs to be done: allow plugins to hook into vim's eventloop. Given
> interface to add and remove filedescriptors being watched with custom
> callbacks and possibly a timeout callback would be all that's needed.

An alternative would be to allow any python thread to call the vim-python
interface through message passing.

Instead of calling directly a python function named 'func' that can only be
run by the vim-thread, a plain python thread could do:

ret = vim.threadsafe_eval(func)

or, when 'func' has arguments:

ret = vim.threadsafe_eval(lambda: func(arg1, arg2))

threadsafe_eval() accepts a callable as argument. It puts the callable in a
queue so that the callable may be executed later by the vim-thread and gets
the return value of the callable from another queue (instead of the return
value, the queue may contain the unhandled exception raised by the callable).

This could be implemented with two instances of the python Queue class. The
queues are of size 1 to handle concurrent access to the queues from multiple
threads.

* The first Queue instance contains the callable:
The producers are the callers of threadsafe_eval(). threadsafe_eval()
blocks waiting to put the callable in the queue.

The consumer is a C function that is called:
. in all the places where netbeans_parse_messages() is invoked in Vim
source code. That is: when Vim is idle waiting for characters or when
Vim runs the sleep command.
. in ui_breakcheck() so that it will be invoked when Vim does a
long-lasting job and then checks regularly for <Ctl-C>.

This C function gets the callable from the queue, instantiates an object
of the Result class and runs the callable. The return value of the
callable (or the unhandled exception) is stored in the Result object as
its 'value' and the Result object is put in the second queue.

* The second Queue instance contains the Result object:
threadsafe_eval() blocks waiting for a Result object. If the object
'value' contains an Exception instance, the exception is re-raised,
otherwise 'value' is returned.


Xavier

[Bram Moolenaar]

It does support multi-byte. Andrei noticed that some of the multi-byte
functions are consuming a lot of time.

--
GUARD #1: What, ridden on a horse?
ARTHUR: Yes!
GUARD #1: You're using coconuts!
ARTHUR: What?
GUARD #1: You've got two empty halves of coconut and you're bangin' 'em
together.
The Quest for the Holy Grail (Monty Python)

[tyru]

Hi vimmers!

'updatetime' option is used as event-timer among Vimmers who knows
Vimscript well.
so I think making updatetime buffer-local is the easiest way to
implement async feature.

I also want Vim to have more sophisticated built-in async feature, though.
+1 for poll() interface if it can be implemented.

agreed :)

>
> Best regards,
> Tony.
> --
> "You can bring any calculator you like to the midterm, as long as it
> doesn't dim the lights when you turn it on."
> -- Hepler, Systems Design 182
>
>

> --
> --
> 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 this message because you are subscribed to the Google
> Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jan Pobrislo]

On Sat, 11 May 2013 04:45:50 +0200, Tony Mechelynck <antoine.m...@gmail.com> wrote:
> > 1) Add VimL api to hook into the eventloops. The unix poll() eventloop seems
> > simple enough to start with.
>
> Is it guaranteed to be available? Think MS-Windows or IBM-mainframe.
>

Nope, neither are some other optional features. What I'm saying here is that
the eventloop that covers significant part of vim installs (terminal on
unix-like platforms) seemed easy enough to hack, so I could start
prototyping on that and then see how it can be transferred to other
platforms.

Generally said, we can not portably handle this on platforms that don't have
filedescriptor handling like this. Luckily, pretty much everybody stole the
BSD socket implementation, so this interface is quite widespread.

It should definitely be more portable than the +clientserver feature, of
which it is functionally superset. (FWIU +clientserver requires either X11
or Windows event queue)

> > 2) Add support for some established eventloop that is already pluggable. I
> > suspect glib can already be accessed inside gvim. My choice for terminal
>
> glib inside Vim? Again, even when compiled on MS Visual C or on some
> z390 compiler? Don't forget that Vim is multi-platform, and that we're
> proud of that.

Glib inside gvim, since gtk+ uses glib internally. More precisely glib is
that part of gtk+ that does not deal with gui, so there's no gvim without
glib. (Unless there's implementation of gvim not based on gtk which I'm
unaware of).

> > vim would probably be libevent which is highly portable and supported by
> > libraries of most scripting languages out there (I know of gevent for
> > python. Perl, lua and ruby should also have one). That way we can have
> > features working those languages first and then go on with VimL api
> > as for 1)
> >

For reference, from libevent.org:
Currently, libevent supports /dev/poll, kqueue(2), event ports, POSIX
select(2), Windows select(), poll(2), and epoll(4).
...
Libevent should compile on Linux, *BSD, Mac OS X, Solaris, Windows, and
more.

Thanks for reply :-)

[Jan Pobrislo]

On Sat, 11 May 2013 15:44:10 +0200, Xavier de Gaye <xde...@gmail.com> wrote:
> An alternative would be to allow any python thread to call the vim-python
> interface through message passing.

That indeed is also possible, but for it to work properly you need to create
interface for waking the main thread from iowait, which again means that you
need to change the eventloop implementation anyway. And since you can
implement message passing and multithreading whenever you have proper
pluggable eventloop (assuming the platform supports something akin to
socketpair() for waking) I don't see the point of having way more
complicated and non-standard interface via message passing. Not to mention
it would force programmers to spend extra effort on data structure locking,
which is quite well known to be error-prone and produces hard to debug bugs.

The point of implementing new eventloop based on libevent is that you can
then use it transparently from any scripting language vim supports (except
for VimL itself) without any extra code in each language. Just pull in
whatever wrapper the language has for libevent and you're set to go.

Not that I'm strictly against such feature, it will still be way better than
any updatetime hack out there, it just seems more tedious to both to
implement and subsequently to use.

Thanks for reply.

[Tony Mechelynck]

My understanding was that glib is the C library included with gcc,
regardless of whether some GUI development package (and which one) is
also installed. As such, glib is not included with MS Visual C which is
one of the most popular C compilers used (including by Bram) when
compiling Vim for Windows. I don't know which C compiler is included on
IBM EBCDIC zOS systems; for all I know it could well be something
totally different (unlike C for zLinux, which is gcc, but running on a
non-Intel-x86-compatible processor). I'm not sure either which compiler
is used on Mac OSX but for all I know it could be some version of gcc.

Additionally, there are several gvim implementations not based on GTK2
(or on the obsolete GTK1) even on Linux, but all of them are compiled
with gcc so I would assume that they are based on glib.

>
>>> vim would probably be libevent which is highly portable and supported by
>>> libraries of most scripting languages out there (I know of gevent for
>>> python. Perl, lua and ruby should also have one). That way we can have
>>> features working those languages first and then go on with VimL api
>>> as for 1)
>>>
>
> For reference, from libevent.org:
> Currently, libevent supports /dev/poll, kqueue(2), event ports, POSIX
> select(2), Windows select(), poll(2), and epoll(4).
> ...
> Libevent should compile on Linux, *BSD, Mac OS X, Solaris, Windows, and
> more.
>
> Thanks for reply :-)
>

Best regards,
Tony.
--
SOLDIER: What? Ridden on a horse?
ARTHUR: Yes!
SOLDIER: You're using coconuts!

[James McCoy]

On Mon, May 13, 2013 at 02:40:20AM +0200, Tony Mechelynck wrote:
> On 12/05/13 21:28, Jan Pobrislo wrote:
> >Glib inside gvim, since gtk+ uses glib internally. More precisely glib is
> >that part of gtk+ that does not deal with gui, so there's no gvim without
> >glib. (Unless there's implementation of gvim not based on gtk which I'm
> >unaware of).
>
> My understanding was that glib is the C library included with gcc,

Maybe you're thinking of glibc, but that's not part of gcc either. glib
is as Jan describes it -- https://developer.gnome.org/glib/stable/.

> As such, glib is not included with MS Visual C
> which is one of the most popular C compilers used (including by
> Bram) when compiling Vim for Windows.

Quoting from the above link:

GLib is a general-purpose utility library, which provides many useful
data types, macros, type conversions, string utilities, file
utilities, a mainloop abstraction, and so on. It works on many
UNIX-like platforms, as well as Windows and OS X. GLib is released
under the GNU Library General Public License (GNU LGPL).

Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jame...@jamessan.com>

[Ken Takata]

Hi,

2013/05/11 Sat 5:25:21 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > 2013/05/10 Fri 10:21:37 UTC+9 mattn wrote:
> > > On Friday, May 10, 2013 3:55:02 AM UTC+9, Bram Moolenaar wrote:
> > > > > https://code.google.com/p/vim-soc2008-regexp/wiki/nfa_bugs
> > > >
> > > > Andrei (the student who worked on this) does mention multi-byte. He
> > > > says it slows down the execution, thus the multi-byte support should be
> > > > there. We need to find the latest version of the code.
> > >
> > > vim72-re ?
> >
> > I have updated Andrei's patch for 7.3.929.
> > https://bitbucket.org/k_takata/vim-soc2008-regexp-mq/src/438636dfa7c6faa41b5f1281c7a931f6938c64df/vim-soc2008-regexp.diff?at=default
> >
> > I also fixed the following:
> > * Couldn't compile with VC10.
> > * Update makefiles for Windows. (Make_cyg.mak, Make_ming.mak and Make_mvc.mak)
> > * Some typos.
> > * Indents.
>
> Thanks!
>
> > Maybe we need more work and testing...
>
> Definitely. My plan is to collect a large number of files for supported
> syntax. Then compare the highlighting with the old and the new engine.
> I expect this the toughest way to verify regexp patterns work properly.
>
> Another thing to do is checking performance. Andrei already noticed
> that the new engine can be twice as slow as the old one. We either need
> to make it faster or use the old engine where it is faster.

I have updated the regexp patch:
https://bitbucket.org/k_takata/vim-soc2008-regexp-mq/src/0ba4d0226d1d83cb30b7b2474d06c69b324e9692/vim-soc2008-regexp.diff?at=default

Two items are fixed:
* Fix compile error with VC10 when DEBUG is defined.
* Fix indents.

The latest patch will be available at:
https://bitbucket.org/k_takata/vim-soc2008-regexp-mq/src/tip/vim-soc2008-regexp.diff?at=default
("tip" is used as a commit ID.)

I tested whether this new engine supports multibyte or not.
I tried with enc=utf-8 and enc=cp932. It seems to work.

Thanks,
Ken Takata

[Bram Moolenaar]

Thanks! Hopefully I can start integrating the patch coming weekend.

--
I'm sure that I asked CBuilder to do a "full" install. Looks like I got
a "fool" install, instead. Charles E Campbell, Jr, PhD

[Fanhe Fanhed]

I have two patches to submit...

I think the IDE features can provide by plugins, I am making an IDE project.

2013/5/14 Bram Moolenaar <Br...@moolenaar.net>

[Charles Campbell]

Jan Pobrislo wrote:
> Glib inside gvim, since gtk+ uses glib internally. More precisely glib is
> that part of gtk+ that does not deal with gui, so there's no gvim without
> glib. (Unless there's implementation of gvim not based on gtk which I'm
> unaware of).
>

A gvim can be compiled using motif under Linux (ie. no gtk).

Regards,
C Campbell

[Ron Aaron]

I know it's late to vote, but some sort of sane 'gdb' integration would be supremely useful. I haven't found any packages for this that don't involve a lot of setup.

[Bram Moolenaar]

There are several implementations, including my own "Agide".
Pick one that is the best and improve it...
Most likely it won't require more than a few changes inside Vim itself.

--
Corn oil comes from corn and olive oil comes from olives, so where
does baby oil come from?

[ZyX]

> BTW: Is there any upcoming support for c++11 especially indent of c++11 files? Syntax highlighting can be done by external systax files but the indenting could not be modified by users.

Really? Check out :h 'indentexpr'. It could be modified, but you will either have to do some hacks relying on cindent() result or rewrite everything what is there in C code in other language.

[Oliver Rath]

Hi list!

Am 09.05.2013 05:51, schrieb Bram Moolenaar:
>
> [..]
> 5. add collaborative editing
> [..]

This is a feature that Im looking for a long time. Im not so deep inside
that I would be able to write the code for this, but maybe I can give a
hint from the Libreoffice-project, which uses this way for generating
this (if I understand right, this is not yet contributed as stable):

- all collaborating programs are using a chatroom based on jabber
protocol, so it is possiblie to collaborate over net
- the editing commands are sent as xml-code to this chatroom, so all
are able to get complex actions, too (maybe this is not needed for
vim)
- every writer gets an own color, so it is possible to see, who is
writing at the moment

On the other side, at the moment it is possible to collaborate "a bit"
with vim running inside a screen, but this requires a login for all
subscribers to the machine running screen.

Last but not least there exist a project for collaborated writing:
Google Wave, which is imho open source, so there we can find some useful
code for this.

Regards from Linuxtag Berlin

Oliver

[Charles]

There was this new plugin in the news several days ago

https://github.com/FredKSchott/CoVim

CoVim - Collaborative Editing for Vim

[Thomas Köhler]

Hallo Bram,

Thomas Köhler wrote:
> Attached, you can find a new version of prolog.vim (syntax
> highlightning for prolog) and koehler.vim (my colorscheme). The
> former fixes a bug in prologClauseHead higlightning, the later
> now supports the Underline and Ignore groups.

While I'm at it, I also just fixed a bug in uil.vim, see attached
version.

Ciao,
Thomas

--
Thomas Köhler Email: jean...@picard.franken.de
<>< WWW: http://gott-gehabt.de
IRC: tkoehler Freenode: thkoehler
PGP public key available from Homepage!

[Thomas Köhler]

Hello Bram, hello Ron,

Bram Moolenaar wrote:
> Hello Vim users,

[...]
> Besides that, if you are maintaining runtime files, please send me any
> pending updates. I will not make big changes just before the release,
> everything needs some time for testing. Let's set a deadline at the end
> of May.

Attached, you can find a new version of prolog.vim (syntax
highlightning for prolog) and koehler.vim (my colorscheme). The
former fixes a bug in prologClauseHead higlightning, the later
now supports the Underline and Ignore groups.

@Ron: please include the koehler.vim in your own repository.

Bye,

[Thomas Köhler]

Hallo Bram,
Thomas Köhler wrote:
> While I'm at it, I also just fixed a bug in uil.vim, see attached
> version.

Well, next time I'll first fix ALL bugs, then submit a new
version... here's the final version that fixes another small
glitch.

[Bram Moolenaar]

Thomas Köhler wrote:

> Hallo Bram,
>
> Thomas Köhler wrote:
> > Attached, you can find a new version of prolog.vim (syntax
> > highlightning for prolog) and koehler.vim (my colorscheme). The
> > former fixes a bug in prologClauseHead higlightning, the later
> > now supports the Underline and Ignore groups.
>
> While I'm at it, I also just fixed a bug in uil.vim, see attached
> version.

Thanks. I'll use the second version.


--
BLACK KNIGHT: None shall pass.
ARTHUR: I have no quarrel with you, brave Sir knight, but I must cross
this bridge.
BLACK KNIGHT: Then you shall die.

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Bram Moolenaar]

Thomas Köhler wrote:

> Hello Bram, hello Ron,
>
> Bram Moolenaar wrote:
> > Hello Vim users,
> [...]
> > Besides that, if you are maintaining runtime files, please send me any
> > pending updates. I will not make big changes just before the release,
> > everything needs some time for testing. Let's set a deadline at the end
> > of May.
>
> Attached, you can find a new version of prolog.vim (syntax
> highlightning for prolog) and koehler.vim (my colorscheme). The
> former fixes a bug in prologClauseHead higlightning, the later
> now supports the Underline and Ignore groups.

Thanks, I'll include them.

--
DENNIS: You can't expect to wield supreme executive power just 'cause some
watery tart threw a sword at you!