Thread: [Vim-latex-devel] CVS keyword expansion
Brought to you by:
srinathava,
tmaas
Menu
▾
▴
vim-latex-devel
|
From: Srinath A. <sr...@fa...> - 2003-01-09 21:10:45
|
Hello, It looks like we need to rethink how to set the keyword expanion mode of our files... What would be ideal for us is if CVS is able to inhibit CRLF conversions while also permitting expansion of stuff such as $Header$. Unfortunately, it looks like CVS is a bit confused about line endings and keyword substitutions. The only way of inhibiting EOL conversions is to tell CVS that the file is binary, which unfortunately throws away keyword subsitution. The following thread in google groups sounded promising, but my cvs client doesn't seem to support the CVS_MODE variable which is proposed there. (The online manual at cvshome.org also doesn't mention CVS_MODE). It also mentions that jCVS is able to do what we want, but I do not have time right now to try it. http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=fa.ion3edv.6g8l9e%40ifi.uio.no&rnum=1&prev=/groups%3Fq%3Dline%2Bconversion%2Bgroup:fa.info-cvs%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Dfa.ion3edv.6g8l9e%2540ifi.uio.no%26rnum%3D1 The only way to have keyword expansion is therefore to remove the -kb flag from files. So the question is: Are there platforms for which the cvs client performs a CRLF conversion which vim doesn't like? Is one of us developers on such a platform? If so, should we bother unsetting the -kb flag to allow keyword subsitution? Or should we just forget about keyword substitution? Note, that since I make releases via my sourceforge shell account, the .zip and .tar.gz packages always have UNIX style EOLs in the files, which should be fine with vim on any platform... Srinath |
|
From: Benji F. <be...@me...> - 2003-01-09 21:45:59
|
Srinath Avadhanula wrote: > Hello, > > It looks like we need to rethink how to set the keyword expanion mode of > our files... What would be ideal for us is if CVS is able to inhibit > CRLF conversions while also permitting expansion of stuff such as > $Header$. Unfortunately, it looks like CVS is a bit confused about line > endings and keyword substitutions. The only way of inhibiting EOL conversions > is to tell CVS that the file is binary, which unfortunately throws away > keyword subsitution. > > The following thread in google groups sounded promising, but my cvs > client doesn't seem to support the CVS_MODE variable which is proposed > there. (The online manual at cvshome.org also doesn't mention CVS_MODE). > It also mentions that jCVS is able to do what we want, but I do not have > time right now to try it. > > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=fa.ion3edv.6g8l9e%40ifi.uio.no&rnum=1&prev=/groups%3Fq%3Dline%2Bconversion%2Bgroup:fa.info-cvs%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Dfa.ion3edv.6g8l9e%2540ifi.uio.no%26rnum%3D1 > > The only way to have keyword expansion is therefore to remove the -kb > flag from files. So the question is: > > Are there platforms for which the cvs client performs a CRLF conversion > which vim doesn't like? Is one of us developers on such a platform? If > so, should we bother unsetting the -kb flag to allow keyword > subsitution? Or should we just forget about keyword substitution? I think the only likely problem is if one of us uses DOS-style line endings, and they get uploaded to the CVS repository. How do we test this? Maybe we should each do a "cvs add" and then "cvs commit" on the test project, then someone using Linux (like me) can download the files and check with ":set ff?". I have always thought that -kb was a bit of an abuse. OTOH, I am not sure that keyword substitution gives us anything very useful. > Note, that since I make releases via my sourceforge shell account, the > .zip and .tar.gz packages always have UNIX style EOLs in the files, > which should be fine with vim on any platform... Can you add something to the makefile that will check for and correct line endings? It seems to be safe to run dos2unix on a file already in unix format; with the -k flag, it keeps the time stamp. --Benji |
|
From: Srinath A. <sr...@fa...> - 2003-01-10 00:56:47
|
On Thu, 9 Jan 2003, Benji Fisher wrote: > > I think the only likely problem is if one of us uses DOS-style > line endings, and they get uploaded to the CVS repository. How do we > test this? Maybe we should each do a "cvs add" and then "cvs commit" on > the test project, then someone using Linux (like me) can download the > files and check with ":set ff?". Okay. I just checked this. I did the following: (On my dos machine): dos > date > dosfile2 dos > unix2dos dosfile2 dos > cvs add dosfile2 dos > cvs ci -m 'was ff=dos when created' dosfile2 Then on my sourceforge account nix > cvs update nix > vim dosfile2 Guess what? I see the annoying ^M character at the EOL! But ff? gives me 'unix'. Setting ff=dos and saving doesn't help. However, doing 'dos2unix dosfile2' does help in removing the ^M character and ff is also correctly identified as unix... So well, I guess we are somewhat screwed if the file being commited is in dos format. I am wondering why this didn't happen already... But this problem is not really related to -kb at all... You'll notice that I didn't use -kb anywhere... If I do nix > cvs admin -kb dosfile2 nix > cvs update dosfile2 Even then, it doesn't help... So whats the conclusion from all this? I really don't know... > Can you add something to the makefile that will check for and > correct line endings? It seems to be safe to run dos2unix on a file > already in unix format; with the -k flag, it keeps the time stamp. Yes... I'll do this. But what about files in which there are spurious ^M characters? Srinath |
|
From: Mikolaj M. <mi...@wp...> - 2003-01-10 11:42:57
|
On Thu, Jan 09, 2003 at 04:56:42PM -0800, Srinath Avadhanula wrote: > Guess what? I see the annoying ^M character at the EOL! But ff? gives me > 'unix'. Setting ff=dos and saving doesn't help. However, doing > 'dos2unix dosfile2' does help in removing the ^M character and ff is > also correctly identified as unix... > So well, I guess we are somewhat screwed if the file being commited is > in dos format. I am wondering why this didn't happen already... It seems the only solution is to add in modeline ff=unix in all files. Mikolaj |
|
From: Benji F. <be...@me...> - 2003-01-10 12:09:21
|
Srinath Avadhanula wrote:
> On Thu, 9 Jan 2003, Benji Fisher wrote:
>
> Okay. I just checked this. I did the following:
>
> Then on my sourceforge account
>
> nix > cvs update
> nix > vim dosfile2
>
> Guess what? I see the annoying ^M character at the EOL! But ff? gives me
> 'unix'. Setting ff=dos and saving doesn't help. However, doing
> 'dos2unix dosfile2' does help in removing the ^M character and ff is
> also correctly identified as unix...
Try this:
nix > vim dosfile2
:set ffs?
If the 'fileformats' option does not include "dos" then it explains the
behavior you got. Try (still in vim)
:set ffs+=dos
:e!
and I think it will set 'ff' to "dos".
> So well, I guess we are somewhat screwed if the file being commited is
> in dos format. I am wondering why this didn't happen already...
Maybe the CVS CR/LF conversion did some good. I guess I am not
clear on how it caused problems in the first place...
> But this problem is not really related to -kb at all... You'll notice
> that I didn't use -kb anywhere... If I do
>
> nix > cvs admin -kb dosfile2
> nix > cvs update dosfile2
>
> Even then, it doesn't help...
>
> So whats the conclusion from all this? I really don't know...
>
>
>> Can you add something to the makefile that will check for and
>>correct line endings? It seems to be safe to run dos2unix on a file
>>already in unix format; with the -k flag, it keeps the time stamp.
>
>
> Yes... I'll do this. But what about files in which there are spurious ^M
> characters?
That counts as a "funky character" and should be removed anyway.
Before changing the makefile, you should check out a fresh copy and make
sure we do not have any ^M characters lurking. Can grep handle that?
Mikolaj Machowski wrote:
>
> It seems the only solution is to add in modeline ff=unix in all files.
I think this is worth doing. Even if we adopt another solution
(like using dos2unix in the makefile) this could be a second line of
defense. By itself, it is not quite enough: if I create a file with
DOS-style line endings, add the modeline, save it, and commit it, then
it still has DOS-style line endings. Vim only changes the line endings
when the file is loaded with that modeline.
--Benji
|
|
From: Srinath A. <sr...@fa...> - 2003-01-11 03:36:38
|
Hmm... It looks like my last "experiment" might have been flawed... Since it was very fishy that a file was being exported with CRLF EOLs even on a unix machine, I tried again: dos> date > dosfile3 dos> unix2dos dosfile3 dos> cvs add dosfile3 I checked to see if the file had the '-kb' sticky tag. It didnt. unix> cvs update unix> vim dosfile3 And now dosfile3 doesn't have the '^M' characters and its also ff=unix. So I don't know what went wrong last time... In any case, setting -kb for the files might actually be a bad idea because in some situations, a cvs client might create dos style files on a unix clients... Bad Idea! So what I propose is the following: Unsetting the -kb flag from all our files. This will have the side-effect that cvs clients on windows machines will create dos style EOLs. Therefore its not possible to create packages via a DOS machine... But as I mentioned previously, this shouldn't be a problem because I create releases from my linux account on sf.net. Also, it will enable using keyword substitution... Also, as far as verifying that the files are all in unix format at release time, Ulrich Spoerlin suggested I use: file `find . -print` | grep CRLF | sed s/:.*// | xargs dos2unix I'll add this to our makefile just to make doubly sure... Srinath PS: The tip about 'ffs' was very helpful! Turns out there that the system vimrc on sf.net sets lots of very nondefault values, one of those being 'ffs=unix' with the comment "I want to see those ^M characters when I am editing dos files"... Go figure. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X