Thread: [Vim-latex-devel] Re: [Vim-latex-cvs] vimfiles/plugin imaps.vim,1.7,1.8
Brought to you by:
srinathava,
tmaas
Menu
▾
▴
vim-latex-devel
|
From: Benji F. <be...@me...> - 2002-12-08 17:07:19
|
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
|
|
From: Srinath A. <sr...@fa...> - 2002-12-08 19:38:50
|
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
|
|
From: Benji F. <be...@me...> - 2002-12-08 20:32:28
|
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
|
|
From: Luc H. <her...@fr...> - 2002-12-08 22:20:59
|
* 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/
|
|
From: Srinath A. <sr...@fa...> - 2002-12-08 23:12:41
|
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.
|
|
From: Luc H. <her...@fr...> - 2002-12-09 00:32:45
|
* 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/
|
|
From: Srinath A. <sr...@fa...> - 2002-12-09 02:54:50
|
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
|
|
From: Luc H. <her...@fr...> - 2002-12-09 16:55:20
|
* 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
|
|
From: Benji F. <be...@me...> - 2002-12-11 16:56:14
|
Luc Hermitte wrote:
> * On Sun, Dec 08, 2002 at 06:54:47PM -0800, Srinath Avadhanula <srinath=
@fastmail.fm> wrote:
>=20
>>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')
>=20
>=20
> Indeed, but you loose flexibility in that case. The day the new languag=
e
> C% arise, it would not be able to take advantage of the C mapping for
> 'for' as it defines a new operator : '??'=20
> ;-)
My proposal (see other strands on this thread) also deals with this.
[snip]
>=20
> And I definitively agree, functions like IMAPS() should be independent
> of any placeholder characters. Somehow, '<+' and '+>' (as well as '=AB'=
&
> '=BB' today) look like placeholders characters, and more important: the=
y
> look like things that some languages may use -- like for instance '=AB'
> and '=BB' in LaTeX documents written in French.
>=20
>=20
>>And I think each language choosing its own placeholders is most
>>elegant and robust...
>=20
> =20
> 100% agree.
Did I snip anything that argues against the IMAP(ft, lhs, ...)=20
proposal?
--Benji
|
|
From: Luc H. <her...@fr...> - 2002-12-11 22:29:42
|
* On Wed, Dec 11, 2002 at 12:00:41PM -0500, Benji Fisher <be...@me...> wrote:
> Did I snip anything that argues against the IMAP(ft, lhs, ...)
> proposal?
Nope. Considering the way it is meant to be used [1], it's fine with me.
Otherwise, once you have done with IMAPxxx(), I have some proposals to
improve the jumping functions -- actually, they are the last version of
the functions Gergely Kontra simplified (he did cut all the options he
found in my original script)
However, they require that the default closing marker/placeholder
character to be defined with nr2char(char2nr("\xbb")) -- I don't really
understand why.
[1] I wrote many smart mappings and abbreviations that insert one text
or another depending on the syntaxic context (comment, string or
character) ; so I need to write things that looks like:
inoremap seq <C-r>=Function('seq', skeleton_with_marker/placehoders)
--
Luc Hermitte
http://hermitte.free.fr/vim/
|
|
From: Mikolaj M. <mi...@wp...> - 2002-12-09 10:32:50
|
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
|
|
From: Benji F. <be...@me...> - 2002-12-09 15:45:15
|
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
|
|
From: Srinath A. <sr...@fa...> - 2002-12-10 01:13:30
|
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
|
|
From: Benji F. <be...@me...> - 2002-12-11 16:51:42
|
Srinath Avadhanula wrote:
> 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...
I agree.
[snip]
> 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.
>=20
> 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.
OK, I had a good, long look at imaps.vim. As currently written,=20
IMAP() and IMAP_PutTextWithMovement() are global functions, and their=20
input has to use the hard-coded special values. This could be a problem=20
if, for example, "<<" and ">>" are used a French quotation marks, and=20
the user wants them in the replacement text. I think the=20
[bg]:Imap_PlaceHolder* should be used internally as well as in the file.
> 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.
Good.
> 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).
[snip]
>=20
>>IMAP(). I propose changing this to
>>
>> :call IMAP(ft, lhs, rhs1, ph1, rhs2, ph2, ...)
>>
>=20
> This is a beautiful solution. But consider that not all macros in
> latex-suite are triggered from IMAP(). Some of them do something like:
>=20
> inoremap <M-c> <C-r>=3DTex_MathCal()<CR>
>=20
> Then Tex_MathCal() does:
>=20
> return Imap_PutTextWithMovement("\\cite{=AB=BB)=AB=BB")
>=20
> So I suppose we will also have to change Imap_PutTextWithMovement() to
> accept variable arguments... Although the solution above does look lik=
e
> it could be _the_ correct solution, I have a feeling that hardcoding
> placeholders is not such a big deal at all...
>=20
> Assumption:
>=20
> latex-suite will never need to use strings like "<+something+>" except
> for demarcating placeholer characters.
> This assumtion is ****important*****
>=20
> Execution:
>=20
> envmacros.vim does:
>=20
> call Tex_IMAP('`/', '\frac{<++>}{<++>}<++>', 'tex')
>=20
> texrc does:
>=20
> let g:Imap_PlaceHolderStart =3D "\xab"
> let g:Imap_PlaceHolderEnd =3D "\xbb"
>=20
> 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.
>=20
> Finally, when the user press `/, he expands to \frac{|}{=AB=BB}=AB=BB w=
here | 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 us=
es a
> language where =AB=BB are legitimate chars.
>=20
> 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().
>=20
> Therefore, we could presumably have a user with an ftplugin/xml.vim
> file where he sets:
>=20
> let b:Imap_PlaceHolderStart =3D '?'
> let b:Imap_PlaceHolderEnd =3D '?'
>=20
> call IMAP('li`', '<li>??</li>??', 'xml')
>=20
> The crazy mathematician does
>=20
> " I have proved that the following strings occur with a probability
> " less than 1/(2*pi)^5*10e-12 in my files. I hope this is safe
> " enough.
> let b:Imap_PlaceHolderStart =3D '%xdf@#$'
> let b:Imap_PlaceHolderEnd =3D '*&#$*&'
>=20
> When he presses `/, he will get \frac{|}{%xdf@#$*&#$*&}%xdf@#$*&#$*&
> with | ofcourse denoting cursor position.
>=20
> Does this make everyone happy?
>=20
> Please try to come up with cases where the above system might fail...
>=20
> Okay... this mail is getting out of hand...
>=20
> Srinath
I think your proposal will work, but I think it will be hard to=20
maintain. First, I do not like the idea of an extra level of=20
indirection: Tex_Foo() as a wrapper for IMAP_Foo(). Second, it is=20
strange for Tex_Foo() to know about the "<+" character in LaTeX suite=20
and also the [bg]:Imap_PlaceHolder* variables.
I propose changing the IMAP() and Imap_PutTextWithMovement()=20
functions with versions that take a variable number of arguments, as=20
discussed above. Internally and in the file, they will use the=20
[bg]:Imap_PlaceHolder* variables, with "<+" and "+>" as the defaults.=20
This scheme has the following advantages (some of which your proposal=20
shares):
1. no funky characters in script files
2. Scripts that call IMAP() and Imap_PutTextWithMovement() do not need=20
to know what the special characters are.
3. When the user decides to change [bg]:Imap_PlaceHolder*, nothing else=20
needs to be changed.
There are also some other changes I would like to make.
4. Is there any reason not to use curly-brace variables? These are=20
available in all vim 6.x (i.e., not new in 6.1 and not, as far as I can=20
tell, a compilation option).
5. I would like to move the documentation from the comments to=20
doc/imaps.txt .
6. other clever simplifications
If we can agree on the IMAP(ft, lhs, ...) approach, then I will do=20
the work. I should be able to get some of it done on Friday.
--Benji
|
|
From: Srinath A. <sr...@fa...> - 2002-12-12 01:27:48
|
I agree that the IMAP() with the variable number of arguments is the
most elegant and sound. But consider the fact that changing imaps will
also mean changing every place where
Imap_PutTextWithMovement() and IMAP() are used...
For example, consider the following code snippet from envmacros.vim:
-----------------------------------%<-----------------------------------
let s:figure =3D "\\begin{figure}[=ABhtpb=BB]\<cr>\\begin{center}\<cr>\\psf=
ig{figure=3D=ABeps file=BB}\<cr>\\end{center}\<cr>\\caption{=ABcaption text=
=BB}\<cr>\\label{fig:=ABlabel=BB}\<cr>\\end{figure}=AB=BB"
" Tex_figure: {{{
function! Tex_figure(env)
if g:Tex_UseMenuWizard =3D=3D 1
let flto =3D input('Float to (htbp)? ')
let caption =3D input('Caption? ')
let center =3D input('Center ([y]/n)? ')
let label =3D input('Label (for use with \ref)? ')
" additional to AUC Tex since my pics are usually external files
let pic =3D input('Name of Pic-File? ')
if flto !=3D ''
let flto =3D '['.flto."]\<cr>"
else
let flto =3D "\<cr>"
endif
if pic !=3D ''
let pic =3D '\input{'.pic."}\<cr>"
else
let pic =3D "=E4\<cr>"
endif
if caption !=3D ''
let caption =3D '\caption{'.caption."}\<cr>"
endif
if label !=3D ''
let label =3D '\label{fig:'.label."}\<cr>"
endif
if center =3D=3D 'y'
let centr =3D '\begin{center}' . "\<cr>"
let centr =3D centr . pic
let centr =3D centr . caption
let centr =3D centr . label
let centr =3D centr . '\end{center}' . "\<cr>"
else
let centr =3D pic
let centr =3D centr . caption
let centr =3D centr . label
endif
let figure =3D '\begin{'.a:env.'}'.flto
let figure =3D figure . centr
let figure =3D figure . '\end{'.a:env.'}'
return IMAP_PutTextWithMovement(figure)
else
return IMAP_PutTextWithMovement(s:figure)
endif
endfunction
call IMAP('EDE', "\<C-r>=3DTex_description()\<CR>", 'tex')
-----------------------------------%<-----------------------------------
Ofcourse, this code is "extracted" from envmacros.vim rather than
directly cut and pasted, but the general flow of information is as
indicated... You will see that with the variable argument syntax, these
kind of functions will take a significant amount of tweaking... I think
almost of envmacros.vim and elementmacros.vim will have to be
re-written.
Also mathmacros.vim contains about 600 lines which look like this:
-----------------------------------%<-----------------------------------
let s:pA =3D 'amenu <silent> 85 '.s:MathMenuName
exe s:pA2a.'mathbf{} <plug><C-r>=3DIMAP_PutTextWithMovement(=
"\\mathbf{=E4}=AB=BB")<cr>'
-----------------------------------%<-----------------------------------
Changing these will also require a nontrivial amount of work.
I hope I dont come across as discouraging or anything, but the fact
remains that imaps.vim is heavily depended upon by many many things in
latex-suite. (Ofcourse, thats all the more reason to make it better).
So even if we do decide to go with the variable number of arguments
method, we should make sure that latex-suite doesnt remain broken for
too long in the change period. What about creating new functions called
IMAP_new and Imap_PutTextWithMovement_new and begin to slowly port
things across to use these. When we are satisfied that almost (or all)
or latex-suite uses these functions, then rename them to IMAP and
Imap_PutTextWithMovement and remove the originals... (the standard way
to obsolete things in software, I suppose...)
Let me know what you think.
Also, in places like mathmacros.vim, I would think that the easiest way
to affect the change is to first do a quick
exec "% s/\e4/<++>/g" " for <a-umlaut>
exec "% s/\xab/<+/g" " for "<<"
exec "% s/\xbb/+>/g" " for ">>"
% s/IMAP_PutTextWithMovement/Tex_PutTextWithMovement/g
where Tex_PutTextWithMovement() will have to be the "hacky" function
which knows both about the "\xab" characters and the
[g:b]Imap_PlaceHolder* settings. This new function will split its
arguments into variable arguments and then call
Imap_PutTextWithMovement_new.
In any case, I would think that some wrapper function like
Tex_PutTextWithMovement would have been useful even if we had
Imap_PutTextWithMovement_new from the beginning.
Srinath
On Wed, 11 Dec 2002, Benji Fisher wrote:
> OK, I had a good, long look at imaps.vim. As currently written,
> IMAP() and IMAP_PutTextWithMovement() are global functions, and their
> input has to use the hard-coded special values. This could be a problem
> if, for example, "<<" and ">>" are used a French quotation marks, and
> the user wants them in the replacement text. I think the
> [bg]:Imap_PlaceHolder* should be used internally as well as in the file.
>
> > 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.
>
> Good.
>
> > 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).
> [snip]
> >
> >>IMAP(). I propose changing this to
> >>
> >> :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:
> >
> > return 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 lik=
e
> > 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:
> >
> > call Tex_IMAP('`/', '\frac{<++>}{<++>}<++>', 'tex')
> >
> > texrc does:
> >
> > let g:Imap_PlaceHolderStart =3D "\xab"
> > let 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 w=
here | 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 us=
es 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:
> >
> > let b:Imap_PlaceHolderStart =3D '?'
> > let b:Imap_PlaceHolderEnd =3D '?'
> >
> > call IMAP('li`', '<li>??</li>??', 'xml')
> >
> > The crazy mathematician does
> >
> > " I have proved that the following strings occur with a probability
> > " less than 1/(2*pi)^5*10e-12 in my files. I hope this is safe
> > " enough.
> > let b:Imap_PlaceHolderStart =3D '%xdf@#$'
> > let 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
>
> I think your proposal will work, but I think it will be hard to
> maintain. First, I do not like the idea of an extra level of
> indirection: Tex_Foo() as a wrapper for IMAP_Foo(). Second, it is
> strange for Tex_Foo() to know about the "<+" character in LaTeX suite
> and also the [bg]:Imap_PlaceHolder* variables.
>
> I propose changing the IMAP() and Imap_PutTextWithMovement()
> functions with versions that take a variable number of arguments, as
> discussed above. Internally and in the file, they will use the
> [bg]:Imap_PlaceHolder* variables, with "<+" and "+>" as the defaults.
> This scheme has the following advantages (some of which your proposal
> shares):
>
> 1. no funky characters in script files
> 2. Scripts that call IMAP() and Imap_PutTextWithMovement() do not need
> to know what the special characters are.
> 3. When the user decides to change [bg]:Imap_PlaceHolder*, nothing else
> needs to be changed.
>
> There are also some other changes I would like to make.
>
> 4. Is there any reason not to use curly-brace variables? These are
> available in all vim 6.x (i.e., not new in 6.1 and not, as far as I can
> tell, a compilation option).
>
> 5. I would like to move the documentation from the comments to
> doc/imaps.txt .
>
> 6. other clever simplifications
>
> If we can agree on the IMAP(ft, lhs, ...) approach, then I will do
> the work. I should be able to get some of it done on Friday.
>
> --Benji
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Vim-latex-devel mailing list
> Vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vim-latex-devel
>
>
--=20
Srinath Avadhanula
Dec 11 4:58pm
Excellent day for drinking heavily. Spike office water cooler.
|
|
From: Srinath A. <sr...@fa...> - 2002-12-12 04:15:58
|
Just a small correction..
On Wed, 11 Dec 2002, Srinath Avadhanula wrote:
> Also mathmacros.vim contains about 600 lines which look like this:
>
> -----------------------------------%<-----------------------------------
> let s:pA =3D 'amenu <silent> 85 '.s:MathMenuName
> exe s:pA2a.'mathbf{} <plug><C-r>=3DIMAP_PutTextWithMovemen=
t("\\mathbf{=E4}=AB=BB")<cr>'
> -----------------------------------%<-----------------------------------
>
> Changing these will also require a nontrivial amount of work.
>
> <snip>
>
> ... I would think that the easiest way to affect the change is to
> first do a quick
>
> exec "% s/\e4/<++>/g" " for <a-umlaut>
> exec "% s/\xab/<+/g" " for "<<"
> exec "% s/\xbb/+>/g" " for ">>"
> % s/IMAP_PutTextWithMovement/Tex_PutTextWithMovement/g
>
> where Tex_PutTextWithMovement() will have to be the "hacky" function
> which knows both about the "\xab" characters and the
> [g:b]Imap_PlaceHolder* settings. This new function will split its
> arguments into variable arguments and then call
> Imap_PutTextWithMovement_new.
Tex_PutTextWithMovement will _not_ need to know about
[g:b]Imap_PlaceHolder* settings, because it will call the
Imap_PutTextWithMovement_new() function, not the
Imap_PutTextWithMovement() function...
thats all for now.
This is the last 10 days of classes... So I will not be doing any
actual coding in the meantime.
Thanks,
Srinath
|
|
From: Benji F. <be...@me...> - 2002-12-12 12:35:20
|
Srinath Avadhanula wrote:
> Just a small correction..
>=20
> On Wed, 11 Dec 2002, Srinath Avadhanula wrote:
>=20
>>Also mathmacros.vim contains about 600 lines which look like this:
>>
>>-----------------------------------%<----------------------------------=
-
>>let s:pA =3D 'amenu <silent> 85 '.s:MathMenuName
>>exe s:pA2a.'mathbf{} <plug><C-r>=3DIMAP_PutTextWithMovem=
ent("\\mathbf{=E4}=AB=BB")<cr>'
>>-----------------------------------%<----------------------------------=
-
>>
>>Changing these will also require a nontrivial amount of work.
Your snipped example is a problem (defining a string and later=20
calling IMAP) but this is not hard. I can do this with a suitable=20
:%s/../../gc .
>><snip>
>>
>>... I would think that the easiest way to affect the change is to
>>first do a quick
>>
>>exec "% s/\e4/<++>/g" " for <a-umlaut>
>>exec "% s/\xab/<+/g" " for "<<"
>>exec "% s/\xbb/+>/g" " for ">>"
>>% s/IMAP_PutTextWithMovement/Tex_PutTextWithMovement/g
>>
>>where Tex_PutTextWithMovement() will have to be the "hacky" function
>>which knows both about the "\xab" characters and the
>>[g:b]Imap_PlaceHolder* settings. This new function will split its
>>arguments into variable arguments and then call
>>Imap_PutTextWithMovement_new.
>=20
> Tex_PutTextWithMovement will _not_ need to know about
> [g:b]Imap_PlaceHolder* settings, because it will call the
> Imap_PutTextWithMovement_new() function, not the
> Imap_PutTextWithMovement() function...
>=20
> thats all for now.
I do not need two wrapper functions. I'll use=20
Tex_PutTextWithMovement() but not Imap_PutTextWithMovement_new(). I'll=20
see how much I can finish tomorrow morning...
--Benji
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X