vim-latex-devel

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

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

      Sorry, I should really start a new branch, but I have not done 
that before, so I am just attaching a file.  The new syntax is

:call IMAP("tex", "foo", "b", "", "ar")

I have tested this:  typing "foo" gives

b|ar

with | indicating the cursor position.  So far so good!

      BUT it does not work if 'enc' is set to utf-8 and I use "\xab" and 
"\xbb" as place holders.  I'll post a question to the vim users' list.

      Since this is in transition, it is not a good time to add new 
packages, etc.  If you want to add them with the old syntax, please use 
Tex_IMAP() and Tex_PutTextWithMovement() for now.

					--Benji

[Vim-latex-devel] [devel] Re: multibyte in patterns & jumping to placeholders

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

Benji,

I answer your point about encoding on the vim-latex ML.

* On Fri, Dec 13, 2002 at 06:21:15PM -0500, Benji Fisher <be...@me...> wrote:
>      More multi-byte woes.  If 'encoding' is set to utf-8, then a MB 
> character does not match itself!
> 
> :let foo = "\xab"
> :set enc?
>   encoding=latin1
> :echo foo =~ foo
> 1
> :set enc=utf8
> :set enc?
>   encoding=utf-8
> :echo foo =~ foo
> 0

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.

Earlier this week I ask on the vim ML if somebody could test my latest
version of my variation on Stephen Riehm's bracketing system, but I get
no response. :-((
So I don't know if it correctly works with encodings other than
latin1,2,15 or utf-8 set from .vimrc.

> Is this expected, or is it a bug?  Is there a work-around?  Am I
> supposed to do this?
> :echo iconv(foo, 'latin1', &enc) =~ foo
> 1

Hum, this is another quite odd workaround.

Otherwise, looks like a bug to me.
Or may be it concerns 'termencoding'. I don't know.

____________________
Regarding the other e-mail you sent on the vim-latex-devel ML.

> "        File: imaps.vim
> [...]
> " IMAP_Jumpfunc: takes user to next ?place-holder? {{{
> " Author: Gergely Kontra
> "         taken from mu-template.vim by him This idea is originally
> "         from Stephen Riehm's bracketing system.
> " modified by SA to use optional place holder characters.
> function! IMAP_Jumpfunc()

That is not completly true. The version Gergely rewrote was a simplifed
version over the function I originally wrote. I know he didn't wanted of
the complexity of my function. So he get rid of the possibility of
having different strings to express the markers (aka placeholders).
[However, selecting the marker instead of echoing its value is Gergely
idea]

Then Srinath unaware of my function, I guess, reintroduced this
functionnality.  But several things are still missing.

Here is a little list of other things taken into account in my function:
- the 'wrapscan' option is used -- 'W' is not an acceptable option to
  'search()', 'wrapscan' is meant to settle this issue.
- It can jump forward or backward -- thanks to Robert Kelly IV (aka
  feral).
- I leave the possibility to select _or_ erase the marker (/placeholder)
  we jump to -- select-mode is not always very handy.
  BTW, we can select empty markers instead of deleting them.
- It can be configured thanks to options and '<Plug>xxxx' mappings.
- It jumps to the next/prev marker even if the cursor is
  in the middle of a marker -- thanks to Robert again.
- It is compatible with the two strings you use to define your
  placeholders -- I guessed you will not revert back to my original
  variation on Stephen's bracketing system.
- It correclty works even when the marker (we jump to) is within a
  closed folder.
- There is a documentation up to date.
- It is compatible with the next version of mu-template I plan to
  release soon -- actually the version 0.29 of mu-template is compatible
  with my variation and with imaps.vim.
  But as the jumping function becomes quite complex, my version of
  bracketing.base.vim will be part of mu-template 0.30 and more.
- The screen never flashes -- there exist other variations that make the
  screen flash.
- It has been patched regarding the encoding issue -- but more tests
  should be done. I guess I will upload my last version on SF during by
  the end of this week-end.
- It is maintained and will be maintained by myself: no need to
  reinvent the wheel or having 10 person fixing the same bug or adding
  the same feature at monthes (or years) of interval.





So, if you agree with me to not waste energy, you can consider making
    http://hermitte.free.fr/vim/ressources/plugin/bracketing.base.vim
part of vim-latex ; after all Srinath already put me in the credits for
my variation on Stephen's bracketing system. ;-)

In order to have the documentation and the mapping that inserts a marker
around a visually-selected text (or the current word) and the
documentation, two other files are required. Check the tarball archive:
    http://hermitte.free.fr/vim/ressources/ lh-map-tools.vim


Have a nice week-end !

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

Re: [Vim-latex-devel] [devel] Re: multibyte in patterns & jumping to placeholders

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

Hey Luc,

I will incorporate your jump function into latex-suite.

I am in a kind of a hurry right now, so I will write more later.

> So, if you agree with me to not waste energy, you can consider making
>     http://hermitte.free.fr/vim/ressources/plugin/bracketing.base.vim
> part of vim-latex ; after all Srinath already put me in the credits for
> my variation on Stephen's bracketing system. ;-)
>
the URL above gives me a URL not found on this server message.

> In order to have the documentation and the mapping that inserts a marker
> around a visually-selected text (or the current word) and the
> documentation, two other files are required. Check the tarball archive:
>     http://hermitte.free.fr/vim/ressources/ lh-map-tools.vim
>

The same for this one.

Thanks,

Srinath

[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] 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] 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] 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] new version of plugin/imaps.vim

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

