ANN: W32 executables for 6.3 and 7.0

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

ANN: W32 executables for 6.3 and 7.0

A.J.Mechelynck
Hello Vimmers!

----- Original Message -----
From: "Bram Moolenaar" <[hidden email]>
To: <[hidden email]>
Sent: Sunday, July 24, 2005 7:50 PM
Subject: Patch 6.3.085


>
> Patch 6.3.085
> Problem:    Crash in syntax highlighting code. (Marc Espie)
> Solution:   Prevent current_col going past the end of the line.
> Files:     src/syntax.c
[...]

The corresponding executables for W32 are now available.

For 7.0, Bram has sent the files which were missing from yesterday's
nightly, and a 7.00aa.0114 distribution is now available; but I see that a
new snapshot (0115) has been posted and I'm starting a new build roll; the
results should appear in an hour or so if there is no problem.

See http://users.skynet.be/antoine.mechelynck/vim/
- Check the "last change" date at the top of the page
- Click 'My "changes" distro' for 6.3 and/or 'The experimental Vim 7' for
7.00aa
- IMPORTANT: Read the text before downloading.

Happy Vimming!
Tony.


Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

Bruce Who
Hi, Tony:

        I downloaded and tried vim7.0aa the day before yesterday, and was a little disappointed. I know it's far too late to speak of this topic now, and what I can do now is just to hope next version of vim can be improved.

gvim7.00aa impression
=====================

        balloon_expr is improved, but I still don't know how to use it. I write a script

" a.vim
function! MyBalloonExpr()
  return 'Cursor is at line ' . v:beval_lnum .
  \', column ' . v:beval_col .
  \ ' of file ' .  bufname(v:beval_bufnr) .
  \ ' on word "' . v:beval_text . '"'
endfunction
set bexpr=MyBalloonExpr()
set ballooneval

and then source this file and edit another file, but nothing happen.

    when I open gvim7.00aa, the first empty buffer's name is [No name], it's not translated into my local language as usual. Is this a bug? I just unzip the file to my vim directory instead of overwriting the vim63 directory.


No modern GUI elements
======================

    When I opened the gvim7.0aa, wow, it still looked like the gvim6.3, the same GUI! Yes, I mean *g*Vim not vim. gVim still doesn't look like any other text editors(I think it's unnecessary to refer to 'other text editors' here):

    1) No tabs which list your open buffers along the top or bottom of your screen. Let's call it buf_tabs.

    I know minibufexpl.vim and I'm using it. It simulate the buf_tabs, but not well. we may

      - close the minibuf by <C-W>q accidently
      - when we use :bn and :bp to go through the buffers we also enter the minibuf which is not expected.
      - when we save or modify the current buffer, minibuf is not updated immediately. Only when we swith to another buffer, the '+' mark is added or removed from the buffer's name in the minibuf.
      - if we saved a session one minutes ago, and we open it now, then there is always a warning about minibuf. And after all buffers are loaded, the minibuf is empty.

    In my humble opinion, all these issues are hard to solve just by vim script.

    2)no file explorer window

    we also have filexplorer.vim and I'm using it too. It's not as good as a built-in file explorer if any:

        - I just need this window after gvim is open and keep this window always at the left side of my editor and can hide it when I need. But, yes, I usually close it accidently, :-< . Everytime I open a file by <Enter>, the filexplorer window disaapears and I need open it again! This situation usually happens when I open vim, I need to open several files of a project then.
      - when we use :bn and :bp to go through the buffers we also enter the bufexplorer which is not expected.


    I think these two features are basic elements of modern text editor, and they can help newbies a lot. Why not implement them for gVim?


IDE or text editor?
===================

    I don't know exactly what vim will become, but now it is just a powerful text editor but an IDE. Some of my mates don't use vim because IDEs provide them the convenience of program developing. IDEs' text editor are so weak, but they provide call-tips/debugger/project management,... while vim doesn't.

    As a python programmer, I can only edit .py files with vim. Intellisense doesn't support python, I have used pydiction for about ten minutes and dropped it because it changes isk option. Another pain is that I cannot debug python files within vim itself. Everytime I debug python scripts, I have to open pythonwin and debug it there.

    IMHO, it's the tendency that text editor should become more and more like IDE. the new fad eclipse is something like this. And lately I learn that another popular text-editor UltraEditor is gonna become a IDE called UEeditor, and it seems very close to my ideal texteditor, here are some screenshots:

