Re: BOF Vim 8 - Suggestions

2007-01-29 Thread Alexei Alexandrov
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
 give a hungry person food, teach him how to grow food.
 

Sort of OT but still: before teaching it's better to give them some food - 
otherwise they will die before they even learn anything...

-- 
Alexei Alexandrov


Re: BOF Vim 8 - Suggestions

2007-01-26 Thread A.J.Mechelynck

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:

map buffer silent up gk
imap buffer silent up C-ogk
map buffer silent down gj
imap buffer silent down C-ogj
map buffer silent home ghome
imap buffer silent home C-oghome
map buffer silent end gend
imap buffer silent end C-ogend

***May i suggest a new command (or a standard plugin that is easy to find) that
would do all of the above in one easy step?***



Optionally, the user could want this too:

setlocal linebreak
setlocal nolist  Necessary for linebreak
setlocal display+=lastline

I'm not sure if it's OK or if it's going too far :-)

[...]
The following (among others) are set once and for all in my vimrc:

set nojoinspaces
set selection=inclusive keymodel=startsel
set mousemodel=popup selectmode=mouse,key
set laststatus=2
set display=lastline
set list listchars=tab:\|_,eol:¶
silent! set listchars+=nbsp:~
 Up, Down  move up/down by screen lines
 j k   (default) move down/up by file lines
map Down  gj
imapDown  C-Ogj
map Upgk
imapUpC-Ogk

No problem for me, and no need to change them from file to file.


Best regards,
Tony.


Re: BOF Vim 8 - Suggestions

2007-01-26 Thread A.J.Mechelynck

Georg Dahn wrote:

Hi!

--- A.J.Mechelynck [EMAIL PROTECTED] wrote:

map Down  gj
imapDown  C-Ogj
map Upgk
imapUpC-Ogk


IMHO these mappings are a better choice:

noremap Down gj
noremap Up gk
inoremap expr Down pumvisible() ? \ltDown : \ltC-Ogj
inoremap expr Up pumvisible() ? \ltUp : \ltC-Ogk


These two are V7 only, so:

if exists(*pumvisible)
inoremap expr Down pumvisible() ? \ltDown : \ltC-Ogj
inoremap expr Up   pumvisible() ? \ltUp   : \ltC-Ogj
else
inoremap Down C-Ogj
inoremap Up   C-Ogk
endif



With this the cursor keys still work with the popup menu.

In addition I define the following mappings:

noremap S-Down gj
noremap S-Up gk
inoremap S-Down C-OghC-Ogj
inoremap S-Up C-OghC-Ogk
nnoremap S-Down ghC-Ogj
nnoremap S-Up ghC-Ogk

With these mappings invoking the selection mode works more consistently with
above mappings.


No problem for me, and no need to change them from file to file.


I fully agree with this.

Best wishes,
Georg



Best regards,
Tony.


Re: BOF Vim 8 - Suggestions

2007-01-26 Thread Marcus Aurelius

--- 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 expr Down pumvisible() ? \ltDown : \ltC-Ogj
   inoremap expr Up   pumvisible() ? \ltUp   : \ltC-Ogj
 else
   inoremap Down C-Ogj
   inoremap Up   C-Ogk
 endif
 
(...)
  noremap S-Down gj
  noremap S-Up gk
  inoremap S-Down C-OghC-Ogj
  inoremap S-Up C-OghC-Ogk
  nnoremap S-Down ghC-Ogj
  nnoremap S-Up ghC-Ogk
  
  With these mappings invoking the selection mode works more consistently
 with
  above mappings.


This is getting complicated... That's why i suggested a single command that
unified all of this, and would not conflict with pop-up menus or anything.

__
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 


Re: BOF Vim 8 - Suggestions

2007-01-25 Thread A.J.Mechelynck

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 Vim 
features inacessible, and for others, forces constant reminders everywhere in


the help and in support mailing lists: If you use Ctrl-V to paste, use
Ctrl-Q 
instead whenever the help says to use Ctrl-V.


