Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.9.2.4,1.9.2.5

[Benji F. <be...@me...>]

Srinath Avadhanula wrote:
 > On Thu, 19 Dec 2002, Benji Fisher wrote:

Item 1:
======

 >>> " Break text up into "initial <+template+> final"; any piece may
 >>> be empty. let initial  = substitute(text, pattern, '\1', '') let
 >>> template = substitute(text, pattern, '\2', '') let final    =
 >>> substitute(text, pattern, '\3', '')
 >>>
 >>> This assumes that there is only a single <+template+> in the
 >>> text.
 >>
 >> Why do you say that?  The cursor should be placed on template; all
 >> the place holders in final will be replaced.

      This question still stands.

 > What I didnt quite understand was why you treated the first
 > placeholder seperately from the rest?
 >
 > Why not simply do
 >
 > let text = substitute(text, '\V'.phs.'\(\.\{-}\)'.phe,
 > phsUser.'\1'.pheUser, 'g')
[snip]
 > All of this code seems to do effectively what that one substitute
 > should be doing. (Note, I am not trying to save lines, using one
 > substitute also seems to be clearer logically). Or is there something
 > I am missing?

      Yes, I think you are missing something.  See the example below.

 >> let final = substitute(final, '\V'.startpat.'\(\.\{-}\)'.endpat, \
 >> escape(phs, '\') . '\1' . escape(phe, '\'), 'g')
 >
 > Precisely what I do in the latest version! escape(phs, '\') is
 > phsUser and so on...
 >
 >> I do not like your solution.  Part of the reason for these new,
 >> optional arguments is that the following should work:
 >>
 >> :call IMAP("foo", "bar <++> <<cursor>> <++> <<next>>", "", "<<",
 >> ">>")
 >>
 >> I think your method breaks this.
 >
[snip]
 > But with this fix, the example you give works just fine for me. I
 > _do_ use the optional arguments in the latest version too... Never
 > ignored them. In the example above, after pressing foo, I end up with
 >
 >
 > bar | <+cursor+> <++> <+next+>
 >
 > with the cursor shown at | if g:Imap_PlaceHolder's are left at
 > default values. If they are changed to something like '?' and '?',
 > then I get
[snip]
 >
 > Did your version do something different? I just checked and at least
 > for the example you mention it seems to work the same...

      I get

bar <++> <+cursor+> <++> <+next+>

with "<+cursor+>" highlighted in Select mode.  I think the intention of
the above call to IMAP() is to insert a literal "<++>" into the buffer, 
and position the cursor on "<<cursor>>" (modified to "<+cursor+>"). 
This is why I broke the string into initial, template, and final.

Item 2:
======

>>> Also, I dont think
>>>     let marker = phs . phs . phe . phe
>>> 
>>> is a "rare" enough string. As in the previous example, this could simply be
>>> ????. We do _not_ want to accidentally delete stuff from the user's files.
>>> 
>>>     let marker = '<!--- @#% Start Here @#% ----!>'

 >>> This sounds safer. Ofcourse, we could always make a search and be
 >>> sure, but I am willing to bet that this string will never happen
 >>> on purpose in some file.
 >>
 >> We only have to worry about the marker appearing in the text
 >> inserted by IMAP_PutTextWithMovement().  Can you think of an
 >> example where my marker is still there after the substitute()
 >> commands?
 >
 > Note that we could have
 >
 > let g:Imap_PlaceHolderStart = '?' let g:Imap_PlaceHolderEnd = '?'
 > call IMAP('foo', 'bar ?template? and 2 empty templates: ???? bar',
 > '', '?', '?')
 >
 > Then when we search backward from the end, we will not land at the
 > beginning... Ofcourse, this is an improbable scenario, but why take
 > the chance?

      I get "?" for the characters you are using, but I assume that your 
"2 empty templates" should look something like "<--><-->".  (I'll 
pretend tha the call to IMAP() gives "<-" and "->" as the place-holder 
arguments.)  My proposed marker is "<-<-->->", nested place holders.  We 
do not intend to support nested markers, and none of our substitutions 
respect them; this is why I think this is safe.  If "<-<-->->" did occur 
in the rhs argument, it would be not be there any more after the 
substitute() steps.

Item 3:
======

 >>> into the main trunk and get working on a next release version and
 >>> also solving the encoding problem once and for all...
 >>
 >> You forgot to mention testing.
 >
 > Absolutely. But I am wondering how to apply patches to the other
 > parts of the suite which need a stable interface to IMAP() and
 > IMAP_PutTextWithMovement(). I agree that we can take time testing on
 > the branch, but its somewhat essential to at least fix on a good
 > prototype. The internals can be optimized without hurrying...

      I think you are right:  the two items above are internal, and we 
can decide on what to do after merging the changed into the main branch. 
  I am done with grading, so I can do some more coding; but I do not 
want to make changes until we agree on what to do.  As the CVS docs say, 
"log messages are not a substitute for communication." ;)

					--Benji