http://www.ultraedit.com/index.php?name=coppermine&file=thumbnails&album=13

    class hierachy viewer/tag viewer/project management/template management, .... It astounded me when I knew it. Yes,yes, we have plugin scripts which can do the same thing: taglist.vim, project.tgz, but they can never be used as easily as bulit-in ones.


program language or texteditor?
===============================
    vim scripts becomes much more powerful than ever before. We have list now, so we can kick liblist.vim away. It seems you guys are more interested in developing a powerful programming language than a texteditor. There are some simple things that vim doesn't support, for example, I cannot use vim to convert my file's encoding. I always have to use notepad to convert my mbcs encoded files to utf-8.


Anyway, I'm gonna continue using vim as my texteditor and hope it can be improved in the future. This post may be so long that I should post it in my blog or somewhere.

======= 2005-07-25 06:21:52 Tony Mechelynck wrote: =======

>Hello Vimmers!
>
[...]

= = = = = = = = = = = = = = = = = = = =
                       
Best regards,

????????????????Bruce Who
????????????????????2005-07-26

Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

Mathias Michaelis
Hello Bruce

> I always have to use notepad to convert my mbcs encoded files to
> utf-8.
>
Why that? Here is what I do to convert the actual buffer from latin1
to utf-8:

:w
:set encoding=utf-8
:e ++enc=latin1
:set fileencoding=utf-8
:set bomb
:w

HTH
Mathias
Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

Bram Moolenaar
In reply to this post by Bruce Who

Bruce Who wrote:

> Hi, Tony:

Strange to send this to Tony.  He does a lot of things but developing
Vim isn't one of them.

> I downloaded and tried vim7.0aa the day before yesterday, and was a
> little disappointed. I know it's far too late to speak of this topic
> now, and what I can do now is just to hope next version of vim can be
> improved.

From your text it shows you don't understand Vim very well.  I would
suggest to read the help text about the things you want to use Vim for.
Most obvious example where this applies:

> balloon_expr is improved, but I still don't know how to use it.

I use it every day and it works just fine.

> when I open gvim7.00aa, the first empty buffer's name is [No name],
> it's not translated into my local language as usual. Is this a bug? I
> just unzip the file to my vim directory instead of overwriting the
> vim63 directory.

You probably need to install the message translation files in the right
place.

> No modern GUI elements

While other editors concentrate on improving the looks, the work on Vim
aims at people who want to get work done.

> 1) No tabs which list your open buffers along the top or bottom of
> your screen. Let's call it buf_tabs.

I have some ideas about supporting tabs, but I don't know when it gets
implemented.  They require reaching for the mouse, thus they are not all
that useful.

> 2) no file explorer window

Yes there is.  It even supports remote file exploring.  Just edit the
directory.  Besides, the "Open..." item from the menu has the standard
file selector to browse around.

> IDE or text editor?

Text editor.

There may be a number of IDE-like features, but text editing is and will
be the main thing.

> As a python programmer, I can only edit .py files with vim.
> Intellisense doesn't support python, I have used pydiction for about
> ten minutes and dropped it because it changes isk option. Another pain
> is that I cannot debug python files within vim itself. Everytime I
> debug python scripts, I have to open pythonwin and debug it there.

Some kind of intellisense is planned for Vim 7.

> IMHO, it's the tendency that text editor should become more and more
> like IDE. the new fad eclipse is something like this.

Eclipse works well for Java, not much else.  It's a pity it's bulky and
slow.  And makes it difficult to plugin a real editor.

> And lately I learn that another popular text-editor UltraEditor is
> gonna become a IDE called UEeditor, and it seems very close to my
> ideal texteditor, here are some screenshots:
>
> http://www.ultraedit.com/index.php?name=coppermine&file=thumbnails&album=13

Very nice pictures, but can you still edit text with that thing?  They
do have a good marketing department...

Looks like a "we reinvented the wheel for you!" program.  They even
invented a new "UEStudio '05 project format...

Why didn't they call it the "me too" IDE?

> program language or texteditor?
> ===============================
> vim scripts becomes much more powerful than ever before. We have list
> now, so we can kick liblist.vim away. It seems you guys are more
> interested in developing a powerful programming language than a
> texteditor. There are some simple things that vim doesn't support, for
> example, I cannot use vim to convert my file's encoding. I always have
> to use notepad to convert my mbcs encoded files to utf-8.

