Re: VimWiki - again - but with a brand new option
On 5/8/07, Gary Johnson <[EMAIL PROTECTED]> wrote: On 2007-05-08, Ian Tegebo <[EMAIL PROTECTED]> wrote: > On 5/8/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > Ian Tegebo wrote: > > > I would like to make another implementation independent suggestion; > > > one could make a VimWiki more valuable by importing the _extremely_ > > > valuable vim helpfiles into it. > > > > Please don't do this. It might sound like a nice idea, but it means > > making a branch that will be very hard to merge back into the help files > > of the distribution. > I feel misunderstood but it serves me right for not saying what I mean... > > Synchronizing data is no fun, I agree. While I was up in the clouds I > was imaging that the wiki would be the authoritative source for the > helpfiles after doing an initial _import_. Then the text version > would be exported as needed, e.g. end user runtime update or for a new > release. This seems like a bad idea. The vim help files are an authoritative source because their content is under the control of an authority: Bram. Others are encouraged to submit patches that correct errors or clarify wording, but before any of those patches are applied, Bram looks at them to be sure they are correct and consistent with the help files' style. I was assuming the wiki that would be chosen would allow for some level of access control. I'm also assuming a group of trusted long-time users could be delegated the responsibility of administering the wiki. If Bram is the only one who should make changes to an object than I agree that those objects wouldn't be useful in a wiki. I think it's possible to have a protected part of the wiki for helpfiles that is write restricted and have another part that is more open that can easily reference those files. Of course, if the value added by more hands on the helpfiles doesn't exceed the cost in maintenance than this is a poor choice. I don't think I've really seen any issues with updates to helpfiles, they were just an example. So far I think the point was to just be able to link to parts of them more easily - I didn't really mean to dwell on the help system. I was just hoping to carry the point that wikis _can_ provide a lot of valuable function if properly cultivated. In all this I've lost track of what the purpose of a VimWiki would be. Was it just meant to host vim tips? Thinking about the format of tips now, I wonder if a blog format wouldn't be more suitable. For example, tips are posts that then have comments while most blogs have these features as well as search and RSS. VimBlog? To this end I wonder if there are enough people to support more apps given the work load the vimonline team has: Bugs https://sourceforge.net/tracker/?atid=391887&group_id=27891&func=browse Features https://sourceforge.net/tracker/?atid=391890&group_id=27891&func=browse -- Ian Tegebo
Re: VimWiki - again - but with a brand new option
On 5/8/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Ian Tegebo wrote: > On 5/6/07, Sebastian Menge <[EMAIL PROTECTED]> wrote: > > Hi all > > > > Independent of the implementation used, I suggest to develop good > > guidelines. The Wiki should be really valuable and not redundant to > > vim-tips or mailing-lists. > > I would like to make another implementation independent suggestion; > one could make a VimWiki more valuable by importing the _extremely_ > valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. I feel misunderstood but it serves me right for not saying what I mean... Synchronizing data is no fun, I agree. While I was up in the clouds I was imaging that the wiki would be the authoritative source for the helpfiles after doing an initial _import_. Then the text version would be exported as needed, e.g. end user runtime update or for a new release. Please use the wiki for tips. That is an addition to the help files. > For example, I would love to be able to quickly correct spelling > mistakes or contribute to plugin helpfiles a la a Wiki interface. I > could then imagine updating my local helpfiles through the Wiki > interface via a sync-plugin. If you see spelling mistakes in the help files please send them to me. I just fixed 250 of them, because someone send me a list. That's useful for everyone. The main goal now is to get the Vim tips collection back to live. It has been dead for three months now! Does the VimOnline team want help? How does one sign up? There are a lot of bugs at the sourceforge site that aren't triaged. Some are misdirected vim-dev@/vim@ posts. -- Ian Tegebo
Re: VimWiki - again - but with a brand new option
On 5/6/07, Sebastian Menge <[EMAIL PROTECTED]> wrote: Hi all Independent of the implementation used, I suggest to develop good guidelines. The Wiki should be really valuable and not redundant to vim-tips or mailing-lists. I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. For example, I would love to be able to quickly correct spelling mistakes or contribute to plugin helpfiles a la a Wiki interface. I could then imagine updating my local helpfiles through the Wiki interface via a sync-plugin. The Wiki would ideally understand how to link to vim-scripts and vim-tips like vimonline currently does. As a bonus, mailing-list posts would also linkable and magical indexing would populate the bottom of each Wiki page with relevant search results from the list similar to O'Reilly's Safari. It's fun to dream! I'm serious about getting the helpfiles imported into the Wiki though. I know about the VimDoc project; I think this could be the next evolution in that direction. http://vimdoc.sourceforge.net/htmldoc/usr_toc.html -- Ian Tegebo
Re: vim 7.1?
On 4/28/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Ian Tegebo wrote: > On 4/27/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > Jonathan Smith wrote: > > > > > With the insane number of patches collecting against 7.0, and > > > presumably the new features accumulating in the devel tree, is anyone > > > thinking about when a 7.1 release might be made? > > > > Yeah, it's about time for Vim 7.1. Unfortunately I haven't found a good > > moment to make a new release. And I don't see it happening in the > > coming weeks either... > > Would it be possible for people to help make new releases? You can certainly help fixing bugs. There is about a hundred of them at the top of the todo list. Is the most updated TODO list for bug fixes and features "vim -c ':help todo.txt'" on a fresh build? -- Ian Tegebo
Re: vim 7.1?
On 4/27/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Jonathan Smith wrote: > With the insane number of patches collecting against 7.0, and > presumably the new features accumulating in the devel tree, is anyone > thinking about when a 7.1 release might be made? Yeah, it's about time for Vim 7.1. Unfortunately I haven't found a good moment to make a new release. And I don't see it happening in the coming weeks either... Would it be possible for people to help make new releases? -- Ian Tegebo
Re: Wish, Kate like file list.
On 4/12/07, Edd Barrett <[EMAIL PROTECTED]> wrote: Hi, This might already be possible, please excuse me if it is. I love the editting features of vim, but find that navigating between open files is quite difficult. Ideally I think I would be quite confortable with a kate like interface for listing open files: http://www.kde.org/screenshots/images/3.1/fullsize/2.png (screenshot) You might want to look at winmanager: http://robotics.eecs.berkeley.edu/~srinath/vim/snapshot2.JPG http://www.vim.org/scripts/script.php?script_id=95 It seems a very popular plugin for accomplishing this. If you search for 'tree' or 'file explorer' in the scripts section you'll see many more options. -- Ian Tegebo
Re: Wish, Kate like file list.
On 4/12/07, Ingo Karkat <[EMAIL PROTECTED]> wrote: Edd Barrett wrote: > Hi, > > This might already be possible, please excuse me if it is. > > I love the editting features of vim, but find that navigating between > open files is quite difficult. > > Ideally I think I would be quite confortable with a kate like > interface for listing open files: > http://www.kde.org/screenshots/images/3.1/fullsize/2.png (screenshot) > > I got quite close by messing about with netrw in a vertical split, but > the list pane did not: > > - Remain the same size > - Show only one file to be open in the right hand pane. It would > always split again for each newly selected file. > > Does anyone know how to do this? > > Would anyone find this useful? > > I have looked into using vim-part inside kate, but this is not > supported for my UNIX distribution. > I haven't used Kate, but I'm using a combination of - project (http://vim.sourceforge.net/scripts/script.php?script_id=69) to (re-)open files belonging to a custom file structure, - ProjectBrowse (http://vim.sourceforge.net/scripts/script.php?script_id=943) to open files in subdirectories and - most useful - - bufexplorer (http://vim.sourceforge.net/scripts/script.php?script_id=42) to navigate between files currently open in buffers. I've set up those plugins to open in a vertical split at the left side (like in most IDEs). Each view can be toggled on/off via a function key (F2, F3, F4). If one view is already open, trying to open another one will close the former, so that they don't eat up all of my window space. I was hoping the SideBar.vim plugin would do this for me: http://www.vim.org/scripts/script.php?script_id=720 Unfortunately it's broken for me in vim70 (shame on me for not contacting the maintainer or fixing it myself). At the moment it doesn't properly control the width of the sidebar. I was hoping to use only one function key that would cycle through my sidebars; maybe CTRL-FX would drop a sidebar or prompt to add another. Thanks for you code! -- Ian Tegebo
Re: syntax/man.vim: manSubHeading is a bit too general?
On 4/9/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
The manSubHeading is defined as
syn match manSubHeading "^\s\{3\}[a-z][a-z ]*[a-z]$"
This will, however, match more lines than I think is intended. It
will, for example, match the line
\t returns are what are recorded and compared with the data git keeps
where "\t" is a horizontal tabulation. I'm guessing that the actual
regex should be
^ \{3\}[a-z][a-z ]*[a-z]$
I hope nobody minds if I take this opportunity to ask a question about
vim's pattern matching.
After reading |pattern| I wonder if the following is more efficient:
syn match manSubHeading '^ \{3\}\l\l\?\l$'
Taken from |pattern|:
- Matching with a collection can be slow, because each character in
the text has to be compared with each character in the collection.
Use one of the other atoms above when possible. Example: "\d" is
much faster than "[0-9]" and matches the same characters
Do people find this to make a different for moderate file sizes, e.g.
the man page for 'less' being ~2000 lines?
--
Ian Tegebo
Building Vim7 with perl support using Aap
I followed the instructions at: http://www.a-a-p.org/ports.html and that installation yielded a vim without perl support. After looking at: http://www.a-a-p.org/examples.html#variants It seems like adding several flags shouldn't be that hard; I could even imagine that recipe files have already been written for this. Any recommendations? -- Ian Tegebo
