vim-latex-devel

[Vim-latex-devel] new version of imaps.vim

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

sri...@us... wrote:
> Modified Files:
>       Tag: b-newimaps
> 	imaps.vim=20
> Log Message:
> . modified the older version (Tex_IMAP) to use the new IMAP() function.
> . changed Tex_PutTextWithMovement() to just a hack. It substitutes '<+'=
 and
>   '+>' with the s:PlaceHolder*() variables and then calls the new
>   Imap_PutText...

      Thanks.  That was on my TODO list:  make Tex_IMAP() and=20
Tex_PutTextWithMovement() wrappers for the new versions.

> sorry for the short cvs log. I am running really late.
>=20
> NOTE: This is a work in progress. the changed version of Tex_IMAP() is =
not
> yet working quite robustly enought. It is sometimes generating more
> arguments than are needed.

      Examples?  Maybe my simplified version will work better.

> This commmit will be followed by another huge commit which is essential=
ly
> replacing all =E4 characters with <++>, =AB with <+ and so on....

      That was also on the TODO list. ;)

> Therefore...
>=20
> FROM HENCEFORTH:
>=20
> Use <+ and +> instead of =AB and =BB
>=20
> Better still, dont use any placeholders at all and use the new IMAP()
> function.

      Can you test this?  It might be a solution to the remaining=20
encoding problems.

:let foo =3D "\xab"
:echo iconv(foo, "latin1", &enc) =3D~ foo

It should return 1 (I hope).

					--Benji

Re: [Vim-latex-devel] new version of imaps.vim

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

This is bad! We have a problem with vim's limitation of only letting
functions take upto 20 arguments...

On Sat, 14 Dec 2002, Benji Fisher wrote:

> > NOTE: This is a work in progress. the changed version of Tex_IMAP() is not
> > yet working quite robustly enought. It is sometimes generating more
> > arguments than are needed.
>
>       Examples?  Maybe my simplified version will work better.

Thanks for the simplifications!  Turns out the Tex_IMAP() function was
fine. But the following

call Tex_IMAP('EPI', "\\begin{picture}(<+width+>, <+height+>)"
                \ . "(<+xoff+>,<+yoff+>)\<cr>\\put(<+xoff+>,<+yoff+>)"
                \ . "{\\framebox(<++>,<++>){<++>}}\<cr>\\end{picture}<++>",
                \ 'tex')

creates more than 20 arguments!

Now what? A long term solution to this problem is ofcourse changing vim
to be more script friendly and accept more than 20 arguments (Its bad
that there are limitations in the first place!). But I suspect that Bram
will most probably ask us to use some hack to get around the limitation
rather than change things... And even if he does change it, it will be
bad to make latex-suite depend on the very latest vim being installed.

So... Whats the hack around it?

Maybe if IMAP() is called with the same LHS more than once, it appends
this RHS to the previous RHS? Then change Tex_IMAP() to call
IMAP() with chunks of 20 arguments each time? This is sad... A simple
function getting needlessly complex.

I'll let others think about it / implement it :)

About imaps... For sometime I have been thinking of having IMAPS() take
a flag which makes it "safe", i.e if the user defines other mappings
with the same LHS before latex-suite, it will not override his
mappings... Now the flag argument could also be useful for telling us
whether this is part of an append or an entirely new RHS... The flag
cannot be optional. It will have to be left as '' if we just want it to
overwrite like now.

>       Can you test this?  It might be a solution to the remaining
> encoding problems.
>
> :let foo = "\xab"
> :echo iconv(foo, "latin1", &enc) =~ foo
>

Yes. This seems to echo 1 with encoding set to both 'latin1' and
'utf8'...

Another thing to note: There seem to be a lot of patches in vim 6.0
towards MB chars... Therefore, maybe we should only test on vim 6.0 w/o
patches henceforth, so we have the safest...

Srinath

-- 
Srinath Avadhanula
Dec 14 12:13pm
According to Arkansas law, Section 4761, Pope's Digest:  "No person
shall be permitted under any pretext whatever, to come nearer than
fifty feet of any door or window of any polling room, from the opening
of the polls until the completion of the count and the certification of
the returns."

[Vim-latex-devel] Re: new version of imaps.vim