You need a powerful script language to write powerful plugins.
Otherwise all the functionality would need to be implemented in C code.

--
No man may purchase alcohol without written consent from his wife.
                [real standing law in Pennsylvania, United States of America]

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

RE: ANN: W32 executables for 6.3 and 7.0

Goli, Rajesh (Rajesh)
In reply to this post by A.J.Mechelynck
Bruce,

>No tabs which list your open buffers along the top or bottom of your
screen. Let's call it buf_tabs.

:ls
It is faster and needs no mouse.

> no file explorer window

:help explore

> when we use :bn and :bp to go through the buffers we also enter the
bufexplorer which is not expected.

:set nobuflisted
:help buflisted

> IDE or text editor?

Vim, I believe is a powerful text editor and should remain to be so.

> program language or texteditor?

IMHO, the powerful scripting language is what allows vim to be as extensible
and versatile as it is. Without this vim would be toothless.

Cheers,
Rajesh
Reply | Threaded
Open this post in threaded view
|

Balloons! [was: Re: ANN: W32 executables for 6.3 and 7.0]

François Pinard
In reply to this post by Bram Moolenaar
[Bram Moolenar]

> I use [balloon_expr] every day and it works just fine.

I'm curious, and presume we all are: what for? :-)

--
Fran?ois Pinard   http://pinard.progiciels-bpi.ca
Reply | Threaded
Open this post in threaded view
|

Balloons! [was: Re: ANN: W32 executables for 6.3 and 7.0]

Bram Moolenaar

Fran?ois -

> > I use [balloon_expr] every day and it works just fine.
>
> I'm curious, and presume we all are: what for? :-)

While debugging with Agide.  The balloon shows the variable value under
the cursor (gdb gets the value, Agide passes it to Vim and Vim shows the
balloon).

- Bram

--
Why is "abbreviation" such a long word?

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

Bruce Who
In reply to this post by A.J.Mechelynck
Hi, Mathias:

        thanks! It works. I tried :set fenc=utf-8 without success. I thinks it's because I didn't set :bomb.

======= 2005-07-26 15:29:55 Mathias Michaelis wrote: =======

>Hello Bruce
>
>> I always have to use notepad to convert my mbcs encoded files to
>> utf-8.
>>
>Why that? Here is what I do to convert the actual buffer from latin1
>to utf-8:
>
>:w
>:set encoding=utf-8
>:e ++enc=latin1
>:set fileencoding=utf-8
>:set bomb
>:w
>
>HTH
>Mathias

= = = = = = = = = = = = = = = = = = = =
                       
Best regards,

????????????????Bruce Who
????????????????????2005-07-27

Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

Bruce Who
In reply to this post by A.J.Mechelynck
Hi, Bram:

        Thanks for your reply.

======= 2005-07-26 17:40:54 Bram Moolenaar wrote: =======

>
>Bruce Who wrote:
>
>> Hi, Tony:
>
>Strange to send this to Tony.  He does a lot of things but developing
>Vim isn't one of them.

    Sorry for that. I didn't mean to send this only to Tony. I just replied his post. I didn't want to create another thread.

>> I downloaded and tried vim7.0aa the day before yesterday, and was a
>> little disappointed. I know it's far too late to speak of this topic
>> now, and what I can do now is just to hope next version of vim can be
>> improved.
>
>From your text it shows you don't understand Vim very well.  I would
>suggest to read the help text about the things you want to use Vim for.
>Most obvious example where this applies:
>
>> balloon_expr is improved, but I still don't know how to use it.
>
>I use it every day and it works just fine.

    But I have never learned that what a balloon box look like. I tried the example which I posted yesterday without success. I guess it's not for ususal vim script writing.

>
>> when I open gvim7.00aa, the first empty buffer's name is [No name],
>> it's not translated into my local language as usual. Is this a bug? I
>> just unzip the file to my vim directory instead of overwriting the
>> vim63 directory.
>
>You probably need to install the message translation files in the right
>place.
>
>> No modern GUI elements
>
>While other editors concentrate on improving the looks, the work on Vim
>aims at people who want to get work done.
>
>> 1) No tabs which list your open buffers along the top or bottom of
>> your screen. Let's call it buf_tabs.
>
>I have some ideas about supporting tabs, but I don't know when it gets
>implemented.  They require reaching for the mouse, thus they are not all
>that useful.

        No, it IS useful indeed. Please take a look at here:

