vim-latex-devel — Mailing list for developers/maintainers of the vim-latex project

[Vim-latex-devel] Re: Review of vim-latex status

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

Hi,

* On Tue, Dec 24, 2002 at 01:11:30PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> Things which need to improve
> ============================
> 1. Atleast for me, the diacritics have been a longstanding source of
>    annoyance at unexpected times. Everytime I try doing a=b, I get
>    a\'{b}. And assignments like a=b are so common that this becomes
>    painful pretty fast. I would love to find out a better way to
>    implement support for diacritics. I am in fact thinking of disabling
>    diacritics by default unless we get some better ideas.

AFAIK, "a\'b" is valid, and most LaTeX implementations now support
8-bits characters. I.e.: I never write "\'e" (nor the ugly "\'{e}")
anymore, but simply "é". The diacritics stuff is useless to me, even
when I write documents in French. I'd rather type one more key when I
need to enter expanded diacritics like \oe -- since then, I added a more
logical digraph for oe (œ) into vim.
The format used by (La)TeX is very simple and logical.

> Future Directions
> =================
> These are things which are on my "cool things to do" list. Please feel
> free to share your own.

> 1. Dependency checking: i.e, when the user chooses the 'pdf' format,
>    latex-suite automatically compiles the dvi file, converts to ps and
>    then to pdf according to user preferences. I know that lh-tex (by
>    Luc) already has these kind of things implemented. 
>
>    But from what I can see, he has hardcoded the dependencies, i.e pdf
>    always follows from ps and things like that. I would think that we
>    could have options like

Yes and No.
The dependencies are indeed hardcoded, but I propose to ways to produce
the pdf file: thanks to (e)pdf(la)tex, or thanks to ps2pdf following a
first convertion done with 'dvips -Ppdf'.

I'd rather have both possibility beeing directly available (ie two
different mappings) from vim without having to change even only one
option.

> 	   Tex_FormatDepenency_pdf = 'ps'
> 	   Tex_FormatDepenency_ps = 'dvi'
> 	   Tex_FormatDepenency_dvi = 'tex'
>    which enable a customized dependency setting. 

I don't know if we can be that generic...

>    I propose that we have a discussion about the best way to implement
>    this. (Luc can start by telling us how he did it). 

...I already tried to factorize all common transformations into
sub-functions. The result is:
- s:Make() that runs ':make' (and saves vim-options before changing
  them, echoes different things, and checks for errors)
  Note: this is a low level function used by the TKMake{*}file()
  functions.
- s:CheckDeps() that checks dependency issues between two files (which
  one is newer than the other), and runs the proper s:TKMake{ext}file()
  function if needed.

- s:TKMakeDVIfile() : implements the main loop that converts .tex files
  into .dvi or .pdf. It also run bibtex, makeindex, etc if needed
- s:MakePdfTeXfile(...) <=> call <sid>TKMakeDVIfile((a:0>0)?(a:1):5, "pdf")
- s:TKMakePSfile() : implements the transformation .dvi->.ps
  does some other common things, _and_ checks weither we must use the
  -Ppdf option or not (according to the parameters passed). 
- s:TKMakePDFfile() : implements the transformation .ps->.pdf

You proposed to merge all the TKMake{*}file() functions into one. I fear
the result will be too complex because: 
- the transformation .tex->* is not like the other transformations
  (latex may have to be run three times or more, bibtex and makeindex
  may be used, etc)
- the tranformation .dvi->.ps checks one little parameter


What can be done is to have one dependencies engine (DE) that uses the
options you proposed, and the various TKMake functions. With a
registering facility, the DE could be extended with new functions
(because tomorrow, we rather produce an XMLfo document before the final
pdf -- odd idea, but we never know).
I'm not sure it is so important.

BTW: I have some similar functions to launch the various viewers.

>    Since this is (will be) such a core part of latex-suite,
>    I would like this to be implemented after a lot of thought.

> 2. Compilation Sequence: Again, Luc has implemented a way to run latex,
>    bibtex, makeindex etc according to what needs to be run etc. 

I don't deserve all the credits. The initial version is from Tomer Kol
(that why many function-names start with TK).

> 3. New developer: Becase Luc has implemented both 1 and 2 in lh-tex, I
>    propose that we get Luc into the developer team if he wants. To
>    start with, he can implement his ideas on a seperate branch.
>    Afterwards, we can merge this into the main trunk.

