Thread: [Vim-latex-devel] Review of vim-latex status
Brought to you by:
srinathava,
tmaas
Menu
▾
▴
vim-latex-devel
|
From: Srinath A. <sr...@fa...> - 2002-12-24 21:11:41
|
Hello,
Its been quite a hectic coding time in the vim-latex project and its
time to step back and take note of all the things which we did/will do.
Things which were improved
==========================
1. imaps.vim: This was simplified by BF and also we think we have solved
the encoding issues as far as we can tell. For me, on win32 and on
some tests on unix machine, the current version just works.
2. Compilation: Carl Mueller's suggestion led to a pretty nifty compiler
program which syns the quickfix window with the log preview window
providing the advantages of both the quickfix window by allowing you
to jump and get a quick overview of all errors while providing more
detailed descriptions of each error via the log window.
3. The packages.vim file was robustified. This has not yet been commited
to the main branch because I am still waiting to hear from Mikolaj.
Actually, not too many changes were made. Just the menu creating code
was changed and a function Tex_MakeSubMenu was extracted which will
be used in other parts of latex-suite in the future.
4. Mikolaj added many new packages. Latex-suite now supports 38
packages! Support for the amsmath package is really excellent.
5. A _lot_ of bugfixes happened since the last release.
Things which need to improve
============================
1. Atleast for me, the diacritics have been a longstanding source of
annoyance at unexpected times. Everytime I try doing a=b, I get
a\'{b}. And assignments like a=b are so common that this becomes
painful pretty fast. I would love to find out a better way to
implement support for diacritics. I am in fact thinking of disabling
diacritics by default unless we get some better ideas.
2. This is as of now, poor documentation at various places. Often times,
the script file contains documentation, whereas it should be in a
doc/.txt file (in the case of imaps.vim). Sometimes, documentation is
just plain missing (in the case of bibtex.vim). I suspect that there
are quite a few features of latex-suite even I dont know about.
Especially in the case of bibtex.vim, the lack of documentation and
menu items etc leads it to be completeley lost to the end-user.
Latex-suite really needs some time spent on documentation.
3. There are still 'funky' characters in various places of latex-suite
leading to internationalization issues.
4. Some of the maps do not check for hasmapto(rhs) and mapcheck(lhs)
before mapping. This needs to change.
Future Directions
=================
These are things which are on my "cool things to do" list. Please feel
free to share your own.
1. Dependency checking: i.e, when the user chooses the 'pdf' format,
latex-suite automatically compiles the dvi file, converts to ps and
then to pdf according to user preferences. I know that lh-tex (by
Luc) already has these kind of things implemented. But from what I
can see, he has hardcoded the dependencies, i.e pdf always follows
from ps and things like that. I would think that we could have
options like
Tex_FormatDepenency_pdf = 'ps'
Tex_FormatDepenency_ps = 'dvi'
Tex_FormatDepenency_dvi = 'tex'
which enable a customized dependency setting. I propose that we have
a discussion about the best way to implement this. (Luc can start by
telling us how he did it). We could then come up with an framework we
all agree on and then implement it in a manner consistent with
latex-suite. Since this is (will be) such a core part of latex-suite,
I would like this to be implemented after a lot of thought.
2. Compilation Sequence: Again, Luc has implemented a way to run latex,
bibtex, makeindex etc according to what needs to be run etc. This too
needs to be part of latex-suite. Again, I would think we should
discuss this and then implement. Again, it will be a core part. For
both points 1 and 2, we should I think come up with an empty vim file
containing just funciton prototypes and documentation which we all
agree on. After that, we will implement it.
3. New developer: Becase Luc has implemented both 2 and 3 in lh-tex, I
propose that we get Luc into the developer team if he wants. To start
with, he can implement his ideas on a seperate branch. Afterwards, we
can merge this into the main trunk.
4. Citation browser: I know that auctex from emacs has a feature where
it sets up a browsable window of the citations found in the bibtex
file. We could implement a system where if the user presses <Alt-c>,
\cite{} is inserted and the browser comes up asking him to choose a
citation.
5. Removal of unwanted cruft: I am pretty sure latex-suite has features
which it can afford to lose.
Happy Holidays!!! (My girlfriend is dragging me off to some shopping
now)
Srinath
|
|
From: Srinath A. <sr...@fa...> - 2002-12-25 03:53:53
|
I knew I was forgetting something else... On Tue, 24 Dec 2002, Srinath Avadhanula wrote: > Things which were improved > ========================== I forgot some of the most important improvements! Carl Mueller's suggestions have led to nice improvements in inserting environments. I also find the bracket completion macros invaluable... I haven't really used the polymorphic <M-c> macros too much yet, but I am sure they will be a help as well... Srinath |
|
From: Mikolaj M. <mi...@wp...> - 2002-12-26 22:46:34
|
On Tue, Dec 24, 2002 at 01:11:30PM -0800, Srinath Avadhanula wrote:
Hello,
Sorry for not responding in last weeks but I was cutted off
from e-mail.
> 3. The packages.vim file was robustified. This has not yet been commited
> to the main branch because I am still waiting to hear from Mikolaj.
> Actually, not too many changes were made. Just the menu creating code
> was changed and a function Tex_MakeSubMenu was extracted which will
> be used in other parts of latex-suite in the future.
I am still on limited computer use. Please merge newpackages branch.
Well done. If you have any improvements in this area let me know.
> 4. Mikolaj added many new packages. Latex-suite now supports 38
> packages! Support for the amsmath package is really excellent.
Some new are awaiting in home for stabilization of new placeholders
system.
> Things which need to improve
> ============================
> 1. Atleast for me, the diacritics have been a longstanding source of
> annoyance at unexpected times. Everytime I try doing a=b, I get
> a\'{b}. And assignments like a=b are so common that this becomes
> painful pretty fast. I would love to find out a better way to
> implement support for diacritics. I am in fact thinking of disabling
> diacritics by default unless we get some better ideas.
diacritics are rarely used. If you need it for your national letters
probably they are built-in in LaTeX and you don't need to play with =b
things. Maybe disable it by default and add switch to turn it on/off?
> Future Directions
> =================
> These are things which are on my "cool things to do" list. Please feel
> free to share your own.
> 1. Dependency checking: i.e, when the user chooses the 'pdf' format,
> latex-suite automatically compiles the dvi file, converts to ps and
> then to pdf according to user preferences.
Why? pdflatex thing works good enough. Dvi format has advantage of
possibility of forward/backward searching in dvi viewers but if you need
it you will be making pdf files at the end of day.
> 3. New developer: Becase Luc has implemented both 2 and 3 in lh-tex, I
> propose that we get Luc into the developer team if he wants. To start
> with, he can implement his ideas on a seperate branch. Afterwards, we
> can merge this into the main trunk.
Fine :)
> 4. Citation browser: I know that auctex from emacs has a feature where
> it sets up a browsable window of the citations found in the bibtex
> file. We could implement a system where if the user presses <Alt-c>,
> \cite{} is inserted and the browser comes up asking him to choose a
> citation.
It could be done also for labels, refpages and so on. I did some time
ago something like this. I have to find it...
> 5. Removal of unwanted cruft: I am pretty sure latex-suite has features
> which it can afford to lose.
Hmm. I would vote for "other miscellaneous stuff taken from imaps.vim in
main.vim (lines 117-136 in my version). This is really redundant IMO.
My suggestions:
1. Move smartspace.vim and brackets.vim to ftplugin/latex-suite
directory (and add proper lines in main.vim). Now they are in
ftplugin/tex dir and they are automagically sourced. IMO this is a Bad
Thing(tm). We do not have control in which order they are sourced and
more important user doesn't have control. Because this files have
mappings user should have possibility to overwrite it. With latex-suite
files in ftplugin/tex dir user have to give special names to be sure his
files are sourced at the end.
2. Create vim-latex format with vim-latex menus integrated with normal
Vim menus like this is in HTML editors. For example: disable Syntax
menus, put TeX-Suite/Templates menu into File/New Latex File menu.
Mikolaj
|
|
From: Srinath A. <sr...@fa...> - 2002-12-27 00:51:02
|
On Thu, 26 Dec 2002, Mikolaj Machowski wrote:
> Some new are awaiting in home for stabilization of new placeholders
> system.
The placeholder system has been stabilized.. If we do make any changes,
it will be internal changes, so the interace never changes... In all the
package files, just use the '<+' and '+>' characters instead of the old
=AB and =BB characters...
> diacritics are rarely used. If you need it for your national letters
> probably they are built-in in LaTeX and you don't need to play with =3Db
> things. Maybe disable it by default and add switch to turn it on/off?
>
Precisely what I was thinking... I will disable them by default.
> Why? pdflatex thing works good enough. Dvi format has advantage of
> possibility of forward/backward searching in dvi viewers but if you need
> it you will be making pdf files at the end of day.
>
Well, its just a nice thing to do... I gave pdf as an example... For ps
files, afaik, dvips is the only way... Morevoer, this will be
customizable. If the user wants to use pdflatex, he would be able to
tell latex-suite to use pdflatex which takes tex files not ps files...
> > 3. New developer: Becase Luc has implemented both 2 and 3 in lh-tex, I
> > propose that we get Luc into the developer team if he wants. To star=
t
> > with, he can implement his ideas on a seperate branch. Afterwards, w=
e
> > can merge this into the main trunk.
>
> Fine :)
Luc, Please let us know if you think you like this idea...
Also, Carl Mueller has made invaluable contributions to latex-suite. If
he desires, he could join the team too
> > 4. Citation browser: I know that auctex from emacs has a feature where
> > it sets up a browsable window of the citations found in the bibtex
> > file. We could implement a system where if the user presses <Alt-c>,
> > \cite{} is inserted and the browser comes up asking him to choose a
> > citation.
>
> It could be done also for labels, refpages and so on. I did some time
> ago something like this. I have to find it...
>
Let's make this as general as possible, so the citation browser, the
reference browser etc only have to supply a list to some central handler
function...
> > 5. Removal of unwanted cruft: I am pretty sure latex-suite has features
> > which it can afford to lose.
>
> Hmm. I would vote for "other miscellaneous stuff taken from imaps.vim in
> main.vim (lines 117-136 in my version). This is really redundant IMO.
>
Done! Feel free to suggest more deletions.
> 1. Move smartspace.vim and brackets.vim to ftplugin/latex-suite
> directory (and add proper lines in main.vim). Now they are in
> ftplugin/tex dir and they are automagically sourced. IMO this is a Bad
> Thing(tm). We do not have control in which order they are sourced and
> more important user doesn't have control. Because this files have
> mappings user should have possibility to overwrite it. With latex-suite
> files in ftplugin/tex dir user have to give special names to be sure his
> files are sourced at the end.
>
Well, overwriting the maps is not a problem. See the latest version of
tex/brackets.vim. It does
if !hasmapto('Tex_MathBF', 'i') && mapcheck('<M-b>', 'i') =3D=3D ''
=09inoremap <buffer> <silent> <M-b> <C-r>=3DTex_MathBF()<CR>
endif
This enables a user to overwrite the plugin using something like
inoremap <buffer> <silent> mykey <C-r>=3DTex_MathBF()<cr>
his ftplugin/tex.vim file.
The reason I chose this way was this provides a nice (or at least easy)
way to extend latex-suite. The final aim is that each of these files is
kind of independent of the rest, so the user can pick up whatever pieces
he wants. Also note that tex_latexSuite.vim is still sourced before
files in the tex/ directory. Therefore latex-suite will still be able to
provide hooks to these plugins if wanted... I wonder what others think
of this issue...
> 2. Create vim-latex format with vim-latex menus integrated with normal
> Vim menus like this is in HTML editors. For example: disable Syntax
> menus, put TeX-Suite/Templates menu into File/New Latex File menu.
>
Hmmm... I am not really sure what you mean... What do you mean by
'vim-latex' format? Also, whats a natural place for the TeX-Environments
menu? That will have to be seperate, right?
Srinath
|
|
From: Carl M. <cm...@ma...> - 2002-12-27 15:45:48
|
On Thu, Dec 26, 2002 at 04:51:00PM -0800, Srinath Avadhanula wrote: > > Also, Carl Mueller has made invaluable contributions to latex-suite. If > he desires, he could join the team too > I'm not sure that I have time to participate in the way that everyone else on this list does. Also, I have already contributed most of my ideas. If I come up with anything else, I could send it to Srinath, and I'll still participate in the mailing list (if I think of anything else). Best wishes, Carl |
|
From: Luc H. <her...@fr...> - 2002-12-27 22:02:32
|
* On Thu, Dec 26, 2002 at 04:51:00PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> > Why? pdflatex thing works good enough.
Not always. I used pst-uml for a C++ course I updated. As I had not
installed pdfTricks on my system (actually, I am not sure that miktex
supports pdfTricks), I wasn't able to use pdflatex. I had to use dvips +
ps2pdf. While I used pdflatex for the subjects of the exams.
> [...]
> if !hasmapto('Tex_MathBF', 'i') && mapcheck('<M-b>', 'i') == ''
> inoremap <buffer> <silent> <M-b> <C-r>=Tex_MathBF()<CR>
> endif
I see another problem here. Meta mappings are a pure headache!
As often as possible, I suggest that latex-suite does not propose them
by default. For instance, here <M-b> is linked to 'â' with my
configuration. That means, I will have to hit '<c-v>^age' if I want to
write 'âge' and not '\mathbf{ne}<++>'.
BTW, I prefer ']bf' (or ']mbf') to '<M-b>'. In the long run I'm
interrested in a single mapping that will insert '\textbf{}' or
'\mathbf{}' according to the context.
--
Luc Hermitte
http://hermitte.free.fr/vim/
|
|
From: Carl M. <cm...@ma...> - 2002-12-27 23:07:11
|
On Fri, Dec 27, 2002 at 03:31:48AM +0100, Luc Hermitte wrote:
> BTW, I prefer ']bf' (or ']mbf') to '<M-b>'. In the long run I'm
> interrested in a single mapping that will insert '\textbf{}' or
> '\mathbf{}' according to the context.
I considered the <M-b> mapping for \mathbf{} as my greatest
idea, it was just that the Alt key is handy, and I don't use
it for anything else. Possibly, there should be a second
"mapleader" key, in addition to "`" (backtick). Maybe the
semicolon key ";" is worth considering, although it is used
in typing. Perhaps ";" could begin all sorts of macros
which would adjust the font. In that case, ";;" (two
semicolons) could be used to insert a single semicolon.
Or, maybe <C-g> is a good choice; it's not used, and it's
easy to reach. Also, <C-`> (control-backtick) is a
possibility.
Best wishes,
Carl
|
|
From: Carl M. <cm...@ma...> - 2002-12-28 19:50:30
|
> I considered the <M-b> mapping for \mathbf{} as my greatest
> idea,
Sorry, I meant that it WASN'T my greatest idea; (irony intended).
Best wishes,
Carl
|
|
From: Srinath A. <sr...@fa...> - 2002-12-30 03:23:13
|
I personally think that the bracket completion macros are a GREAT idea!
Also, I have tried to implement all the ideas from auctex.vim into the
latest version of latex-suite. I remember that you used the fact that
amsmath is used to change some behaviors... Thats the only thing missing
right now... I will have to take a look at auctex.vim again to see where
you used it...
Srinath
On Sat, 28 Dec 2002, Carl Mueller wrote:
> > I considered the <M-b> mapping for \mathbf{} as my greatest
> > idea,
>
> Sorry, I meant that it WASN'T my greatest idea; (irony intended).
>
> Best wishes,
> Carl
>
|
|
From: Carl M. <cm...@ma...> - 2002-12-31 01:48:15
|
Dear Srinath,
On Sun, Dec 29, 2002 at 07:23:11PM -0800, Srinath Avadhanula wrote:
> I remember that you used the fact that
> amsmath is used to change some behaviors...
The presence of
\usepackage{amsmath}
was used for the function key macros for entering
environments, and to replace them. I picked out the most
common environments in each case (most common for me).
" KEY LATEX AMSLATEX
"
" F1 equation equation
" F2 \[...\] equation*
" F3 eqnarray align
" F4 eqnarray* align*
" F5 asks for environment asks for environment
For me, the environments are logically ordered in this way,
that is,
one-line, with numbering
one-line, without numbering
mulitine, with numbering
mulitine, without numbering
Of course, the current scheme of picking out an environment
with a number is nice, too. The user can always bind the
function keys if he/she wants to save an extra key stroke or 2.
Maybe, the choices presented to the user could depend on the
presence of \usepackage{amsmath}.
In general, I like to use the fewest number of keystrokes.
That's why, for \mathbf, I have the user type a letter and
then press <Alt-b> (which then capitalizes the letter and
encloses it in \mathbf{} ). Then I realized that with this
method, the same key could be used for several purposes,
depending on the key that preceded it. For instance,
<Alt-l> preceded by a bracket inserts \left...\right, but if
it is not preceded by a bracket, it produces \label{}.
Actually, the "smart brackets" were the earliest case of this
that I know of; These were part of emacs auctex.
In general, we should pay close attention to existing
packages. In addition to emacs auctex, there is a related
emacs package called ultratex. It has the auctex mappings,
but also has "lightning completion", which is sort of the
same thing as word completion with <C-N> or <C-P>. But you
do not have the option of rejecting the completion. This
never appealed to me, but I know a number of mathematicians
who like it. Also, in ultratex, typing $$ results in
$$
$$
Typing more dollar signs will make the environment cycle
through \begin{equation}...\end{equation}, and so on. I
decided that it was easier to just get what you want with a
single keystroke, with F1 - F4.
Best wishes,
Carl
|
|
From: Benji F. <be...@me...> - 2002-12-31 02:14:52
|
Carl Mueller wrote:
[snip]
> In general, we should pay close attention to existing
> packages. In addition to emacs auctex, there is a related
> emacs package called ultratex. It has the auctex mappings,
> but also has "lightning completion", which is sort of the
> same thing as word completion with <C-N> or <C-P>. But you
> do not have the option of rejecting the completion. This
> never appealed to me, but I know a number of mathematicians
> who like it. [snip]
Did you ever try my word_complete.vim script? It is probably too
clunky to include with the latex suite, but it was an interesting
exercise. ;)
http://www.vim.org/script.php?script_id=73
--Benji
|
|
From: Carl M. <cm...@ma...> - 2002-12-31 02:22:53
|
Dear Benji, > Did you ever try my word_complete.vim script? It is probably too > clunky to include with the latex suite, but it was an interesting > exercise. ;) I might have tried it, come to think of it. Was it based on lightning completion? I once attended a lecture by S. S. Chern, (a well-known geometrer) who said that the basic ideas are really very few (in mathematics). Probably, the same is true with computers, so we should certainly make use of other peoples' ideas, even from the emacs world. Best wishes, Carl |
|
From: Benji F. <be...@me...> - 2002-12-31 03:02:27
|
Carl Mueller wrote:
> Dear Benji,
>
>
>> Did you ever try my word_complete.vim script? It is probably too
>>clunky to include with the latex suite, but it was an interesting
>>exercise. ;)
>
>
> I might have tried it, come to think of it. Was it based on
> lightning completion?
>
> I once attended a lecture by S. S. Chern, (a well-known
> geometrer) who said that the basic ideas are really very few
> (in mathematics). Probably, the same is true with computers,
> so we should certainly make use of other peoples' ideas,
> even from the emacs world.
>
> Best wishes,
> Carl
In principle, I agree, but in practice I have never used emacs, so
it is hard for me to borrow from it. Anyway, word_complete.vim
automatically invokes <C-P>, then highlights the completion in Select
mode. It works by mapping every alphabetic character (or maybe only the
lower-case ones).
Who was it who said, "Lesser artists borrow. Great artists steal"?
--Benji
|
|
From: Srinath A. <sr...@fa...> - 2002-12-31 07:06:29
|
On Mon, 30 Dec 2002, Benji Fisher wrote: > Who was it who said, "Lesser artists borrow. Great artists steal"? Apparently it was Igor Stravinsky. According to google :) Speaking of great steals: Take a look at reftex: http://zon.astro.uva.nl/~dominik/Tools/reftex/ Especially check out the screenshots in: http://zon.astro.uva.nl/~dominik/Tools/reftex/reftex-nutshell.html Some of those screenshots are really really cool.... I think however, that true to the emacs philosophy, they try to do way too much... All of this can be implemented without all the fancyness with some grep's... The single most useful thing ofcourse will be a citation browser http://zon.astro.uva.nl/~dominik/Tools/reftex/screenshots/select-cite.gif Ofcourse, the ability to sort the bibtex file according to various files might be a help in inserting citation tags more easily... In order to "borrow" ideas from the emacs world, I have even installed emacs on my windows box. Unfortunately, the only command which I have found a liking for so far has been the <C-x><C-c> command.... I have tried briefly to activate the viper mode in order to bring myself to stay a little longer, but I didn't come across the method to do this easily enough... Srinath |
|
From: Carl M. <cm...@ma...> - 2003-01-06 15:05:32
|
About the Alt macros, how about the following?
1. As an option, the user can turn on the <Alt> mappings.
(This was mentioned by others.)
2. As a default, use the <Insert> key for the <Alt> mappings.
The <Insert> key isn't used for anything else, is it?
It could be a right handed version of the "`" mappings.
Besides the <Alt> mappings that I wrote, one could use the
<Insert> key for mappings that control fonts, such as
{\em ...} and so on.
I'd still like to keep the <Alt> mappings as an option, since the
<Alt> key is more handy than the <Insert> key.
Best wishes,
Carl
|
|
From: Benji F. <be...@me...> - 2003-01-06 15:24:05
|
Carl Mueller wrote:
> About the Alt macros, how about the following?
>
> 1. As an option, the user can turn on the <Alt> mappings.
> (This was mentioned by others.)
>
> 2. As a default, use the <Insert> key for the <Alt> mappings.
> The <Insert> key isn't used for anything else, is it?
> It could be a right handed version of the "`" mappings.
> Besides the <Alt> mappings that I wrote, one could use the
> <Insert> key for mappings that control fonts, such as
> {\em ...} and so on.
>
> I'd still like to keep the <Alt> mappings as an option, since the
> <Alt> key is more handy than the <Insert> key.
The <Insert> key is used to toggle between Insert and Replace
modes. I almost never use Replace mode, and I often hit the <Insert>
key when I am aiming for the <Del> key, so I have :imap'ed it to <Nop>.
In other words, it is not quite true that the <Insert> key is
unused, but it is pretty close.
--Benji
|
|
From: Srinath A. <sr...@fa...> - 2003-01-07 02:16:25
|
On Mon, 6 Jan 2003, Benji Fisher wrote:
> Carl Mueller wrote:
> > About the Alt macros, how about the following?
> >
> > 1. As an option, the user can turn on the <Alt> mappings.
> > (This was mentioned by others.)
I think having an option g:Tex_UseMetaMappings (defaults to 0, i.e 'no')
is a good thing...
> > 2. As a default, use the <Insert> key for the <Alt> mappings.
> > The <Insert> key isn't used for anything else, is it?
> > It could be a right handed version of the "`" mappings.
> > Besides the <Alt> mappings that I wrote, one could use the
> > <Insert> key for mappings that control fonts, such as
> > {\em ...} and so on.
> >
> The <Insert> key is used to toggle between Insert and Replace
> modes. I almost never use Replace mode, and I often hit the <Insert>
> key when I am aiming for the <Del> key, so I have :imap'ed it to <Nop>.
>
> In other words, it is not quite true that the <Insert> key is
> unused, but it is pretty close.
>
Hmm... Lets see... What about moving away from "special" keys altogether
and using ']l' ']b' ']c' etc in insert mode (as Luc suggests) and
<M-[lbc]> in normal mode (or maybe even ']b' etc in normal mode as
well)? This way people who want to use <M-c> etc for national characters
can continue to do so... Ofcourse this makes the users of latex-suite
learn yet another "leader" character... Maybe ']' can be reserved for
beginning maps which change the text before them in some way... In the
future, we could have more of such maps...
Ofcourse, I have still not gotten around to creating a good way to let
the end user over-ride the maps. Benji suggested that a section of texrc
can have things like
" Pressing <F5> will prompt you for which environment to insert.
" Change <F5> to change the ``hotkey''.
nmap <silent> <F5> <Plug>Tex_FastEnvironmentInsert
etc. The user needs to change the lhs in these lines to customize...
But texrc or the user's copy of texrc is sourced only once when
latex-suite initializes, not for every BufEnter event... So that might
not be a good place...
Should we just document all the maps created by latex-suite in
latex-suite.txt and then put "Read the docs about how to override
mappings" somewhere in the install instructions?
Luc, Mikolaj, Fabio any suggestions? The rest of us AFAIK do not use
the meta key anyway...
I just thought about this? Are things like ']b' etc going to cause the
same kind of problems diacritics caused? Do strings like ']b' occur
often in latex?
Srinath
|
|
From: Benji F. <be...@me...> - 2003-01-07 03:46:46
|
Srinath Avadhanula wrote:
> Hmm... Lets see... What about moving away from "special" keys altogether
> and using ']l' ']b' ']c' etc in insert mode (as Luc suggests) and
> <M-[lbc]> in normal mode (or maybe even ']b' etc in normal mode as
> well)? This way people who want to use <M-c> etc for national characters
> can continue to do so... Ofcourse this makes the users of latex-suite
> learn yet another "leader" character... Maybe ']' can be reserved for
> beginning maps which change the text before them in some way... In the
> future, we could have more of such maps...
>
> Ofcourse, I have still not gotten around to creating a good way to let
> the end user over-ride the maps. Benji suggested that a section of texrc
> can have things like
>
> " Pressing <F5> will prompt you for which environment to insert.
> " Change <F5> to change the ``hotkey''.
> nmap <silent> <F5> <Plug>Tex_FastEnvironmentInsert
>
> etc. The user needs to change the lhs in these lines to customize...
> But texrc or the user's copy of texrc is sourced only once when
> latex-suite initializes, not for every BufEnter event... So that might
> not be a good place...
Actually, I was suggesting something more radical. Something like
this:
" We do not need much of a comment because we use long, descriptive
" variable names.
" Key for inserting a TeX environment (duh).
" See :help latex-environment for details.
" Usually, these :help pointers in the comments will apply to several
" options at once.
let Tex_FastEnvironmentInsert = '' " '<F5>' is popular.
" Either default to empty string as above or else comment it out:
" let Tex_FastEnvironmentInsert = '<F5>'
Then the TexSetOptions() function (called on each FileType tex event, I
think) can test whether g:Tex_FastEnvironmentInsert exists (or is not
the empty string) and use it to define a map if so. This is the way I
did it way back in texmacros.vim (for vim 5.3+).
> Should we just document all the maps created by latex-suite in
> latex-suite.txt and then put "Read the docs about how to override
> mappings" somewhere in the install instructions?
Yes. Each group of related options in texrc should have a comment
pointing to the appropriate tag in doc/latex-suite.txt .
> Luc, Mikolaj, Fabio any suggestions? The rest of us AFAIK do not use
> the meta key anyway...
>
> I just thought about this? Are things like ']b' etc going to cause the
> same kind of problems diacritics caused? Do strings like ']b' occur
> often in latex?
Closed intervals are pretty common: $[a,b]$. Some authors like
to reverse the brackets for open intervals: $]a,b[$ instead of
$(a,b)$. (I have to restrain myself: let's not disparage anyone's
nationality!) Of course, we could make ']b' do something special in
text mode, but not in math mode.
Vim modes: Insert (and Replace)
Normal (a.k.a. Beep or Escape mode)
Command (a.k.a. : or Ex mode)
Visual (and Select)
TeX modes: Horizontal (a.k.a text or paragraph mode)
(and Restricted Horizontal, a.k.a. LR, mode)
Vertical (and Internal Vertical)
Math
Display Math
Why do I mention this? Mostly because it is late, but also because I
was a little worried that mentioning a TeX mode might lead to confusion
because Vim had modes, too.
--Benji
|
|
From: Luc H. <her...@fr...> - 2003-01-07 11:03:34
|
* On Mon, Jan 06, 2003 at 10:55:15PM -0500, Benji Fisher <be...@me...> wrote:
> Srinath Avadhanula wrote:
> >Hmm... Lets see... What about moving away from "special" keys
> >altogether and using ']l' ']b' ']c' etc in insert mode (as Luc
> >suggests)
This is an idea I've stolen from Sven scripts. Now, I'm used to it and
like it.
> >and <M-[lbc]> in normal mode (or maybe even ']b' etc in normal mode
> >as well)?
> >This way people who want to use <M-c> etc for national characters can
> >continue to do so... Ofcourse this makes the users of latex-suite
> >learn yet another "leader" character...
May be, may be not. What about two options:
- [bg]:meta_or_mapleader
- [bg]:insert_mapleader
If the first is true, mappings are defined as '<M-{key}>', otherwise the
mappings are defined with '{[bg]:insert_mapleader}{key}'.
The configuration step is a little more complex, but still quite simple.
What is really hard to propose to the end user is a simple way to change
the {key}/{sequence_of_keys}. For instance, I like ']em' to insert
'\emph{}', but what do you prefer ? 'FEM', ']FEM', ']EM' ?
> >Maybe ']' can be reserved for beginning maps which change the text
> >before them in some way...
What do you mean by 'before them' ?
> [...]
> >" Pressing <F5> will prompt you for which environment to insert.
> >" Change <F5> to change the ``hotkey''.
> >nmap <silent> <F5> <Plug>Tex_FastEnvironmentInsert
> >
> >etc. The user needs to change the lhs in these lines to customize...
> >But texrc or the user's copy of texrc is sourced only once when
> >latex-suite initializes, not for every BufEnter event... So that
> >might not be a good place...
Why don't you put it in a {rtp}/ftplugin/tex/ directory ?
Or do something like:
#### {rtp}/ftplugin/tex/tex_options-commands.vim ####
" excerpt from a similar file from my C++ ftplugins
let s:esc_pwd = ''
" Function: s:CheckOptions() {{{
" Role: Checks whether we must reload the options file to match the
" current project.
function! s:CheckOptions()
if s:esc_pwd != escape(getcwd(), '\')
let s:pwd = getcwd()
let s:esc_pwd = escape(s:pwd, '\')
let g:do_load_tex_options = 1
if filereadable("./tex_options.vim")
so ./tex_options.vim
else
runtime ftplugin/tex/tex_options.vim
endif
endif
endfunction
" }}}
call s:CheckOptions()
" + definition of a Vim-command if needed.
####
But, that supposes:
- the mappings in .texrc (I really don't like this name) are buffer
mappings, not global mappings
And I wonder if we really need to reload the options every time we enter
a new buffer. I think the end-user will likely have the same mappings
for all his (La)TeX buffers.
> Actually, I was suggesting something more radical. Something like
> this:
>
> let Tex_FastEnvironmentInsert = '' " '<F5>' is popular.
> " Either default to empty string as above or else comment it out:
> " let Tex_FastEnvironmentInsert = '<F5>'
>
> Then the TexSetOptions() function (called on each FileType tex event,
> I think) can test whether g:Tex_FastEnvironmentInsert exists (or is
> not the empty string) and use it to define a map if so. This is the
> way I did it way back in texmacros.vim (for vim 5.3+).
I like this approach: let's take advantage of the ftplugin mecanism.
> >Luc, Mikolaj, Fabio any suggestions? The rest of us AFAIK do not use
> >the meta key anyway...
I use (ie: define to mappings binded to ...) the meta keys only for
NORMAL mode now. While they overlap with accentuated character (Vim does
not make any difference when I hit 'é' or '<M-i>').
> >I just thought about this? Are things like ']b' etc going to cause
> >the same kind of problems diacritics caused? Do strings like ']b'
> >occur often in latex?
> Closed intervals are pretty common: $[a,b]$. Some authors like to
> reverse the brackets for open intervals: $]a,b[$ instead of $(a,b)$.
That's true. I completly forgot. As finding non funky keys not used in a
way or in other is nearly impossible (except if you like ^X), I think
the easiest for us is to have the end-user to define his preferences on
this topic -- cf. the 2 options in the beginning of this message. Then,
he will use ']', '#', 'µ', ... what ever he want and can to use.
> (I have to restrain myself: let's not disparage anyone's
> nationality!)
In France, we do use ']a,b[' for open intervals, is it used elsewhere ?
> Of course, we could make ']b' do something special in text mode, but
> not in math mode.
>
> Vim modes: [...]
> TeX modes: [...]
>
> Why do I mention this? Mostly because it is late, but also because I
> was a little worried that mentioning a TeX mode might lead to
> confusion because Vim had modes, too.
Don't worry.
BTW, it would be nice if we could define mappings aware of the TeX mode.
For instace, an same mapping would insert '\textbf{}' or '\mathbf{}'
according to the current TeX mode.
--
Luc Hermitte
http://hermitte.free.fr/vim/
|
|
From: Mikolaj M. <mi...@wp...> - 2003-01-07 22:35:32
|
On Tue, Jan 07, 2003 at 12:02:31PM +0100, Luc Hermitte wrote:
> the {key}/{sequence_of_keys}. For instance, I like ']em' to insert
> '\emph{}', but what do you prefer ? 'FEM', ']FEM', ']EM' ?
I like FEM because:
]FEM it too long
]EM can lead to inconsistence. Are we getting rid of F only for \emph{}
or for all font commands? Look for FIT. It is \itshape{}. You can change
it for ]IT but what about EIT (\begin{itemize})?
Existing system of shortcuts is slightly awkward bu at least (I hope)
internally consistent.
Really nice would be something quite different. Possibility for user to
create his own mappings by doing :map ]em FEM (in another words: create
latexSuite API). But I do not know how to do this.
> Don't worry.
> BTW, it would be nice if we could define mappings aware of the TeX mode.
> For instace, an same mapping would insert '\textbf{}' or '\mathbf{}'
> according to the current TeX mode.
This is possible with checking of current syntax. Benji did it for
inserting cdots, and I used it in 'polski' file.
if synIDattr(synID(line('.'),col('.')-1,0),"name") =~ '^texMath\|^texZone'
Mikolaj
|
|
From: Benji F. <be...@me...> - 2003-01-07 23:00:47
|
Mikolaj Machowski wrote:
> On Tue, Jan 07, 2003 at 12:02:31PM +0100, Luc Hermitte wrote:
>
>>the {key}/{sequence_of_keys}. For instance, I like ']em' to insert
>>'\emph{}', but what do you prefer ? 'FEM', ']FEM', ']EM' ?
>
>
> I like FEM because:
> ]FEM it too long
> ]EM can lead to inconsistence. Are we getting rid of F only for \emph{}
> or for all font commands? Look for FIT. It is \itshape{}. You can change
> it for ]IT but what about EIT (\begin{itemize})?
> Existing system of shortcuts is slightly awkward bu at least (I hope)
> internally consistent.
> Really nice would be something quite different. Possibility for user to
> create his own mappings by doing :map ]em FEM (in another words: create
> latexSuite API). But I do not know how to do this.
This is what <Plug> is for. We already use this in imaps.vim .
Just search for "<Plug>" to see the examples.
>>Don't worry.
>>BTW, it would be nice if we could define mappings aware of the TeX mode.
>>For instace, an same mapping would insert '\textbf{}' or '\mathbf{}'
>>according to the current TeX mode.
>
>
> This is possible with checking of current syntax. Benji did it for
> inserting cdots, and I used it in 'polski' file.
>
> if synIDattr(synID(line('.'),col('.')-1,0),"name") =~ '^texMath\|^texZone'
I am familiar with this idea, but I cannot take credit for the ...
map. When I met Bram last summer, I suggested that the next Big Thing
for vim should be a better way to deal with regions (math in TeX
documents, comments in many languages, script languages in HTML-like
languages, etc.) We'll see what happens.
--Benji
|
|
From: Srinath A. <sr...@fa...> - 2003-01-07 23:40:58
|
On Tue, 7 Jan 2003, Benji Fisher wrote:
> Mikolaj Machowski wrote:
> > create his own mappings by doing :map ]em FEM (in another words: create
> > latexSuite API). But I do not know how to do this.
>
Well, Mikolaj's idea works OOTB for me... for example, if I do:
imap ]em FEM
Then when I press ]em, I do use latex-suite's FEM macro. Unfortunately,
doing
call IMAP(']em', 'FEM', 'tex')
doesn't work (I just get 'FEM')...
> This is what <Plug> is for. We already use this in imaps.vim .
> Just search for "<Plug>" to see the examples.
Well, latex-suite provides <plug>s for things like IMAP_Jumpfunc(), not
for things like EFI in insert mode which generates the figure micro
template... Doing it the <plug> way for those will be, I think
needlessly complex.
If we had a way of modifying s:LookupCharacter() in imaps.vim so that
its public, then we could have done something like:
call IMAP(']em', "\<C-r>=IMAP_LookupMap('FEM')\<CR>", 'tex')
(Ofcourse, this is not the way IMAP_LookupMap works right now...)
and then ]em will expand to what FEM did previously... Maybe we can even
provide a function,
IMAP_Remap('FEM', ']em', 'tex')
which well, does what Mikolaj wants... For some time, I have been
thinking of providing a IMAP_UnMap() function... If we implement that,
IMAP_Remap() will be implemented almost the same way...
In short, I do not think doing what Mikolaj wants is very complex, and
in fact, instead of going about it changing all the places where the
maps are created, providing a IMAP_Remap() might be the way to go.
Ofcourse, this a new feature, so maybe we should wait for a little
while. I am thinking of making another vim.sf.net sometime soon, because
we seem to be decently stable and bug-free...
Srinath
|
|
From: Luc H. <her...@fr...> - 2003-01-08 01:21:48
|
* On Tue, Jan 07, 2003 at 11:36:20PM +0100, Mikolaj Machowski <mi...@wp...> wrote:
> On Tue, Jan 07, 2003 at 12:02:31PM +0100, Luc Hermitte wrote:
> > the {key}/{sequence_of_keys}. For instance, I like ']em' to insert
> > '\emph{}', but what do you prefer ? 'FEM', ']FEM', ']EM' ?
>
> I like FEM because:
> ]FEM it too long
> ]EM can lead to inconsistence.
I didn't wanted to propose new mappings. My point is that we all have
different preferences. Having an option to define the leading key is
really easy, contrary to the following keys.
For instance, we could write a function like:
function s:DefMappings()
call IMAP( b:TeXleader.'EM', '\emph{', '}')
call IMAP( b:TeXleader.'BF', '\textbf{', '}')
...
endfunction
Everyone have good reason to prefer one keybinding to another.
For instance,
- i'd rather the mapleader does not belong to '\c[a-z]'. I may have to
use an accronym like FEM someday.
- FEM implies I hold the <shift> key
- I quite never use ']' ; because I use a bracketing system and because
I rarely write intervals. However ']' requires me to press <AltGr>.
- the backquote (`) is a dead key on my keyboard
- I often write tables (&)
- '#', 'µ', '£', or '€' may be nice for me, but most of them are funky
characters you may not have on your keyboard.
Anyway, the leading character is not a problem at all with a function
like s:DefMappings() -- BTW, I recall my advice to use commands that
defines mappings and menus in one call: that eases the maintenance of
the list of mappings supported.
> [...]
> what about EIT (\begin{itemize})?
']ul' in my environment ;-)
I have exactly the same mappings for common LaTeX and HTML constructs.
Benji added:
> This is what <Plug> is for. We already use this in imaps.vim.
> Just search for "<Plug>" to see the examples.
Indeed. But I don't find the '<Plug>' thing as handy with ftplugins
having hundred of mappings as it is with plugins.
Moreover:
- it does not solve the problem that the menus can't be synchronized
with mappings that the end-user tuned with the '<Plug>mappings'.
- many mappings are based on IMAP() that calls :imap itself instead of
returning a string.
So, I agree with Srinath's opinion:
S> Well, latex-suite provides <plug>s for things like IMAP_Jumpfunc(),
S> not for things like EFI in insert mode which generates the figure
S> micro template... Doing it the <plug> way for those will be, I think
S> needlessly complex.
---- context dependant mappings ----
> > BTW, it would be nice if we could define mappings aware of the TeX
> > mode. For instace, an same mapping would insert '\textbf{}' or
> > '\mathbf{}' according to the current TeX mode.
>
> This is possible with checking of current syntax. Benji did it for
> inserting cdots, and I used it in 'polski' file.
>
> if synIDattr(synID(line('.'),col('.')-1,0),"name") =~ '^texMath\|^texZone'
As I remember, the test is more tricky than that. But yes it is the
idea. Except that ... IMAP() is not handy to define such things.
The easiest approach should be:
imap what-ever-bf <c-r>=BF()<cr>
With BF() returning '\textbf{<+cursor-pos+>}<++>' or
'\mathbf{<+cursor-pos+>}<++>'.
Today, the trick imposing the less changes will be a BF() function
returning the correct (according to user's preferences) FBF or MBF
string.
--
Luc Hermitte
http://hermitte.free.fr/vim/
|
|
From: Carl M. <cm...@ma...> - 2003-01-07 18:30:54
|
On Mon, Jan 06, 2003 at 06:16:22PM -0800, Srinath Avadhanula wrote: > Hmm... Lets see... What about moving away from "special" keys altogether > and using ']l' ']b' ']c' etc in insert mode (as Luc suggests) and > <M-[lbc]> in normal mode (or maybe even ']b' etc in normal mode as > well)? I know that some people use the ']b' map, and it does seem very convenient. But isn't there a danger that someone will type a[x]b[x] and get garbage? (Of course, not if they use automatic bracket insertion, but they might not want to). There are lots of mathematical situations where functions have square brackets. I would not create a mapping like that for my own typing. '?' seems like a reasonable mapleader, but it's harder to type than ']', since you have to hold down the shift key, and maybe it's wierd to use it as a mapleader. Would the apersand '&' be good? That is not used in mathematics, as far as I know. Perhaps, since the backtick ` is already a mapleader, double backtick `` should be the second mapleader? <Insert> might still be worth considering. In any case, ther problem needs careful consideration. Best wishes, Carl |
|
From: Mikolaj M. <mi...@wp...> - 2003-01-07 22:35:27
|
On Mon, Jan 06, 2003 at 06:16:22PM -0800, Srinath Avadhanula wrote: > Should we just document all the maps created by latex-suite in > latex-suite.txt and then put "Read the docs about how to override > mappings" somewhere in the install instructions? > Luc, Mikolaj, Fabio any suggestions? The rest of us AFAIK do not use > the meta key anyway... > I just thought about this? Are things like ']b' etc going to cause the > same kind of problems diacritics caused? Do strings like ']b' occur > often in latex? IMO such mappings should be normal, without using IMAP mechanisms (it is possible to wait until they "expire"). m. |
×
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