Cream for Vim may be a third attempt but I'm not sure, I haven't looked
into it.


I think i must defend mswin.vim here (and :behave mswin) ;-)
Some shortcuts are really invaluable:
Ctrl+S (save, compare to :w; i use Ctrl+S a lot!), Ctrl+Tab (next window,
compare to Ctrl+W, W), Ctrl+Z (undo... i'm so used to Ctrl+Z...), 


Others, such as Ctrl+A (select all) and Ctrl+V (paste) do conflict with other
commands, but compare them to ggVG and +p

Sometimes i miss Ctrl+Backspace (for delete word backward) and Ctrl+Delete
(delete word forward).

My main gripe about Vim commands is that gj and gk are almost unusable without
a bunch of mappings, and formatting a paragraph takes 4 keys (gwip - i hav
mapped it to F12). Well, if you format the paragraph you don't need gj and gk,
but you get the idea... ;-)

I do like Vim commands, but the commands Ctrl+{A,Z,X,C,V,Y,Tab} are so widely
available that i'm used to use them in Vim too.


Marcus


- I use Ctrl-A (increment number) a lot. i_CTRL-A (repeat insert) I don't but 
it exists. For Select all I do use ggVG (or GVgg or VG if I'm at top or Vgg if 
I'm at bottom) which isn't hard to remember because I also use gg V and G a 
lot separately.

- CTRL-S apparently isn't mapped in Vim. For save I've mapped F3 as follows:

:map F3 :wa|wvCR
:imap F3 C-O:wa|wvCR

In other programs I don't use Ctrl-S but File = Save using the mouse. I don't 
use that much though, because I use Vim exclusively for all editing tasks.
- CTRL-Z (both Normal and Insert) is suspend, I use :sus . For undo I use u 
which is even easier than Ctrl-Z (u-for-undo, and no modifier key).
- I use Ctrl-X (decrement number) a lot; i_CTRL-X starts Insert completion of 
various kinds, including i_CTRL-X_CTRL-O (omnicompletion) which I'm still 
learning to use; but it's useful enough that I've set up syntax completion 
using the distributed autoload/syntaxcomplete.vim and a custom script (copied 
from :help ft-syntax-omni) in .vim/after/plugin/.
- Ctrl-C is Stop; I don't know where is Ctrl-Break. i_CTRL-C is leave Insert 
mode, I use Esc. For copy-to-clipboard I use +y and :y + -- see below. (For 
copy all to clipboard I use :%y + which is one command, rather than Ctrl-A 
Ctrl-C which is two commands.) In Dos/Windows, Ctrl-C existed as stop in Dos 
long before Windows invented to use it for Copy -- and I'm an old Dos hand, so 
Ctrl-C = stop is no less familiar to me than Ctrl-C = copy.
- Ctrl-V is start Block visual; i_CTRL-V is Literalize; I use them both. 
Having to mention Ctrl-Q  on the list because I don't know whether the other 
guy is or isn't using mswin.vim is a hassle; and if I don't, there are too 
many newbies who don't realize that the true Vim function of Ctrl-V is 
hidden from them. I do use +p +P and :put +, and I've also mapped F4 to 
:$put + to paste linewise at end-of-file. I also use +y and :y + as well as 
+d and :d + but when pasting within Vim I don't use the clipboard at all: I 
use the unnamed register instead, or named registers for repeated pastes.
- Ctrl-Y is Scroll, i_CTRL-Y is Insert character above cursor. I don't use 
them much but they're there. For redo I use Ctrl-R which isn't harder to type 
than Ctrl-Y -- and easier to remember since R is the first letter of Redo.
- I'm not sure what Ctrl-Tab means in native Vim, if anything, but I can't 
use that keychord because my kde window manager preempts it (select virtual 
desktop) and it never gets to Vim. Anyway, to move to next window I know 
about Ctrl-W w. I even use that so much that I've mapped F11 to ^Ww (next or 
nth window) and Shift-F11 to ^WW (previous or nth window).
- Ctrl-BS and Ctrl-Del I didn't know about; in Vim, Ctrl-BS is mentioned in 
the help; it extends a Visual area to the left margin; Ctrl-Del is, according 
to the help, cut Visual area; on my Linux system it does cut but not to 
clipboard. You can remap them to anything if you like. To delete words, I use 
diw (delete inner word) and daw (delete a word) which are both useful and 
intuitive.


