Against r1115
With this patch, envmacros.vim allows more customizations.
1.
let g:Tex_EnvLabelprefix_equation = "eq:"
=> labels in equations have the prefix eq:
this works for:
figure,table,theorem,definition,lemma,proposition,corollary,assumption,remark,equation,eqnarray,align,multline
2.
let g:Tex_EnvEndWithCR = 0
=>
completed environments end with:
\end{env-type}
<++>
instead of
\end{env-type}<++>
This saves one CR ;)
3.
let g:Tex_LabelAfterContent = 0
=>
Put the label before the content of an environment, e.g.
\begin{equation}
\label{eq:<++>}
<++>
\end{equation}
<++>
Against r1115
This patch is by me. I forgot to log in.
I can see how some people might like #1.
However, I think #2 and #3 are bad ideas.
In the case of #2, I see little reason why you'd expect every \end{environment} to be followed by a carriage return. Especially in mathematical environments (e.g., cases or matrices), there may be some stylistic conventions that continue content on the same line as the \end.
In the case of #3, more complex equation environments (like eqnarray or align or multiline or gather or...), \label will often follow the content and show up in the same place as the resulting label (similar with \notag). I see no reason why to introduce an asymmetry for equation. Perhaps a better approach would be:
\begin{equation}
<++>
\label{eq:<++>}<++>
\end{equation}<++>
to allow for all use cases.
ad #2:
That's purely a matter of taste. Even in mathematical environments I like to have a "cases" or "pmatrix" spanned over several lines. In my PhD thesis, I have 1120 "\end{something}", but only 7 are not followed by a CR.
ad #3:
If you put the label at the end of an environment, there are two possible pitfalls:
- the autoref feature of hyperref won't work properly (see attached file)
- the spacing around a subequation environment is not correct.
Concerning your approach: Is there any reason for the placeholder after the label?
I can't add a file here.
Here is a minimal (non)-working example:
\documentclass{amsart}
\usepackage{hyperref}
\newtheorem{theorem}{Theorem}
% Just some offset to distinguish the numbers of the theorems and of the equations:
\setcounter{theorem}{10}
\begin{document}
\section{This works}
\begin{theorem}
\label{thm:bla}
\begin{equation}
\label{eq:blub}
1+2
\end{equation}
Some theorem.
\end{theorem}
\autoref{thm:bla} contains \autoref{eq:blub}.
\section{This does not work}
\begin{theorem}
\begin{equation}
1+2
\label{eq:blub2}
\end{equation}
Some theorem.
\label{thm:bla2}
\end{theorem}
\autoref{thm:bla2} contains \autoref{eq:blub2}.
\end{document}
\autoref is only going to fail if you put the \label for the theorem after the equation. I'm not sure why you'd ever do that. Again, the argument was that \labels tend to follow where where the tag conventionally shows up in the rendered document. Thus, a theorem label shows up at the top of the environment, and an equation label shows up at the end of the equation environment. That rule works even if you're not cognizant about how refstepcounter works. Things get more complicated for floats, like figure, where the juxtaposition of labels and captions can have a different impact on where things are anchored. The main point is that there is no general "environment layout" that holds for absolutely all environments -- especially when you expand beyond simple equation environments (IMO).
Regardless, something like:
\begin{equation}
<++>\label{<++>}<++>
\end{equation}<++>
covers all use cases.
I didn't notice until now that you're forcing "eq:" on inserted equation environments. I don't think that's a good idea. Although it may be conventional for people to prefix equation labels with "eq:", it is certainly not necessary. Again, going back to refstepcounter, \autoref doesn't use the prefix to determine label type (although cleveref might -- I think early versions of cleveref did). So it is a matter of style.
Furthermore, because of #1, the "eq:" prefix in the automated environments should match whatever is set in #1. It should not be static text.
Following your argumentation, there should be no CR after the \begin{equation} as well...
What do you mean with "static text"?
However, since typesetting (of environments) is a matter of taste - see our discussion ;) -, everything which was added in this patch is customizable. If you do not change the default parameters, nothing would change.
I don't think I ever suggested that there shouldn't be a CR after \begin{equation}. Notice that all of the <++>'s I suggested were on lines that eventually had CR's on them (except for the last one).
I didn't review your patch until now, but I thought your comments made me think you had redefined EEQ to insert
\label{eq:<++>}
where the "eq:" was a static part of the EEQ IMAP. I didn't realize that EEQ called a function that you had re-defined to use your prefixes (which would be the desired way to do such a thing if such a thing was desired). Consequently, setting all of the prefixes to empty would restore the previous EEQ/etc. behavior.
Lately, I haven't found much in Vim-LaTeX to be that useful. I've had to generate my own Makefile to do the auxiliary processing I need for most of my documents that Vim-LaTeX doesn't support, and so I find myself not really valuing much over syntax highlighting. However, occasionally I do enjoy environment IMAPs, and I would have to stop using them if the default label position would be at the top of each equation-like environment.
I didn't notice that your #2 and #3 are configurable (I skipped right by that) and default to the existing behavior. I worry that #1 would introduce a difference as the current EEQ doesn't insert a prefix. What's the answer to that?
I think that if you augmented the documentation with entries about the new parameters, then these changes could get checked in.
> I didn't notice that your #2 and #3 are configurable (I skipped right by
> that) and default to the existing behavior. I worry that #1 would introduce
> a difference as the current EEQ doesn't insert a prefix. What's the answer
> to that?
Again, it is customizable and the default is the current behavior.
> I think that if you augmented the documentation with entries about the new
> parameters, then these changes could get checked in.
I will do this. Am I right, that I have to edit "doc/latex-suite.xml" and the other files will be generated automatically by "make"?
Uploaded new version of the patch, including changes in the documentation.
I can't upload the patch here. (Why?)
I send it on the mailinglist.
Log in to post a comment.