Why not. I won't have so many time to spend on the project, but I will
be glad to parcipate.
But beware, I have many, many ideas with some of them implemented in
completly different ways than the ones you choose for latex-suite.

> 4. Citation browser: I know that auctex from emacs has a feature where
>    it sets up a browsable window of the citations found in the bibtex
>    file. We could implement a system where if the user presses <Alt-c>,
>    \cite{} is inserted and the browser comes up asking him to choose a
>    citation.

Nice idea.

> 5. Removal of unwanted cruft: I am pretty sure latex-suite has features
>    which it can afford to lose.

6. Sometimes, I'd like some feedback about the last improvments I made
   in mu-template. But before, I must found some time to finish to write
   the documentation and to definitively fix the funky-characters issue.
   The big last improvment concerns the possibility to hit for instance:
   '\tab^R<SPACE>' which pops up a dialog box asking for which
   template-file we wish to expand (here: tabular, tabeqnarray, etc)

> Happy Holidays!!! (My girlfriend is dragging me off to some shopping
> now)
:-)

Happy holidays.

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

Re: [Vim-latex-devel] Review of vim-latex status

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

On Thu, 26 Dec 2002, Mikolaj Machowski wrote:

> Some new are awaiting in home for stabilization of new placeholders
> system.

The placeholder system has been stabilized.. If we do make any changes,
it will be internal changes, so the interace never changes... In all the
package files, just use the '<+' and '+>' characters instead of the old
=AB and =BB characters...

> diacritics are rarely used. If you need it for your national letters
> probably they are built-in in LaTeX and you don't need to play with =3Db
> things. Maybe disable it by default and add switch to turn it on/off?
>
Precisely what I was thinking... I will disable them by default.

> Why? pdflatex thing works good enough. Dvi format has advantage of
> possibility of forward/backward searching in dvi viewers but if you need
> it you will be making pdf files at the end of day.
>
Well, its just a nice thing to do... I gave pdf as an example... For ps
files, afaik, dvips is the only way... Morevoer, this will be
customizable. If the user wants to use pdflatex, he would be able to
tell latex-suite to use pdflatex which takes tex files not ps files...

> > 3. New developer: Becase Luc has implemented both 2 and 3 in lh-tex, I
> >    propose that we get Luc into the developer team if he wants. To star=
t
> >    with, he can implement his ideas on a seperate branch. Afterwards, w=
e
> >    can merge this into the main trunk.
>
> Fine :)

Luc, Please let us know if you think you like this idea...

Also, Carl Mueller has made invaluable contributions to latex-suite. If
he desires, he could join the team too

> > 4. Citation browser: I know that auctex from emacs has a feature where
> >    it sets up a browsable window of the citations found in the bibtex
> >    file. We could implement a system where if the user presses <Alt-c>,
> >    \cite{} is inserted and the browser comes up asking him to choose a
> >    citation.
>
> It could be done also for labels, refpages and so on. I did some time
> ago something like this. I have to find it...
>
Let's make this as general as possible, so the citation browser, the
reference browser etc only have to supply a list to some central handler
function...

> > 5. Removal of unwanted cruft: I am pretty sure latex-suite has features
> >    which it can afford to lose.
>
> Hmm. I would vote for "other miscellaneous stuff taken from imaps.vim in
> main.vim (lines 117-136 in my version). This is really redundant IMO.
>
Done! Feel free to suggest more deletions.

> 1. Move smartspace.vim and brackets.vim to ftplugin/latex-suite
> directory (and add proper lines in main.vim). Now they are in
> ftplugin/tex dir and they are automagically sourced. IMO this is a Bad
> Thing(tm). We do not have control in which order they are sourced and
> more important user doesn't have control.  Because this files have
> mappings user should have possibility to overwrite it. With latex-suite
> files in ftplugin/tex dir user have to give special names to be sure his
> files are sourced at the end.
>
Well, overwriting the maps is not a problem. See the latest version of
tex/brackets.vim. It does

if !hasmapto('Tex_MathBF', 'i') && mapcheck('<M-b>', 'i') =3D=3D ''
=09inoremap <buffer> <silent> <M-b> <C-r>=3DTex_MathBF()<CR>
endif

This enables a user to overwrite the plugin using something like

inoremap <buffer> <silent> mykey <C-r>=3DTex_MathBF()<cr>

his ftplugin/tex.vim file.

