On Thu, Oct 08, 2009 at 01:15:08PM +0200, Richard Pöttler wrote: > Thanks for this. I will try it, once I got some more spare time. > May I keep your address as a contact, if I get into some trouble?
You're welcome to (and maybe you'll give an idea or two on how to proceed wrt cpan as well :>). > > Also a way to get one's manually committed sins into the scripts > > database. A way to have the script detect and remark (not touch) such > > sins? > > Nice idea. One thing, which might get complicated is, how to determine, > whether some updates for this "custom" scripts are available. Should the > url be fetched and then the md5sum compared with a stored one, or the > entire page (assuming it is a html page) be searched for a given > pattern? I'd rather keep it simple, and just consider vim.sf.net via Dr.Chips GetLatest* script and instead provide a way to assist in dealing with script or configuration associated meta information (I changed that, look there on the authors homepage, did this, moved that, set this to use that script). For more detailed replies to your questions, let me sketch what I'd try as a first attempt for each of them: Detect a script being modified: - have the user place a <samename>.diff in there might be the easiest or even more basic: require the user to edit the database and set some field. - wrt md5sum: might require even mangling the line-end before calculation to not see a difference on just files being safe on the wrong os. Detect a newer version: - probably sanest to just restrict yourself to vim.org. I'd expect the authors to mention major updates heres or bump versions once in a while. - AFAIR there were some screen or web-scrapers trying to outguess an authors best attempt at version obfuscation (filename or even dir does change on update). Others always use the same link, in which case just burning bandwidth might suffice. * But instead of going there (maybe excepting vim.org via Dr.Chips * GetLatest) I'd rather want two options to extract the update link * urls from the database (esp. for non vim.org / vim.sf.net scripts): one would be an url per line, the other would be a html file listing name, link and version (sorted on name). That should be enough support to ease *manually checking* the script's parent sites once in a long while. Mark scripts that are maintained e.g. by GetLatest or the symlinks created by some distro tools like vim-addons (vim-addon-manager package in Ubuntu). * More assistance tool than risk being too clever. * Provide a place to keep the meta information, and suggest a * reusable structure for such information Updating: - BE CAREFUL if not asking the user for a double check. VERY VERY CAREFUL. Backup. Don't delete backups for at least a month. - In case of doubt, maybe download it, maybe even unpack it, and just report it instead of possibly overwriting things. More of like an assistance mode than trying to be too clever. DrChip's GetLatestVimScripts pretty much reads like this IF a) autoinstall can be turnedoff (yes: g:getLatestVimScripts_allowautoinstall) and b) bulks at autoinstall if a local change is detected (both content or maybe also location). One way for reuse would be to generate it's *.dat just before a run. At the minimum ensure that the scripts play nice with each other (e.g. in the above report, add a flag 'auto-updated' unless the scriptid is manually set to 0 as that one comment hints). Given the ugly tricks in vimscript #2768, it should be possible to _make_ GetLatest callable from Perl, even when run by cron. Also check 2613, 2444, which do something similar to GetLatest outside of vim to allow for cron [I'm no user of these either:)] > How do you have it now? manual hunting for updates or bad scripts only in case of errors :/. Happened only once to me, started with tracking down the script (move everything out of .vim and slowly moving things back & test & iterate). Ended surprisingly quick: with a workaround and a vim bug being filed by the author. -- cu Peter l Jakobi [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