I have files where I intentionally have long lines and I use gj and gk (so 
much that I've remapped them to Up and Down). 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 script, and they are part of my Vim settings -- they don't 
count as a bunch, since I don't have to do them over every time Vim starts.


Summary: I still think that mswin.vim is a PITA and that whoever needs quick 
mappings 

Re: BOF Vim 8 - Suggestions

2007-01-25 Thread Marcus Aurelius
--- 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 Up and Down). 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 script, and they are part of my Vim settings -- they don't 
 count as a bunch, since I don't have to do them over every time Vim starts.



To edit long lines, i have a script that does the work. But i don't use it all
the time, so i havent put it in vimrc.

Vim already has a few options that are responsible for setting other options,
such as 'binary' and :behave. Maybe it could have more of this kind of settings
(something like this has been suggested earlier in this thread, but i guess the
comparison with 'binary' and :behave had not been made yet).

If the user wants to edit long lines, (s)he cannot write a quick mapping
on-the-fly, because he needs something like this:

map buffer silent up gk
imap buffer silent up C-ogk
map buffer silent down gj
imap buffer silent down C-ogj
map buffer silent home ghome
imap buffer silent home C-oghome
map buffer silent end gend
imap buffer silent end C-ogend

***May i suggest a new command (or a standard plugin that is easy to find) that
would do all of the above in one easy step?***



Optionally, the user could want this too:

setlocal linebreak
setlocal nolist  Necessary for linebreak
setlocal display+=lastline

I'm not sure if it's OK or if it's going too far :-)




I use these mappings too:

imap F12 C-ogwip
nmap F12 gwip
vmap F12 gw

But I agree that they are just personal preference and would not integrate
seamlessly with the Vim command structure.

BTW, I also miss Ctrl+A (increment number) in Windows mode and Ctrl+Q is a
weird alternative for Ctrl+V, but i can live with that ;-_). However, the
Ctrl+X functionality is not lost, since cut only works if there is something 
selected.

__
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 


Re: BOF Vim 8 - Suggestions

2007-01-24 Thread Marcus Aurelius

--- 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 inacessible, and for others, forces constant reminders everywhere in
 
 the help and in support mailing lists: If you use Ctrl-V to paste, use
 Ctrl-Q 
 instead whenever the help says to use Ctrl-V.
 
 Cream for Vim may be a third attempt but I'm not sure, I haven't looked
 into it.

I think i must defend mswin.vim here (and :behave mswin) ;-)
Some shortcuts are really invaluable:
Ctrl+S (save, compare to :w; i use Ctrl+S a lot!), Ctrl+Tab (next window,
compare to Ctrl+W, W), Ctrl+Z (undo... i'm so used to Ctrl+Z...), 

Others, such as Ctrl+A (select all) and Ctrl+V (paste) do conflict with other
commands, but compare them to ggVG and +p

Sometimes i miss Ctrl+Backspace (for delete word backward) and Ctrl+Delete
(delete word forward).

My main gripe about Vim commands is that gj and gk are almost unusable without
a bunch of mappings, and formatting a paragraph takes 4 keys (gwip - i hav
mapped it to F12). Well, if you format the paragraph you don't need gj and gk,
but you get the idea... ;-)

I do like Vim commands, but the commands Ctrl+{A,Z,X,C,V,Y,Tab} are so widely
available that i'm used to use them in Vim too.


Marcus

__
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 


Re: BOF Vim 8 - Suggestions