The reason I chose this way was this provides a nice (or at least easy)
way to extend latex-suite. The final aim is that each of these files is
kind of independent of the rest, so the user can pick up whatever pieces
he wants. Also note that tex_latexSuite.vim is still sourced before
files in the tex/ directory. Therefore latex-suite will still be able to
provide hooks to these plugins if wanted... I wonder what others think
of this issue...

> 2. Create vim-latex format with vim-latex menus integrated with normal
> Vim menus like this is in HTML editors. For example: disable Syntax
> menus, put TeX-Suite/Templates menu into File/New Latex File menu.
>
Hmmm... I am not really sure what you mean... What do you mean by
'vim-latex' format? Also, whats a natural place for the TeX-Environments
menu? That will have to be seperate, right?

Srinath

Re: [Vim-latex-devel] Review of vim-latex status

[Mikolaj M. <mi...@wp...>]

On Tue, Dec 24, 2002 at 01:11:30PM -0800, Srinath Avadhanula wrote:

Hello,

Sorry for not responding in last weeks but I was cutted off
from e-mail.

> 3. The packages.vim file was robustified. This has not yet been commited
>    to the main branch because I am still waiting to hear from Mikolaj.
>    Actually, not too many changes were made. Just the menu creating code
>    was changed and a function Tex_MakeSubMenu was extracted which will
>    be used in other parts of latex-suite in the future.

I am still on limited computer use. Please merge newpackages branch.
Well done. If you have any improvements in this area let me know.

> 4. Mikolaj added many new packages. Latex-suite now supports 38
>    packages! Support for the amsmath package is really excellent.

Some new are awaiting in home for stabilization of new placeholders
system.

> Things which need to improve
> ============================
> 1. Atleast for me, the diacritics have been a longstanding source of
>    annoyance at unexpected times. Everytime I try doing a=b, I get
>    a\'{b}. And assignments like a=b are so common that this becomes
>    painful pretty fast. I would love to find out a better way to
>    implement support for diacritics. I am in fact thinking of disabling
>    diacritics by default unless we get some better ideas.

diacritics are rarely used. If you need it for your national letters
probably they are built-in in LaTeX and you don't need to play with =b
things. Maybe disable it by default and add switch to turn it on/off?

> Future Directions
> =================
> These are things which are on my "cool things to do" list. Please feel
> free to share your own.
> 1. Dependency checking: i.e, when the user chooses the 'pdf' format,
>    latex-suite automatically compiles the dvi file, converts to ps and
>    then to pdf according to user preferences.

Why? pdflatex thing works good enough. Dvi format has advantage of
possibility of forward/backward searching in dvi viewers but if you need
it you will be making pdf files at the end of day.

> 3. New developer: Becase Luc has implemented both 2 and 3 in lh-tex, I
>    propose that we get Luc into the developer team if he wants. To start
>    with, he can implement his ideas on a seperate branch. Afterwards, we
>    can merge this into the main trunk.

Fine :)

> 4. Citation browser: I know that auctex from emacs has a feature where
>    it sets up a browsable window of the citations found in the bibtex
>    file. We could implement a system where if the user presses <Alt-c>,
>    \cite{} is inserted and the browser comes up asking him to choose a
>    citation.

It could be done also for labels, refpages and so on. I did some time
ago something like this. I have to find it...

> 5. Removal of unwanted cruft: I am pretty sure latex-suite has features
>    which it can afford to lose.

Hmm. I would vote for "other miscellaneous stuff taken from imaps.vim in
main.vim (lines 117-136 in my version). This is really redundant IMO.

My suggestions:

1. Move smartspace.vim and brackets.vim to ftplugin/latex-suite
directory (and add proper lines in main.vim). Now they are in
ftplugin/tex dir and they are automagically sourced. IMO this is a Bad
Thing(tm). We do not have control in which order they are sourced and
more important user doesn't have control.  Because this files have
mappings user should have possibility to overwrite it. With latex-suite
files in ftplugin/tex dir user have to give special names to be sure his
files are sourced at the end.

2. Create vim-latex format with vim-latex menus integrated with normal
Vim menus like this is in HTML editors. For example: disable Syntax
menus, put TeX-Suite/Templates menu into File/New Latex File menu.

Mikolaj

Re: [Vim-latex-devel] Review of vim-latex status

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

I knew I was forgetting something else...

On Tue, 24 Dec 2002, Srinath Avadhanula wrote:

> Things which were improved
> ==========================

I forgot some of the most important improvements!