http://vim.sourceforge.net/scripts/script.php?script_id=159

        minibufexpl.vim has been downloaded for 11094 times by now.

    Buf-tabs is not only used to swith buffers, if you don't want to search for mouse it's still useful. If we have tabs, we can easily know which buffer is modified, which buffer we are editing, how many buffers we have opened without escaping to normal mode and type :ls<CR> and escape back to insert mode.

>
>> 2) no file explorer window
>
>Yes there is.  It even supports remote file exploring.  Just edit the
>directory.  Besides, the "Open..." item from the menu has the standard
>file selector to browse around.

        I didn't mean the FileDialog opened by :browse confirm e. I mean a window list all files in a directory like what :Explore creates. This window is not only used to open files but also tell users how many files there are in a directory and their name/type(by icon)/date/..., and you may also run them by double-click.


    Yes, we have minibufexpl.vim and :Explore, then why I still need tabs and file explorer window? Because the windows created by plugins are not as good as builtin ones as I mentioned in previous post. One big disadvantage is that these windows are all treated as normal windows for buffers, so I ususally close them by accident and :bn/:bp also take me to these windows.

>
>> IDE or text editor?
>
>Text editor.
>
>There may be a number of IDE-like features, but text editing is and will
>be the main thing.
>
>> As a python programmer, I can only edit .py files with vim.
>> Intellisense doesn't support python, I have used pydiction for about
>> ten minutes and dropped it because it changes isk option. Another pain
>> is that I cannot debug python files within vim itself. Everytime I
>> debug python scripts, I have to open pythonwin and debug it there.
>
>Some kind of intellisense is planned for Vim 7.

   I'd like to know if vim7 is going to support python better? I mean 1) intellisense for python 2) debugger for python.

>
>> IMHO, it's the tendency that text editor should become more and more
>> like IDE. the new fad eclipse is something like this.
>
>Eclipse works well for Java, not much else.  It's a pity it's bulky and
>slow.  And makes it difficult to plugin a real editor.
>
>> And lately I learn that another popular text-editor UltraEditor is
>> gonna become a IDE called UEeditor, and it seems very close to my
>> ideal texteditor, here are some screenshots:
>>
>> http://www.ultraedit.com/index.php?name=coppermine&file=thumbnails&album=13
>
>Very nice pictures, but can you still edit text with that thing?  They
>do have a good marketing department...
>
>Looks like a "we reinvented the wheel for you!" program.  They even
>invented a new "UEStudio '05 project format...
>
>Why didn't they call it the "me too" IDE?

        IDEs are popular, IMHO, vim need to be made easily-integratable to other IDEs or a IDE itself. At the moment, it's hard to integrate vim to our own programs. When we create a application concerning with text-editing, we need to create a widgets ourselves. Life will be better if we can easily use vim in our own application. What about a wxVim or wxpyVim widgets?

>
>> program language or texteditor?
>> ===============================
>> vim scripts becomes much more powerful than ever before. We have list
>> now, so we can kick liblist.vim away. It seems you guys are more
>> interested in developing a powerful programming language than a
>> texteditor. There are some simple things that vim doesn't support, for
>> example, I cannot use vim to convert my file's encoding. I always have
>> to use notepad to convert my mbcs encoded files to utf-8.
>
>You need a powerful script language to write powerful plugins.
>Otherwise all the functionality would need to be implemented in C code.
>
>--
>No man may purchase alcohol without written consent from his wife.
> [real standing law in Pennsylvania, United States of America]
>
> /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
>///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
>\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
> \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///

= = = = = = = = = = = = = = = = = = = =
                       
Best regards,

????????????????Bruce Who
????????????????????2005-07-27

Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

A.J.Mechelynck
----- Original Message -----
From: "Bruce Who" <[hidden email]>
To: "Bram Moolenaar" <[hidden email]>; "vim" <[hidden email]>
Sent: Wednesday, July 27, 2005 4:23 AM
Subject: Re: ANN: W32 executables for 6.3 and 7.0


> Hi, Bram:
>
> Thanks for your reply.
>
> ======= 2005-07-26 17:40:54 Bram Moolenaar wrote: =======
>
>>
>>Bruce Who wrote:
[...]

