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

Re: [Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8

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

I am glad we are having this discussion on the way to implement this.
Hopefully, we will be able to come up with a nice long term solution...

> or some such.  I type <C-J> and get "< 5 >" in Select mode.  OK,
> provided that <C-J> jumps to the "<label>" and does not delete "< 5 >";
> is this what happens, or does the place holder get deleted if I hit
> <C-J> again?
>
>       More realistic:  lots of people are too lazy to use $\langle$ and
> $\rangle$, so $<f, g>$ is likely to come up.
>

I think its essential to understand how placeholders are used... They
are a bit more flexible than that. The only place where we need to
ensure that there are no fake strings like '<f, g>' is in latex-suite
itself. Its okay if the user has them at other places in the file. In
this case, the user chooses a different value of g:Imap_PlaceHolder*
variables.

Just to be clear, the only real problem with hardcoding something like
'<' or '<+' into latex-suite is only when latex-suite itself has some
macros defined with strings like '<+something+>' without meaning for
them to be placeholders.

Also, <C-j> only deletes the placeholders if they are things like
"<++>". If there is some explanation like "<+something+>", then it wont
get deleted by pressing <C-j>. It will be replaced when you type some
printable char.

>      If I try this with an HTML file, things get ugly.  Need I say more?
>
Again, this is not an issue. The user will have different placeholder
settings for html. Imap_JumpFunc() uses the buffer local value of the
place holder settings for jumping.

Again, just to emphasize, we are not trying to decide on a single
character to be used across all languages/locales etc. We are just
trying to decide for latex-suite... imaps.vim is kinda independent of
this. (At present, Imap_PutTextWithMovement tries to replace certain
patterns in the lhs with the user's place holder settings. This should
be moved over to something in latex-suite).

> 3. The "<++>" proposal might work, but I will make two predictions:
> (a) Some crazed mathematician will decide that "<+f, g+>" is the right
> notation for some sort of inner product.
> (b) If there is not already an XML variant that uses "<+tags
> like=3Dthis+>", there will be soon.

Again, we only need to ensure that latex-suite itself doesn't use "<+"
except as a placeholder. The crazy mathematician will have to change his
setting for placeholders. The XML thing is not an issue as stated
before.

> IMAP().  I propose changing this to
>
> =09:call IMAP(ft, lhs, rhs1, ph1, rhs2, ph2, ...)
>
This is a beautiful solution. But consider that not all macros in
latex-suite are triggered from IMAP(). Some of them do something like:

inoremap <M-c> <C-r>=3DTex_MathCal()<CR>

Then Tex_MathCal() does:

=09return Imap_PutTextWithMovement("\\cite{=AB=BB)=AB=BB")

So I suppose we will also have to change Imap_PutTextWithMovement() to
accept variable arguments...  Although the solution above does look like
it could be _the_ correct solution, I have a feeling that hardcoding
placeholders is not such a big deal at all...

Assumption:

latex-suite will never need to use strings like "<+something+>" except
for demarcating placeholer characters.
This assumtion is ****important*****

Execution:

envmacros.vim does:

=09call Tex_IMAP('`/', '\frac{<++>}{<++>}<++>', 'tex')

texrc does:

=09let g:Imap_PlaceHolderStart =3D "\xab"
=09let g:Imap_PlaceHolderEnd =3D "\xbb"

We define a new function Tex_IMAP which replaces "<+" with the user's
choice of g:Imap_PlaceHolderSetting and then call IMAP() with this new
thing. Similary Imap_PutTextWithMovement is replaced with
Tex_PutTextWithMovement.

Finally, when the user press `/, he expands to \frac{|}{=AB=BB}=AB=BB where=
 | is
the cursor position. If he wants he could set a different value of the
place holder, if =AB=BB does not display nicely on his comp or if he uses a
language where =AB=BB are legitimate chars.

NOTE: imaps.vim will no longer try to replace the "<+" chars with
[gb]:Imap_PlaceHolderStart. It will only use this setting in the
Imap_JumpFunc().

Therefore, we could presumably have a user with an ftplugin/xml.vim
file where he sets:

=09let b:Imap_PlaceHolderStart =3D '?'
=09let b:Imap_PlaceHolderEnd =3D '?'

=09call IMAP('li`', '<li>??</li>??', 'xml')

The crazy mathematician does

=09" I have proved that the following strings occur with a probability
=09" less than 1/(2*pi)^5*10e-12 in my files. I hope this is safe
=09" enough.
=09let b:Imap_PlaceHolderStart =3D '%xdf@#$'
=09let b:Imap_PlaceHolderEnd =3D '*&#$*&'

When he presses `/, he will get \frac{|}{%xdf@#$*&#$*&}%xdf@#$*&#$*&
with | ofcourse denoting cursor position.

Does this make everyone happy?

Please try to come up with cases where the above system might fail...

Okay... this mail is getting out of hand...

Srinath

Re: [Vim-latex-devel] coding standards?

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

On Mon, Dec 09, 2002 at 11:20:20AM -0500, Benji Fisher wrote:
>      What are our coding standards?
> 1. I think Srinath once asked me to use "tabs, not spaces" for 
> indenting.  Does this mean that I should set 'ts' to 2, instead of 
> setting 'sts' and leaving 'ts' at 8?

Some time ago Srinath asked me to add this settings to modelines in lS
files:

ts=4:sw=4:noet:fdm=marker
> 2. Some files have change logs at the top.  Is this left over from 
> pre-CVS days, or do we want to update these?

It is rather leftover. I would rather stick with CVS logs.

> 3. Should we try for consistent time stamps?  If so, is there a script 
> for updating them?  Or should we let CVS take care of that, and stop 
> cluttering the diff files with changed time stamps?

I am using lastchange.vim by Srinath (it is somewhere on vim-online).
I'd like to save them. It is useful with playing off-line before
commiting changes to repository.

> 4. Does anyone feel strongly about the number of columns and 'wrap' 
> versus 'nowrap'?

I know. Long lines are ugly but in Vim it is easier to maintain single
looong line than many short lines. Of course if I am a minority...

Mikolaj

Re: [Vim-latex-devel] coding standards?

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

> 1. I think Srinath once asked me to use "tabs, not spaces" for
> indenting.  Does this mean that I should set 'ts' to 2, instead of
> setting 'sts' and leaving 'ts' at 8?

I am not really familiar with 'sts', but this is what works for me in my
.vimrc:

set ts=4
let &sw = &ts

Hmmm... looking at 'sts', it looks like it fakes a tab with a mixture of
spaces and tags. I dont think I like that. I would definitely prefer all
leading indentation to be strictly tabs. This way (and AFAIK it is the
only way) people who like different indent levels can view the file
according to the 'ts' value they prefer.

Also, apart from the leading indentation being in tabs, none of the
other indentation should be in tabs. I use the following mapping for tab
which does both these things. (this was posted by Michael Geddes).

-------------------------%<-------------------------
imap <tab> <c-r>=<SID>InsertSmartTab()<cr>
fun! s:InsertSmartTab()
	if strpart(getline('.'),0,col('.')-1) =~'^\s*$'
		return "\<Tab>"
	endif
	let ts = &ts
	let sp=(virtcol('.') % &sw)
	if sp==0
		let sp = &sw
	endif
	return strpart("                  ",0,1+ts-sp)
endfun
-------------------------%<-------------------------

I have been meaning to extend this idea for the <bs> key too, but keep
putting it off...

> 2. Some files have change logs at the top.  Is this left over from
> pre-CVS days, or do we want to update these?

Yes. They are leftovers. Please remove them as you see fit.

> 3. Should we try for consistent time stamps?  If so, is there a script
> for updating them?  Or should we let CVS take care of that, and stop
> cluttering the diff files with changed time stamps?
>
I didn't think much about this. I would think that letting cvs deal with
this would be a better idea. I dont know much about how to do it though
via cvs though... For now, Mikolaj and me use lastchange.vim from:

http://vim.sourceforge.net/script.php?script_id=259

> 4. Does anyone feel strongly about the number of columns and 'wrap'
> versus 'nowrap'?

Hmm... Haven't thought about this. But if you feel strongly about it,
please let us know. Someplaces in envmacros.vim, where looong macros are
defined, its cleaner to have 'nowrap' and have the whole thing be on a
single line, imo. But inside the code itself, everything within 78
columns is best. I myself have 'nowrap' in my .vimrc and try to restrict
all my actual code to within 78 cols.

-- 
Srinath Avadhanula
Dec 9 1:31pm
I'm N-ary the tree, I am,
N-ary the tree, I am, I am.
I'm getting traversed by the parser next door,
She's traversed me seven times before.
And ev'ry time it was an N-ary (N-ary!)
Never wouldn't ever do a binary.  (No sir!)
I'm 'er eighth tree that was N-ary.
N-ary the tree I am, I am,
N-ary the tree I am.

[Vim-latex-devel] linebreak and tw=0

[Vincent N. <v-...@ke...>]

Hi,
 
You latex-suite is great!
 
I would like to use it but set options 'linebreak' and 'tw=0'.
'main.vim' seems to change this setting to 'tw=79'. I have tried to
change this setting in 'main.vim' and have also tried 'set tw=0' once
the file is loaded. Neither option seems to work though. It works for a
while but then tw is set back to 79 some how.
 
Do you have any suggestions on how I might solve this issue?
 
Regards,
 
Vincent

[Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8

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

* On Sun, Dec 08, 2002 at 06:54:47PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> Therefore we could conceivably have ftplugin/c.vim containing lines
> like:
> let b:Imap_PlaceHolderStart = '?'
> let b:Imap_PlaceHolderEnd = '?'
> call IMAP('for', "for (??; ??; ??) {\n??\n}??", 'c')

Indeed, but you loose flexibility in that case. The day the new language
C% arise, it would not be able to take advantage of the C mapping for
'for' as it defines a new operator : '??' 
;-)


> The problem you mention is when some new language has legitimate
> characters such as '<+' and Imap_PutTextWithMovement() tries to replace
> those with the placeholder characters. 

That's my point: defining a highly evolutive and language/configuration
independent plugin.

> That problem can be solved by using a new function
> Tex_PutTextWithMovement() instead of Imap_PutTextWithMovement() which
> first replaces things like « (or '<+' or '!mark!') with the user's
> choice and then calls Imap_PutTextWithMovement(). This makes

That's an option.

> > It is not really problematic !  I will use '!mark!' for instance
> > (instead of '¡mark!' currently used) to express the markers (aka
> > placeholders)
> 
> Well, on further thinking, it does make sense to use longer things
> like '!mark!' or something similar and then replace with the user's
> placeholder choice in `Imap_PutTextWithMovement'()... 

> But this will mean again that the scripts themselves become really
> long and unreadable...

Not always. Check again the mappings ']em' and ']ee' I proposed you.
The mecanics that permits such writings is very complex [1], but once
written, the end-coders that write and maintain TeX (/HTML/...)
code-snippets have a very easy job left.

However, I must admit that my mappings for C&C++ constructs and common
brackets are quite complex. [I think that today I should be able to
simplify them as my VimL skills have improved.]

> Well, there seems to be fair arguments for and against the using of
> things like !mark!. But I would think that a solution where imaps is
> completeley independent of the choice of placeholder characters is best.

['!mark!' is not a placeholder -- actually, this is a mapping with my
settings ; it is replaced by maparg('!mark!', i')]

And I definitively agree, functions like IMAPS() should be independent
of any placeholder characters. Somehow, '<+' and '+>' (as well as '«' &
'»' today) look like placeholders characters, and more important: they
look like things that some languages may use -- like for instance '«'
and '»' in LaTeX documents written in French.

> And I think each language choosing its own placeholders is most
> elegant and robust...
 
100% agree.


[1] but it does not handle insert-mode mappings only ... command-,
insert- and normal-mode mappings _and_ menus are handled. So, I think it
is a fair price.
-- 
Luc Hermitte

[Vim-latex-devel] coding standards?

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

      What are our coding standards?

1. I think Srinath once asked me to use "tabs, not spaces" for 
indenting.  Does this mean that I should set 'ts' to 2, instead of 
setting 'sts' and leaving 'ts' at 8?

2. Some files have change logs at the top.  Is this left over from 
pre-CVS days, or do we want to update these?

3. Should we try for consistent time stamps?  If so, is there a script 
for updating them?  Or should we let CVS take care of that, and stop 
cluttering the diff files with changed time stamps?

4. Does anyone feel strongly about the number of columns and 'wrap' 
versus 'nowrap'?

					--Benji

Re: [Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8

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

Mikolaj Machowski wrote:
> On Mon, Dec 09, 2002 at 01:30:44AM +0100, Luc Hermitte wrote:
>=20
>>* On Sun, Dec 08, 2002 at 03:12:10PM -0800, Srinath Avadhanula <srinath=
@fastmail.fm> wrote:
>>
>>>Option 1:
>>>    change things like '\onlyslides{??}??' to
>>>    "\\onlyslides{\xab\xbb}\xab\xbb"
>>
>>Hard to read IMHO. Hard to maintain.
>>
>>>Option 2:
>>>    Change it to something like "\\onlyslides{<++>}<++>"
>>>    Here the placeholder (or marker) characters are "<+" and "+>".
>>
>>Easier to read, but imaps may not work with a new language using '<+'
>>and '+>'. I think you should choose something expressive and odd enough
>>to not beeing used by anything else.
>=20
>=20
> But it is very hard to find something odd and common to various
> encodings. Why not simple '<' and '>'? Easy to read; easy to maintain;
> everywhere won't be problems with encoding; shorter than '<+', '+>'.
>=20
> Mikolaj

      I guess I will not actually implement anything today...

      IIUC, templates are supposed to include prompts like

\label{fig:=ABlabel=BB}

1. If we use < and > then we will only occasionally have trouble when=20
the file contains

	A silly example:  $3 < 5 > 4$

or some such.  I type <C-J> and get "< 5 >" in Select mode.  OK,=20
provided that <C-J> jumps to the "<label>" and does not delete "< 5 >";=20
is this what happens, or does the place holder get deleted if I hit=20
<C-J> again?

      More realistic:  lots of people are too lazy to use $\langle$ and=20
$\rangle$, so $<f, g>$ is likely to come up.

     If I try this with an HTML file, things get ugly.  Need I say more?

2. The current system has problems.  Here is a new one.  I try

:set enc=3Dlatin1 fenc=3Dlatin1

so that things look right as I edit plugin/imaps.vim (and read=20
doc/latex-suite.txt).  Now, when I copy from gvim and paste into=20
Mozilla, gvim gets an X-windows error and crashes.

3. The "<++>" proposal might work, but I will make two predictions:
(a) Some crazed mathematician will decide that "<+f, g+>" is the right=20
notation for some sort of inner product.
(b) If there is not already an XML variant that uses "<+tags=20
like=3Dthis+>", there will be soon.

Conclusions:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

      The place holders can already be configured.  We have to encourage=20
the use of this option, and we have to change the defaults.  We have to=20
allow for place holders with more than one character.

      I think that "<++>" is a reasonable default.

      I think that the IMAP() function should be changed.  Currently:

	:call IMAP(lhs, rhs, ft)

and rhs optionally contains the place-holder characters.  If the user=20
decides to change these characters, (s)he must rewrite all the calls to=20
IMAP().  I propose changing this to

	:call IMAP(ft, lhs, rhs1, ph1, rhs2, ph2, ...)

with a variable number of arguments.  The rhsx arguments are plain text.=20
  The phx arguments are either "<" or ">" and indicate that the=20
corresponding place holder should be inserted.  Or simpler:  if place=20
holders always come in pairs, and I am not missing a third kind of=20
special character, the phx arguments are also plain text, to be enclosed=20
in "<>" pairs.  For example,

	:call IMAP('tex', 'bf`', '\textbf{', '', '}', '')

would expand "bf`" to "\textbf{<>}<>".

					--Benji

Re: [Vim-latex-devel] compilation noise

[febs <fab...@ti...>]

I> When I am in a.tex and do \ll, things work fine. I am left in a.
> However, when I make some mistake in say c, then I will be taken to c...
> But thats a feature. Are you referring to something else?

Yes!

> If you want to compile a.tex while in c.tex, then you'll need to do

... Yep, I have created the addictional empty file and I can now compile it 
all while editing any file.
I also know that it is a (very fine) feature that a compilation error brings 
up the final that generated it.
What I felt bad is that I tried to compile (referring to your example) b.tex; 
the compilation was _good_ and the current buffer then contained C.tex! 
And I had to press CTRL-O two times to get back to b.tex! That was annoying.

The funny (not so) stuff is that NOW thinks works well as they should. 
Pheraps last time I used some "strange" setting that caused the bug. I hade 
some buffers hidden by :hide, can this matter? I'm sure last time the error 
was there, I have dome many chacks before mailing.
Now that I had some "extra" check, I just opened a file and splitted another, 
last time i got many many buffers opened. 
If the "bug" (?) will shows again I will save the session hopefully to be 
useful. 

Bye and thank you

Re: [Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8

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

On Mon, Dec 09, 2002 at 01:30:44AM +0100, Luc Hermitte wrote:
> * On Sun, Dec 08, 2002 at 03:12:10PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> > Option 1:
> >     change things like '\onlyslides{??}??' to
> >     "\\onlyslides{\xab\xbb}\xab\xbb"
> Hard to read IMHO. Hard to maintain.
> > Option 2:
> >     Change it to something like "\\onlyslides{<++>}<++>"
> >     Here the placeholder (or marker) characters are "<+" and "+>".
> Easier to read, but imaps may not work with a new language using '<+'
> and '+>'. I think you should choose something expressive and odd enough
> to not beeing used by anything else.

But it is very hard to find something odd and common to various
encodings. Why not simple '<' and '>'? Easy to read; easy to maintain;
everywhere won't be problems with encoding; shorter than '<+', '+>'.

Mikolaj

Re: [Vim-latex-devel] : Hi: I'm getting tuX appearin

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

Hi,

This might have been from an old version of imaps.vim. Try upgrading if
you wish.

On Sun, 8 Dec 2002, David Rayner wrote:

> BTW your website doesn't have a "bugs fixed" page!!
>
It also doesn't have a lot of things. This is mostly because of the fact
that a finite number of people with finite time to spare only have
a finite number of things they can do. Simple really. You are welcome to
scan through the CVS logs and come up with a nice change log and bugs
fixed page.

-- 
Srinath Avadhanula
Dec 8 7:14pm
Common sense is instinct, and enough of it is genius.
		-- Josh Billings

Re: [Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8

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

On Mon, 9 Dec 2002, Luc Hermitte wrote:

> > Option 2:
> >     Change it to something like "\\onlyslides{<++>}<++>"
> >     Here the placeholder (or marker) characters are "<+" and "+>".
>
> Easier to read, but imaps may not work with a new language using '<+'
> and '+>'. I think you should choose something expressive and odd enough
> to not beeing used by anything else.

Well, imaps is almost unaffected by whether we choose '<+' and '+>' for
placeholders or not. That will behave according to the value of g:(or
b:)Imap_PlaceHolder* characters. Therefore we could conceivably have
ftplugin/c.vim containing lines like:

let b:Imap_PlaceHolderStart =3D '?'
let b:Imap_PlaceHolderEnd =3D '?'

call IMAP('for', "for (??; ??; ??) {\n??\n}??", 'c')

So using something which is not very expressive is not that important.
We just need to make sure that there is no ambiguity within one language
itself. For example, I do not think that any of the latex maps will
become ambiguous with the placeholders I've mentioned...

The problem you mention is when some new language has legitimate
characters such as '<+' and Imap_PutTextWithMovement() tries to replace
those with the placeholder characters. That problem can be solved by
using a new function Tex_PutTextWithMovement() instead of
Imap_PutTextWithMovement() which first replaces things like =AB (or '<+'
or '!mark!') with the user's choice and then calls
Imap_PutTextWithMovement(). This makes

> It is not really problematic !  I will use '!mark!' for instance
> (instead of '=A1mark!' currently used) to express the markers (aka
> placeholders)
>

Well, on further thinking, it does make sense to use longer things like
'!mark!' or something similar and then replace with the user's
placeholder choice in Imap_PutTextWithMovement()... But this will mean
again that the scripts themselves become really long and unreadable...

Well, there seems to be fair arguments for and against the using of
things like !mark!. But I would think that a solution where imaps is
completeley independent of the choice of placeholder characters is best.
And I think each language choosing its own placeholders is most elegant
and robust...

Srinath

[Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8

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

* On Sun, Dec 08, 2002 at 03:12:10PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> Option 1:
>     change things like '\onlyslides{«»}«»' to
>     "\\onlyslides{\xab\xbb}\xab\xbb"

Hard to read IMHO. Hard to maintain.

> Option 2:
>     Change it to something like "\\onlyslides{<++>}<++>"
>     Here the placeholder (or marker) characters are "<+" and "+>".

Easier to read, but imaps may not work with a new language using '<+'
and '+>'. I think you should choose something expressive and odd enough
to not beeing used by anything else.

>     Now the characters (and the vim scripts) will be correctly displayed
>     across all platforms/locales etc. The problem with this approach,
>     ofcourse is that we are using 2 characters instead of 1. This will
>     make the expansions generally longer... 

It is not really problematic !
I will use '!mark!' for instance (instead of '¡mark!' currently used) to
express the markers (aka placeholders)

> Hmm.... As you can imagine, I am leaning towards option 2. Are there
> any other suggestions?

Don't worry about beeing even more expressive. The time consumption is
not so hihg.

> On Sun, 8 Dec 2002, Luc Hermitte wrote:
> The way things work now in latex-suite is that things like
> 
> let s:figure = "\\begin{figure}[«htpb»]\<cr>\\begin{center}..."
> 
> are defined. When Imap_PutTextWithMovement is called it attempts to
> replace «» chars with the thing defined in g:Imap_PlaceHolder*. In a
> way therefore, latex-suite does actually wrap the commands into a
> central function.

For complex insertions like this one, I am more inclined to use
template-files. 
In http://hermitte.free.fr/vim/ressources/after/template/tex/ you will
found how I plan to support templates for TeX.[1] 

At this moment, I need to patch muTemplate to support different
encodings. My main problem beeing to find something as short as '¡'...¡'
but independant of the encoding used.

> >   call <SID>MapMenu4Env("50.370.200", '&LaTeX.&Environments.&itemize',
> >       \ ']ei', 'itemize', '\item ')
> >   that also defines 3 mappings and 3 menus. The insert mode mapping
> >   ']ei' inserts:
> >     \begin{itemize}
> >     \item µ
> >     \end{itemize}«»
> 
> Wont this also create exactly the same problems we are seeing now. 
> For example, I am replying to this mail in vim with encoding=latin1.
> When I switch to utf8, the \mu character looks like <b5> etc...

[I used mu, in this email, to represent where the cursor will be, I may
also have used '§']

Nope. Because MapMenu4Env() mecanics looks like:
- building 3 strings (3 modes) 
- where the INSERT-mode string is :
  '\begin{'.a:tex_env.'!close!<CR>'.a:middle.' <CR>\end{'.a:tex_env.'}<esc>ks', 
  As a result, ']ee' is i-mapped to: 
    \begin{enumerate!close!<CR>\item  <CR>\end{enumerate}<Esc>ks
  '{' may be already mapped to [2] to '{}«»<esc>F{a' (or may be not
  mappd at all)
  '}' if mapped is supposed to be mapped to '<esc>/}/<cr>a'
  '!close!' jumps to the marker (and delete it) if b:usemarks is set, or
  just moves one character to the right otherwise.

It is completly dependant on some asumption I made, but you can do
something similar with vim-latex.

The map&menus functions are highly complex, but in the end, defining
mappings in very easy as every LaTeX environments are based on the same
principles.

For more complex environments, template-files are, IMO, easier to handle
and maintain.

Back to your remark, the problem is to correctly define b:marker_open
(b|g:placeholder_left or something like that in imaps.vim) whatever the
encoding is.


[1] '¿...¿' will be replaced by 'VimL: ...'
[2] actually '{' is mapped to a very complex function that expand '{'
into different things according to: - the context (comment, string, or
other), - the value of b:usemarks, - the values of b:marker_open and
b:marker_close.
-- 
Luc Hermitte
http://hermitte.free.fr/vim/

Re: [Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8

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

Okay, Benji and Luc have convinced me. Let's get on with the great
change :) But before that, I would like to have a little bit of thought
about whats the best thing to change these things to.

Option 1:
    change things like '\onlyslides{=AB=BB}=AB=BB' to "\\onlyslides{\xab\xb=
b}\xab\xbb"
    I am wondering however, whether this will create problems with
    people who use international character sets etc. Ofcourse, now the
    files themselves will be easily readable, but I wonder if the way
    "\xab" displays on the screen depends on the locale which the user is
    currently using etc. A disadvantage of something like this will be
    that the vim scripts themselves will look pretty ugly with "\xab"
    kinda things all over the place...

Option 2:
    Change it to something like "\\onlyslides{<++>}<++>"
    Here the placeholder (or marker) characters are "<+" and "+>".
    Now the characters (and the vim scripts) will be correctly displayed
    across all platforms/locales etc. The problem with this approach,
    ofcourse is that we are using 2 characters instead of 1. This will
    make the expansions generally longer... Ofcourse, the users can
    still set g:Imap_PlaceHolder* to some different single width chars
    if they so desire...
    The advantage in this method is that the change will be very easy to
    implement. Just doing a simple
    % s/=AB\(.\{-}\)=BB/<+\1+>/g
    should suffice... In option 1, because of the \, we will have to
    careful about the difference between '\frac{=E4}{=AB=BB}=AB=BB' and
    "\\frac{=E4}{=AB=BB}=AB=BB".
    Also in option 2, the scripts will be lot more readable.
    The danger in option 2 ofcourse is that in some situation, the user
    has things like "<+" in the file independent of latex-suite. (But in
    that case, the user can use a different value for the placeholders).

Hmm.... As you can imagine, I am leaning towards option 2. Are there any
other suggestions?

On Sun, 8 Dec 2002, Luc Hermitte wrote:

> May be you could wrap these call into commands that will automatically
> build the different environments and TeX commands.
> That's what I've done in my lh-tex package. Thus, patching the files
> will be quite easy. [1]
>

The way things work now in latex-suite is that things like

let s:figure =3D "\\begin{figure}[=ABhtpb=BB]\<cr>\\begin{center}..."

are defined. When Imap_PutTextWithMovement is called it attempts to
replace =AB=BB chars with the thing defined in g:Imap_PlaceHolder*. In a wa=
y
therefore, latex-suite does actually wrap the commands into a central
function.

>   call <SID>MapMenu4Env("50.370.200", '&LaTeX.&Environments.&itemize',
>       \ ']ei', 'itemize', '\item ')
>   that also defines 3 mappings and 3 menus. The insert mode mapping
>   ']ei' inserts:
>     \begin{itemize}
>     \item =B5
>     \end{itemize}=AB=BB
>

Wont this also create exactly the same problems we are seeing now. For
example, I am replying to this mail in vim with encoding=3Dlatin1. When I
switch to utf8, the \mu character looks like <b5> etc...

--=20
Srinath Avadhanula
Dec 8 2:40pm
Bees are very busy souls
They have no time for birth controls
And that is why in times like these
There are so many Sons of Bees.

[Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8

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

* On Sun, Dec 08, 2002 at 11:38:24AM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> call s:Tex_SpecialMacros('', 'EnvCommands.&Slides.', '&onlyslides{}', 
> 	\ '\onlyslides{«»}«»', 0)
> in envmacros.vim.
> 
> Will it be possible to somehow change things so that in the
> initialization of latex-suite, we change the encoding once while
> sourcing envmacros.vim and such files and from then on in the
> functions themselves use the "\xab" character? 

> Will this make it possible to keep envmacros.vim unchanged? the «
> characters are used all over the place.

May be you could wrap these call into commands that will automatically
build the different environments and TeX commands.
That's what I've done in my lh-tex package. Thus, patching the files
will be quite easy. [1] 


My problem now regarding encoding is to change some mappings ; e.g.
'¡jump!' will be changed to '!jump!' or something like that.

My advice (as we have some similar concerns): don't use '«»' or 'ä' when
you need to define the different mappings, but something else that will
be easy to read and independent of encoding. [I chose to continue to use
¡jump! and ¡mark! ... but It won't last].

> In envmacros.vim, someplaces in the packages/* files, and other places.
> So some way of being able to work with all of them unchanged is ideal.

Yes. But right now they need to be changed. I completly with Benji:
don't use explicetly and so often '«»', 'ä' or anything else so
dependant on encoding in the Vim files. 


[1] To give an idea, here is the kind of definitions done into lh-tex:
  :MapMenu 50.370.100.400 &LaTeX.&Fonts.S&hort\ Scope.&Emphasize  ]em  emph
  that defines 3 menus and 3 mappings.
  The insert mode mapping ']em' inserts: '\emph{µ}«»' where 'µ'
  symbolises where the cursor will be placed and '«»' the marker
  inserted (can be anything else depending on configuration)

  or:
  call <SID>MapMenu4Env("50.370.200", '&LaTeX.&Environments.&itemize', 
      \ ']ei', 'itemize', '\item ')
  that also defines 3 mappings and 3 menus. The insert mode mapping
  ']ei' inserts: 
    \begin{itemize}
    \item µ
    \end{itemize}«»

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

[Vim-latex-devel] : Hi: I'm getting tuX appearin

[David R. <da...@tv...>]

Hi,
I installed a November version of vim-latex suite, but noticed I was getting a horrible 
string appearing apparently randomly while I was editing NON-TEX files ie my perl or 
php scripts. If I remember correctly it was something like <t_ux>. (I un-installed your 
suite!)

BTW your website doesn't have a "bugs fixed" page!!




Best Regards
David Rayner MSc CEng


Best Regards
David Rayner MSc CEng

Re: [Vim-latex-devel] vimfiles/plugin imaps.vim,1.7,1.8

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

Srinath Avadhanula wrote:
> Hey Benji,
> 
>>* Are there any files other than plugin/imaps.vim that need this sort of
>>change?
> 
> texrc also contains the '?' character in the definition of
> g:Tex_IgnoredWarnings. I tried the 'ga' command on it. It shows up as
> hex a1. I dont remember offhand what else needs changing, but this
> particular thing in the texrc is causing problems for people with chinese
> language settings.
> 
> 
>>* Are there any recent changes to 'encoding' etc. that should be undone
>>if this works?
> 
> 
> All these changes are in imaps.vim. The functions
> IMAP_PutTextWithMovement() and the IMAP_JumpFunc() will both have to be
> reverted back to the old versions. The new versions although they did
> work created big screen glitches as I noted... It will be really nice if
> we could have a way to solve this without having to change encoding...

      Thanks.  That will help.  I guess I can get the complete story 
either from the CVS viewer at SourceForge or from my saved CVS-generated 
e-mails.

> But wait. I just thought about this: Won't all of the macros have to be
> changed to use the "\xab" and "\xbb" characters as well. As of now, we
> have things like:
> 
> call s:Tex_SpecialMacros('', 'EnvCommands.&Slides.', '&onlyslides{}', '\onlyslides{??}??', 0)
> 
> in envmacros.vim.
> 
> Will it be possible to somehow change things so that in the
> initialization of latex-suite, we change the encoding once while
> sourcing envmacros.vim and such files and from then on in the functions
> themselves use the "\xab" character? Will this make it possible to keep
> envmacros.vim unchanged? the ? characters are used all over the place.
> In envmacros.vim, someplaces in the packages/* files, and other places.
> So some way of being able to work with all of them unchanged is ideal.

      I disagree.  If you saw my 'encoding' thread on the vim users' 
list, you know that I have had trouble while editing these files.  I 
worry that I (or CVS or ...) will munge some of these characters one of 
these days.  I think it is safest for vim script files to contain 
nothing but safe, universally understood, ASCII characters.  I think we 
should change all of our files now, to avoid trouble in the future.

					--Benji

Re: [Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8

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

Hey Benji,

Thanks for taking care of this. I will wait for you solution :) I will
use this strategy henceforth...

> * Are there any files other than plugin/imaps.vim that need this sort of
> change?
>
texrc also contains the '=A1' character in the definition of
g:Tex_IgnoredWarnings. I tried the 'ga' command on it. It shows up as
hex a1. I dont remember offhand what else needs changing, but this
particular thing in the texrc is causing problems for people with chinese
language settings.

> * Are there any recent changes to 'encoding' etc. that should be undone
> if this works?

All these changes are in imaps.vim. The functions
IMAP_PutTextWithMovement() and the IMAP_JumpFunc() will both have to be
reverted back to the old versions. The new versions although they did
work created big screen glitches as I noted... It will be really nice if
we could have a way to solve this without having to change encoding...

But wait. I just thought about this: Won't all of the macros have to be
changed to use the "\xab" and "\xbb" characters as well. As of now, we
have things like:

call s:Tex_SpecialMacros('', 'EnvCommands.&Slides.', '&onlyslides{}', '\onl=
yslides{=AB=BB}=AB=BB', 0)

in envmacros.vim.

Will it be possible to somehow change things so that in the
initialization of latex-suite, we change the encoding once while
sourcing envmacros.vim and such files and from then on in the functions
themselves use the "\xab" character? Will this make it possible to keep
envmacros.vim unchanged? the =AB characters are used all over the place.
In envmacros.vim, someplaces in the packages/* files, and other places.
So some way of being able to work with all of them unchanged is ideal.


--=20
Srinath Avadhanula
Dec 8 11:19am
"Cogito ergo I'm right and you're wrong."
=09=09-- Blair Houghton

[Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8

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

sri...@us... wrote:
> Update of /cvsroot/vim-latex/vimfiles/plugin
> In directory sc8-pr-cvs1:/tmp/cvs-serv31595
>=20
> Modified Files:
> 	imaps.vim=20
> Log Message:
[snip]
>=20
> If only someone had told me at the beginning not to use ascii > 127
> characters!! I think in the next major rev, we will have to undertake a
> major overhaul of all the macros to not use any of the higher ascii
> characters. Maybe modify IMAP() to allow for multiple character placeho=
lder
> characters... (maybe '{+' and '+}' like in cream).
[snip]

Srinath et al:

      I wish I had thought of this before you did a lot of work on=20
changing the 'encoding' settings.  I think there is a much simpler=20
solution to this problem:  stick with standard keyboard characters.=20
Instead of a line like

	let text =3D substitute(text, '=BB', phe, 'g')

from plugin/imaps.vim, use

	let text =3D substitute(text, "\xbb", phe, 'g')

I think this should have identical results.  Another option, when using=20
a string that is going to be used in Input mode (typically the return=20
value of Function() in a construction like :imap <key> <c-r>=3DFunction()=
)=20
is to try "\<C-K>>>".  This would need testing.

      I will try this tomorrow, unless someone wants to do it first.  A=20
few questions:

* Are there any files other than plugin/imaps.vim that need this sort of=20
change?

* Are there any recent changes to 'encoding' etc. that should be undone=20
if this works?

					--Benji

Re: [Vim-latex-devel] compilation noise

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

> >       Have you tried
> >
> > :make %
>
> whoa, it worked. why nobody told me that before? :)
> I think it should go in the FAQ.

Okay! The FAQ is a little too short anyway...

> About that, the new site designe is fine and I like very much it ant it's new
> sections. Qhy don't you put it as the "default" one ?

I will do it soon. As of now, I always get a very "raw" feeling when I
see it. A few more things here and there. A little bit better layout and
it will be put up.

> >       Maybe Srinath can help with that one.
>
> I hope too. I noticet that I have to CTRL-O TWO times and not just one!

One more of those "I cannot reproduce this" things... I tried making
a.tex, b.tex and c.tex as follows:

% a.tex
\documentclass{report}
\begin{document}
\include{b}
\include{c}
\end{document}

% b.tex
This is file b.

% c.tex
This is file c.

When I am in a.tex and do \ll, things work fine. I am left in a.
However, when I make some mistake in say c, then I will be taken to c...
But thats a feature. Are you referring to something else?
If you want to compile a.tex while in c.tex, then you'll need to do
something additional. From the docs:

-----------------------------------%<-----------------------------------
                                                        *latex-master-file*
Often times the file you are currently editing is only a fragment being
\input'ed into a master tex file. In such cases you will need to do create a
dummy file in the directory containing the current file. This dummy file is of
the form:
>
    <mailfilename>.latexmain

In other words, if the current file is ~/thesis/chapter.tex, where
chapter.tex is being \input'ed into ~/thesis/main.tex, then create a file
called >
    main.tex.latexmain
<
in the ~/thesis directory. This will then run "latex main.tex"
NOTE: Here main.tex.latexmain is a different file from main.tex itself.
main.tex need not be renamed. The contents of main.tex.latexmain are not used.
This ofcourse restricts each directory to have a single master file.

-----------------------------------%<-----------------------------------

Thanks,

Srinath

Re: [Vim-latex-devel] compilation noise

[febs <fab...@ti...>]

>       Have you tried
>
> :make %

whoa, it worked. why nobody told me that before? :)
I think it should go in the FAQ.
About that, the new site designe is fine and I like very much it ant it's new
sections. Qhy don't you put it as the "default" one ?

>       Maybe Srinath can help with that one.

I hope too. I noticet that I have to CTRL-O TWO times and not just one!

Bye, thnx again.

Re: [Vim-latex-devel] compilation noise

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

febs wrote:
> Well, it's about compilation with \ll 
> (there is still no way to compile with :make to me, althoug I have installed 
> another PC with a different linux distribution...)

      Have you tried

:make %

> my source file includes some others. when I "\ll", and the compilation works, 
> current window becomes owned by last file included. I have to manually get 
> back to the point where I was with CTRL-O. There is an escape?

      Maybe Srinath can help with that one.

HTH					--Benji

[Vim-latex-devel] compilation noise

[febs <fab...@ti...>]

Well, it's about compilation with \ll 
(there is still no way to compile with :make to me, althoug I have installed 
another PC with a different linux distribution...)

my source file includes some others. when I "\ll", and the compilation works, 
current window becomes owned by last file included. I have to manually get 
back to the point where I was with CTRL-O. There is an escape?

Thank you.

Fabio

[Vim-latex-devel] [vim-latex - Help] RE: Errors with vim-latex in windows

[<no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=1780350
By: tangyuq

I know how to duplicate the problem now. 
In vim:
:set encoding=cp936
then load a tex file and the problem may appear.

In vim:
:help encoding-names
:help encoding
More information about locale and language is avaiable. Hope it is helpful.


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge and visit: 
https://sourceforge.net/forum/monitor.php?forum_id=173627

[Vim-latex-devel] [vim-latex - Help] RE: Errors with vim-latex in windows

[<no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=1780300
By: tangyuq

I forgot:
In the control panel of windows(win2k and winxp), there is a "regional and language
setting" in which the operating system's language and text coding environment
will be set.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge and visit: 
https://sourceforge.net/forum/monitor.php?forum_id=173627

[Vim-latex-devel] [vim-latex - Help] RE: Errors with vim-latex in windows

[<no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=1780235
By: tangyuq

Hi,

I got some similar problems with vim in linux before. I think you can duplicate
the problem in linux as well and it may be more convenient to figure it out
in linux than in windows.

There are some environment variables, such LANG, ..., that affect the program's
behavior of internationalization, ex. vim. Just use "set LANG=cn_...",  I am
sorry I can not remember it exactly. You can search google for the
internationalization issues. Later when I finish the final exam, I may be able
to come back and give your more information about that if you still have no
idea at that time. I am really sorry now. :(

Thanks.

Yuqing

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge and visit: 
https://sourceforge.net/forum/monitor.php?forum_id=173627