Carl Mueller's suggestions have led to nice improvements in inserting
environments. I also find the bracket completion macros invaluable...
I haven't really used the polymorphic <M-c> macros too much yet, but
I am sure they will be a help as well...

Srinath

[Vim-latex-devel] Review of vim-latex status

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

Hello,

Its been quite a hectic coding time in the vim-latex project and its
time to step back and take note of all the things which we did/will do.

Things which were improved
==========================
1. imaps.vim: This was simplified by BF and also we think we have solved
   the encoding issues as far as we can tell. For me, on win32 and on
   some tests on unix machine, the current version just works.

2. Compilation: Carl Mueller's suggestion led to a pretty nifty compiler
   program which syns the quickfix window with the log preview window
   providing the advantages of both the quickfix window by allowing you
   to jump and get a quick overview of all errors while providing more
   detailed descriptions of each error via the log window.

3. The packages.vim file was robustified. This has not yet been commited
   to the main branch because I am still waiting to hear from Mikolaj.
   Actually, not too many changes were made. Just the menu creating code
   was changed and a function Tex_MakeSubMenu was extracted which will
   be used in other parts of latex-suite in the future.

4. Mikolaj added many new packages. Latex-suite now supports 38
   packages! Support for the amsmath package is really excellent.

5. A _lot_ of bugfixes happened since the last release.

Things which need to improve
============================
1. Atleast for me, the diacritics have been a longstanding source of
   annoyance at unexpected times. Everytime I try doing a=b, I get
   a\'{b}. And assignments like a=b are so common that this becomes
   painful pretty fast. I would love to find out a better way to
   implement support for diacritics. I am in fact thinking of disabling
   diacritics by default unless we get some better ideas.

2. This is as of now, poor documentation at various places. Often times,
   the script file contains documentation, whereas it should be in a
   doc/.txt file (in the case of imaps.vim). Sometimes, documentation is
   just plain missing (in the case of bibtex.vim). I suspect that there
   are quite a few features of latex-suite even I dont know about.
   Especially in the case of bibtex.vim, the lack of documentation and
   menu items etc leads it to be completeley lost to the end-user.
   Latex-suite really needs some time spent on documentation.

3. There are still 'funky' characters in various places of latex-suite
   leading to internationalization issues.

4. Some of the maps do not check for hasmapto(rhs) and mapcheck(lhs)
   before mapping. This needs to change.

Future Directions
=================
These are things which are on my "cool things to do" list. Please feel
free to share your own.

1. Dependency checking: i.e, when the user chooses the 'pdf' format,
   latex-suite automatically compiles the dvi file, converts to ps and
   then to pdf according to user preferences. I know that lh-tex (by
   Luc) already has these kind of things implemented. But from what I
   can see, he has hardcoded the dependencies, i.e pdf always follows
   from ps and things like that. I would think that we could have
   options like
	   Tex_FormatDepenency_pdf = 'ps'
	   Tex_FormatDepenency_ps = 'dvi'
	   Tex_FormatDepenency_dvi = 'tex'
   which enable a customized dependency setting. I propose that we have
   a discussion about the best way to implement this. (Luc can start by
   telling us how he did it). We could then come up with an framework we
   all agree on and then implement it in a manner consistent with
   latex-suite. Since this is (will be) such a core part of latex-suite,
   I would like this to be implemented after a lot of thought.

2. Compilation Sequence: Again, Luc has implemented a way to run latex,
   bibtex, makeindex etc according to what needs to be run etc. This too
   needs to be part of latex-suite. Again, I would think we should
   discuss this and then implement. Again, it will be a core part. For
   both points 1 and 2, we should I think come up with an empty vim file
   containing just funciton prototypes and documentation which we all
   agree on. After that, we will implement it.

3. New developer: Becase Luc has implemented both 2 and 3 in lh-tex, I
   propose that we get Luc into the developer team if he wants. To start
   with, he can implement his ideas on a seperate branch. Afterwards, we
   can merge this into the main trunk.

4. Citation browser: I know that auctex from emacs has a feature where
   it sets up a browsable window of the citations found in the bibtex
   file. We could implement a system where if the user presses <Alt-c>,
   \cite{} is inserted and the browser comes up asking him to choose a
   citation.

5. Removal of unwanted cruft: I am pretty sure latex-suite has features
   which it can afford to lose.

Happy Holidays!!! (My girlfriend is dragging me off to some shopping
now)

Srinath

Re: [Vim-latex-devel] ``''<<>>

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

Hey Fabio,

Benji implemented the new feature. I have uploaded the latest version
which includes this.

