Hi Bram Moolenaar, you wrote:
>
>> To finish, I'm not suggesting that the optimum one-size-fits-all set
>> of mappings be determined. Any set of well-planned mappings
>> would be better than the current blank slate.
>
> The best set of mappings is what you make yourself. That's like: don't
> gi
Hi Stefano Zacchiroli, you wrote:
>
> The solution of being compatible when invoked as 'vi' and being
> nocompatible when invoked in a different way made everybody happy. The
> (trivial) patch we are using to implement this behaviour is available
> at:
>
>
> http://svn.debian.org/wsvn/pkg-vim
--- "A.J.Mechelynck" <[EMAIL PROTECTED]> escreveu:
> Georg Dahn wrote:
> > Hi!
> >
> > --- "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote:
>
> These two are V7 only, so:
>
> if exists("*pumvisible")
> inoremap pumvisible() ? "\Down" : "\C-O>gj"
> inoremap pumvisible() ? "\Up" :
Georg Dahn wrote:
Hi!
--- "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote:
map gj
imap gj
map gk
imapgk
IMHO these mappings are a better choice:
noremap gj
noremap gk
inoremap pumvisible() ? "\Down>" : "\C-O>gj"
inoremap pumvisible() ? "\Up>" : "\C-O>gk"
These t
Hi!
--- "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote:
> map gj
> imap gj
> map gk
> imapgk
IMHO these mappings are a better choice:
noremap gj
noremap gk
inoremap pumvisible() ? "\Down>" : "\C-O>gj"
inoremap pumvisible() ? "\Up>" : "\C-O>gk"
With this the cursor k
Marcus Aurelius wrote:
[...]
If the user wants to edit long lines, (s)he cannot write a quick mapping
on-the-fly, because he needs something like this:
mapgk
imapgk
mapgj
imapgj
mapg
imapg
mapg
imapg
***May i suggest a new command (or a standard plugin that is ea
--- "A.J.Mechelynck" <[EMAIL PROTECTED]> escreveu:
> I have files where I intentionally have long lines and I use gj and gk (so
> much that I've remapped them to and ). I don't see why you gripe
> about "a bunch" of mappings: the mappings I need, or want, are in my vimrc or
> in some other scri
Marcus Aurelius wrote:
--- "A.J.Mechelynck" <[EMAIL PROTECTED]> escreveu:
This approach has already been attempted, not just once as Bram said, but at
least twice (evim and mswin.vim), and the results are far from convincing:
"easy" vim is actually harder to use, and mswin.vim makes some useful
--- "A.J.Mechelynck" <[EMAIL PROTECTED]> escreveu:
> This approach has already been attempted, not just once as Bram said, but at
> least twice (evim and mswin.vim), and the results are far from convincing:
> "easy" vim is actually harder to use, and mswin.vim makes some useful Vim
> features i
On 1/21/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
On 1/21/07, Marc Weber <[EMAIL PROTECTED]> wrote:
> My comments on nohl:
> nnoremap :nohl echo ""
> should clear message line and remove highlighting
nnoremap :silent! nohighlight
Hm, sorry, my bad, the 'echo ""' is what one wants.
n
On Sun, Jan 21, 2007 at 10:55:44PM +0100, Nikolai Weibull wrote:
> On 1/21/07, Marc Weber <[EMAIL PROTECTED]> wrote:
>
> >My comments on nohl:
> >nnoremap :nohl echo ""
> >should clear message line and remove highlighting
>
> nnoremap :silent! nohighlight
Whenever I put any of these 2 command
On 1/21/07, Marc Weber <[EMAIL PROTECTED]> wrote:
My comments on nohl:
nnoremap :nohl echo ""
should clear message line and remove highlighting
nnoremap :silent! nohighlight
?
nikolai
I didn't knew exactly where to reply
My comments on nohl:
nnoremap :nohl echo ""
should clear message line and remove highlighting
This kind of one line command is to be put into vimrc, right?
It's not worth implementing it in C code of vim?
I agree that its not a good idea to introduce yet a
John Beckett wrote:
> > Perhaps providing a file with commented-out option settings and
> > mappings.
>
> Yes. This would be relatively painless. In my wild imagination, I
> prefer a command in Vim that would edit vimrc (creating it if
> necessary), then append/edit a source command that include
Hi group,
I would like to be able to specify that the fragment of text in a
folded line be colored as it would normally appear (i.e. in it's
unfolded state).
This would make folding much more useful to me. This would
facilitate reading the contents of a properly folded file at a
glance, and perm
A.J.Mechelynck wrote:
IMHO it is important that function keys (with the exception of F1 = :help)
should by default _not_ have preset functions in Vim, in order that they
be safely available for whatever mappings any user would want to assign to
them, without competing with existing functions. T
John Beckett wrote:
Bram Moolenaar wrote:
The idea is that you can press ESC a few times without having to
check what mode you are in exactly (that can be quite difficult at
times). Typing one ESC too many is easily done, I don't like this
to have side effects.
Of course, and I wouldn't have
Bram Moolenaar wrote:
The idea is that you can press ESC a few times without having to
check what mode you are in exactly (that can be quite difficult at
times). Typing one ESC too many is easily done, I don't like this
to have side effects.
Of course, and I wouldn't have suggested that pressi
John Beckett wrote:
> Bram Moolenaar wrote:
> > No, I don't want that. Pressing ESC is to get back to Normal mode,
> > it should not have side effects like this.
>
> OK. But my suggestion was not that ESC would go to Normal mode _and_
> clear highlighting. My proposal was that if I start in Ins
A.J.Mechelynck wrote:
It took me quite some time to get around to finding out how to use the
quickfix window. I would venture that a beginning user can blissfully
ignore it and concentrate on the basic ":help " command, the
normal-mode yank, put and delete command, and on switching between Norm
John Beckett wrote:
Bram Moolenaar wrote:
No, I don't want that. Pressing ESC is to get back to Normal mode,
it should not have side effects like this.
OK. But my suggestion was not that ESC would go to Normal mode _and_
clear highlighting. My proposal was that if I start in Insert mode,
then
Bram Moolenaar wrote:
No, I don't want that. Pressing ESC is to get back to Normal mode,
it should not have side effects like this.
OK. But my suggestion was not that ESC would go to Normal mode _and_
clear highlighting. My proposal was that if I start in Insert mode,
then press ESC I would be
Ilya Bobir wrote:
If you think that you can provide a better defaults for novice users you
can just write a script that will adjust vim the way you see it and ask
Bram to add it into the distribution along with a note in the tutor
OK. Perhaps that would handle the issue. I don't care how it's
Nikolai Weibull wrote:
Well, hlsearch only kicks in /after/ you've completed your search,
whether you're using 'incsearch' or not. I once thought this was a
nice feature, but I've realized that I rarely need to have other
matches highlighted. I mean, either I've found what I want using
'incsear
Stefano Zacchiroli wrote:
On Thu, Jan 18, 2007 at 05:46:55PM +0100, A.J.Mechelynck wrote:
Vim defaults to 'compatible' mode everywhere, except where it finds a
"user" _vimrc or .vimrc (system vimrc doesn't count).
I personally recommend to create the following as $HOME/_vimrc (or
$HOME/.vimrc
Martin Stubenschrott wrote:
On Fri, Jan 19, 2007 at 07:28:51PM +1100, John Beckett wrote:
In the BOF talk, Bram really was asking for ideas on what would make
new users flock to Vim.
Biggest changes would really be defaults imho. And that should be done
without really compromising compatible m
John Beckett wrote:
[...]
Then, I could write an email to a friend saying
"Run gvim and do .
Then you can press F11 to do ".
For example, perhaps F11 = ":cn", Shift-F11 = ":cp".
[...]
This sounds very like file types. When you are opening a file
appropriate actions can be done automatically i
John Beckett wrote:
> Bram Moolenaar wrote:
> > Mostly PageUp and PageDown do the reverse of each other. If you
> > mean that the cursor has moved, that is a completely different thing.
>
> I'm not sure what "completely different thing" adds. I'm just trying
> to respond to your call for sugges
Matthew Winn wrote:
> In other products I've seen where search highlighting is always on, it
> generally takes users no more than a couple of seconds to realise that
> if the highlighting is distracting them all they have to do is enter a
> search that won't work, typically by dragging their finge
On Fri, 19 Jan 2007 23:15:57 +1100, "John Beckett"
<[EMAIL PROTECTED]> wrote:
> IMHO it is quite idiotic that Vim has the really great feature of
> globally highlighting searches, but the user has to learn how to
> map keys to make it work in a sensible way. I suppose there
> are people who don't
On Fri, Jan 19, 2007 at 01:09:41PM +0100, Martin Stubenschrott wrote:
> First and most important thing would be to enable nocompatible by
> default when the executable name is (g)vim, compatible should still be
> on, when the executable name is vi. Enabling/disabling by an (non-)existing
That's pr
On 1/19/07, John Beckett <[EMAIL PROTECTED]> wrote:
Nikolai Weibull wrote:
> Perhaps a better way is to leave 'hlsearch' off and provide a binding
> that toggles it on and off. That way you don't get the "distracting"
> highlighting until you actually request it.
OK but I imagine most people wo
A.J.Mechelynck wrote:
I sense an attitude here that it's just the luser's loss if they
don't learn how to use Vim. Fair enough, but there should be a way
for a non-vi user to enter a command telling Vim "I'm one of those
95% of people who use a modern PC - please switch to a useful mode".
"Easy
Nikolai Weibull wrote:
Perhaps a better way is to leave 'hlsearch' off and provide a binding
that toggles it on and off. That way you don't get the "distracting"
highlighting until you actually request it.
OK but I imagine most people would like hlsearch on while they
are searching (I certainl
On Fri, Jan 19, 2007 at 07:28:51PM +1100, John Beckett wrote:
> In the BOF talk, Bram really was asking for ideas on what would make
> new users flock to Vim.
Biggest changes would really be defaults imho. And that should be done
without really compromising compatible mode.
First and most importa
Bram Moolenaar wrote:
Mostly PageUp and PageDown do the reverse of each other. If you
mean that the cursor has moved, that is a completely different thing.
I'm not sure what "completely different thing" adds. I'm just trying
to respond to your call for suggestions on how to make Vim more
attra
John Beckett wrote:
A.J.Mechelynck wrote:
I personally recommend to create the following as $HOME/_vimrc
(or $HOME/.vimrc) immediately after first installation, and to
add tweaks as one gets going:
...
Good advice, as always, Tony. But I am trying to crack a different
nut.
In the BOF talk, Br
On Thu, Jan 18, 2007 at 05:46:55PM +0100, A.J.Mechelynck wrote:
> Vim defaults to 'compatible' mode everywhere, except where it finds a
> "user" _vimrc or .vimrc (system vimrc doesn't count).
>
> I personally recommend to create the following as $HOME/_vimrc (or
> $HOME/.vimrc) immediately after
On 1/19/07, John Beckett <[EMAIL PROTECTED]> wrote:
One problem was how search highlighting is persistent (which is
great), but it is very distracting to some people when you want to
turn your attention to another issue. Telling him how to map a key
to do ':nohl' is just unnecessary mumbo jumbo.
A.J.Mechelynck wrote:
I personally recommend to create the following as $HOME/_vimrc
(or $HOME/.vimrc) immediately after first installation, and to
add tweaks as one gets going:
...
Good advice, as always, Tony. But I am trying to crack a different
nut.
In the BOF talk, Bram really was asking
On 1/18/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
I do agree that good defaults are important. But backwards
compatibility is also important. It's not always easy to make a choice.
I think some things would be really sane to have on by default, such
as :syntax on, but at the same time it
John Beckett wrote:
> Sorry I'm late, but I just listened to the Vim BOF session that Bram
> mentioned three months ago.
>
> In the talk, Bram sounded quite evangelical with regard to promoting
> Vim usage, and he asked for suggestions on how he should best spend
> his limited time in working to
Hi John Beckett, you wrote:
>
> The best way to expand Vim usage IMHO would be to work out better
> default settings to improve the first hour of contact. In addition,
> perform necessary fixups, but resist new features.
>
I also think that Vim is feature-enough. What affects me most of all eve
Mikołaj Machowski wrote:
I won't say more now. If Bram feels that improved defaults would be
worth investigating, a discussion here would probably be best.
OTOH people who dream in Vim script may not be the best source of
ideas on how Vim should be configured to win new converts.
I suppose this
> 1. Persistence of search highlighting is IMO good thing.
Forgot to explain why: newbies often are pressing Esc just in case of ... . So
this key shouldn't do by default anything more than changing of mode.
m.
Adaptacja bestsellerowej powieśc
> I won't say more now. If Bram feels that improved defaults would be
> worth investigating, a discussion here would probably be best.
> OTOH people who dream in Vim script may not be the best source of
> ideas on how Vim should be configured to win new converts.
I suppose this apply for me also
Sorry I'm late, but I just listened to the Vim BOF session that Bram
mentioned three months ago.
In the talk, Bram sounded quite evangelical with regard to promoting
Vim usage, and he asked for suggestions on how he should best spend
his limited time in working towards a new version ("Vim 8").
I
47 matches
Mail list logo