Hello!

I just got done with an exam. So a little time for vimming. I will
mostly do the outstanding things like the web-page cvs screw up and a
few other things. I will also put this new version of imaps.vim into a
new branch which I shall call... lets see...

b-newimaps

(Lets make it convention to name all branch tags with a leading 'b-').

Next time, keep your old copy of the repository and check out the new
version into a new directory using

cvs checkout -r b-newimaps -d newdir

Then newdir will contain the new branch files.

BTW, branching in CVS is _extremeley_ easy, contrary to popular opinion.
All that needs to be done is:

1. go to the local repository.
2. "cvs update" to bring things up to date.
3. "cvs tag trunk-<date>" (replace <date> with current date).
   this step is not essential. But it helps to keep a tagged version at
   the root of every branch.
4. "cvs tag -b b-newimaps"

thats it!

then do the checkout thing I mention earlier.

Further reading:

http://cvsbook.red-bean.com/cvsbook.html#Branches

The link has a very nice explanation of all these concepts, including
ofcourse how to merge changes from the branch onto the trunk.
Recommended reading for any hacker :)

------ IMPORTANT ---------
Its very important to tag the whole branch repository every time a
change from it is merged into the main trunk. I suppose we should
somehow automate this...

This is important because if we want to merge from the branch onto the
main trunk more than once, then we cvs needs to know the 2 revs from
which it calculates the diff.
------ IMPORTANT ---------

In the web cvs, you will need to select the correct branch to view the
branch versions of the files.

Hopefully, this email will serve as a future short reference for cvs
branching.

Srinath

On Fri, 13 Dec 2002, Benji Fisher wrote:

>       Sorry, I should really start a new branch, but I have not done
> that before, so I am just attaching a file.  The new syntax is
>
> :call IMAP("tex", "foo", "b", "", "ar")
>
> I have tested this:  typing "foo" gives
>
> b|ar
>
> with | indicating the cursor position.  So far so good!
>
>       BUT it does not work if 'enc' is set to utf-8 and I use "\xab" and
> "\xbb" as place holders.  I'll post a question to the vim users' list.
>
>       Since this is in transition, it is not a good time to add new
> packages, etc.  If you want to add them with the old syntax, please use
> Tex_IMAP() and Tex_PutTextWithMovement() for now.
>
> 					--Benji
>

[Vim-latex-devel] new CVS branch

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

Srinath Avadhanula wrote:
> Hello!
> 
> I just got done with an exam. So a little time for vimming. I will
> mostly do the outstanding things like the web-page cvs screw up and a
> few other things. I will also put this new version of imaps.vim into a
> new branch which I shall call... lets see...
> 
> b-newimaps
> 
> (Lets make it convention to name all branch tags with a leading 'b-').
> 
> Next time, keep your old copy of the repository and check out the new
> version into a new directory using
> 
> cvs checkout -r b-newimaps -d newdir

      Make that

$ cvs -z3 -d 
:ext:ma...@cv...:/cvsroot/vim-latex get -r 
b-newimaps -d alpha vimfiles

Replace "macvimx" with your user name and replace "alpha" with whatever 
you like.

> Then newdir will contain the new branch files.
> 
> BTW, branching in CVS is _extremeley_ easy, contrary to popular opinion.
> All that needs to be done is:
> 
> 1. go to the local repository.
> 2. "cvs update" to bring things up to date.
> 3. "cvs tag trunk-<date>" (replace <date> with current date).
>    this step is not essential. But it helps to keep a tagged version at
>    the root of every branch.
> 4. "cvs tag -b b-newimaps"
> 
> thats it!
> 
> then do the checkout thing I mention earlier.
> 
> Further reading:
> 
> http://cvsbook.red-bean.com/cvsbook.html#Branches
> 
> The link has a very nice explanation of all these concepts, including
> ofcourse how to merge changes from the branch onto the trunk.
> Recommended reading for any hacker :)
> 
> ------ IMPORTANT ---------
> Its very important to tag the whole branch repository every time a
> change from it is merged into the main trunk. I suppose we should
> somehow automate this...
> 
> This is important because if we want to merge from the branch onto the
> main trunk more than once, then we cvs needs to know the 2 revs from
> which it calculates the diff.
> ------ IMPORTANT ---------
> 
> In the web cvs, you will need to select the correct branch to view the
> branch versions of the files.
> 
> Hopefully, this email will serve as a future short reference for cvs
> branching. 
      Yes, hence the new subject line.  I apologize:  you sent us 