2007-01-21 Thread John Beckett

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. There aren't so many keys 
that users can safely use as the {lhs} of a mapping with no fear that it 
will collide with an existing function.


For the record, I don't want function keys to be mapped by default. I am
suggesting that there should be a really simple (preferably built-in) way to
invoke a sample set of mappings for a C programmer.

For example, I could then send someone an email telling them to download
Vim and enter command :set template=cprogram (or whatever). I could
then advise the new user (a C programmer, not a dummy) that they can do
(whatever) to grep stuff, and (whatever) to use ctags. You would then have
one more converted Vim user!

As a final comment, I would recommend that any such template should
include mappings:
- Clear search highlights and the message line.
- Search for highlighted text.

John



Re: BOF Vim 8 - Suggestions

2007-01-21 Thread SM Smithfield

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 permit demure colors for the rest of the fold to keep
it out of the way.

Beyond that I would like to be able to have be able to specify the
length of the text fragment.

Beyond that I would like to see the format of the folded line
exposed in a fashion similar to the status line.



Mark.



Re: BOF Vim 8 - Suggestions

2007-01-21 Thread Martin Stubenschrott
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 esc :nohl bar echo cr
 should clear message line and remove highlighting
 
 nnoremap Esc Esc:silent! nohighlightCR

Whenever I put any of these 2 commands in my .vimrc, vim beeps on
startup, and when I press 'k' it deletes the current and above line.

--
Martin


Re: BOF Vim 8 - Suggestions

2007-01-21 Thread Nikolai Weibull

On 1/21/07, Nikolai Weibull [EMAIL PROTECTED] wrote:

On 1/21/07, Marc Weber [EMAIL PROTECTED] wrote:

 My comments on nohl:
 nnoremap esc :nohl bar echo cr
 should clear message line and remove highlighting

nnoremap Esc Esc:silent! nohighlightCR


Hm, sorry, my bad, the 'echo CR' is what one wants.

 nikolai


Re: BOF Vim 8 - Suggestions

2007-01-20 Thread Bram Moolenaar

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 press ESC I would be in Normal mode (as normal :), but if I
 press ESC again then highlighting and message text would be cleared.

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.

 I'm happy so long as you've heard my idea. A couple of people here
 seem to think that _I_ want these suggestions. Not at all. I'm
 fluent in Vim and don't need any of my proposals for myself. But my
 recent experience of trying to make Vim attractive to a programmer
 moving into Linux showed me that some simple changes to Vim might
 make it a lot more attractive to new users.

  You appear to assume that what you want is what everybody wants.
 
 No! For posterity let me record that I am not one of those people.
 I'm only making these suggestions because I know you want to
 promote Vim usage, and some way to easily invoke a
 pre-defined set of behaviour for a modern PC would help IMHO.

It's a bit dangerous to assume that someone else wants something.  Do
you know about the Abeline paradox?

I don't think you can define modern PC without getting into a lot of
discissions.  Unless you mean MS-Windows XP PC with notepad, that
would be clearer.

  Imagine how many exceptions we need to handle in the
  documentation: if you use theme X then this doesn't work
  and you need to type XYZ.
 
 I take your point and agree. But I will make one final suggestion:
 Do not hide how Vim works. Tell users about vimrc, and what a
 mapping is, etc. People who would use Vim are smart, and can
 instantly understand that there is a config file, and that keys can
 be mapped. But a new user will probably not want to take the time to
 work out the details and their optimum settings right now.

Perhaps providing a file with commented-out option settings and
mappings.  With comments and/or links to the help to explain what they
do.  The :options window still requires adding lines to a script file.
And it doesn't support mappings.

 Take the wonderful quickfix window (which I use mainly for vimgrep).
 Using quickfix with ':copen' etc just doesn't work for me. I don't
 mind typing a few commands, but in this situation, the commands
 interfere too much with my thoughts. Once I mapped keys for :copen,
 :cn and :cp, quickfix was a magnificent feature.

