Re: [Vim-latex-devel] Re: imaps, version of 3rd jan 2003

[Srinath A. <sr...@fa...>]

On Wed, 8 Jan 2003, Luc Hermitte wrote:
> > This was a bug. I have fixed it. Actually, fixing this bug made me
> > realize that I was making some other stuff needlessly complex. Things
> > are nice and simple after this bug fix. Thanks! See the latest version
> > in the cvs tree...
>
> I will check it. Does it works even when the cursor is within a
> placeholder boundaries ? [my last conclusions was that I need to call
> searchpair twice]

It does work... If you are in the middle of a placeholder and press
<C-j> it will goto the next placeholder. <C-K> selects the placeholder
you are current in...

> The guilty code is:
>     ':call histdel("/", -1)|let @/=histget("/", -1)'
> I think it is due to the fact it is returned as a string passed to
> '<c-r>='. Set 'cmdheight' to 2 or more to see the echoing.

Hmm... I dont see anything on the commandline even with cmdheight = 2.
Dunno... Maybe I'll randomly add a <silent> next time...

> In fact, I was wondering why a
>     :normal <Plug>IMAP_JumpForward
> wasn't enough ? Or may be directly a:
>     :call IMAP_JumpFunc(0)
>
> What makes the inclusive search so different and required ?
>
Well, here's the comment in the latest imaps.vim

" IMAP_Jumpfunc: takes user to next <+place-holder+> {{{
" Author: Luc Hermitte
" Arguments:
" direction: flag for the search() function. If set to '', search forwards,
"            if 'b', then search backwards. See the {flags} argument of the
"            |search()| function for valid values.
" inclusive: In vim, the search() function is 'exclusive', i.e we always goto
"            next cursor match even if there is a match starting from the
"            current cursor position. Setting this argument to 1 makes
"            IMAP_Jumpfunc() also respect a match at the current cursor
"            position. 'inclusive'ness is necessary for IMAP() because a
"            placeholder string can occur at the very beginning of a map which
"            we want to select.
"            We use a non-zero value only in special conditions. Most mappings
"            should use a zero value.

In short, if we didn't take care of inclusion, then if we did

call IMAP('foo', '<+one+> <+two+>', '')

then on pressing foo we would be taken to <+two+>. This was something
from a while ago... I'll have to check whether we still need this
because it looks like /something/e has the effect of including a match
at the current position.

> I will eventually have to make many experiments in order to be able to:
> - let ftplugins change the values of opening and closing string
> - let ftplugins encoded in latin1, utf-8, etc
> - be compatible with any encoding of fileencoding for the current
>   buffer/file.
>
Benji has spent time on this and I think we have a working system right
now to do all of this. We have even thought of things like "what if the
placeholder setting was done in a file with 'fenc' different from the
tex file which the user is editing?" So if you want, you might want to
see whats done here.

> The important advantage: it wraps the call to iconv(). Neither the
> end-user nor the .texrc writter have to worry about calling iconv() for
> funky strings.
>
Yes. Benji wrote s:Iconv(), a wrapper for iconv() which does these
things

> I'm skeptical about their usefulness (English ?). When we need long
> tags/comments, I'd rather use a templates plugin like the one written by
> Robert "Feral" Kelly.

Well, even if we have some other ways of generating templates, I would
be very reluctant to have another function do the actual jumping between
placeholders. Code duplication! Besides, multi line placeholders were a
snap to support. Does this templates plugin offer something different?
Also, latex-suite does support templates in custommacros.vim

Srinath