directions before, but that was when I had just installed Linux, and I 
only kept one copy, and I had problems ...  (Note to self:  time for a 
backup!)

					--Benji

Re: [Vim-latex-devel] site CVS

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

On Fri, Dec 13, 2002 at 10:17:56PM -0800, Srinath Avadhanula wrote:
> Hello!
> I just got done with an exam. So a little time for vimming. I will
> mostly do the outstanding things like the web-page cvs screw up and a
> few other things. I will also put this new version of imaps.vim into a
> new branch which I shall call... lets see...

I think we can remove package and template directories from site CVS.
Not from site but from CVS. Better solution to update this files will be
running cron with script like that:

------------
#!/bin/sh
# download cvs tarball from its place to our home directory
wget -q http://cvs1.sourceforge.net/cvstarballs/vim-latex-cvsroot.tar.gz

# move it to proper place of www directory
cp vim-latex-cvsroot.tar.gz /home/groups/v/vim/vim-latex/htdocs/packages

# now, we have to go there
cd /home/groups/v/vim/vim-latex/htdocs/packages

# here is a hack, I can't believe this is not possible with simple
# switch but also I am not able to find it in tar docs.
tar -zxf vim-latex-cvsroot.tar.gz vimfiles/ftplugin/latex-suite/packages/
cp -f vimfiles/ftplugin/latex-suite/packages/* .
rm -rf vimfiles/ vim-latex-cvsroot.tar.gz
-------------

I did not tested it fully (wget works). Next steps are impossible
because I do not have permissions. Big plus there is only one
place where package files (also templates) are.

Re: [Vim-latex-devel] site CVS

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

Hey Mikolaj,

I just fixed the web page screwup. The problem before was that the
groups htdocs/ directory was checked out with

cvs -d:ext:srinathava@cvs1 ...

Thats why it asked you for my password last time.

Now I have checked it out with anonymous pserver. I have also changed
the permissions of the htdocs/ directory to be group writable. Therefore
anyone should be able to log into sf.net, change to the groups htdocs
directory and run

cvs update -q

You can also optionally cd to htdocs/packages and do a

cvs update -q

NOTE: The htdocs/packages directory is a local repository copy of
'vimfiles/ftplugin/latex-suite/packages' module not the
'htdocs/packages' module. I will actually remove the htdocs/pacakges
from the master CVS sometime soon.

NOTE 2: I need to do similar things to the htdocs/templates directory...

I think therefore that a cron job can be simplified to:

-----------------------%<-----------------------
#!/bin/sh

# update the htdocs directory
cd /home/groups/v/vim/vim-latex/htdocs; cvs -q update
# update the packages directory
cd /home/groups/v/vim/vim-latex/htdocs/packages; cvs -q update
-----------------------%<-----------------------

This will I think be also a bit more robust.

I do not have a good idea about how to set up cron jobs. If you want,
you can go ahead and do it using your sf.net account.

NOTE: The web-page now points to the latest "raw" CVS version of the
htdocs module... This means that some of the things point to
comingsoon.inc, and the links link is broken (the irony!)

I am also thinking of making syncmail send emails for commits to the
htdocs/ module. If the subscribers to vim-latex-cvs object, I will
reconsider.

Thanks,

Srinath

> ------------
> #!/bin/sh
> # download cvs tarball from its place to our home directory
> wget -q http://cvs1.sourceforge.net/cvstarballs/vim-latex-cvsroot.tar.gz
>
> # move it to proper place of www directory
> cp vim-latex-cvsroot.tar.gz /home/groups/v/vim/vim-latex/htdocs/packages
>
> # now, we have to go there
> cd /home/groups/v/vim/vim-latex/htdocs/packages
>
> # here is a hack, I can't believe this is not possible with simple
> # switch but also I am not able to find it in tar docs.
> tar -zxf vim-latex-cvsroot.tar.gz vimfiles/ftplugin/latex-suite/packages/
> cp -f vimfiles/ftplugin/latex-suite/packages/* .
> rm -rf vimfiles/ vim-latex-cvsroot.tar.gz
> -------------
>

-- 
Srinath Avadhanula
Dec 14 2:59pm
Ray's Rule of Precision:
	Measure with a micrometer.  Mark with chalk.  Cut with an axe.