>>> 2) no file explorer window
>>
>>Yes there is.  It even supports remote file exploring.  Just edit the
>>directory.  Besides, the "Open..." item from the menu has the standard
>>file selector to browse around.
>
> I didn't mean the FileDialog opened by :browse confirm e. I mean a window
> list all files in a directory like what :Explore creates. This window is
> not only used to open files but also tell users how many files there are
> in a directory and their name/type(by icon)/date/..., and you may also run
> them by double-click.
[...]

And Bram meant (by "edit the directory") that ":Explore $VIMRUNTIME" has
been superseded by ":e $VIMRUNTIME", ":Sexplore $VIM/vimfiles" by ":new
$VIM/vimfiles", ":Explore" (with no arguments) by ":e ." etc. The display is
approximately the same though some features are very slightly different; and
now you can even do ":e ftp://ftp.vim.org/pub/vim/" if you have a
command-line FTP client that Vim recognises.

Best regards,
Tony.


Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

Bram Moolenaar
In reply to this post by Bruce Who

Bruce Who wrote:

> >> balloon_expr is improved, but I still don't know how to use it.
> >
> >I use it every day and it works just fine.
>
> But I have never learned that what a balloon box look like. I tried
> the example which I posted yesterday without success. I guess it's not
> for ususal vim script writing.

The example works, but perhaps there is something in your setup that
prevents it from working.  That's the problem with GUI things, they
don't work everywhere.  And balloons don't work in a console (yet).

> >> 1) No tabs which list your open buffers along the top or bottom of
> >> your screen. Let's call it buf_tabs.
> >
> >I have some ideas about supporting tabs, but I don't know when it gets
> >implemented.  They require reaching for the mouse, thus they are not all
> >that useful.
>
> No, it IS useful indeed. Please take a look at here:
>
> http://vim.sourceforge.net/scripts/script.php?script_id=159
>
> minibufexpl.vim has been downloaded for 11094 times by now.
>
> Buf-tabs is not only used to swith buffers, if you don't want to
> search for mouse it's still useful. If we have tabs, we can easily
> know which buffer is modified, which buffer we are editing, how many
> buffers we have opened without escaping to normal mode and type
> :ls<CR> and escape back to insert mode.

Tabs only show the buffer name.  There is only limited space, thus
showing other info will be a problem.  Even just fitting the file name
in there already requires shortening it (and that's not easy, you may be
editing "foo.c" in two different directories).

This is a typical example of something that sounds nice but will be
disappointing once it's working.  If you want a full list of all buffer
names you do have to use a window or menu for it.  Trying to cram them
all in Tabs breaks many UI guidelines.
 
> Yes, we have minibufexpl.vim and :Explore, then why I still need tabs
> and file explorer window? Because the windows created by plugins are
> not as good as builtin ones as I mentioned in previous post. One big
> disadvantage is that these windows are all treated as normal windows
> for buffers, so I ususally close them by accident and :bn/:bp also
> take me to these windows.

Whatever features are added to Vim, they won't prevent you from making
mistakes.

> >Some kind of intellisense is planned for Vim 7.
>
> I'd like to know if vim7 is going to support python better? I mean
> 1) intellisense for python

I will try to do that.  The suggestions I gathered so far involve
connecting to the Python interpreter to gather information about the
identifiers.  That won't be easy...

> 2) debugger for python.

Vim can be the text window of the debugger, but not the debugger itself.
Agide does this, but currently it only works with gdb.  I don't know of
someone who tried to make it work for Python.

> IDEs are popular, IMHO, vim need to be made easily-integratable to
> other IDEs or a IDE itself. At the moment, it's hard to integrate vim
> to our own programs. When we create a application concerning with
> text-editing, we need to create a widgets ourselves. Life will be
> better if we can easily use vim in our own application. What about a
> wxVim or wxpyVim widgets?

Sure, go ahead and make it.  I do think modularity is a good thing.  We
already have the NetBeans interface, used to have Vim work with the
NetBeans IDE.  Thus it's certainly possible.

--
A disclaimer for the disclaimer:
"and before I get a huge amount of complaints , I have no control over the
disclaimer at the end of this mail :-)" (Timothy Aldrich)

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

James Vega-3
In reply to this post by Bruce Who
On Tue, Jul 26, 2005 at 11:13:24AM +0800, Bruce Who wrote:

