Thread: Re: [Vim-latex-devel] Re: Review of vim-latex status (Page 2)
Brought to you by:
srinathava,
tmaas
Menu
▾
▴
vim-latex-devel
|
From: Srinath A. <sr...@fa...> - 2002-12-31 08:09:32
|
Hey Carl!
On Mon, 30 Dec 2002, Carl Mueller wrote:
> " 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,
>
That makes a lot of sense... The way I have implemented the
<S-F1>-<S-F4> keys is to ask the user to initialize a variable,
g:Tex_HotKeyMappings, which defaults to
g:Tex_HotKeyMappings =
\ 'eqnarray*,eqnarray,bmatrix'
(The default was chosen on a whim. Note bmatrix is an amsmath
environment.)
With this default, only <S-F1> through <S-F3> are mapped. Putting one
more item in the list will map <S-F4>... Since this variable is set
during the initialization, it will be somewhat tricky to use the
knowledge of \usepackage{amsmath}... By tricky, I dont mean coding as
much as how to document and approach this feature...
Should we have two variables
g:Tex_HotKeyMappings_amslatex = 'equation,equation*,align,align*'
g:Tex_HotKeyMappings_latex = 'equation,\[,eqnarray,eqnarray*'
and then use one or the other? But I am thinking that since we want to
encourage the user to customize latex-suite anyway, is there a reason to
have this intelligence at all? Most users will I think either use
amsmath all the time or never... So they could just tailor the setting
once and forget about it...
Also, is there any reason, why you always don't use the multiline
versions. If you want to do just one equation, you could just choose not
to insert another \\ and an equation. This way, we could two of those
keys for something else...
> 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
Thats an interesting idea... As of now, <S-F5> recognizes the
environment the user is in and asks him to choose which new environment
to change it to (from a list)... Maybe we can have a command which
instead of asking just cycles through a few possibilities? That might be
faster in some cases...
Also, from now on, with latex-suite introducing so many mappings, it
might be a good idea to only provide commands as Luc suggests and let
the user choose a mapping for it if he wants to use the feature...
Srinath
|
|
From: Carl M. <cm...@ma...> - 2002-12-31 16:11:46
|
Dear Srinath,
On Tue, Dec 31, 2002 at 12:09:22AM -0800, Srinath Avadhanula wrote:
> Should we have two variables
>
> g:Tex_HotKeyMappings_amslatex = 'equation,equation*,align,align*'
> g:Tex_HotKeyMappings_latex = 'equation,\[,eqnarray,eqnarray*'
>
> and then use one or the other? But I am thinking that since we want to
> encourage the user to customize latex-suite anyway, is there a reason to
> have this intelligence at all? Most users will I think either use
> amsmath all the time or never... So they could just tailor the setting
> once and forget about it...
Actually, I prefer the solution that you give above, with
the hotkey maps. If users don't like this, they could just
map the keys as they wish. Probably, you are right, and
people just use latex or amslatex exclusively. Of course,
some people have multiple collaborators, so they have to use
both.
Emacs auctex scans the file to determine which kind of latex
is being used, and customizes itself accordingly. It seems
to me that \usepackage{...amsmath...} is an umambiguous way
to check whether amslatex is being used (except when the
file is first created). At least this would allow the use
of the package on all kinds of files. Otherwise, there
might be a need for a different configuration files for each
paper. Could it be an option?
>
> Also, is there any reason, why you always don't use the multiline
> versions. If you want to do just one equation, you could just choose not
> to insert another \\ and an equation. This way, we could two of those
> keys for something else...
This sounds reasonable, but no one does it. In fact, the
multiline versions weren't designed to be used this way,
and journal typesetters would probably complain. You are
trying to do something equivalent to fixing the illogical
spelling of English -- it sounds good, but people don't want
to be forced to switch to someone else's system.
>
> > 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
>
> Thats an interesting idea...
I personally don't like this feature of ultratex, and I
prefer auctex to ultratex. I just wanted to point out what
other people have done. But it does have the advantage that
you only have to remember one thing -- typing dollar signs.
Best wishes,
Carl
|
|
From: Mikolaj M. <mi...@wp...> - 2003-01-01 22:34:22
|
On Tue, Dec 31, 2002 at 11:13:32AM -0500, Carl Mueller wrote:
> Actually, I prefer the solution that you give above, with
> the hotkey maps. If users don't like this, they could just
> map the keys as they wish. Probably, you are right, and
> people just use latex or amslatex exclusively. Of course,
> some people have multiple collaborators, so they have to use
> both.
> Emacs auctex scans the file to determine which kind of latex
> is being used, and customizes itself accordingly. It seems
> to me that \usepackage{...amsmath...} is an umambiguous way
> to check whether amslatex is being used (except when the
> file is first created). At least this would allow the use
> of the package on all kinds of files. Otherwise, there
> might be a need for a different configuration files for each
> paper. Could it be an option?
Names of all supported packages detected in preamble (almost all
ams-latex packages) are in g:Tex_package_supported.
Mikolaj
|
|
From: Srinath A. <sr...@fa...> - 2003-01-03 02:32:12
|
Hello!
Happy New Year!
On Tue, 31 Dec 2002, Carl Mueller wrote:
> Actually, I prefer the solution that you give above, with
> the hotkey maps. If users don't like this, they could just
> map the keys as they wish. Probably, you are right, and
> people just use latex or amslatex exclusively. Of course,
> some people have multiple collaborators, so they have to use
> both.
>
> Emacs auctex scans the file to determine which kind of latex
> is being used, and customizes itself accordingly. It seems
> to me that \usepackage{...amsmath...} is an umambiguous way
> to check whether amslatex is being used (except when the
> file is first created). At least this would allow the use
> of the package on all kinds of files. Otherwise, there
> might be a need for a different configuration files for each
> paper. Could it be an option?
>
As Mikolaj has said, g:Tex_package_supported gets
initialized by latex-suite by scanning the main latex file
for \usepackage{} lines. This is a comma seperated list of
all packages which the user has used... We could always use
this in conjunction with what I was mentioning previously
with having
g:Tex_HotKeys_amslatex =3D '...'
g:Tex_HotKeys_latex =3D '...'
But I think we both agree that this is not really necessary.
Letting the user choose one variable is I think sufficient.
If someone really wants it and comes up with a compelling
argument, I think we can go ahead and make the necessary
changes...
> This sounds reasonable, but no one does it. In fact, the
> multiline versions weren't designed to be used this way,
> and journal typesetters would probably complain. You are
> trying to do something equivalent to fixing the illogical
> spelling of English -- it sounds good, but people don't want
> to be forced to switch to someone else's system.
>
Okay! Makes sense. Make they do some optimization based on
the fact that there is only one equation or something...
> I personally don't like this feature of ultratex, and I
> prefer auctex to ultratex. I just wanted to point out what
> other people have done. But it does have the advantage that
> you only have to remember one thing -- typing dollar signs.
>
Well, the way latex-sutie is shaping up, at least for
environments (not just mathematical environments, but
anything at all), the user needs to remember just <F5> and
<S-F5>. For me at least, this is more than sufficient. Along
with the clever little auctex mappings like `/ -> \frac{}{},
etc, I can type almost everything I need...
The only remaining annoyance seems to be that for almost all
eurpean users, the meta mappings come as a nasty surprise.
For them <M-c> is a very commonly used key... I am presently
thinking of ways to get around this...
A drastic step will be to remove the <M-c> mapping by
defauly and instead provide a map <Plug>Tex_MathCal which
provides the same functionality. The user if he wants can
then do:
=09nmap <M-c> <Plug>Tex_MathCal
Unfortunately, since most users will be too lazy to do any
customization, the really cool <M-l> mapping will be left
unused by most of the english speaking latex users.
I know Luc would be happy if we took out the meta mappings.
What do the others think? Is there a more elegant way of
handing this? Maybe check encoding or something? Do people
who like to use literal =EC, =E1 and such use some encoding
different from latin1 and utf8? We could make a somewhat
more informed guess that way...
Srinath
|
|
From: Benji F. <be...@me...> - 2003-01-03 03:28:31
|
Srinath Avadhanula wrote:
> Hello!
>
> Happy New Year!
Yes, let's have a productive 2003! (Too many mathematicians on
this list ... no, that's not a factorial. ;)
> The only remaining annoyance seems to be that for almost all
> eurpean users, the meta mappings come as a nasty surprise.
> For them <M-c> is a very commonly used key... I am presently
> thinking of ways to get around this...
>
> A drastic step will be to remove the <M-c> mapping by
> defauly and instead provide a map <Plug>Tex_MathCal which
> provides the same functionality. The user if he wants can
> then do:
> nmap <M-c> <Plug>Tex_MathCal
> Unfortunately, since most users will be too lazy to do any
> customization, the really cool <M-l> mapping will be left
> unused by most of the english speaking latex users.
>
> I know Luc would be happy if we took out the meta mappings.
> What do the others think? Is there a more elegant way of
> handing this? Maybe check encoding or something? Do people
> who like to use literal ?, ? and such use some encoding
> different from latin1 and utf8? We could make a somewhat
> more informed guess that way...
>
> Srinath
I agree with Luc. We can make it a little easier by making it
possible to turn several key mappings on or off with one setting. I
prefer pleasant surprises for those who read the docs to nasty surprises
for those who do not. ;)
--Benji
|
|
From: Carl M. <cm...@ma...> - 2002-12-31 01:59:52
|
I forgot another interesting feature of ultratex. Typing <CR> in the middle of a math environment does not break the line, but takes you out of the current pair of brackets. This is similar to the current system of <<>>. This seems too intrusive to me. My own solution to this problem was to use <Alt-F> to take you to the next pair of brackets. I bound the <C-F> and <C-E> keys as in emacs, and these are also useful for getting out from between brackets. I'm not saying these are better than <<>>, which is very elegant. Of course, there will always be some times when the user doesn't want to go to the <<>>. No system is perfect. I recommend staying with <<>>. Best wishes, Carl |
|
From: Luc H. <her...@fr...> - 2002-12-27 01:11:51
|
Hi,
* On Tue, Dec 24, 2002 at 01:11:30PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> Things which need to improve
> ============================
> 1. Atleast for me, the diacritics have been a longstanding source of
> annoyance at unexpected times. Everytime I try doing a=b, I get
> a\'{b}. And assignments like a=b are so common that this becomes
> painful pretty fast. I would love to find out a better way to
> implement support for diacritics. I am in fact thinking of disabling
> diacritics by default unless we get some better ideas.
AFAIK, "a\'b" is valid, and most LaTeX implementations now support
8-bits characters. I.e.: I never write "\'e" (nor the ugly "\'{e}")
anymore, but simply "é". The diacritics stuff is useless to me, even
when I write documents in French. I'd rather type one more key when I
need to enter expanded diacritics like \oe -- since then, I added a more
logical digraph for oe () into vim.
The format used by (La)TeX is very simple and logical.
> Future Directions
> =================
> These are things which are on my "cool things to do" list. Please feel
> free to share your own.
> 1. Dependency checking: i.e, when the user chooses the 'pdf' format,
> latex-suite automatically compiles the dvi file, converts to ps and
> then to pdf according to user preferences. I know that lh-tex (by
> Luc) already has these kind of things implemented.
>
> But from what I can see, he has hardcoded the dependencies, i.e pdf
> always follows from ps and things like that. I would think that we
> could have options like
Yes and No.
The dependencies are indeed hardcoded, but I propose to ways to produce
the pdf file: thanks to (e)pdf(la)tex, or thanks to ps2pdf following a
first convertion done with 'dvips -Ppdf'.
I'd rather have both possibility beeing directly available (ie two
different mappings) from vim without having to change even only one
option.
> Tex_FormatDepenency_pdf = 'ps'
> Tex_FormatDepenency_ps = 'dvi'
> Tex_FormatDepenency_dvi = 'tex'
> which enable a customized dependency setting.
I don't know if we can be that generic...
> I propose that we have a discussion about the best way to implement
> this. (Luc can start by telling us how he did it).
...I already tried to factorize all common transformations into
sub-functions. The result is:
- s:Make() that runs ':make' (and saves vim-options before changing
them, echoes different things, and checks for errors)
Note: this is a low level function used by the TKMake{*}file()
functions.
- s:CheckDeps() that checks dependency issues between two files (which
one is newer than the other), and runs the proper s:TKMake{ext}file()
function if needed.
- s:TKMakeDVIfile() : implements the main loop that converts .tex files
into .dvi or .pdf. It also run bibtex, makeindex, etc if needed
- s:MakePdfTeXfile(...) <=> call <sid>TKMakeDVIfile((a:0>0)?(a:1):5, "pdf")
- s:TKMakePSfile() : implements the transformation .dvi->.ps
does some other common things, _and_ checks weither we must use the
-Ppdf option or not (according to the parameters passed).
- s:TKMakePDFfile() : implements the transformation .ps->.pdf
You proposed to merge all the TKMake{*}file() functions into one. I fear
the result will be too complex because:
- the transformation .tex->* is not like the other transformations
(latex may have to be run three times or more, bibtex and makeindex
may be used, etc)
- the tranformation .dvi->.ps checks one little parameter
What can be done is to have one dependencies engine (DE) that uses the
options you proposed, and the various TKMake functions. With a
registering facility, the DE could be extended with new functions
(because tomorrow, we rather produce an XMLfo document before the final
pdf -- odd idea, but we never know).
I'm not sure it is so important.
BTW: I have some similar functions to launch the various viewers.
> Since this is (will be) such a core part of latex-suite,
> I would like this to be implemented after a lot of thought.
> 2. Compilation Sequence: Again, Luc has implemented a way to run latex,
> bibtex, makeindex etc according to what needs to be run etc.
I don't deserve all the credits. The initial version is from Tomer Kol
(that why many function-names start with TK).
> 3. New developer: Becase Luc has implemented both 1 and 2 in lh-tex, I
> propose that we get Luc into the developer team if he wants. To
> start with, he can implement his ideas on a seperate branch.
> Afterwards, we can merge this into the main trunk.
Why not. I won't have so many time to spend on the project, but I will
be glad to parcipate.
But beware, I have many, many ideas with some of them implemented in
completly different ways than the ones you choose for latex-suite.
> 4. Citation browser: I know that auctex from emacs has a feature where
> it sets up a browsable window of the citations found in the bibtex
> file. We could implement a system where if the user presses <Alt-c>,
> \cite{} is inserted and the browser comes up asking him to choose a
> citation.
Nice idea.
> 5. Removal of unwanted cruft: I am pretty sure latex-suite has features
> which it can afford to lose.
6. Sometimes, I'd like some feedback about the last improvments I made
in mu-template. But before, I must found some time to finish to write
the documentation and to definitively fix the funky-characters issue.
The big last improvment concerns the possibility to hit for instance:
'\tab^R<SPACE>' which pops up a dialog box asking for which
template-file we wish to expand (here: tabular, tabeqnarray, etc)
> Happy Holidays!!! (My girlfriend is dragging me off to some shopping
> now)
:-)
Happy holidays.
--
Luc Hermitte
http://hermitte.free.fr/vim/
|
|
From: Srinath A. <sr...@fa...> - 2002-12-27 19:58:28
|
Well, at least one issue seems to be decided upon. The diacritics will
go!
Your scheme seems quite excellent! I think the latter suggestion of
making specific functions such as Tex_Convert_{from}_to_{to} and then
calling these from a central Tex_Compile() function (the dependency
engine) which uses options such as:
" Dependency definitions
" for tex -> dvi -> ps -> pdf
g:Tex_dvi_dependsOn = 'tex'
g:Tex_ps_dependsOn = 'dvi'
g:Tex_pdf_dependsOn = 'ps'
" Compilation rules.
g:Tex_CompileRule_dvi = 'latex \nonstopmode \input{$*}'
g:Tex_CompileRule_ps = 'dvips -Ppdf $*'
g:Tex_CompileRule_pdf = 'ps2pdf $*'
is the best way to go... The Tex_Convert_tex_to_dvi and
Tex_Convert_tex_to_pdf can both use another function Tex_Convert_tex
with a few changed options... The Tex_Convert_tex can be a special
function which also runs the makeindex, bibtex etc as needed.
Maybe I will get around to it when I next get time... As of now, I am
still fixing little bugs here and there... If you are interested, you
could get access to our CVS treee...
On Thu, 26 Dec 2002, Luc Hermitte wrote:
> 6. Sometimes, I'd like some feedback about the last improvments I made
> in mu-template. But before, I must found some time to finish to write
> the documentation and to definitively fix the funky-characters issue.
> The big last improvment concerns the possibility to hit for instance:
> '\tab^R<SPACE>' which pops up a dialog box asking for which
> template-file we wish to expand (here: tabular, tabeqnarray, etc)
>
Well, as of now latex-suite does this in 2 ways. If the user presses the
<F5> key on an empty line, then it prompts him to insert an environment
from amongst a list. (This idea is from auctex.vim) It also supports
"custom macros". These are basically files in the latex-suite/macros/
directory. Your feature could be implemented as:
inoremap <C-x>t <C-r>=Tex_ReadCustomMacro()<CR>
This pops up a prompt asking the user to choose from the files found in
the macros/ directory and asks the user to choose one. This is then read
in. The file can contain optional placeholders etc...
Srinath
|
|
From: Luc H. <her...@fr...> - 2002-12-27 23:27:15
|
Hello,
* On Fri, Dec 27, 2002 at 11:58:10AM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> Your scheme seems quite excellent! I think the latter suggestion of
> making specific functions such as Tex_Convert_{from}_to_{to} and then
> calling these from a central Tex_Compile() function (the dependency
> engine) which uses options such as:
>
> " Dependency definitions
> " for tex -> dvi -> ps -> pdf
> g:Tex_dvi_dependsOn = 'tex'
> g:Tex_ps_dependsOn = 'dvi'
> g:Tex_pdf_dependsOn = 'ps'
> " Compilation rules.
> g:Tex_CompileRule_dvi = 'latex \nonstopmode \input{$*}'
> g:Tex_CompileRule_ps = 'dvips -Ppdf $*'
> g:Tex_CompileRule_pdf = 'ps2pdf $*'
Hum ... If we adopt this approach (with a dependency engine), then the
compilation rules should be named regarding the source format as well.
Ie: we should have:
g:Tex_CompileRule_ps2pdf = 'ps2pdf $*'
and
g:Tex_CompileRule_tex2pdf = 'pdflatex \nonstopmode \input{$*}'
BTW: the dependency engine should allow us to have an open system. For
instance, we could add a support for Tex4HT.
The last thing to "study" is how we will run/call this dependency
engine.
> is the best way to go... The Tex_Convert_tex_to_dvi and
> Tex_Convert_tex_to_pdf can both use another function Tex_Convert_tex
> with a few changed options...
You're right. It will be neater (/more neat ?) than my current code.
I was first skeptical about the dependency engine. Now I think it should
not be so complex to implement.
> Maybe I will get around to it when I next get time... As of now, I am
> still fixing little bugs here and there... If you are interested, you
> could get access to our CVS treee...
May be the easiest thing to do is to start from the current code in
tex-tools.vim.
Moreover, it supports a little more advanced scheme regarding the way
the main latex file is specified (ie: it supports both your way and
Tomer's way ; and personnally, I prefer Tomer one's ;-)).
tex-tools.vim does also try to take care of many oddities like how to
detect that a :make failed, etc. But there are also unsolved (at least,
I am not satisfied by my workarounds) issues like :grep from win32-vim
launch from cygwin.
> On Thu, 26 Dec 2002, Luc Hermitte wrote:
> > 6. Sometimes, I'd like some feedback about the last improvments I
> > made in mu-template. But before, I must found some time to finish
> > to write the documentation and to definitively fix the
> > funky-characters issue. The big last improvment concerns the
> > possibility to hit for instance: '\tab^R<SPACE>' which pops up a
> > dialog box asking for which template-file we wish to expand
> > (here: tabular, tabeqnarray, etc)
>
> Well, as of now latex-suite does this in 2 ways.
> - [.. auctex's way ..]
I do know it. But I found this way hard to configure to one's
preferences.
> - It also supports "custom macros". These are basically files in the
> latex-suite/macros/ directory. Your feature could be implemented as:
> inoremap <C-x>t <C-r>=Tex_ReadCustomMacro()<CR>
>
> This pops up a prompt asking the user to choose from the files found
> in the macros/ directory and asks the user to choose one. This is then
> read in. The file can contain optional placeholders etc...
If I remember well, this second way uses an earlier (and official)
version of mu-template.
I have added many things since the last official release. Moreover, it
is not limited to LaTeX.
--
Luc Hermitte
http://hermitte.free.fr/vim/
|
|
From: Benji F. <be...@me...> - 2002-12-30 13:54:12
|
Srinath Avadhanula wrote:
> 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.
This is a useful review. I am sorry I could not reply sooner.
> 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.
Yes, this is annoying. Features should follow the principle of
least surprise. They should be off by default if they cause problems
for anyone: it is better to require the user to do some work (edit
texrc, for example) to turn on a useful feature than to force the user
to twiddle things to get it to work.
Sooner or later, I plan to have a comprehensive look at texrc:
put the definition of :TexLet elsewhere, move the documentation into
doc/latex-suite.txt, review the defaults. For now, turning off
diacritics by default is a great first step.
:help design-flexible
> 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.
I give this a very high priority.
:help design-documented
> 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
> =================
Yup, there is plenty left to do. ;)
--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