Hi Nikolay
I've turned your suggestion into a page about order of steps to fix Vim:
http://vim-wiki.mawercer.de/wiki/vim-development/fixing-vim-next-steps.html
Have a look at the (Comment ..) text, please add some samples. Code can
be added by
{{{
...
}}}
I've also added you as collaborator to
On Monday, December 2, 2013 5:40:48 AM UTC-2, Sergey Khorev wrote:
> I am not sure whether it is ok to post a question to a specific member.
> However, I think that Serguey Khoreve is the person in better position to
> answer me. In the documentation of vim-mzscheme, I found references to a
> vi
I made a typo in the previous posting. Here are the lines to compile mz-vim:
~/vim# ./configure --enable-mzschemeinterp --with-features=small
~/vim# make
~/vim# sudo make install
Racket should be built from sources, as stated in the previous post.
--
--
You received this message from the "vi
I wonder how vim building and installation works. After building Vim, I checket
the src directory to see how large was the exec file. Thus:
~/vim# ls src/vim -lia
35097123 -rwxr-xr-x 1 ed ed 15941469 Dez 2 12:05 src/vim
[2]+ Donegvim
~/vim#
There it is. It occupies about 1
Dnia Poniedziałek, 2 Grudnia 2013 14:25 Marc Weber
napisał(a)
>
> Excerpts from Nikolay Pavlov's message of Mon Dec 02 08:41:43 +0100 2013:
> > - Making vim embeddable (making it second point since it is even more
> > refactoring).
> Keep in mind that Yzis team failed on this, see
> http://www.
On Dec 2, 2013 5:25 PM, "Marc Weber" wrote:
>
> Hi Nikolay
>
> I've turned your suggestion into a page about order of steps to fix Vim:
>
http://vim-wiki.mawercer.de/wiki/vim-development/fixing-vim-next-steps.html
>
> Have a look at the (Comment ..) text, please add some samples. Code can
> be add
On Dec 2, 2013 6:28 PM, "Mikołaj Machowski" wrote:
>
> Dnia Poniedziałek, 2 Grudnia 2013 14:25 Marc Weber
napisał(a)
> >
> > Excerpts from Nikolay Pavlov's message of Mon Dec 02 08:41:43 +0100
2013:
> > > - Making vim embeddable (making it second point since it is even more
> > > refactoring).
>
2013-12-02 15:56, Nikolay Pavlov skrev:
> > - Unicode support in regular expressions.
> Can you also provide a simple use case, here ?
How do you match a Russian word? This will be /\b\p{Cyrillic}+\b/
in Perl. There is a big bunch of Unicode properties that you can
place inside figure braces t
On Dec 2, 2013 7:36 PM, "BPJ" wrote:
>
> 2013-12-02 15:56, Nikolay Pavlov skrev:
>
>> > > - Unicode support in regular expressions.
>> > Can you also provide a simple use case, here ?
>>
>> How do you match a Russian word? This will be /\b\p{Cyrillic}+\b/
>> in Perl. There is a big bunch of Unic
I have a very slow network connection, so accessing letter drives are painful.
For that reason, I work off the local HD as much as possible, then painfully
synchronize my HD content with my network drive when I feel it is unwise to put
it off.
One problem that puzzles me is that netrw is slow
On Monday, December 2, 2013 10:14:45 AM UTC-6, Paul wrote:
> I have a very slow network connection, so accessing letter drives are
> painful. For that reason, I work off the local HD as much as possible, then
> painfully synchronize my HD content with my network drive when I feel it is
> unwise
Excerpts from Nikolay Pavlov's message of Mon Dec 02 15:56:25 +0100 2013:
> Currently such interfaces are pretty much useless without using vim.eval or
> vim.command (or equivalents in your language of choice). I started creating
> wrappers around various C structures (like that vim.options thingie
On Dec 2, 2013 8:44 PM, "Marc Weber" wrote:
>
> Excerpts from Nikolay Pavlov's message of Mon Dec 02 15:56:25 +0100 2013:
> > Currently such interfaces are pretty much useless without using
vim.eval or
> > vim.command (or equivalents in your language of choice). I started
creating
> > wrappers aro
On Monday, December 2, 2013 11:30:16 AM UTC-5, Ben Fritz wrote:
>On Monday, December 2, 2013 10:14:45 AM UTC-6, Paul wrote:
>> I have a very slow network connection, so accessing letter drives
>> are painful. For that reason, I work off the local HD as much as
>> possible, then painfully synchroni
On Mon, Dec 02, 2013 at 06:23:44AM -0800, Ed Kostas wrote:
> I wonder how vim building and installation works. After building Vim, I
> checket the src directory to see how large was the exec file. Thus:
> ~/vim# ls src/vim -lia
> 35097123 -rwxr-xr-x 1 ed ed 15941469 Dez 2 12:05 src/vim
> [2]+ D
Marc,
Is it possible to address the 'Esc key timeout' issue in terminal ViM? ViM has
a short delay when exiting Insert mode because it needs to determine if the
user pressed escape key or if this is the start of some new sequence.
I'm sure fixing this would have destabilizing ripple effects on a
Ben Fritz wrote:
On Monday, December 2, 2013 10:14:45 AM UTC-6, Paul wrote:
I have a very slow network connection, so accessing letter drives are painful.
For that reason, I work off the local HD as much as possible, then painfully
synchronize my HD content with my network drive when I feel i
Paul wrote:
On Monday, December 2, 2013 11:30:16 AM UTC-5, Ben Fritz wrote:
On Monday, December 2, 2013 10:14:45 AM UTC-6, Paul wrote:
I have a very slow network connection, so accessing letter drives
are painful. For that reason, I work off the local HD as much as
possible, then painfully syn
Over the past years of working with many tools(from visual studio to vim + tmux
+ zsh) I've built a mental model of what would be the perfect tool for my
work as a programmer/system administrator, so I will share its concepts here
as a means of contributing to the idea. Hopefully this will be helpf
Excerpts from Nikolay Pavlov's message of Mon Dec 02 18:12:00 +0100 2013:
> Wondering whether gobject may make python-vim API look like rather regular
> python module and not like something ctypes-based with many implementation
> details leaking.
Writing a small python layer on top should be easy.
> irc: Have you seen my mail
Please don't expect me to reply within 1h. 24 to 48h should must be
enough :)
> - Client-server model from the core, following tmux ideas regarding
> sessions/windows.
You think its enough to say "client-server" model? Please try this:
client-server model for these
On Dec 2, 2013 10:41 PM, "Marc Weber" wrote:
>
> Excerpts from Nikolay Pavlov's message of Mon Dec 02 18:12:00 +0100 2013:
> > Wondering whether gobject may make python-vim API look like rather
regular
> > python module and not like something ctypes-based with many
implementation
> > details leaki
On Dec 2, 2013 11:35 PM, "Nikolay Pavlov" wrote:
>
>
> On Dec 2, 2013 10:41 PM, "Marc Weber" wrote:
> >
> > Excerpts from Nikolay Pavlov's message of Mon Dec 02 18:12:00 +0100
2013:
> > > Wondering whether gobject may make python-vim API look like rather
regular
> > > python module and not like s
On Mon, Dec 2, 2013 at 3:55 PM, Marc Weber wrote:
> You think its enough to say "client-server" model? Please try this:
>
> client-server model for these use cases:
> - ..
> - ..
> - ..
- Multiple clients connected to the same vim instance would provide an easy way
to have collaborative ed
It seems odd to build a lot of these things into vim when excellent
solutions exist with more generic applications. You (Thiago) mention
already using tmux+vim, and I find that solves most of the issues you
list, and thus I'd find adding those to vim to be superfluous.
On 2013-12-02 23:13, Thiago
On Tue, Dec 3, 2013 at 12:40 AM, Tim Chase wrote:
> It seems odd to build a lot of these things into vim when excellent
> solutions exist with more generic applications. You (Thiago) mention
> already using tmux+vim, and I find that solves most of the issues you
> list, and thus I'd find adding t
agree
I think it'll move vim to a new milestone if more cool stuff can be integrated
into vim. Throw away other sick hackings and stay just with vim . Like emacs .
How about lightweight version (current) and a new(heavy ) version , toggle-able
via a new 'compatible ' knob?
from iPhone
On Dec
Excerpts from Nikolay Pavlov's message of Mon Dec 02 20:35:18 +0100 2013:
> Note: this means that if there is reference somewhere when you redefine
> function that reference will still use old definition. I consider such
> stability an advantage.
I always assumed that
- restarting Vim is that fast
On 02.12.13 19:41, Marc Weber wrote:
> > I do not remember clearly, but was not it suggested to take PCRE syntax? I
> > do not remember any discussions suggesting taking PCRE and replacing parser
> > code, but I may have missed something.
> I don't remember wether it was public. Facts: PCRE is fast
29 matches
Mail list logo