> No modern GUI elements
> ======================
>
>     When I opened the gvim7.0aa, wow, it still looked like the
>     gvim6.3, the same GUI! Yes, I mean *g*Vim not vim. gVim still
>     doesn't look like any other text editors(I think it's unnecessary
>     to refer to 'other text editors' here):
>
>     1) No tabs which list your open buffers along the top or bottom of
>     your screen. Let's call it buf_tabs.
>
>     I know minibufexpl.vim and I'm using it. It simulate the buf_tabs,
>     but not well. we may
>
>       - close the minibuf by <C-W>q accidently
>       - when we use :bn and :bp to go through the buffers we also
>         enter the minibuf which is not expected.
MiniBufExpl has two commands to specifically address this.  :MBEbn and
:MBEbp act like :bn and :bp, except they skip the MBE buffer.

>       - when we save or modify the current buffer, minibuf is not
>         updated immediately. Only when we swith to another buffer, the
>         '+' mark is added or removed from the buffer's name in the
>         minibuf.
>       - if we saved a session one minutes ago, and we open it now,
>         then there is always a warning about minibuf. And after
>         all buffers are loaded, the minibuf is empty.

James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

Bruce Who
In reply to this post by A.J.Mechelynck
Hi, Bram:


======= 2005-07-27 17:29:19 Bram Moolenaar wrote: =======

>
>Tabs only show the buffer name.  There is only limited space, thus
>showing other info will be a problem.  Even just fitting the file name
>in there already requires shortening it (and that's not easy, you may be
>editing "foo.c" in two different directories).
>
>This is a typical example of something that sounds nice but will be
>disappointing once it's working.  If you want a full list of all buffer
>names you do have to use a window or menu for it.  Trying to cram them
>all in Tabs breaks many UI guidelines.

        I never expect that tabs show as much infomation as :ls command. I just wonder if you donnot use minibufexpl and/or tabs, how do you swith between buffers? For me, at least two steps are required:
    1) type :ls to get a list of all buffers
    2) use :[N]b to jump to that buffer
    If gvim has tabs, we can easily know buffer names(not full path)/buffer number(I thinks it's necessary for gvim), then we can directly use :[N]b jump to that buffer.

    It's a rare case that two 'foo.c' is open. Even if this case happens, we can jump to them one by one(only two, it won't take us a lot of time) to check if it's the right one. Regardless of the rare case, tabs can make things easy.
 
>> Yes, we have minibufexpl.vim and :Explore, then why I still need tabs
>> and file explorer window? Because the windows created by plugins are
>> not as good as builtin ones as I mentioned in previous post. One big
>> disadvantage is that these windows are all treated as normal windows
>> for buffers, so I ususally close them by accident and :bn/:bp also
>> take me to these windows.
>
>Whatever features are added to Vim, they won't prevent you from making
>mistakes.

        No, if it's a tabs widget instead of a window created by scripts it's impossible to be closed by command like <C-W>w/:bw/:bd. And minibufexpl.vim really doesn't work so well, I have listed some disadvantages in my previous post. It's not minibufexpl.vim's fault. It's hard to create really tabs by scripts.

    I believe I'm not the only one who need tabs. At least minibufexpl.vim users all need it. And I think they have more reasons than I have.

>
>> >Some kind of intellisense is planned for Vim 7.
>>
>> I'd like to know if vim7 is going to support python better? I mean
>> 1) intellisense for python
>
>I will try to do that.  The suggestions I gathered so far involve
>connecting to the Python interpreter to gather information about the
>identifiers.  That won't be easy...
>
>> 2) debugger for python.
>
>Vim can be the text window of the debugger, but not the debugger itself.
>Agide does this, but currently it only works with gdb.  I don't know of
>someone who tried to make it work for Python.

        I tryied to write such a plugin long time ago and failed. I have found several other python-debugger plugins, but they don't work like what I expected. They need run pdb to debug. I prefer a debugger like which IDLE or pythonwin or Komodo has.

= = = = = = = = = = = = = = = = = = = =
                       
Best regards,

????????????????Bruce Who
????????????????????2005-07-28

Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

A.J.Mechelynck
----- Original Message -----
From: "Bruce Who" <[hidden email]>
To: "Bram Moolenaar" <[hidden email]>; "vim" <[hidden email]>
Sent: Thursday, July 28, 2005 5:50 AM
Subject: Re: ANN: W32 executables for 6.3 and 7.0