That's just because you happen to need this, and pick the one feature
out of the thousands available and map it to a key.  If you would want
to do this for all the features you find out that your key combinations
get too complicated.  It's essential that you do this mapping yourself.

 My vague concept about a theme is that it would insert text into
 vimrc. The user would be told this, and they could modify the text
 to taste. Right now, it is pretty easy to get BufExplorer working,
 and then \be is the default key sequence to start it. That's like
 what I am proposing for other killer features of Vim.

If you are not willing to type :copen but typing \co does then I'm 
completely confused.

  You can always tell someone to download your script and use it.
 
 There are too many tips and scripts already. I was hoping (*not* for
 me!) to integrate some of the best work procedures into one or two
 pre-defined behaviours.

Everybody has a different set of features that he needs.

-- 
A fine is a tax for doing wrong.  A tax is a fine for doing well.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///


Re: BOF Vim 8 - Suggestions

2007-01-20 Thread A.J.Mechelynck

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 suggested that pressing ESC should
clear search highlights if that action weren't harmless.

However, all I really wanted was to have my 'humble opinion' heard,
and you've been patient spelling out the problems - thanks.


I'm only making these suggestions because I know you want to
promote Vim usage, and some way to easily invoke a
pre-defined set of behaviour for a modern PC would help IMHO.


It's a bit dangerous to assume that someone else wants something.
Do you know about the Abeline paradox?


In the downloaded BOF, you said What would be the killer feature
for Vim 8 ...[so] a lot more people will start using Vim?. I
agree that words can be dangerous, but surely it's reasonable to
conclude from the BOF that you want to promote Vim usage?

I know you had a killer feature in mind. I'm putting the contrary
view that work should instead go into making the existing features
more accessible.


I don't think you can define modern PC without getting into a
lot of discissions.  Unless you mean MS-Windows XP PC with
notepad, that would be clearer.


Making Vim work on its extraordinary range of platforms is a
magnificent achievement, and I'm not suggesting that Vim should be
configured in a way that interferes with that.

By modern PC I mean any system from the last few years, running
Linux or MS-Windows or whatever (not a terminal). IMHO some built-in
samples making use of function keys would help promote Vim. The Vim
Tips website is not useful for someone who just wants to evaluate
whether Vim would help them in their next programming project. It
would require a very dedicated new user to select one of the
competing tips, then figure out how to install and use it.


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. There aren't so many keys that 
users can safely use as the {lhs} of a mapping with no fear that it will 
collide with an existing function.





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 includes a
standard script distributed with Vim.


Take the wonderful quickfix window (which I use mainly for vimgrep)


That's just because you happen to need this, and pick the one
feature out of the thousands available and map it to a key.


Yes - I am being prescriptive. There should be a do it this way
built-in script with a carefully planned set of mappings for a
programmer. That would include mapping common quickfix and tags
operations to function keys.

Also include another set of mappings for a poet, or whatever. But
IMHO it is a shame that a C programmer might try Vim but not have
the time or patience to see how well grep and ctags can be
integrated into an editor.


Everybody has a different set of features that he needs.


Yes. So how about providing a built-in template just for C
programmers (and maybe a couple of other categories, if they can
readily be identified). If a C programmer tried Vim for an hour,
wouldn't you want them to see grep and ctags? A new user won't be
convinced by the statement just type ':cn' for the next hit, and
BTW you can map it to a key if you want to take another hour.

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.

John




I'm not convinced. Vim users are such a medley lot that what is well-planned 
for some might quite well be not only be ill-planned but even a PITA for others.



Best regards,
Tony.


Re: BOF Vim 8 - Suggestions

2007-01-19 Thread Nikolai Weibull

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's a whole hell of a lot easier
to change the defaults by providing a .vimrc that gets sourced if the
user doesn't have a .vimrc than change the defaults in the source (as
that affects everyone).

 nikolai