[Luc H. <her...@fr...>]

* On Sat, Dec 14, 2002 at 12:38:10PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> This is bad! We have a problem with vim's limitation of only letting
> functions take upto 20 arguments...

Is it the same with commands ?


> call Tex_IMAP('EPI', "\\begin{picture}(<+width+>, <+height+>)"
>                 \ . "(<+xoff+>,<+yoff+>)\<cr>\\put(<+xoff+>,<+yoff+>)"
>                 \ . "{\\framebox(<++>,<++>){<++>}}\<cr>\\end{picture}<++>",
>                 \ 'tex')
> creates more than 20 arguments!

> So... Whats the hack around it?

template-files ?
Moreover, it is easier for the end user to configure -- if he needs to.

> [encoding]
> Another thing to note: There seem to be a lot of patches in vim 6.0
> towards MB chars... Therefore, maybe we should only test on vim 6.0
> w/o patches henceforth, so we have the safest...

I ran Benji's `experiment' on Gvim-win32 6.1-263 on MsWindows Me.
And I get the same result he did.


-- 
Luc Hermitte
http://hermitte.free.fr/vim/

Re: [Vim-latex-devel] new version of imaps.vim

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

Srinath Avadhanula wrote:
> This is bad! We have a problem with vim's limitation of only letting
> functions take upto 20 arguments...

      Ouch.  I forgot about that. :-(

> On Sat, 14 Dec 2002, Benji Fisher wrote:
> 
> 
>>>NOTE: This is a work in progress. the changed version of Tex_IMAP() is not
>>>yet working quite robustly enought. It is sometimes generating more
>>>arguments than are needed.
>>
>>      Examples?  Maybe my simplified version will work better.
> 
> 
> Thanks for the simplifications!  Turns out the Tex_IMAP() function was
> fine. But the following
> 
> call Tex_IMAP('EPI', "\\begin{picture}(<+width+>, <+height+>)"
>                 \ . "(<+xoff+>,<+yoff+>)\<cr>\\put(<+xoff+>,<+yoff+>)"
>                 \ . "{\\framebox(<++>,<++>){<++>}}\<cr>\\end{picture}<++>",
>                 \ 'tex')
> 
> creates more than 20 arguments!

      Just barely...

> Now what? A long term solution to this problem is ofcourse changing vim
> to be more script friendly and accept more than 20 arguments (Its bad
> that there are limitations in the first place!). But I suspect that Bram
> will most probably ask us to use some hack to get around the limitation
> rather than change things... And even if he does change it, it will be
> bad to make latex-suite depend on the very latest vim being installed.

      The last point is a good one.  No, we have to find a way with vim 
as it is.

> So... Whats the hack around it?
> 
> Maybe if IMAP() is called with the same LHS more than once, it appends
> this RHS to the previous RHS? Then change Tex_IMAP() to call
> IMAP() with chunks of 20 arguments each time? This is sad... A simple
> function getting needlessly complex.

      Too complex.  Maybe we should abandon the variable-argument idea 
and go back to the drawing board.  How about

:fun! IMAP(lhs, rhs, ft, ...)

compatible with the original, but allowing optional place-holders?  In 
other words, use the calling pattern that you came up with for Tex_IMAPS().

> I'll let others think about it / implement it :)
> 
> About imaps... For sometime I have been thinking of having IMAPS() take
> a flag which makes it "safe", i.e if the user defines other mappings
> with the same LHS before latex-suite, it will not override his
> mappings... Now the flag argument could also be useful for telling us
> whether this is part of an append or an entirely new RHS... The flag
> cannot be optional. It will have to be left as '' if we just want it to
> overwrite like now.

      I think that this should be implemented by a variable, 
[bg]:Imap_noclobber or some such.  The user is not going to change all 
the calls to IMAP() in the latex-suite files.

>>      Can you test this?  It might be a solution to the remaining
>>encoding problems.
>>
>>:let foo = "\xab"
>>:echo iconv(foo, "latin1", &enc) =~ foo
> 
> Yes. This seems to echo 1 with encoding set to both 'latin1' and
> 'utf8'...

      Good.  According to the docs, iconv() should always be able to 
convert between utf-8 and latin1.  That is almost as good as knowing 
that we can convert between these and &enc.

> Another thing to note: There seem to be a lot of patches in vim 6.0
> towards MB chars... Therefore, maybe we should only test on vim 6.0 w/o
> patches henceforth, so we have the safest...

      I guess I should boot into W95 from time to time.  I have an 
unpatched 6.1 there; I could install an unpatched 6.0 as well...

					--Benji

Re: [Vim-latex-devel] new version of imaps.vim

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

> > call Tex_IMAP('EPI', "\\begin{picture}(<+width+>, <+height+>)"
> >                 \ . "(<+xoff+>,<+yoff+>)\<cr>\\put(<+xoff+>,<+yoff+>)"
> >                 \ . "{\\framebox(<++>,<++>){<++>}}\<cr>\\end{picture}<++>",
> >                 \ 'tex')
> >
> > creates more than 20 arguments!
>
>       Just barely...
>

Yeah... That might be the only one we ever encounter! Well, on second
thoughts, if vim can limit the arguments, why dont we make imaps also
restrict each map to have only 20 placeholders? ... No... Now I am
sounding just like a sulky kid.

> > Maybe if IMAP() is called with the same LHS more than once, it appends
> > this RHS to the previous RHS? Then change Tex_IMAP() to call
> > IMAP() with chunks of 20 arguments each time? This is sad... A simple
> > function getting needlessly complex.
>
>       Too complex.  Maybe we should abandon the variable-argument idea
> and go back to the drawing board.  How about

It is not too complex... It will be an additional check for the
existense of s:Map_{ft}_{lhs} before assigning something to it.
Ofcourse, Tex_IMAP() will have to do a fair bit of juggling. But I
agree, it might not be worth it...

>
> :fun! IMAP(lhs, rhs, ft, ...)
>
> compatible with the original, but allowing optional place-holders?  In
> other words, use the calling pattern that you came up with for Tex_IMAPS().
>

Hmm... Its kinda sad to have to abandon the better idea because of some
artificial limitation like this :( Well, the thing above is not so bad I
suppose. For all practical purposes, it will be as extensible as the new
idea...

Also, it will be easier to use in situations like the example I
mentioned in a previous mail, where a template is constructed within a
function...

> > Yes. This seems to echo 1 with encoding set to both 'latin1' and
> > 'utf8'...
>
>       Good.  According to the docs, iconv() should always be able to
> convert between utf-8 and latin1.  That is almost as good as knowing
> that we can convert between these and &enc.
>
Will this mean an end to our encoding woes at last without having to
change encoding to and fro? That will be good news indeed.

>       I guess I should boot into W95 from time to time.  I have an
> unpatched 6.1 there; I could install an unpatched 6.0 as well...

Well, I guess you can leave the testing on windows up to me. I will let
others deal with UNIX issues...

So time to come up with a plan again... What are the
IMAP() and IMAP_PutTextWithMovement() functions going to look like?
I guess before implementing the functions themselves, we can design the
prototypes:

" IMAP: set up a filetype specific mapping.
" Description:
"   "maps" the lhs to rhs in files of type 'ft'. If supplied with 2
"   additional arguments, then those are assumed to be the placeholder
"   characters in rhs. If unspecified, then the placeholder characters
"   are assumed to be '<+' and '+>' These placeholder characters in
"   a:rhs are replaced with the users setting of
"   [bg]:Imap_PlaceHolderStart and [bg]:Imap_PlaceHolderEnd settings.
"
function! IMAP(lhs, rhs, ft, ...)

" IMAP_PutTextWithMovement: returns the string with movement appended
" Description:
"   If a:str contains "placeholders", then appends movement commands to
"   str in a way that the user moves to the first placeholder and enters
"   insert or select mode. If supplied with 2 additional arguments, then
"   they are assumed to be the placeholder specs. Otherwise, they are
"   assumed to be '<+' and '+>'. These placeholder chars are replaced
"   with the users settings of [bg]:Imap_PlaceHolderStart and
"   [bg]:Imap_PlaceHolderEnd.
function! IMAP_PutTextWithMovement(str, ...)

Srinath

Re: [Vim-latex-devel] new version of imaps.vim

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

Srinath Avadhanula wrote:
> 
>>:fun! IMAP(lhs, rhs, ft, ...)
>>
>>compatible with the original, but allowing optional place-holders?  In
>>other words, use the calling pattern that you came up with for Tex_IMAPS().
> 
> Hmm... Its kinda sad to have to abandon the better idea because of some
> artificial limitation like this :( Well, the thing above is not so bad I
> suppose. For all practical purposes, it will be as extensible as the new
> idea...

      I am also reluctant to abandon the "new" (old new?) method, having 
gone to the trouble of implementing it, but this seems like the right 
thing to do.

[snip discussion of iconv]

> Will this mean an end to our encoding woes at last without having to
> change encoding to and fro? That will be good news indeed.

      As long as our templates do not use non-standard characters, the 
main problems will go away (unless I am missing something).  If the user 
chooses place holders, or an a:lhs (maybe a:rhs) for IMAP(), that uses 
non-standard characters, there may still be trouble, and I think we can 
get around it with iconv().

> So time to come up with a plan again... What are the
> IMAP() and IMAP_PutTextWithMovement() functions going to look like?
> I guess before implementing the functions themselves, we can design the
> prototypes:
> 
> " IMAP: set up a filetype specific mapping.
> " Description:
> "   "maps" the lhs to rhs in files of type 'ft'. If supplied with 2
> "   additional arguments, then those are assumed to be the placeholder
> "   characters in rhs. If unspecified, then the placeholder characters
> "   are assumed to be '<+' and '+>' These placeholder characters in
> "   a:rhs are replaced with the users setting of
> "   [bg]:Imap_PlaceHolderStart and [bg]:Imap_PlaceHolderEnd settings.
> "
> function! IMAP(lhs, rhs, ft, ...)

      I think that, if left unspecified, the placeholders go through the 
same logic as before:  [bg]:Imap_PlaceHolderStart and 
[bg]:Imap_PlaceHolderEnd, then default to '<+' and '+>'.  The optional 
arguments should always be supplied, except in two cases:

(1) a:rhs does not contain any place holders (not even for cursor placement)

(2) in an ftplugin or similar file, where b:Imap_PlaceHolderStart and 
b:Imap_PlaceHolderEnd have been defined.

> " IMAP_PutTextWithMovement: returns the string with movement appended
> " Description:
> "   If a:str contains "placeholders", then appends movement commands to
> "   str in a way that the user moves to the first placeholder and enters
> "   insert or select mode. If supplied with 2 additional arguments, then
> "   they are assumed to be the placeholder specs. Otherwise, they are
> "   assumed to be '<+' and '+>'. These placeholder chars are replaced
> "   with the users settings of [bg]:Imap_PlaceHolderStart and
> "   [bg]:Imap_PlaceHolderEnd.
> function! IMAP_PutTextWithMovement(str, ...)

      Same comment.

> Srinath

      I may have a little time tomorrow to work on this.  (Morning: 
write solutions to exam.  Afternoon:  proctor the exam.  How do I fit in 
some vimming?  Bring my laptop and use the school's wireless network! ;) 
  Then comes the grading ...)

					--Benji

Re: [Vim-latex-devel] new version of imaps.vim

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

On Mon, 16 Dec 2002, Benji Fisher wrote:

> > Hmm... Its kinda sad to have to abandon the better idea because of some
> > artificial limitation like this :( Well, the thing above is not so bad I
> > suppose. For all practical purposes, it will be as extensible as the new
> > idea...
>
>       I am also reluctant to abandon the "new" (old new?) method, having
> gone to the trouble of implementing it, but this seems like the right
> thing to do.

Well, its not a complete loss. All the simplifications in imaps.vim will
still be retained... Basically, IMAP() and LookupChar...() have both
been reworked compelteley. And it is conceptually simpler, which is
a benefit for end users I suppose...

> > function! IMAP(lhs, rhs, ft, ...)
>
>       I think that, if left unspecified, the placeholders go through the
> same logic as before:  [bg]:Imap_PlaceHolderStart and
> [bg]:Imap_PlaceHolderEnd, then default to '<+' and '+>'.  The optional
> arguments should always be supplied, except in two cases:
>
> (1) a:rhs does not contain any place holders (not even for cursor placement)
>
> (2) in an ftplugin or similar file, where b:Imap_PlaceHolderStart and
> b:Imap_PlaceHolderEnd have been defined.
>

Hmm... The reason I prefered the other way was that that way, all those
places in latex-suite which use IMAP() and Imap_Put...() will not be
changed much. More laziness speaking... But I suppose its better to be
safe than sorry... Will have to do a search and replace across all files
to change

Tex_IMAP(lhs, rhs, ft)

to IMAP(lhs, rhs, ft, '<+', '+>')

and the same for Tex_PutTextWithMovement...

But I am wondering if there are places where an IMAP() call is broken
across lines using \ or something.

>       I may have a little time tomorrow to work on this.  (Morning:
> write solutions to exam.  Afternoon:  proctor the exam.  How do I fit in
> some vimming?  Bring my laptop and use the school's wireless network! ;)
>   Then comes the grading ...)

Heh :) I was actually looking at the course web-site for what youre
teaching. Looks like a fun thing to teach...

Srinath

-- 
Srinath Avadhanula
Dec 16 9:21pm
Steinbach's Guideline for Systems Programming:
	Never test for an error condition you don't know how to
handle.

Re: [Vim-latex-devel] new version of imaps.vim

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

Srinath Avadhanula wrote:
> 
> On Mon, 16 Dec 2002, Benji Fisher wrote:
> 
> Well, its not a complete loss. All the simplifications in imaps.vim will
> still be retained... Basically, IMAP() and LookupChar...() have both
> been reworked compelteley. And it is conceptually simpler, which is
> a benefit for end users I suppose...

      Yes, they are simpler.  This is good for us, but I am not sure it 
affects the end user directly.

> Hmm... The reason I prefered the other way was that that way, all those
> places in latex-suite which use IMAP() and Imap_Put...() will not be
> changed much. More laziness speaking... But I suppose its better to be
> safe than sorry... Will have to do a search and replace across all files
> to change
> 
> Tex_IMAP(lhs, rhs, ft)
> 
> to IMAP(lhs, rhs, ft, '<+', '+>')
> 
> and the same for Tex_PutTextWithMovement...
> 
> But I am wondering if there are places where an IMAP() call is broken
> across lines using \ or something.

      I think something like this should work.  Wrap it in :argdo .

:g/\<IMAP\s*(/execute "normal! %i, '<+', '+>'\<Esc>"

>>      I may have a little time tomorrow to work on this.  (Morning:
>>write solutions to exam.  Afternoon:  proctor the exam.  How do I fit in
>>some vimming?  Bring my laptop and use the school's wireless network! ;)
>>  Then comes the grading ...)
> 
> 
> Heh :) I was actually looking at the course web-site for what youre
> teaching. Looks like a fun thing to teach...

      Yes, it was fun, but now I have to grade the final exams. :-( 
Luckily, it is a pretty small class.

      I just committed a new version of imaps.vim (in the b-newimaps 
branch).  I tested it with several variants (including phs = phe = "|") 
and it seems to work pretty well.  I have not yet edited the rest of the 
files to use the new/old syntax.  Since the new calling syntax is 
compatible with the original, it might be simpler to import the new 
imaps.vim into the main branch, and just replace Tex_IMAP() with IMAP(). 
  Either way, I should finish grading before I do any more work on this.

      Implementation notes:

1. I decided the best method was for IMAP() to store phs and phe in 
script variables.  These (along with rhs) are read by LookupChar() and 
passed to IMAP_PutTextWithMovement().  This avoids duplicating code 
between the two IMAP*() functions, and seems pretty robust in terms of 
allowing the default place holders in the rhs.  I have not yet 
documented this in the comments...

2. It would be easy to calculate lengths and use "\<bs>" and "\<space>" 
to position the cursor.  One of us put in a comment that this does not 
work because strlen() may not return the right thing, and this depends 
on the encoding. :-(  Instead, I chose to use the following marker:

let marker = phs . phs . phe . phe

using the "input" place holders.  I think this is quite safe, but there 
are a lot of cases to consider:  these are/are not the default place 
holders, ...  Anyway, the end op IMAP_PutTextWithMovement() is long and 
complicated, adn perhaps there is a simpler way.

					--Benji