> Hi, Bram:
>
>
> ======= 2005-07-27 17:29:19 Bram Moolenaar wrote: =======
>
>>
>>Tabs only show the buffer name.  There is only limited space, thus
>>showing other info will be a problem.  Even just fitting the file name
>>in there already requires shortening it (and that's not easy, you may be
>>editing "foo.c" in two different directories).
>>
>>This is a typical example of something that sounds nice but will be
>>disappointing once it's working.  If you want a full list of all buffer
>>names you do have to use a window or menu for it.  Trying to cram them
>>all in Tabs breaks many UI guidelines.
>
> I never expect that tabs show as much infomation as :ls command. I just
> wonder if you donnot use minibufexpl and/or tabs, how do you swith between
> buffers? For me, at least two steps are required:
>    1) type :ls to get a list of all buffers
>    2) use :[N]b to jump to that buffer
>    If gvim has tabs, we can easily know buffer names(not full path)/buffer
> number(I thinks it's necessary for gvim), then we can directly use :[N]b
> jump to that buffer.
[...]

Have you tried tearing off gvim's Buffers menu, as I mentioned earlier? Does
it or doesn't it satisfy you and why?

> = = = = = = = = = = = = = = = = = = = =
>
> Best regards,
>
> ????????????????Bruce Who
> ????????????????????2005-07-28

Best regards,
Tony.


Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

Bram Moolenaar
In reply to this post by Bruce Who

Bruce Who wrote:

> >Tabs only show the buffer name.  There is only limited space, thus
> >showing other info will be a problem.  Even just fitting the file name
> >in there already requires shortening it (and that's not easy, you may be
> >editing "foo.c" in two different directories).
> >
> >This is a typical example of something that sounds nice but will be
> >disappointing once it's working.  If you want a full list of all buffer
> >names you do have to use a window or menu for it.  Trying to cram them
> >all in Tabs breaks many UI guidelines.
>
> I never expect that tabs show as much infomation as :ls command. I
> just wonder if you donnot use minibufexpl and/or tabs, how do you
> swith between buffers? For me, at least two steps are required:
>     1) type :ls to get a list of all buffers
>     2) use :[N]b to jump to that buffer
> If gvim has tabs, we can easily know buffer names(not full
> path)/buffer number(I thinks it's necessary for gvim), then we can
> directly use :[N]b jump to that buffer.

You are confusing a few things.  The buffer list is NOT meant to be used
as the list of files one is working on.  It's a list of all file names
that are currently being used.  When the Tabs get implemented they will
NOT show all the items in the buffer list.

The argument list would come closer, but Tabs will be much more useful
when you can fill them indepently from other lists.  It's more like
another page with windows.  You can fill each page with one buffer, but
it must also be possible to split (e.g., to show help text).

> It's a rare case that two 'foo.c' is open. Even if this case happens,
> we can jump to them one by one(only two, it won't take us a lot of
> time) to check if it's the right one. Regardless of the rare case,
> tabs can make things easy.

It's not at all rare for me, I very often edit two versions of the same
file and in that situation it's very important to see the path.  Two
Tabs with "vim.h" or "Makefile" requires me to click on it to see which
one it is, that is undesired.

As I said, this is a feature that, once implemented, will trigger many
more requests from people who use it in various ways.

--
ARTHUR: The swallow may fly south with the sun, or the house martin or the
        plover seek warmer hot lands in winter, yet these are not strangers to
        our land.
SOLDIER: Are you suggesting coconuts migrate?
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

Bruce Who
In reply to this post by A.J.Mechelynck
Hi, Tony:


======= 2005-07-28 12:00:52 Tony Mechelynck wrote: =======

[...]

>
>Have you tried tearing off gvim's Buffers menu, as I mentioned earlier? Does
>it or doesn't it satisfy you and why?
>
I have never knowed this menu, and I found it just now,:-< . But this requires searching for mouse, :-<. I need tabs not only for swithing buffers but also want to know info about buffers(buffer count/name/buffer number) without pressing keys or searching for mouse.

= = = = = = = = = = = = = = = = = = = =
                       
Best regards,

????????????????Bruce Who
????????????????????2005-07-29

Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

Bruce Who
In reply to this post by A.J.Mechelynck
Hi, Bram:

======= 2005-07-28 17:53:03 Bram Moolenaar wrote: =======

>You are confusing a few things.  The buffer list is NOT meant to be used
>as the list of files one is working on.  It's a list of all file names
>that are currently being used.  When the Tabs get implemented they will
>NOT show all the items in the buffer list.
>
>The argument list would come closer, but Tabs will be much more useful
>when you can fill them indepently from other lists.  It's more like
>another page with windows.  You can fill each page with one buffer, but
>it must also be possible to split (e.g., to show help text).
>
>> It's a rare case that two 'foo.c' is open. Even if this case happens,
>> we can jump to them one by one(only two, it won't take us a lot of
>> time) to check if it's the right one. Regardless of the rare case,
>> tabs can make things easy.
>
>It's not at all rare for me, I very often edit two versions of the same
>file and in that situation it's very important to see the path.  Two
>Tabs with "vim.h" or "Makefile" requires me to click on it to see which
>one it is, that is undesired.
>
>As I said, this is a feature that, once implemented, will trigger many
>more requests from people who use it in various ways.
>

Maybe what I really need is not exactly a tabs-wideget, :-<. I just need something that 1)show me all the buffers' names/their buffer numbers/they are modified or not and 2)is always visible and 3)cannot be closed by <C-W>q/:bd/:bw accidently 4)cannot be entered by :bn/:bp.