Re: BOF Vim 8 - Suggestions

2007-01-19 Thread John Beckett

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
attractive to new users. I know a couple of people who don't like
the fact that, in Vim, PageUp does not reverse PageDown.
Naturally I am talking about the cursor moving.


Switching off search highlighting is part of the tutor.  People who
skip the vimtutor are going to run into trouble anyway.


OK - but you could make Vim more attractive if (when enabled
by some new option) pressing Escape in Normal mode cleared
search highlights and cleared the message line.


I do agree that good defaults are important.  But backwards
compatibility is also important.  It's not always easy to make
a choice.


Suggestion: Provide a simple way for a user to invoke a
standard set of predefined mappings. In fact, there could
be various predefined themes that insert useful settings
into vimrc.

Then, I could write an email to a friend saying
Run gvim and do stuff to select a theme.
Then you can press F11 to do clever thing.
For example, perhaps F11 = :cn, Shift-F11 = :cp.

Naturally there would be a lot of different opinion on what
should be included. Anything would be better than the current
situation where I have to convince a prospective new user
to become a guru before they can use some of Vim's
brilliant features.

John



Re: BOF Vim 8 - Suggestions

2007-01-19 Thread Bram Moolenaar

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 suggestions on how to make Vim more
 attractive to new users. I know a couple of people who don't like
 the fact that, in Vim, PageUp does not reverse PageDown.
 Naturally I am talking about the cursor moving.

The completely different thing is that this is not about scrolling but
about moving the cursor so that it's in the visible text.  I know this
is different from most other editors and requires a bit of time getting
used to.  And it's something that will change the feeling of how the
editor works, thus it's unlikely to change.  I thought about this a few
times, but still don't know a solution that won't cause trouble for
people who are used to the vi behavior.  And no, an option is not
really an option.

  Switching off search highlighting is part of the tutor.  People who
  skip the vimtutor are going to run into trouble anyway.
 
 OK - but you could make Vim more attractive if (when enabled
 by some new option) pressing Escape in Normal mode cleared
 search highlights and cleared the message line.

No, I don't want that.  Pressing ESC is to get back to Normal mode, it
should not have side effects like this.  It's always bad when one key
does two or more things.  If you only want one of them you have a
problem.

You appear to assume that what you want is what everybody wants.  Many
users think that way.  But that is not so.  It's very hard to figure out
what works right for most people and doesn't work bad for some people.

  I do agree that good defaults are important.  But backwards
  compatibility is also important.  It's not always easy to make
  a choice.
 
 Suggestion: Provide a simple way for a user to invoke a
 standard set of predefined mappings. In fact, there could
 be various predefined themes that insert useful settings
 into vimrc.

It's better to have the user get used to the existing commands.  There
is one theme for MS-Windows users, and it's already causing quite a
bit of confusion.  I don't think we want more of that.  Imagine how may
exceptions we need to handle in the documentation: if you use theme X
then this doesn't work and you need to type XYZ.

 Then, I could write an email to a friend saying
 Run gvim and do stuff to select a theme.
 Then you can press F11 to do clever thing.
 For example, perhaps F11 = :cn, Shift-F11 = :cp.

You can always tell someone to download your script and use it.  That's
quite simple, you only need to drop it in a specific directory.

 Naturally there would be a lot of different opinion on what
 should be included. Anything would be better than the current
 situation where I have to convince a prospective new user
 to become a guru before they can use some of Vim's
 brilliant features.

No matter under what key you put something, you still need to know what
key it is.

-- 
Portable Computer:  A device invented to force businessmen
to work at home, on vacation, and on business trips.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///


Re: BOF Vim 8 - Suggestions

2007-01-19 Thread Ilya Bobir

John Beckett wrote:

[...]

