New FARR plugin : FZip select files and zip them to any file

[ecaradec]

FZip allow to zip a selection of files. A query take this form :

zip C:\folder1\;c:\folder2\ to c:\test.zip

I used a trick to enable completion at each sublevel of the query : you get completion at C:\folder1\, at C:\folder2\ and at c:\test.zip.  You can autocomplete by typing CTRL-Enter (this replace tab currently ) as FARR doesn't notify plugins on tab key press. May be farr could allow plugins to handle the "tab" key ?
When you begin to type a filename c:\ farr does not seem to trigger the search (at the \ ) ? I'm not sure why but you can type c:/ instead to get results at the root level.

Every time you type ; you begin a new file selection in the file selection. When you are done with file selection type <space>to<space> then the name of the file you want to create. FZip will create a special entry for you to create the file.

You will need the latest fsubcript since I added some functions to the fscript.dll. You can get the latest function updated with all czb and ewemoa developpement at :

http://github.com/ec...cript/commits/master

You can then get the plugin at :

http://github.com/ec...dec/fzip/tree/master

Beyond the zip behavior this plugin is a experiment to see if FARR can use more natural language. Something like ubiquity but outside of the browser.

[mouser]

cool idea and interesting.. doesnt seem to work all that well for me in terms of selecting directories to zip and autocompleting.. but cool idea.

May be farr could allow plugins to handle the "tab" key ?

sure, i could add that if you like.

[mouser]

btw you also need to get latest fscript from ewe which can search deeper for fsubscript plugins.

[ecaradec]

cool idea and interesting.. doesnt seem to work all that well for me in terms of selecting directories to zip and autocompleting.. but cool idea.

-mouser (November 30, 2008, 11:35 AM)

Could you be a bit more explicit on how it doesn't work mouser ? There is a lot of way it can fail. Putting too many space between items, not putting a \ at end of a folder can cause problem zipping.
Autocompleting should work on ctrl-enter. Does it work ?

[ewemoa]

btw you also need to get latest fscript from ewe which can search deeper for fsubscript plugins.

-mouser (November 30, 2008, 11:50 AM)

As near as I can tell, that code (or czb's modification of it) is in the latest.  If the recursive searching is not working, perhaps something broke recently.

[ewemoa]

I tried FZip for the following two cases:

  zip C:\a.txt;C:\b.txt to c:\test.zip <-- didn't work -- no resulting test.zip file

  zip C:\a\;C:\b\ to c:\test.zip <-- worked (completion of directory name via Control-Enter did too)

Any plans to have the completion work so it might "cycle" through various candidates?  I didn't have much luck w/ repeated presses of Control-Enter.


(Also, are you using msysgit or something else?)

[ecaradec]

zip C:\a.txt;C:\b.txt to c:\test.zip <-- didn't work -- no resulting test.zip file

Yes you are right, this is a very very beta version. I will make some correction soon.

[ecaradec]

Also, are you using msysgit or something else

yes it is msysgit. It is better than installing the whole cygwin. I forgot to add a git config core.autocrlf=false in the project. I will fix it soon. If you fork the project don't forget to set the parameters or the diff will be wrong until I fix it. I'll try to provide help if you want to use it given I prefer it to svn. I know it is a bit tough at first (at least it was for me ). Don't hesitate to ask.

[ewemoa]

Thanks for the answers.

I did the following locally after installing msysgit:

  git clone git://github.com/ecaradec/fsubscript.git
  cd fsubscript
  git config core.autocrlf # noticed it was true
  git config core.autocrlf false
  git config core.autocrlf # noticed it was now false
  git diff # noticed not-so-nice diff of FSSCSettings.ahk

Is the last thing something I should worry about at all?

[ecaradec]

I committed a new version that include the 7z.dll that seem necessary for 7z to work correctly. You can get it at the same address as before. There is no need to type ctrl-enter anymore. As long as the request is not complete the completion is automatic on enter.

[ecaradec]

Is the last thing something I should worry about at all?

-ewemoa (December 01, 2008, 11:20 PM)

After changing core.autocrlf you should do a git reset --hard so that git get a new copy of file and correct end of lines and diff should be correct again. Any uncommited change will be erased in the process, so do it on a clean tree.

[ewemoa]

I tried how I understood what you suggested and it seems to work well.

Thanks!

[ewemoa]

I got the latest version [1] [2] and verified that using Enter (not Control-Enter) is enough for completion of not-already completed folder names.

May be you are already considering this, but how about when a folder name is complete, making subsequent presses of Enter cycle through among other possible completions?  Perhaps that is a pain involving state or something...ah, I thought of a hack that wouldn't require state -- as long as one can 'calculate' (say based on some natural sort oder) the 'next' completion candidate based on the current completed folder name, it doesn't seem that state is necessary [3].  What do you think?


[1] 8c1beec944651212584b63964237185118edb10e
[2] Though at first github didn't provide anything -- a little waiting cured this.
[3] Other than the state implicit in the current completed folder name.

[ewemoa]

I have a question about the use of FARR.getQueryString() in Fzip's trigger().

It seems to me that a similar end might be achieved using the following method:

1. in search(), package up queryraw into the args parameter for emitResult()
2. in trigger(), retrieve the query information from the args parameter

Would the outlined method accomplish the same aim, or may be I am missing something important?

If it's the latter, I'd appreciate being informed to help improve my understanding of FARR

Edit: I think I see why getQueryString() may be necessary -- I guess not everything that ends up causing trigger() to occur originates from FZip's emitResult().

[ecaradec]

Edit: I think I see why getQueryString() may be necessary -- I guess not everything that ends up causing trigger() to occur originates from FZip's emitResult().

Exactly The doDeferedSearch caused a new search and it was painful to keep the correct query synchronized. The dark side was easier...