How to use a filetype filter(s) with browse

Using vim 7.2 on ubuntu 10.04. Huge version compiled for gtk.

I have automated a series of menu items that activates `browse' for
different directories.
The process is governed by a menu selection that allows me to set a
series of variables called g:ModelFolder, g:ControllerFolder etc...
Upon another menu selection, the variables are selectively
concatenated to a string that resolves to something like

browse confirm e /home/tim/prj/cgi/baker/akmls

Now, it would be great to add a filetype filter so that
I would have something like

browse confirm e /home/tim/prj/cgi/baker/akmls *.py

Better yet, to have multiple filetypes.. but setting
let g:browsefilter="*.py" doesn't have the expected effect,
I.E. after executing, I still see all directory files in the dialogue.

How can I make this happen?
thanks
-- 
Tim 
tim at johnsons-web.com or akwebsoft.com
http://www.akwebsoft.com

--

-- 
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.

Re: Using browse command

On Dec 28, 10:19 pm, vicky b <vickyb2... <at> gmail.com> wrote:
> Hi all,
>
>    I want to use browse command when i use in GVim when i hit :browse e it
> opens up the filw browser box what is equivalent in console vim or can it
> open in a tab list of files in current directory.
>

Use the netrw file browser plugin distributed with the official Vim
runtime.

Explore in the current window with the :Explore command
Explore in a new split window with the :Sexplore command
Explore in a new tab with the :Texplore command

--

-- 
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: macro for an affine cipher

HAPPY NEW YEAR everybody!

I've made some progress for my quest to secure my files. Having seen that vim can interact with perl using
:perl and :.perldo , I've dropped the affine cipher in favor of just using perl's existing crypto modules
available at www.cpan.org  .

So I've built a perl script that takes four arguments:
1)  a 'steering' value "en" or "de"
2)  the key
3)  name of input file
4)  name of output file

and works great when executed from within the Command Window i.e.

   perl mycoolscript.pl en DontWorryBeHappy plaintext.txt secure.txt

Now I'd like to modify it to be runnable from within a vim session and execute against the whole file
(buffer?) at once.

For example, you have a textfile containing all your passwords.
You want this file to remain encrypted on the hard drive.
You wish to open the file in vim, execute something like:
   :.perldo mycoolscript.pl de DontWorryBeHappy
and =PRESTO= the file is decrypted
You make a few changes then
   :.perldo mycoolscript.pl en DontWorryBeHappy
and =PRESTO= the file is encrypted again. You
   :wq
and are done.

Re: How to get a nice vertical list of open buffers (ordered by mru) that I can easily navigate to by typing drill down?

On Sun, Dec 26, 2010 at 7:34 PM, Rick R <rickcr <at> gmail.com> wrote:
> I'm having trouble finding what I use in my Java IDEs all the time:
>
> - A quick popup of my open buffers listed by most recently used and can be
> cut back by me just starting to type the name of the file, or I can navigate
> by arrows to the file I want
>
> How do I get this behavior in vim? The closest I've come is wildMenu but
> that's really lame when you have a ton of buffers open - since it lists them
> horizontally and most will just say "unamed" until you tab to them.
>
> I use Command-T all the time which I love but that's for all files in my
> project whether the file is an open buffer or not. Sometimes I like to view
> and switch easily between only my current buffers.
>
> The regular most recently used plugin "mru" is nice but that ends up
> including global files used from any vim session (which isn't what I want in
> this case when working on a project.)
>
> Do I need to try the bufmru or lustyExplorer plugins?

I like FuzzyFinder (FufBuffer of FufMruFile is about what you want).
Has a nice fuzzy interface (auto-regex or not to user taste), can find
lots of things besides buffers (files, tags, etc.) with
uniform-as-possible interface and you can easily write callbacks to
find whatever you want.  Super nice.

Britton

--

-- 

Re: Substitute within a highlight group.

On 12/31/2010 05:32 PM, David Fishburn wrote:
> Can you provide the text of the file you are editing.

Forgot to say, I'm using vim 7.3.35 from debian sid.

-- 
sergio.

-- 
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

$TTL 86400
test.zone.net.		IN SOA	ns.zone.net.	mail.test.zone.net. (
				2007031901 ; serial
				21600      ; refresh (6 hours)
				7200       ; retry (2 hours)
				1209600    ; expire (14 days)
				86400      ; minimum (1 day)
				)
			NS	ns.zone.net.
			NS	ns.secondary.zone.net.
			A	192.168.5.9
			MX	10 ns.zone.net.
			TXT	"v=spf1 mx ~all"
$ORIGIN test.zone.net.
$TTL 86400
www			A	192.168.5.9

Re: How to use a filetype filter(s) with browse

On Fri, 31 Dec 2010 15:14:11 -0900, Tim Johnson wrote:

> let g:browsefilter="*.py" doesn't have the expected effect,
> I.E. after executing, I still see all directory files in the dialogue.
> 
> How can I make this happen?

According :help browsefilter it's only for Windows and Motif.

In ftplugin directory, browsefilter is set only for Windows.
-- 
Patrick Texier

--

-- 
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Vim homepage - improvements I'd like to implement. Comment please

Excerpts from Marc Weber's message of Fri Dec 31 08:44:02 +0100 2010:

E) new password request the way its known by other sites:
  - receive mail
  - click link
  - reset password

F) add a way to change a password

G) hide script (we don't have to delete it)?
  only maintainers / authors should be able to hide a script

E) bug tracking system or url field?
   It should be KISS simple: You have to have an account.
   states: open, closed

   actions:
   - create
   - close
   - add comment

Usually a site such as www.vim.org should not be abused to reinvent the
wheel. However most Vim scripts are very small and not all are hosted on
github or the like (?)

About the "reasons" of downvoting: Of course they should be visible to
everyone. Maybe maintainers should be able to add comments so that you
can correct false claims.

About the PHP.net style comments: Yes, they can be messy. However

Re: Vim homepage - improvements I'd like to implement. Comment please

> Bram was so kind adding me to the list of contributors to the Vim project which
> means that I can propose Vim web page changes by sending Bram patches.

Great to hear.

>   A:a way to change the script type afterwards (because Bram had to do this manually using SQL)

Is the script type of any use at all as long as vim.org's search
function doesn't work and we have to use google to search it?

>   C:an opt-in collaboration feature: You can add other users as collaborators to
>     your scripts which means that they can change the description and upload new
>     versions as well (This is similar to what can be done on github)

I'd say only one person should be responsible for maintaining the info
on vim.org. But there should be a way to transfer that responsibility/
maintainership.

>   D:change the voting system this way:

If you actually plan to save votes on a per version basis I'd like to
suggest to implement some sort of inflation (i.e., loss of value over
time). E.g. older versions should IMHO have less weight when
calculating the over-all value. This would also solve/attenuate the
problem with downvotes for older versions. I think you'd only have to
store one value for previous votes + a current one and then let the
over-all value be something like curr + prev * 0.8 or so. And maybe
multiply all kharma points with 0.8 every year.

>     2) force users to give a reason if they vote something down. This will be

Re: Vim homepage - improvements I'd like to implement. Comment please

Excerpts from Tom Link's message of Sat Jan 01 12:34:39 +0100 2011:
> > Bram was so kind adding me to the list of contributors to the Vim project which
> > means that I can propose Vim web page changes by sending Bram patches.
> 
> Great to hear.
> 
> >   A:a way to change the script type afterwards (because Bram had to do this manually using SQL)
> 
> Is the script type of any use at all as long as vim.org's search
> function doesn't work and we have to use google to search it?
Yes: VAM is using it to move /foo.vim into syntax,ftplugin or plugin
folder. Not all plugins have a proper archive containing a "subdir".
That's the only reason I know about. Whether that usage was
intentionally I don't know. It seems to work fine in most cases (for
those where its set wrong I override it)

> I'd say only one person should be responsible for maintaining the info
> on vim.org. But there should be a way to transfer that responsibility/
> maintainership.
So you're fine with what I proposed (only reply if I got this wrong)

> >   D:change the voting system this way:
> 
> If you actually plan to save votes on a per version basis I'd like to
> suggest to implement some sort of inflation (i.e., loss of value over
> time). E.g. older versions should IMHO have less weight when
> calculating the over-all value. This would also solve/attenuate the
> problem with downvotes for older versions. I think you'd only have to
> store one value for previous votes + a current one and then let the
> over-all value be something like curr + prev * 0.8 or so. And maybe

Re: Vim homepage - improvements I'd like to implement. Comment please

Reply to message «Re: Vim homepage - improvements I'd like to implement. Comment 
please», 
sent 14:52:59 01 January 2011, Saturday
by Marc Weber:

> > If you actually plan to save votes on a per version basis I'd like to
> > suggest to implement some sort of inflation (i.e., loss of value over
> > time). E.g. older versions should IMHO have less weight when
> > calculating the over-all value. This would also solve/attenuate the
> > problem with downvotes for older versions. I think you'd only have to
> > store one value for previous votes + a current one and then let the
> > over-all value be something like curr + prev * 0.8 or so. And maybe
> > multiply all kharma points with 0.8 every year.
>
> For plugin versions? Bad idea. You can manipulate by doing version bumps
> only (don't think Vim script authors will do so .. but )
> 
> by time? Great idea. Tools change. so 10 year old karma may no longer be
> valid. But we should discuss which would be the best way.
> 
> So for now I'd like to keep the "old" (stupid ?) value unless more
> discussion has taken place.
I suggest combine this ideas: inflate neither by time nor for plugin updates, 
but inflate for plugin updates if downvoted version is at least one month older 
then new version. Or another suggestion: make an inflate coefficient depend on 
time between plugin updates with 0.8 as a lower limit. Do not inflate anything 
if no new versions were uploaded: I do not see why votes should change just 
because time was changed.