On Mon 1-Dec-08 7:42am -0600, Tony Mechelynck wrote: > > On 01/12/08 14:18, Bill McCarthy wrote: >> On Sun 30-Nov-08 4:47pm -0600, Tony Mechelynck wrote: >> >>> On 30/11/08 12:53, Bram Moolenaar wrote: >>>> Patch 7.2.058 >>>> Problem: Can't add a patch name to the ":version" output. >>>> Solution: Add the extra_patches array. >>>> Files: src/version.c >>> [...] >>> >>> Nice new feature :-). However, unlike the "Modified by" line and the >>> "highest standard patch number", it is reflected only in the output of >>> ":version" -- not on the ":intro" screen, where even the fact that >>> "extra" patches are present does not appear. Is this intentional? >> >> Interesting. I've added the extra patch description similar >> to yours. A similar patch to version.c could be added to >> the floating point patch. >> >> This would require, whenever eval.c is changed: (1) >> reversing the patch, (2) applying Bram's patches then (3) >> reapplying the floating point patch. This is the same >> process others may use today - no change.
> Well, as long as the patch applies (with line shifts but no errors) > there's no urgency to unapply-reapply, I suppose. > > Anyway, as soon as one has more than one "extra patch" applied, > reversing the earlier one will give lineshifts, if only because it is > now lower in version.c Sorry, that email was a draft that I thought I hadn't sent this morning. BTW, I have a fairly formal procedure for dealing with eval.c patching: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Instructions for patching eval.c ================================ 1) Run PREBRAM to copy eval.c.bram to eval.c 2) Run the patches from Bram 3) Run POSTBRAM to copy eval.c to eval.c.bram 4) Run PEVAL to both patch eval.c and asks to finish The finish is POSTEVAL - copies eval.c to eval.c.wjm At any time you can run DEVAL for a directory of eval.* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > See also the variant with "#ifdef FEAT_FLOAT" in the next post to the > one you quoted above. (I'm using common sources [with a shadowdir] for a > huge gvim and a tiny vi, as close as I can get to both ends of the > capability range, and I don't want vi (with -float) to boast about a > patch which is actually disabled in it.) Nice addition. -- Best regards, Bill --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