Then, I could write an email to a friend saying
Run gvim and do stuff to select a theme.
Then you can press F11 to do clever thing.
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 in order to adjust vim or 
you can do it yourself.  So your do stuff to select a theme is 
spelled in vim like :set ft=file type.  If you are writing an e-mail 
and you have vim set as your e-mail text editor it is possible that vim 
will detect you are writing an e-mail and will automatically adjust 
itself for e-mail editing.  You may also add additional file types by 
downloading them from vim.org or somewhere else...


So, most part of a file type specific settings should reside in a file 
type script.  And if you have some general preferences them you should 
add them to your .vimrc.  If a preference is file type specific you can 
add a FileType event to your .vimrc.  I see no point in adding 
themes.  As for me, everything that can be done using themes can 
already be done using things that already exists in vim.


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, 
like If you feel that vim is too difficult to master you may try 
another set of defaults specially crafted for novice users.  In order to 
turn them on just add the following line to your .vimrc: here goes 
command to source your script.


Re: BOF Vim 8 - Suggestions

2007-01-19 Thread John Beckett

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 done,
my aim is just to make the suggestion that to popularise Vim, it would
be helpful to provide easily-accessible and well-thought-out defaults
for some of Vim's more clever features.

John



Re: BOF Vim 8 - Suggestions

2007-01-19 Thread John Beckett

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 in Normal mode (as normal :), but if I
press ESC again then highlighting and message text would be cleared.

I'm happy so long as you've heard my idea. A couple of people here
seem to think that _I_ want these suggestions. Not at all. I'm
fluent in Vim and don't need any of my proposals for myself. But my
recent experience of trying to make Vim attractive to a programmer
moving into Linux showed me that some simple changes to Vim might
make it a lot more attractive to new users.


You appear to assume that what you want is what everybody wants.


No! For posterity let me record that I am not one of those people.
I'm only making these suggestions because I know you want to
promote Vim usage, and some way to easily invoke a
pre-defined set of behaviour for a modern PC would help IMHO.


Imagine how many exceptions we need to handle in the
documentation: if you use theme X then this doesn't work
and you need to type XYZ.


I take your point and agree. But I will make one final suggestion:
Do not hide how Vim works. Tell users about vimrc, and what a
mapping is, etc. People who would use Vim are smart, and can
instantly understand that there is a config file, and that keys can
be mapped. But a new user will probably not want to take the time to
work out the details and their optimum settings right now.

Take the wonderful quickfix window (which I use mainly for vimgrep).
Using quickfix with ':copen' etc just doesn't work for me. I don't
mind typing a few commands, but in this situation, the commands
interfere too much with my thoughts. Once I mapped keys for :copen,
:cn and :cp, quickfix was a magnificent feature.

My vague concept about a theme is that it would insert text into
vimrc. The user would be told this, and they could modify the text
to taste. Right now, it is pretty easy to get BufExplorer working,
and then \be is the default key sequence to start it. That's like
what I am proposing for other killer features of Vim.


You can always tell someone to download your script and use it.


There are too many tips and scripts already. I was hoping (*not* for
me!) to integrate some of the best work procedures into one or two
pre-defined behaviours.

John



Re: BOF Vim 8 - Suggestions

2007-01-19 Thread A.J.Mechelynck

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 press ESC I would be in Normal mode (as normal :), but if I
press ESC again then highlighting and message text would be cleared.

I'm happy so long as you've heard my idea. A couple of people here
seem to think that _I_ want these suggestions. Not at all. I'm
fluent in Vim and don't need any of my proposals for myself. But my
recent experience of trying to make Vim attractive to a programmer
moving into Linux showed me that some simple changes to Vim might
make it a lot more attractive to new users.


You appear to assume that what you want is what everybody wants.


No! For posterity let me record that I am not one of those people.
I'm only making these suggestions because I know you want to
promote Vim usage, and some way to easily invoke a
pre-defined set of behaviour for a modern PC would help IMHO.


Imagine how many exceptions we need to handle in the
documentation: if you use theme X then this doesn't work
and you need to type XYZ.


