I've been complaining about Vim related issues for a long time,
I think its time to stop complaining and just fix it.
Join by providing feedback:
http://mawercer.de/vim.php
or adding additional issues to be fixed here:
http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html
The id
There definitely always is some space for improvements. I'd nevertheless like
to ask if you really think that more of the same is a significant improvement.
Vim is a versatile editor the way it is. I still wish it would have emacs-like
overlays and maybe js as scripting languagee, since I'm conv
To me, vim is more than an editor... Vim is a language which I as well as many
have come to embrace. Yet, as much as I love the modal dialect of vim, I rarely
use vim proper anymore and instead use Sublime Text 3 with vim emulation and
though it isn't a full blown vim experience, the emulation o
Yes! I'd contribute to a Kickstarter campaign for enhancing ViM.
* true async support in the core. Remove notions of updatetime since everything
will be async
* remove backwards compatibility to Vi. I'm assuming that vi backwards
compatibility is hard to maintain? At the very least make nocompati
On Nov 25, 2013 5:24 PM, "Marc Weber" wrote:
>
> I've been complaining about Vim related issues for a long time,
> I think its time to stop complaining and just fix it.
>
> Join by providing feedback:
> http://mawercer.de/vim.php
>
> or adding additional issues to be fixed here:
> http://vim-wiki.
> Making some interpreter standard not only risks slowing user down, but also
> makes it close to impossible to use other people's vim.
Well - that's already the case - and I don't care. People remap :; in
normal mode only (to reduce stress) and the like.
But starting up Vim is fast, adding condit
On Nov 25, 2013 9:23 PM, "Marc Weber" wrote:
>
> > Making some interpreter standard not only risks slowing user down, but
also
> > makes it close to impossible to use other people's vim.
> Well - that's already the case - and I don't care. People remap :; in
> normal mode only (to reduce stress) a
Excerpts from Nikolay Pavlov's message of Mon Nov 25 18:55:56 +0100 2013:
> I do if there is and *may be no* python? Not all interpreters work on the
> same OS+arch combination vim does.
Then there will be no support - why bother?
Then Vim will be "an editor only" on those platforms. But honestly I
On Nov 25, 2013 10:20 PM, "Marc Weber" wrote:
>
> Excerpts from Nikolay Pavlov's message of Mon Nov 25 18:55:56 +0100 2013:
> > I do if there is and *may be no* python? Not all interpreters work on
the
> > same OS+arch combination vim does.
> Then there will be no support - why bother?
> Then Vim
On Mon, Nov 25, 2013 at 5:51 PM, Nikolay Pavlov wrote:
> On Nov 25, 2013 5:24 PM, "Marc Weber" wrote:
> I would consider D in first place. Not that I actually worked with it, but I
> have read lots of articles convincing me that it is way better then C++.
I used D for a project and I quickly wen
Excerpts from Paolo Bolzoni's message of Mon Nov 25 23:12:49 +0100 2013:
> On Mon, Nov 25, 2013 at 5:51 PM, Nikolay Pavlov wrote:
> > On Nov 25, 2013 5:24 PM, "Marc Weber" wrote:
> > I would consider D in first place. Not that I actually worked with it, but I
> > have read lots of articles convin
Excerpts from Nikolay Pavlov's message of Mon Nov 25 19:46:51 +0100 2013:
> Do not know about mzscheme (racket), but if_py does not actually support
> threading: it is cpython that supports it:
The problem is that Vim does not expect called by Vim unless its VimL
calling into Vim or such. Python do
On Nov 26, 2013 6:14 AM, "Marc Weber" wrote:
>
> Excerpts from Nikolay Pavlov's message of Mon Nov 25 19:46:51 +0100 2013:
> > Do not know about mzscheme (racket), but if_py does not actually support
> > threading: it is cpython that supports it:
> The problem is that Vim does not expect called by
On 2013-11-26, Jeff Schwartz wrote:
> To me, vim is more than an editor... Vim is a language which I as
> well as many have come to embrace. Yet, as much as I love the
> modal dialect of vim, I rarely use vim proper anymore and instead
> use Sublime Text 3 with vim emulation and though it isn't a f
Since we are in the topic of improvements, what about a real
rectangular selection?
Example:
s
z
Select everything a part of the right-most s and
the four left-most y?
On Tue, Nov 26, 2013 at 5:46 PM, Gary Johnson wrote:
> On 2013-11-26, Jeff Schwartz wrote:
>> To
Excerpts from Paolo Bolzoni's message of Tue Nov 26 17:56:41 +0100 2013:
> Example:
> s
>
>
> z
>
> Select everything a part of the right-most s and
> the four left-most y?
I don't understand what you're looking for.
Can you mark the characters to select by making the
> From: vim_...@googlegroups.com On Behalf Of Michael Jarvis
> On Monday, November 25, 2013 7:26:42 AM UTC-6, MarcWeber wrote:
> > I've been complaining about Vim related issues for a long time,
> > I think its time to stop complaining and just fix it.
> > The idea is to create a kickstarte
Excerpts from Nikolay Pavlov's message of Mon Nov 25 17:51:30 +0100 2013:
> Making some interpreter standard not only risks slowing user down, but also
> makes it close to impossible to use other people's vim.
Are you talking about pairing? I mean it would be possible to either
introduce "collabora
Dear Konovalov, Vadim
> Sounds naïve.
Maybe it is. But if you don't try you've failed from the very beginning ;)
But let me give you an example:
sturt foo {
char bar[LENGTH]
int something_else;
}
foo s;
for (i = 0, i <= LENGTH, i++){
s.bar[i] = '\x0';
}
Of coure there is a bug, and this
On Tue, November 26, 2013 17:56, Paolo Bolzoni wrote:
> Since we are in the topic of improvements, what about a real
> rectangular selection?
>
> Example:
> s
>
>
> z
>
> Select everything a part of the right-most s and
> the four left-most y?
You can already do that.
I like virtualedit=block more, but thanks for
pointing me in the right direction!
On Wed, Nov 27, 2013 at 8:08 AM, Christian Brabandt wrote:
> On Tue, November 26, 2013 17:56, Paolo Bolzoni wrote:
>> Since we are in the topic of improvements, what about a real
>> rectangular selection?
>>
>> Exam
Hello,
> But let me give you an example:
>
> sturt foo {
> char bar[LENGTH]
> int something_else;
> }
>
> foo s;
>
> for (i = 0, i <= LENGTH, i++){
> s.bar[i] = '\x0';
> }
> [...]
> How could such be fixed?
> Now tell me how I can do that with C/C++?
This is a easy one: embrace C++11 !
It is nice to see someone which actually knows C++ once in a while...
In my environment there is no-one.
On Wed, Nov 27, 2013 at 2:44 PM, wrote:
> Hello,
>
>
>> But let me give you an example:
>>
>> sturt foo {
>> char bar[LENGTH]
>> int something_else;
>> }
>>
>> foo s;
>>
>> for (i = 0, i
Excerpts from hermitte's message of Wed Nov 27 14:44:42 +0100 2013:
> The difficulty with C++, is to force ourselves to forget we also know C.
> (BTW, C/C++ is a beast that shall be hunt down. Either code in C, or
> in C++. Never try to import C good practices in C++ because they don't
> apply)
His
-original message-
Subject: improving Vim - Kickstarter - brainstorming - goals - who wants to
join?
From: Saad Malik
Date: 27/11/2013 5:53 pm
Yes! I'd contribute to a Kickstarter campaign for enhancing ViM.
* true async support in the core. Remove notions of updatetime since everything
-original message-
Subject: improving Vim - Kickstarter - brainstorming - goals - who wants to
join?
From: Saad Malik
Date: 27/11/2013 5:53 pm
Yes! I'd contribute to a Kickstarter campaign for enhancing ViM.
* true async support in the core. Remove notions of updatetime since everything
-original message-
Subject: improving Vim - Kickstarter - brainstorming - goals - who wants to
join?
From: Saad Malik
Date: 27/11/2013 5:53 pm
Yes! I'd contribute to a Kickstarter campaign for enhancing ViM.
* true async support in the core. Remove notions of updatetime since everything
> * true async support in the core.
> Remove notions of updatetime since everything will be async
I don't understand this second sentence, example?
> * remove backwards compatibility to Vi. I'm assuming that vi backwards
> compatibility is hard to maintain? At the very least make nocompatible
> t
> Excerpts from hermitte's message of Wed Nov 27 14:44:42 +0100 2013:
> > The difficulty with C++, is to force ourselves to forget we also
> > know C.
> > (BTW, C/C++ is a beast that shall be hunt down. Either code in C,
> > or in C++. Never try to import C good practices in C++ because
> > they d
On Wednesday, November 27, 2013 7:52:59 PM UTC+4, Saad Malik wrote:
> Yes! I'd contribute to a Kickstarter campaign for enhancing ViM.
> * true async support in the core. Remove notions of updatetime since
> everything will be async
True asynchronous support is badly needed. But for compatibility
Michael Jarvis wrote:
> On Monday, November 25, 2013 7:26:42 AM UTC-6, MarcWeber wrote:
> > I've been complaining about Vim related issues for a long time,
> >
> > I think its time to stop complaining and just fix it.
> >
> >
> >
> > Join by providing feedback:
> >
> > http://mawercer.de/vim
On Monday, November 25, 2013 11:26:42 AM UTC-2, MarcWeber wrote:
> I've been complaining about Vim related issues for a long time,
>
> I think its time to stop complaining and just fix it.
>
>
I agree. Then let us fix it.
>
> Join by providing feedback:
>
> http://mawercer.de/vim.php
>
I
Excerpts from Ed Kostas's message of Sun Dec 01 16:01:42 +0100 2013:
> I want to join, but I receive the following message when I try:
> You don't have permission to access /x/php.fcgi/index.php on this server.
Your message to the mailinglist has been enough, I took notes.
The pages will be back s
On Dec 2, 2013 9:25 AM, "Marc Weber" wrote:
>
> Excerpts from Ed Kostas's message of Sun Dec 01 16:01:42 +0100 2013:
> > I want to join, but I receive the following message when I try:
> > You don't have permission to access /x/php.fcgi/index.php on this
server.
> Your message to the mailinglist h
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 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
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
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
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
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
On Dec 3, 2013 10:08 AM, "Erik Christiansen"
wrote:
>
> 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 somethin
On Dec 3, 2013 10:07 AM, "Marc Weber" wrote:
>
> 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 advanta
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 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).
>
56 matches
Mail list logo