Re: [Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8
Brought to you by:
srinathava,
tmaas
From: Benji F. <be...@me...> - 2002-12-11 16:51:42
|
Srinath Avadhanula wrote: > I am glad we are having this discussion on the way to implement this. > Hopefully, we will be able to come up with a nice long term solution... I agree. [snip] > I think its essential to understand how placeholders are used... They > are a bit more flexible than that. The only place where we need to > ensure that there are no fake strings like '<f, g>' is in latex-suite > itself. Its okay if the user has them at other places in the file. In > this case, the user chooses a different value of g:Imap_PlaceHolder* > variables. >=20 > Just to be clear, the only real problem with hardcoding something like > '<' or '<+' into latex-suite is only when latex-suite itself has some > macros defined with strings like '<+something+>' without meaning for > them to be placeholders. OK, I had a good, long look at imaps.vim. As currently written,=20 IMAP() and IMAP_PutTextWithMovement() are global functions, and their=20 input has to use the hard-coded special values. This could be a problem=20 if, for example, "<<" and ">>" are used a French quotation marks, and=20 the user wants them in the replacement text. I think the=20 [bg]:Imap_PlaceHolder* should be used internally as well as in the file. > Also, <C-j> only deletes the placeholders if they are things like > "<++>". If there is some explanation like "<+something+>", then it wont > get deleted by pressing <C-j>. It will be replaced when you type some > printable char. Good. > Again, just to emphasize, we are not trying to decide on a single > character to be used across all languages/locales etc. We are just > trying to decide for latex-suite... imaps.vim is kinda independent of > this. (At present, Imap_PutTextWithMovement tries to replace certain > patterns in the lhs with the user's place holder settings. This should > be moved over to something in latex-suite). [snip] >=20 >>IMAP(). I propose changing this to >> >> :call IMAP(ft, lhs, rhs1, ph1, rhs2, ph2, ...) >> >=20 > This is a beautiful solution. But consider that not all macros in > latex-suite are triggered from IMAP(). Some of them do something like: >=20 > inoremap <M-c> <C-r>=3DTex_MathCal()<CR> >=20 > Then Tex_MathCal() does: >=20 > return Imap_PutTextWithMovement("\\cite{=AB=BB)=AB=BB") >=20 > So I suppose we will also have to change Imap_PutTextWithMovement() to > accept variable arguments... Although the solution above does look lik= e > it could be _the_ correct solution, I have a feeling that hardcoding > placeholders is not such a big deal at all... >=20 > Assumption: >=20 > latex-suite will never need to use strings like "<+something+>" except > for demarcating placeholer characters. > This assumtion is ****important***** >=20 > Execution: >=20 > envmacros.vim does: >=20 > call Tex_IMAP('`/', '\frac{<++>}{<++>}<++>', 'tex') >=20 > texrc does: >=20 > let g:Imap_PlaceHolderStart =3D "\xab" > let g:Imap_PlaceHolderEnd =3D "\xbb" >=20 > We define a new function Tex_IMAP which replaces "<+" with the user's > choice of g:Imap_PlaceHolderSetting and then call IMAP() with this new > thing. Similary Imap_PutTextWithMovement is replaced with > Tex_PutTextWithMovement. >=20 > Finally, when the user press `/, he expands to \frac{|}{=AB=BB}=AB=BB w= here | is > the cursor position. If he wants he could set a different value of the > place holder, if =AB=BB does not display nicely on his comp or if he us= es a > language where =AB=BB are legitimate chars. >=20 > NOTE: imaps.vim will no longer try to replace the "<+" chars with > [gb]:Imap_PlaceHolderStart. It will only use this setting in the > Imap_JumpFunc(). >=20 > Therefore, we could presumably have a user with an ftplugin/xml.vim > file where he sets: >=20 > let b:Imap_PlaceHolderStart =3D '?' > let b:Imap_PlaceHolderEnd =3D '?' >=20 > call IMAP('li`', '<li>??</li>??', 'xml') >=20 > The crazy mathematician does >=20 > " I have proved that the following strings occur with a probability > " less than 1/(2*pi)^5*10e-12 in my files. I hope this is safe > " enough. > let b:Imap_PlaceHolderStart =3D '%xdf@#$' > let b:Imap_PlaceHolderEnd =3D '*&#$*&' >=20 > When he presses `/, he will get \frac{|}{%xdf@#$*&#$*&}%xdf@#$*&#$*& > with | ofcourse denoting cursor position. >=20 > Does this make everyone happy? >=20 > Please try to come up with cases where the above system might fail... >=20 > Okay... this mail is getting out of hand... >=20 > Srinath I think your proposal will work, but I think it will be hard to=20 maintain. First, I do not like the idea of an extra level of=20 indirection: Tex_Foo() as a wrapper for IMAP_Foo(). Second, it is=20 strange for Tex_Foo() to know about the "<+" character in LaTeX suite=20 and also the [bg]:Imap_PlaceHolder* variables. I propose changing the IMAP() and Imap_PutTextWithMovement()=20 functions with versions that take a variable number of arguments, as=20 discussed above. Internally and in the file, they will use the=20 [bg]:Imap_PlaceHolder* variables, with "<+" and "+>" as the defaults.=20 This scheme has the following advantages (some of which your proposal=20 shares): 1. no funky characters in script files 2. Scripts that call IMAP() and Imap_PutTextWithMovement() do not need=20 to know what the special characters are. 3. When the user decides to change [bg]:Imap_PlaceHolder*, nothing else=20 needs to be changed. There are also some other changes I would like to make. 4. Is there any reason not to use curly-brace variables? These are=20 available in all vim 6.x (i.e., not new in 6.1 and not, as far as I can=20 tell, a compilation option). 5. I would like to move the documentation from the comments to=20 doc/imaps.txt . 6. other clever simplifications If we can agree on the IMAP(ft, lhs, ...) approach, then I will do=20 the work. I should be able to get some of it done on Friday. --Benji |