I take your point and agree. But I will make one final suggestion:
Do not hide how Vim works. Tell users about vimrc, and what a
mapping is, etc. People who would use Vim are smart, and can
instantly understand that there is a config file, and that keys can
be mapped. But a new user will probably not want to take the time to
work out the details and their optimum settings right now.

Take the wonderful quickfix window (which I use mainly for vimgrep).
Using quickfix with ':copen' etc just doesn't work for me. I don't
mind typing a few commands, but in this situation, the commands
interfere too much with my thoughts. Once I mapped keys for :copen,
:cn and :cp, quickfix was a magnificent feature.


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 keyword command, the normal-mode 
yank, put and delete command, and on switching between Normal, Insert and 
maybe Replace modes. Then Visual. Then 'wildmode', 'wildmenu' and filename / 
helptag completion. Once the usefulness of :helpgrep reaches consciousness, 
then it's time to read quickfix.txt more attentively. My solution is just


:map F2 :cnCR
:map S-F2 :cNCR

but what is best for me is not necessarily best for the next guy.



My vague concept about a theme is that it would insert text into
vimrc. The user would be told this, and they could modify the text
to taste. Right now, it is pretty easy to get BufExplorer working,
and then \be is the default key sequence to start it. That's like
what I am proposing for other killer features of Vim.


Rather than insert text into vimrc, source the script from the vimrc. The 
result is the same, but it's much easier to implement -- and to undo if, six 
months or two years later, you decide it's not so great after all.





You can always tell someone to download your script and use it.


There are too many tips and scripts already. I was hoping (*not* for
me!) to integrate some of the best work procedures into one or two
pre-defined behaviours.

John




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 inacessible, and for others, forces constant reminders everywhere in 
the help and in support mailing lists: If you use Ctrl-V to paste, use Ctrl-Q 
instead whenever the help says to use Ctrl-V.


Cream for Vim may be a third attempt but I'm not sure, I haven't looked into 
it.


Best regards,
Tony.


Re: BOF Vim 8 - Suggestions

2007-01-18 Thread Mikołaj Machowski
 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ści Patricka Süskinda 
Pachnidło, Historia Mordercy już w kinach - Naprawdę warto zobaczyć!
http://klik.wp.pl/?adr=www.pachnidlo.wp.plsid=982




Re: BOF Vim 8 - Suggestions

2007-01-18 Thread Alexei Alexandrov
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 every day 
is Vim performance. Especially on Windows. Startup is slower than it should be 
and redraw of the screen is also rather slow - and almost unusable with TTF 
fonts with Antialiasing on. 

If would need to choose _one_ thing I'd like to have in Vim improved I'd choose 
performance...

-- 
Alexei Alexandrov


Re: BOF Vim 8 - Suggestions

2007-01-18 Thread Bram Moolenaar

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 towards a new version (Vim 8).
 
 I am posting this introductory message with my response, plus a
 second message describing a feature I would like (EncryptLine).
 
 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.
 
 If I were starting Vim usage now, I would probably abandon it as
 soon as I discovered that pressing PageUp did NOT reverse the effect
 of PageDown. I still hate that! Vim has many wonderous features, but
 I imagine that many people don't stay to find them because of
 irritations like PgUp/PgDn.

Mostly PageUp and PageDown do the reverse of each other.  If you mean
that the cursor has moved, that is a completely different thing.

 Highlighting all matches when searching is excellent, but there
 needs to be a way for a new user to turn it off. I map Space for
 this, however, it would be better to press Escape to clear
 highlights and message text (if Escape is pressed while in Normal
 mode, remove search highlights and clear any message). Maybe also
 have a way for this feature to be turned off.

This feature is off by default.  Only when you run Vim in non-compatible
mode it's on.

Switching off search highlighting is part of the tutor.  People who skip
the vimtutor are going to run into trouble anyway.

 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 do agree that good defaults are important.  But backwards
compatibility is also important.  It's not always easy to make a choice.

-- 
Everyone has a photographic memory. Some don't have film.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///