Srinath

On Fri, 20 Dec 2002, Fabio Spelta wrote:

> What I meant was
>
> to press " twice, and obtain not just ``'' (with the cursor at the end
> ot that) but ``''<<>>  with the cursor between `` and '', and the chance
> to jump out with ctrl-J !
>
> Sorry if my previous mail was not clear
>
> Thank you!
>

Re: [Vim-latex-devel] TexLet broken?

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

Srinath Avadhanula wrote:
> This was a bug... Double quotes were not supported. I have fixed it.
> Also, I tried to get imaps.vim to screw up by using various combinations
> of enc, fenc, funky placeholders etc, but couldn't succeed so far :)
> 
> So at least for me, the new encoding solution is a go!
> 
> Srinath

      Unfortunately, the fix does not affect anyonoe who made a copy of 
the texrc file.  I will not have time in the near future, but I would 
like to restructure texrc so that :TexLet and SafeLet() are defined 
elsewhere, the documentation is in doc/latexsuite.txt, and texrc itself 
is minimal.

					--Benji

Re: [Vim-latex-devel] ``''<<>>

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

I took a look at main.vim to implement this feature, but
unfortunately, couldn't quite understand the
Tex_Quotes() function! :( A simple look back for g:Tex_SmartQuoteOpen
and inserting '<++>'.g:Tex_SmartQuoteClose.'<++>' on a successful test
doesn't seem to work straight away because there seems to be a fair bit
of moving around in the file for finding out the quotes...

I would think that Benji would be able to do this much more easily
because he has implemented this... If I were to implement this, I would
have to spend a fair bit of time figuring out whats going on... and then
I get tempted to change things around to my liking...

Srinath

On Sat, 21 Dec 2002, Srinath Avadhanula wrote:

>
> I like Fabio's suggestion. If no one else is interested, I will add this
> feature. I dont think I'll add the option straight away. I dont think
> I'll add the option right now.
>
> Srinath
>

[Vim-latex-devel] Bug in packages.vim

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

Bug reports:

Bug 1.
=====
When <F5> is pressed on a line containing the word 'ifthen' (which
latex-suite does not support) in the preamble, then I get the following
errors:

-----------------------------------%<-----------------------------------
E15: Invalid expression:  g:TeX_package_ifthen
Error detected while processing function Tex_FastEnvironmentInsert..Tex_package_from_line..Tex_PutPackage..Tex_pack_supp..Tex_pack_check..Tex_pack:
line   57:
E121: Undefined variable: g:p_list
Error detected while processing function Tex_FastEnvironmentInsert..Tex_package_from_line..Tex_PutPackage..Tex_pack_supp..Tex_pack_check..Tex_pack:
line   57:
E15: Invalid expression:  GetListCount(g:p_list)

Error detected while processing function Tex_FastEnvironmentInsert..Tex_package_from_line..Tex_PutPackage..Tex_pack_updateall..Tex_pack_all..Tex_pack_check..Tex_pack:
line    6:
E121: Undefined variable: g:TeX_package_ifthen
Error detected while processing function Tex_FastEnvironmentInsert..Tex_package_from_line..Tex_PutPackage..Tex_pack_updateall..Tex_pack_all..Tex_pack_check..Tex_pack:
line    6:
E15: Invalid expression:  g:TeX_package_ifthen
Error detected while processing function Tex_FastEnvironmentInsert..Tex_package_from_line..Tex_PutPackage..Tex_pack_updateall..Tex_pack_all..Tex_pack_check..Tex_pack:
line   57:
E121: Undefined variable: g:p_list
Error detected while processing function Tex_FastEnvironmentInsert..Tex_package_from_line..Tex_PutPackage..Tex_pack_updateall..Tex_pack_all..Tex_pack_check..Tex_pack:
line   57:
E15: Invalid expression:  GetListCount(g:p_list)
-----------------------------------%<-----------------------------------

Just to ensure that these bugs did not occur because of the merge from
the new b-newimaps branch, I checked with version 1.14 of packages.vim
" Last Change: nie gru 08 05:00  2002 C

That version also gives the same error.

Bug 2.
=====
When I press <F5> on a line containing the word SIunits, then it gets
changed to:

\usepackage[0]<++>{SIunits}<++>

with the cursor after the 0. This bug was also reported by a latex-suite
user only a few days ago.

Bug 3
=====
Bug 2 also has a 'sub-bug'. My placeholder settings were ignored. If I
choose something different from <+ and +>, they are ignored.

The latest version on b-newpackages does not have this bug. That changes
the lines to
	\usepackage{ifthen}
and
	\usepackage[]<++>{SIunits}<++>
respectively. It also respects the placeholder settings.

Srinath

Re: [Vim-latex-devel] TexLet broken?

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

This was a bug... Double quotes were not supported. I have fixed it.
Also, I tried to get imaps.vim to screw up by using various combinations
of enc, fenc, funky placeholders etc, but couldn't succeed so far :)

So at least for me, the new encoding solution is a go!

Srinath

On Fri, 20 Dec 2002, Benji Fisher wrote:

>       I just tried " in Insert mode, expecting to get `` or '' but I got
> "``" (WITH the double quotes).  The problem seems to be with TexLet.
>
> :TexLet g:Foo = "``"
> :echo Foo
> "``"
>
> Has anyone changed TexLet recently?

Re: [Vim-latex-devel] Re: encoding woes

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

Benji Fisher wrote:
> 
>     I would like to start work on solving the encoding problems.  I 
> think we have to consider all combinations of
> 
> 1. 'enc' is latin1 or utf-8
> 2. 'fenc' is empty or latin1 or utf-8
> 3. the text or the "input" place holders or the "output" place holders 
> are outside the 7-bit ASCII range (i.e., they are "funky," to use the 
> technical term ;).
> 
>     What are the situations where real problems exist?

      I just updated imaps.vim (in the main branch, for the first time 
in a while).  I tested my solution with several comninations of (1) and 
(2) above, producing output like this:

enc = utf-8
fenc =
call IMAP('foo', "ba\xab\xbbr", "", "\xab", "\xbb")
	bar
call IMAP('frob', "bo\xab\xbbr\xabph\xbb", "", "\xab", "\xbb")
	bor<+ph+>
let g:Imap_PlaceHolderStart = "\xab"
let g:Imap_PlaceHolderEnd = "\xbb"
	bork

The first line was produced with <C-R>=&enc ; the second line was 
similar.  I copied the other non-indented lines to the command line. 
(y$ and then :<C-R>"<CR>).  The first indented line was produced with 
"foo"; the second with "frob"; the third with "frob\<C-J>k".  In all 
cases, the cursor was placed as expected.

      As far as I can tell, this solution works.  Let me know if I 
missed a problem, or created one.

					--Benji

Re: [Vim-latex-devel] ``''<<>>

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

I like Fabio's suggestion. If no one else is interested, I will add this
feature. I dont think I'll add the option straight away. I dont think
I'll add the option right now.

Srinath

On Sat, 21 Dec 2002, Benji Fisher wrote:

>  > What I meant was
>  >
>  > to press " twice, and obtain not just ``'' (with the cursor at the end
>  > ot that) but ``''<<>>  with the cursor between `` and '', and the chance
>  > to jump out with ctrl-J !
>  >
>  > Sorry if my previous mail was not clear
>  >
>  > Thank you!
>
>        That is a possibility.  It would require modifying s:TexQuotes()
> in main.vim, and adding another option.
>
> 					--Benji

Re: [Vim-latex-devel] Re: encoding woes

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

Luc Hermitte wrote:
* On Fri, Dec 20, 2002 at 10:04:43AM -0500, Benji Fisher=20
<be...@me...> wrote:

     I would like to start work on solving the encoding problems.  I=20
think we have to consider all combinations of

1. 'enc' is latin1 or utf-8
2. 'fenc' is empty or latin1 or utf-8
3. the text or the "input" place holders or the "output" place holders=20
are outside the 7-bit ASCII range (i.e., they are "funky," to use the=20
technical term ;).

     What are the situations where real problems exist?

      This is the question I would like answered for now.  What=20
situations are actually broken in the current version?

Can we have any certitude about the encoding used by the script file ?
So far, we write our scripts in latin1. But if for one reason or another
the end user changes something in a script and its encoding on the way,
can we be sure iconv(...'latin1') will still work ?
(Same issue with nr2char() & co)

      If we stick to non-funky characters in our script files, I do not=20
think this is an issue.

One part of the solution is to avoid using funky characters in script
files.

I can't agree more. I'm slowy rewriting my scripts to fix this issue.
So, now, when I need the markers for instance, I use the function:
"Marker_Txt(the_comment)"


The only remaining problem, AFAIK, is that funky characters do not
match themselves in some contexts.  I think I can get around this
using iconv() as discussed below.

If possible, I'd rather not having to care of the enconding within the
jumpings function, but when we set the buffer-variables only.

      I am not sure this is possible.  What if the encoding is changed=20
on the fly?

[snip]
I prefer iconv() (now you've shown me this function) for converting
strings. Let's suppose the end user wishes to use "=AB=A1" and "!=BB" in
utf-8. iconv() in that case is easier to use.

But, this seems to suppose that the file where the opening and closing
strings are defined is in latin1. Does having this script file in utf-8
changes anything ?
[snip]

      No, I have tested it where 'enc' is utf-8 and 'fenc' is either=20
empty or also utf-8, as well as other situations.  It looks like a bug=20
to me, but

:let foo =3D "\xab"

seems to assign the latin1 value of "\xab" (if that is the right way to=20
say it) to foo, instead of using the current encoding.  At any rate, it=20
is reasonable that the encoding of the script file, or current buffer,=20
does not affect this.

                     --Benji

Re: [Vim-latex-devel] ``''<<>>

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

 > What I meant was
 >
 > to press " twice, and obtain not just ``'' (with the cursor at the end
 > ot that) but ``''<<>>  with the cursor between `` and '', and the chance
 > to jump out with ctrl-J !
 >
 > Sorry if my previous mail was not clear
 >
 > Thank you!

       That is a possibility.  It would require modifying s:TexQuotes()
in main.vim, and adding another option.

					--Benji

[Vim-latex-devel] Re: encoding woes

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

* On Fri, Dec 20, 2002 at 10:04:43AM -0500, Benji Fisher <be...@me...> wrote:
>      I would like to start work on solving the encoding problems.  I 
> think we have to consider all combinations of
> 
> 1. 'enc' is latin1 or utf-8
> 2. 'fenc' is empty or latin1 or utf-8
> 3. the text or the "input" place holders or the "output" place holders 
> are outside the 7-bit ASCII range (i.e., they are "funky," to use the 
> technical term ;).
> 
>      What are the situations where real problems exist?

Can we have any certitude about the encoding used by the script file ?
So far, we write our scripts in latin1. But if for one reason or another
the end user changes something in a script and its encoding on the way,
can we be sure iconv(...'latin1') will still work ?
(Same issue with nr2char() & co)

> One part of the solution is to avoid using funky characters in script
> files.  

I can't agree more. I'm slowy rewriting my scripts to fix this issue.
So, now, when I need the markers for instance, I use the function:
"Marker_Txt(the_comment)"

> The only remaining problem, AFAIK, is that funky characters do not
> match themselves in some contexts.  I think I can get around this
> using iconv() as discussed below.  

If possible, I'd rather not having to care of the enconding within the
jumpings function, but when we set the buffer-variables only.

May be, we can write mutators (aka "setters") for setting the value of
the strings used for opening and closing the marker (aka placeholder).
The mutator will take care of converting the funky characters received to
something that can be written, matched, searched and substituted.

> Luc Hermitte wrote:
> A little experimentation shows that
> 	:let foo = nr2char(char2nr("\xab"))
> has the same effect as
> 	:let bar = iconv("\xab", "latin1", &enc)
> 
> (I.e., ":echo foo == bar" returns 1.)  Note that strlen(foo) is 2, even 
> though strlen("\xab") is 1!  Thus the solution using nr2char() and 
> char2nr() and the solution using iconv() are similar, but iconv() has 
> the advantage that it is easy to convert back:
> 
> 	:echo "\xab" == iconv(foo, &enc, "latin1")
> returns 1.

I prefer iconv() (now you've shown me this function) for converting
strings. Let's suppose the end user wishes to use "«¡" and "!»" in
utf-8. iconv() in that case is easier to use.

But, this seems to suppose that the file where the opening and closing
strings are defined is in latin1. Does having this script file in utf-8
changes anything ?

So, my proposal looks like (not tested, many bugs expected, I have to go
in a few minutes):

"function! s:SetPlaceholder
function! s:SetMarker(open, close, ...)
    if (a:0 != 0)
	if (a:1 :!~ '[bgw]')
	    call s:Error('incorrect scope character')
	    return
	endif
	let {a:1}:marker_open  = iconv(a:open, current_encoding, &enc)
	let {a:1}:marker_close = iconv(a:close,current_encoding, &enc)
	" or IMAP_placeholder_left and right ... don't remember exactly
    else
	let b:marker_open  = iconv(a:open, current_encoding, &enc)
	let b:marker_close = iconv(a:close,current_encoding, &enc)
    endif
endfunction

command! -nargs=* SetMarker(<args>)

" + the jumpings function that don't use iconv(), nor change the current
" encoding to latin1, even momentarally -- I didn't have to with
" nr2char(char2nr(...)).

The big problem is to know the exact value to use for current_encoding
that will work for:
- a script in latin1 _or_ utf-8 that will use:
  :SetMarker "\xab" "\xbb" b
- SetMarker executed from the command line (in interactive mode)
  whatever the current values for &enc and &termenconding are.

Moreover using this mutator should be easier for end-users than having
to set to variables.


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

Re: [Vim-latex-devel] ``''<<>>

[Fabio S. <fab...@ti...>]

What I meant was

to press " twice, and obtain not just ``'' (with the cursor at the end
ot that) but ``''<<>>  with the cursor between `` and '', and the chance
to jump out with ctrl-J !

Sorry if my previous mail was not clear

Thank you!

[Vim-latex-devel] TexLet broken?

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

      I just tried " in Insert mode, expecting to get `` or '' but I got 
"``" (WITH the double quotes).  The problem seems to be with TexLet.

:TexLet g:Foo = "``"
:echo Foo
"``"

Has anyone changed TexLet recently?

					--Benji

Re: [Vim-latex-devel] ``''<<>>

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

Fabio Spelta wrote:
> :)
> 
> Hello
> 
> What about to implement that fine stuff of <<>> (sorry if I "name" it
> this way :) ) also for the couple of `` and '' ? I'll found it really
> useful!
> 
> Thanx and happy living

      I am not sure what "fine stuff" you mean.  We will soon release a 