I just don't want to jump to another buffer by 3 steps 1):ls 2)find out the buffer number 3):[N]b. It's a simple operation, why should we newbies take so many steps?

= = = = = = = = = = = = = = = = = = = =
                       
Best regards,

????????????????Bruce Who
????????????????????2005-07-29

Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

robert h-2
In reply to this post by Bruce Who
I use Vim off and on on Windows. I use it because it is a really good editor
and not an IDE. I don't use it macro language as I usually find what I want
off the Vim site. However, I really missed a tabbed interface when using it
and so I usually fall back to a simpler editor like SciTE.

If you have the same file multiple times, the answer would be to have the
full path in the title bar. That is the way almost all the editors I have
used work and I have not gotten confused over it.

If Vim had a tabbed interface I would probably not use any other editor and
I would probably start learning its macro language to become a power user.

Everyone has their wants and needs for Vim, I think it would be perfect with
a tabbed interface.

My .02

Robert



Reply | Threaded
Open this post in threaded view
|

Re: ANN: W32 executables for 6.3 and 7.0

A.J.Mechelynck
In reply to this post by Bruce Who
----- Original Message -----
From: "Bruce Who" <[hidden email]>
To: "Bram Moolenaar" <[hidden email]>; "vim" <[hidden email]>
Sent: Friday, July 29, 2005 4:24 AM
Subject: Re: ANN: W32 executables for 6.3 and 7.0
[...]

> Maybe what I really need is not exactly a tabs-wideget, :-<. I just need
> something that 1)show me all the buffers' names/their buffer numbers/they
> are modified or not and 2)is always visible and 3)cannot be closed by
> <C-W>q/:bd/:bw accidently 4)cannot be entered by :bn/:bp.
>
> I just don't want to jump to another buffer by 3 steps 1):ls 2)find out
> the buffer number 3):[N]b. It's a simple operation, why should we newbies
> take so many steps?
>
> = = = = = = = = = = = = = = = = = = = =
>
> Best regards,
>
> ????????????????Bruce Who
> ????????????????????2005-07-29

Unless you want it to apply to very large numbers of buffers, you might use
what I call "the poor man's tabbed editing", or "Rolodex Vim", as follows:

1. :set noequalalways winheight=99999 winminheight=0

2. Don't "hide" the buffers you want to use, but keep them "open" in split
windows.

3. The window for the current buffer will expand up and down, reducing all
other windows to just their status lines and nothing else.

4. The status lines for windows other than the current one are at the top
and bottom of the screen, like the tabs of a Rolodex. They show 'modified'
status by the presence or absence of [+], and (when there is room) the
file's path.

5. Switch buffers as follows:

    5.1. Ctrl-W w goes to the next "tab" down, or from the bottom one to the
top one.

    5.2. Ctrl-W W goes to the next "tab" up, or from the top one to the
bottom one.

    5.3. {count} Ctrl-W w goes to the {count}-th "tab" from top.

    5.4. I use the following mappings; you can vary them at will:

    :map <F11> <C-W>w
    :map <S-F11> <C-W>W
    :imap <F11> <C-O><C-W>w
    :imap <S-F11> <C-O><C-W>W

    5.5. For mouse-lovers (not you or me, but there are others): Clicking a
"tab" with the mouse opens it.

Best regards,
Tony.