version where you may use "<<" and ">>" or "``" and "''" or any other 
markers you like.  You already get "``" and "''" by typing " (and you 
can customize this if you do not want English-style quotation marks). 
Are you looking for a way to jump to ``strings like this'' or something?

HTH					--Benji

[Vim-latex-devel] encoding woes

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

      I would like to start work on solving the encoding problems.  I 
think we have to consider all combinations of

1. 'enc' is latin1 or utf-8
2. 'fenc' is empty or latin1 or utf-8
3. the text or the "input" place holders or the "output" place holders 
are outside the 7-bit ASCII range (i.e., they are "funky," to use the 
technical term ;).

      What are the situations where real problems exist?

      One part of the solution is to avoid using funky characters in 
script files.  The only remaining problem, AFAIK, is that funky 
characters do not match themselves in some contexts.  I think I can get 
around this using iconv() as discussed below.  (I say "some contexts, 
because =~ and match() and substitute() do not work, but / and :s do.)

Luc Hermitte wrote:
> Benji,
> 
> The same workaround than the one I used, seems to work.
> 
> The important thing is that I require the encoding to be set before
> every else. It is a very reallistic requirement.
> The encoding is supposed to be set either by the system (red hat if I
> understood it well, $LANG, locale() & co) or by .vimrc. Therefore,
> 'encoding' is set before any other plugin is run.
> 
> Then, we can notice that:
>     :set enc=utf8
>     :let foo = "\xab"
>     :echo foo =~ foo
>     0
> does not work as it should, but:
>     :set enc=utf8
>     :let foo = nr2char(char2nr("\xab"))
>     :echo foo =~ foo
>     1
> does !
> 
> Don't ask me why, but it does.

      A little experimentation shows that

	:let foo = nr2char(char2nr("\xab"))

has the same effect as

	:let bar = iconv("\xab", "latin1", &enc)

(I.e., ":echo foo == bar" returns 1.)  Note that strlen(foo) is 2, even 
though strlen("\xab") is 1!  Thus the solution using nr2char() and 
char2nr() and the solution using iconv() are similar, but iconv() has 
the advantage that it is easy to convert back:

	:echo "\xab" == iconv(foo, &enc, "latin1")

returns 1.

					--Benji

[Vim-latex-devel] ``''<<>>

[Fabio S. <fab...@ti...>]

:)

Hello

What about to implement that fine stuff of <<>> (sorry if I "name" it
this way :) ) also for the couple of `` and '' ? I'll found it really
useful!

Thanx and happy living
-- 
  Fabio Spelta
  
   email: fab...@ti...
   jabber: fe...@ja...
   ecdl project: http://ecdllibre.sf.net

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

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:
> 
>>: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...>]

> > 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:
> 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