|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-14 07:14:10
|
I've got the following setup (simplified) . .. main.tex chap1/ chap1.tex When editing main.tex, \ll works fine, everything comes out correct. When editing chap1.tex, \ll gives the following. || I can't find file `main.tex'. main.tex || Emergency stop. There is no main.log, only a chap1.log in the chap1/ folder. I conclude that latexsuite is trying to compile inside the chap1/ folder. My CompileRule is as follows:- g:Tex_CompileRule_dvi latex -interaction=nonstopmode --src-specials $* Please advise what else I can do to check this. Am using 64-bit Arch Linux, am using svn revision 1115 with vim 7.3.102 |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-14 12:11:43
|
On Mon, 2011-02-14 at 15:13 +0800, Ng Oon-Ee wrote: > I've got the following setup (simplified) > > . > .. > main.tex > chap1/ > chap1.tex > > When editing main.tex, \ll works fine, everything comes out correct. > > When editing chap1.tex, \ll gives the following. > > || I can't find file `main.tex'. main.tex > || Emergency stop. > > There is no main.log, only a chap1.log in the chap1/ folder. I conclude that latexsuite is trying to compile inside the chap1/ folder. My CompileRule is as follows:- > > g:Tex_CompileRule_dvi latex -interaction=nonstopmode --src-specials $* > > Please advise what else I can do to check this. Am using 64-bit Arch Linux, am using svn revision 1115 with vim 7.3.102 > Sorry, I got contacted off-list, just to confirm, I do have main.tex.latexmain as per the wiki in the root directory. That's why the error refers to 'main.tex' rather than 'chap1.tex' |
|
From: Ted P. <te...@te...> - 2011-02-14 22:28:21
|
> main.tex > chap1/ > chap1.tex First, I assume you are familiar with the TeX FAQ about importing bits of document from subdirectories(?). There are complications that might make you think twice about that sort of organization (but there are packages that make it easier as well): http://www.tex.ac.uk/cgi-bin/texfaq2html?label=docotherdir > When editing chap1.tex, \ll gives the following. > > || I can't find file `main.tex'. main.tex > || Emergency stop. This doesn't make much sense to me. Before TeX-LaTeX starts the build, it changes to the directory containing the latexmain file. The exception to this is when you set the b:fragmentFile parameter, but then it ignores the latexmain entirely. So it doesn't make sense that your build is finding the latexmain and yet not changing to the right directory. According to the TeX-LaTeX compiler.vim source, there used to be problems on Linux machines with changing to directories with spaces in their names. Do any of the directories in the /ABSOULTE/ path have spaces? (e.g., are your files stored within a "My Documents" folder?) It is possible that your vim is choking on the space and not changing directory properly. When I create a sample main.tex and ch1/ch1.tex, it works fine for me. Can you post a minimal example that has this problem? (e.g., a "main.tex" and a "chap1.tex" and information about the directory structure) Perhaps there is something else interesting going on. --Ted -- Ted Pavlic <te...@te...> |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-15 01:10:52
Attachments:
.vimrc
|
On Mon, 2011-02-14 at 17:28 -0500, Ted Pavlic wrote: > > main.tex > > chap1/ > > chap1.tex > > First, I assume you are familiar with the TeX FAQ about importing bits > of document from subdirectories(?). There are complications that might > make you think twice about that sort of organization (but there are > packages that make it easier as well): > > http://www.tex.ac.uk/cgi-bin/texfaq2html?label=docotherdir Thanks for the link. I was aware of issues with paths etc, but figured I'd see what I could do about them once I got started. Not very hard to change back to a flat layout halfway. > > > When editing chap1.tex, \ll gives the following. > > > > || I can't find file `main.tex'. main.tex > > || Emergency stop. > > This doesn't make much sense to me. Before TeX-LaTeX starts the build, > it changes to the directory containing the latexmain file. The exception > to this is when you set the b:fragmentFile parameter, but then it > ignores the latexmain entirely. So it doesn't make sense that your build > is finding the latexmain and yet not changing to the right directory. > > According to the TeX-LaTeX compiler.vim source, there used to be > problems on Linux machines with changing to directories with spaces in > their names. Do any of the directories in the /ABSOULTE/ path have > spaces? (e.g., are your files stored within a "My Documents" folder?) It > is possible that your vim is choking on the space and not changing > directory properly. > > When I create a sample main.tex and ch1/ch1.tex, it works fine for me. > > Can you post a minimal example that has this problem? (e.g., a > "main.tex" and a "chap1.tex" and information about the directory > structure) Perhaps there is something else interesting going on. > > --Ted > My minimal example below. Its VERY minimal:- main.tex-------------------------- \documentclass{article} \begin{document} \input{chap1/chap1.tex} \end{document} ---------------------------------- chap1/chap1.tex------------------- \chapter{Introduction} \section{First section} ---------------------------------- And, of course, main.tex.latexmain is a blank file. Seeing as it works for you (and presumably others as well), I'm wondering whether it has to do with other vim plugins I have. Eclim is the big one, of course. I'm attaching to this email my .vimrc if it makes a difference (maybe my autocmd's are affecting things?). |
|
From: Ted P. <te...@te...> - 2011-02-15 19:49:48
|
> My minimal example below. Its VERY minimal:-
I meant a minimal working example. This one doesn't count because you used:
> \documentclass{article}
and then:
> \chapter{Introduction}
but chapter doesn't exist in article.cls (it does in report.cls or
book.cls though)
Also:
> And, of course, main.tex.latexmain is a blank file. Seeing as it works
main.tex.latexmain is fine, but you can also use simply "main.latexmain"
without the tex. That might look a little nicer (?). (I also recommend
using \include for chapters so you can \includeonly them later in your
writing process)
> for you (and presumably others as well), I'm wondering whether it has to
> do with other vim plugins I have. Eclim is the big one, of course. I'm
> attaching to this email my .vimrc if it makes a difference (maybe my
> autocmd's are affecting things?).
I got rid of my .vimrc and .gvimrc and used your .vimrc, and everything
still works for me.
compiler.vim hasn't changed in a long time. You said you were using svn
revision 1115, which is fairly recent (3 months ago). Have you tried the
latest git version?
You could try something silly like:
:let g:Tex_CompileRule_dvi='pwd > thisdirectory'
and run \ll after that. Look for a "thisdirectory" file. See where it
shows up (in ./chap1, in ./, or perhaps even in ../ <?>) and what its
contents are. I'm sure there's a cleaner way to do debugging in vim, but
I'm no vim expert.
--Ted
--
Ted Pavlic <te...@te...>
Please visit my 2010 d'Feet ALS walk page:
http://web.alsa.org/goto/tpavlic
My family appreciates your support in the fight to defeat ALS.
|
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 01:11:35
|
On Tue, 2011-02-15 at 14:49 -0500, Ted Pavlic wrote:
> > My minimal example below. Its VERY minimal:-
>
> I meant a minimal working example. This one doesn't count because you used:
>
> > \documentclass{article}
>
> and then:
>
> > \chapter{Introduction}
>
> but chapter doesn't exist in article.cls (it does in report.cls or
> book.cls though)
Sorry, changed it to report, however it doesn't get that far (as you can
see)
>
> > for you (and presumably others as well), I'm wondering whether it has to
> > do with other vim plugins I have. Eclim is the big one, of course. I'm
> > attaching to this email my .vimrc if it makes a difference (maybe my
> > autocmd's are affecting things?).
>
> I got rid of my .vimrc and .gvimrc and used your .vimrc, and everything
> still works for me.
>
> compiler.vim hasn't changed in a long time. You said you were using svn
> revision 1115, which is fairly recent (3 months ago). Have you tried the
> latest git version?
1115 is the latest I think. Now that you mention it, source is git,
wonder why my packaging uses svn. Will fix that.
>
> You could try something silly like:
>
> :let g:Tex_CompileRule_dvi='pwd > thisdirectory'
>
> and run \ll after that. Look for a "thisdirectory" file. See where it
> shows up (in ./chap1, in ./, or perhaps even in ../ <?>) and what its
> contents are. I'm sure there's a cleaner way to do debugging in vim, but
> I'm no vim expert.
>
> --Ted
>
pwd (and ls) choke because of all the additional arguments. I'll try
some alternatives and revert.
|
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 01:53:56
Attachments:
eclim.vim
|
On Wed, 2011-02-16 at 09:11 +0800, Ng Oon-Ee wrote: > 1115 is the latest I think. Now that you mention it, source is git, > wonder why my packaging uses svn. Will fix that. Same behaviour in latest git, just installed it. > > > > > You could try something silly like: > > > > :let g:Tex_CompileRule_dvi='pwd > thisdirectory' > > > > and run \ll after that. Look for a "thisdirectory" file. See where it > > shows up (in ./chap1, in ./, or perhaps even in ../ <?>) and what its > > contents are. I'm sure there's a cleaner way to do debugging in vim, but > > I'm no vim expert. > > > > --Ted > > > pwd (and ls) choke because of all the additional arguments. I'll try > some alternatives and revert. > Using 'ls . > thisdirectory' I can confirm that its looking in chap1 instead of the root. However, moving away ~/.vim/eclim.vim (a file used by eclim, as I've mentioned), I see correct behaviour. I'm attaching it here, 170 lines. It does modify runtimepath and basedir, which I'm guessing is what could be affecting the behaviour. |
|
From: Ted P. <te...@te...> - 2011-02-16 03:07:12
|
> However, moving away ~/.vim/eclim.vim (a file used by eclim, as I've > mentioned), I see correct behaviour. I'm attaching it here, 170 lines. > It does modify runtimepath and basedir, which I'm guessing is what could > be affecting the behaviour. Well, AFAIK, eclim is a beast, isn't it? I don't have it installed, but I see that that eclim.vim sources lots of other eclim files that may be causing the problem. If I had to guess, eclim is constantly sitting in the background managing the current directory, and so there's the classical problem with concurrency in software. It's possible that whenever vim-latex changes the directory and the shells out to latex, eclim takes over and resets the directory... So you might want to talk to the eclim folks about what they might suggest (perhaps they'll suggest having Eclipse do your building for you...<?>). Does eclim do much for you while in LaTeX? Perhaps you could setup an autocmd to not load eclim when you're in a .tex file. --Ted -- Ted Pavlic <te...@te...> |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 03:11:44
|
On Tue, 2011-02-15 at 22:07 -0500, Ted Pavlic wrote: > > However, moving away ~/.vim/eclim.vim (a file used by eclim, as I've > > mentioned), I see correct behaviour. I'm attaching it here, 170 lines. > > It does modify runtimepath and basedir, which I'm guessing is what could > > be affecting the behaviour. > > Well, AFAIK, eclim is a beast, isn't it? I don't have it installed, but > I see that that eclim.vim sources lots of other eclim files that may be > causing the problem. > > If I had to guess, eclim is constantly sitting in the background > managing the current directory, and so there's the classical problem > with concurrency in software. It's possible that whenever vim-latex > changes the directory and the shells out to latex, eclim takes over and > resets the directory... > > So you might want to talk to the eclim folks about what they might > suggest (perhaps they'll suggest having Eclipse do your building for > you...<?>). > > Does eclim do much for you while in LaTeX? Perhaps you could setup an > autocmd to not load eclim when you're in a .tex file. > > --Ted > I've already spoken with them, they know the issue and have fixed it upstream, but the specific fix is not released yet. There's a workaround for now in .vimrc:- let g:EclimMakeLCD = 0 |
|
From: Ted P. <te...@te...> - 2011-02-16 04:13:58
|
>> Does eclim do much for you while in LaTeX? Perhaps you could setup an
>> autocmd to not load eclim when you're in a .tex file.
>>
> I've already spoken with them, they know the issue and have fixed it
> upstream, but the specific fix is not released yet. There's a workaround
> for now in .vimrc:-
>
> let g:EclimMakeLCD = 0
If it takes them a long time to fix that, then perhaps that should be
added to an FAQ somewhere.
--Ted
--
Ted Pavlic <te...@te...>
Please visit my 2010 d'Feet ALS walk page:
http://web.alsa.org/goto/tpavlic
My family appreciates your support in the fight to defeat ALS.
|
|
From: Wei Q. <we...@qi...> - 2013-06-14 12:25:12
|
Ted Pavlic <ted <at> tedpavlic.com> writes: > > >> Does eclim do much for you while in LaTeX? Perhaps you could setup an > >> autocmd to not load eclim when you're in a .tex file. Sorry for digging out this old thread. But I'm experiencing the same problem. I didn't have eclim installed. |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-21 09:36:11
|
2011/2/16 Ted Pavlic <te...@te...>: >> And, of course, main.tex.latexmain is a blank file. Seeing as it works > > main.tex.latexmain is fine, but you can also use simply "main.latexmain" > without the tex. That might look a little nicer (?). (I also recommend using > \include for chapters so you can \includeonly them later in your writing > process) Just to comment on this, when using main.latexmain compilation works but auto-completion by <F9> does not. main.tex.latexmain works fine for both compilation and auto-completion. I'm pretty sure this is a (minor) bug, should I report it? |
|
From: Ted P. <te...@te...> - 2011-02-21 16:12:26
|
> Just to comment on this, when using main.latexmain compilation works > but auto-completion by<F9> does not. main.tex.latexmain works fine > for both compilation and auto-completion. > > I'm pretty sure this is a (minor) bug, should I report it? I don't think that's necessary. It doesn't seem like a bug in the strict sense (e.g., my car's performance on the highway is severely hampered by leaving the doors and tailgate open while driving... but that doesn't necessarily indicate a flaw in the car's design). I think it was always intended to use main.tex.latexmain and not main.latexmain (that's why the documentation only refers to main.tex.latexmain, IIRC). It just so happens that main.latexmain happens to work. Personally, I've exploited some of the bugs (e.g., that when I put commands in main.latexmain, no extra buffer is opened... while main.tex.latexmain seems to open a second buffer) as features... but I don't see a reason to support the use of main.latexmain officially at the moment (of course, if someone sees the /need/ for main.latexmain, functionality could be added that is either identical or different than main.tex.latexmain, but the details should be illuminated in the documentation). Best -- Ted -- Ted Pavlic <te...@te...> |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-21 16:19:37
|
On Mon, 2011-02-21 at 11:12 -0500, Ted Pavlic wrote: > > Just to comment on this, when using main.latexmain compilation works > > but auto-completion by<F9> does not. main.tex.latexmain works fine > > for both compilation and auto-completion. > > > > I'm pretty sure this is a (minor) bug, should I report it? > > I don't think that's necessary. It doesn't seem like a bug in the strict > sense (e.g., my car's performance on the highway is severely hampered by > leaving the doors and tailgate open while driving... but that doesn't > necessarily indicate a flaw in the car's design). > > I think it was always intended to use main.tex.latexmain and not > main.latexmain (that's why the documentation only refers to > main.tex.latexmain, IIRC). It just so happens that main.latexmain > happens to work. Personally, I've exploited some of the bugs (e.g., that > when I put commands in main.latexmain, no extra buffer is opened... > while main.tex.latexmain seems to open a second buffer) as features... > but I don't see a reason to support the use of main.latexmain officially > at the moment (of course, if someone sees the /need/ for main.latexmain, > functionality could be added that is either identical or different than > main.tex.latexmain, but the details should be illuminated in the > documentation). Okay, the only reason I brought it up is that you recommended main.latexmain =). Was quite surprised to see that it broke completion, would think its quite unusable in that case (how do you use latex without citing, after all). Cheers |
|
From: Ted P. <te...@te...> - 2011-02-21 16:23:06
|
> Okay, the only reason I brought it up is that you recommended > main.latexmain =). Was quite surprised to see that it broke completion, > would think its quite unusable in that case (how do you use latex > without citing, after all). F9 is too far away from the home row. It's much faster to avoid auto-completion entirely. (not to mention, does F9 even work with \autoref? I haven't even checked that... but that would be required for me to even start to bother with completion) But thanks for your opinion. :-p --Ted -- Ted Pavlic <te...@te...> |
|
From: Gerd W. <ger...@ma...> - 2011-02-22 07:23:32
|
Hi,
I use the F9-completion very often and feel to make some advertising ;)
I patched the outline.py, such that it offers a greater gain for me. But
first I will take up Ted's arguments.
> > Additionally \citep, \citet, \citeauthor, etc... Not sure if they
would
> > match whatever pattern triggers the F9 completion... But I never use
> > \cite (in favor of the natbib variaties) and almost never use \ref (in
> > favor of hyperref's \autoref), and so F9 is potentially unhelpful.
That's no big deal - the recognizing of the other commands can be easily
added - just post your problems.
> Moreover, doesn't F9 depend on a Python script? One of the big reasons I
> use Vim is that I can wall myself off from depending on other tools (and
> maximize my portability).
For me it is no problem that F9 depends on Python. I use my ViM
configuration at three linux machines, all offering Python in ViM. Does
Python+ViM works in
Windows?
> So I guess those are my reasons why completion doesn't concern me...
>
> -) F9 is uncomfortably far from any other key on the keyboard... would
> have preferred a command-mode combination, maybe...
You guessed it already - remapping is everything ;)
> -) Questionable support for \autoref (and custom variants, like
> \Autoref, \Autorefs, and \autorefs)
>
> -) Questionable support for natbib \citep, \citet, and friends
>
> -) Dependence on Python
See above.
Now I will comment my customizations. I patched/rewrote outline.py. Now,
it
looks at the aux-file and not at the tex-file. If I write some
mathematical
text, then I think "I need equation (3.4)". Up to now, I needed to look
in the
tex-file for the corresponding label. With my patched version, I can do
the
following:
Typing (3.4)<F9> results in \eqref{eq:a_beautiful_equation}
Moreover, I also works for theorems etc. Typing theorem.4.5 results in
\autoref{thm:a_nice_theorem}
You can find these patch in my github-vim-configuration
https://github.com/gerw/vim-conf-gerw. You need the files
bundle/vim-latex-suite/ftplugin/latex-suite/{auxoutline.py,texviewer.vim}.
I
the next days I may publish a patch for latex-suite, depending on the
response
here.
Gerd
|
|
From: Gerd W. <ger...@ma...> - 2011-02-22 13:00:55
|
> I can see how someone editing a single
> document would often want to complete both ways.
In which situation you need to stick to the old tex-based completion? I
used my aux-based completion since one or two months and I never missed
the tex-based completion.
The only advantage of the tex-based completion is, that you see some
neighbourhood (one line before or after) of the \label, but mostly this
contained no information for me.
>> Typing (3.4)<F9> results in \eqref{eq:a_beautiful_equation}
>
> [ Note: The need for \eqref can be mitigated with varioref's
> \labelformat and/or hyperref's \autoref. There is absolutely no reason
> that equations need to be handled differently within the main LaTeX
> content than any other reference. ]
>
>> Moreover, I also works for theorems etc. Typing theorem.4.5 results in
>> \autoref{thm:a_nice_theorem}
>
> I'm a little confused (I haven't looked at the script) about how the
> completer picks the \*ref you want. Some people are going to use the
> \*refs provided by the cleveref package. Others (like me) are going to
> use \autoref nearly everywhere but other variants (\Autoref) in some
> places and \ref in some other cases (after "and", for example), and I
> would never ever use \eqref. How could I configure?
Currently, this can't be customized, but it is surely possible.
> I also am confused about using "theorem.4.5" some places and "(3.4)"
> other places.
For referencing equations you type (equation.number). This does work also
with (A.1) or (12.23c).
For referencing something which is not an equation you type
latex-counter-name.number, e.g. section.2 or subsection.2.12,...
> For one, how is the average user going to know for sure
> exactly which AUX name to use (thm.4.5 vs theorem.4.5)?
You have to use the name of the latex counter.
> And why the different handling of equations?
Because I can type (2.2) faster than equation.2.2.
> Furthermore, I think I would much rather type...
>
> \autoref{theorem.4.5<F9>}
>
> and have that replaced with
>
> \autoref{thm:a_nice_theorem}
This does work.
Gerd
|
|
From: Ted P. <te...@te...> - 2011-02-23 04:41:20
|
> In which situation you need to stick to the old tex-based completion? I
> used my aux-based completion since one or two months and I never missed
> the tex-based completion.
It's too restrictive for me to need to have the PDF visible at every
time I edit. It's nice sometimes to see a numbered equation, realize you
want a reference to it, and quickly add a reference without figuring out
its label. However, normally when I'm referring to equations in-line
with text, I'm writing that text soon after I generated the equation
label (and in close proximity). Moreover, I use a label that has some
useful meaning. For example, a reference to Newton's Second Law could be
"eq:n2l", and I wouldn't have to open up a PDF to find it.
So I can see some cases where the aux-based completion would be
convenient, but I think most people would need the tex-based completion
most of the time.
>> I'm a little confused (I haven't looked at the script) about how the
>> completer picks the \*ref you want. Some people are going to use the
>> \*refs provided by the cleveref package. Others (like me) are going to
>> use \autoref nearly everywhere but other variants (\Autoref) in some
>> places and \ref in some other cases (after "and", for example), and I
>> would never ever use \eqref. How could I configure?
> Currently, this can't be customized, but it is surely possible.
So long as...
\ref{thm.4.5<F9>
\autoref{thm.4.5<F9>
\ScoobyDooRef{thm.4.5<F9>
all leave their macros in tact, then it wouldn't be a problem. People
who don't like your choices can type their own choices and just use F9
to fill in the labels.
>> For one, how is the average user going to know for sure
>> exactly which AUX name to use (thm.4.5 vs theorem.4.5)?
> You have to use the name of the latex counter.
A lot of people (especially when journals setup theorem-like
environments for you) won't know the counter name. I suppose they could
assume they know the first letter of the counter and use F9 to figure
out the rest<?>.
> Because I can type (2.2) faster than equation.2.2.
But, as you say, the counter.number still works.
>> Furthermore, I think I would much rather type...
>>
>> \autoref{theorem.4.5<F9>}
>>
>> and have that replaced with
>>
>> \autoref{thm:a_nice_theorem}
> This does work.
And leaves the macro (whatever it is called) in tact? Does the macro
have to end in "ref" or will the completion be activated for any curly
brace?
--Ted
--
Ted Pavlic <te...@te...>
Please visit my 2010 d'Feet ALS walk page:
http://web.alsa.org/goto/tpavlic
My family appreciates your support in the fight to defeat ALS.
|
|
From: Ted P. <te...@te...> - 2011-02-21 16:31:52
|
> Additionally \citep, \citet, \citeauthor, etc... Not sure if they would > match whatever pattern triggers the F9 completion... But I never use > \cite (in favor of the natbib variaties) and almost never use \ref (in > favor of hyperref's \autoref), and so F9 is potentially unhelpful. Moreover, doesn't F9 depend on a Python script? One of the big reasons I use Vim is that I can wall myself off from depending on other tools (and maximize my portability). I think you use eclim to leverage Eclipse-ish tools (CheckStyle and so on), which is a fundamentally different way to edit. So I guess those are my reasons why completion doesn't concern me... -) F9 is uncomfortably far from any other key on the keyboard... would have preferred a command-mode combination, maybe... -) Questionable support for \autoref (and custom variants, like \Autoref, \Autorefs, and \autorefs) -) Questionable support for natbib \citep, \citet, and friends -) Dependence on Python But perhaps I'm being too harsh...<?> --Ted -- Ted Pavlic <te...@te...> |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-22 08:00:39
|
On Tue, Feb 22, 2011 at 3:23 PM, Gerd Wachsmuth <ger...@ma...> wrote: > Hi, > > I use the F9-completion very often and feel to make some advertising ;) > I patched the outline.py, such that it offers a greater gain for me. But > first I will take up Ted's arguments. Interesting work, not immediately useful for me, but you never know. Any reason why your patches aren't submitted upstream? |
|
From: Gerd W. <ger...@ma...> - 2011-02-22 09:06:41
|
On Tue, 22 Feb 2011, Ng Oon-Ee wrote: > On Tue, Feb 22, 2011 at 3:23 PM, Gerd Wachsmuth > <ger...@ma...> wrote: >> Hi, >> >> I use the F9-completion very often and feel to make some advertising ;) >> I patched the outline.py, such that it offers a greater gain for me. But >> first I will take up Ted's arguments. > > Interesting work, not immediately useful for me, but you never know. > > Any reason why your patches aren't submitted upstream? Because I did not publish them _yet_. I will prepare several patches in the next days. I forgot one question: Should my new aux-based completion _replace_ the old tex-based completion or should it be offered as a new _alternative_, choosable by the user??? Regards Gerd |
|
From: Ted P. <te...@te...> - 2011-02-22 12:36:25
|
> That's no big deal - the recognizing of the other commands can be easily
> added - just post your problems.
I have no problems with <F9> as I have no desire to ever need such a
feature.
> Now I will comment my customizations. I patched/rewrote outline.py. Now,
> it
> looks at the aux-file and not at the tex-file. If I write some
> mathematical
> text, then I think "I need equation (3.4)". Up to now, I needed to look
> in the
> tex-file for the corresponding label. With my patched version, I can do
> the
> following:
This is a very different feature, and so it seems like it should be
either added as a separate completer or merged (as opposed to replacing)
with the existing F9 completion. I can see how someone editing a single
document would often want to complete both ways.
> Typing (3.4)<F9> results in \eqref{eq:a_beautiful_equation}
[ Note: The need for \eqref can be mitigated with varioref's
\labelformat and/or hyperref's \autoref. There is absolutely no reason
that equations need to be handled differently within the main LaTeX
content than any other reference. ]
> Moreover, I also works for theorems etc. Typing theorem.4.5 results in
> \autoref{thm:a_nice_theorem}
I'm a little confused (I haven't looked at the script) about how the
completer picks the \*ref you want. Some people are going to use the
\*refs provided by the cleveref package. Others (like me) are going to
use \autoref nearly everywhere but other variants (\Autoref) in some
places and \ref in some other cases (after "and", for example), and I
would never ever use \eqref. How could I configure?
I also am confused about using "theorem.4.5" some places and "(3.4)"
other places. For one, how is the average user going to know for sure
exactly which AUX name to use (thm.4.5 vs theorem.4.5)? And why the
different handling of equations?
Furthermore, I think I would much rather type...
\autoref{theorem.4.5<F9>}
and have that replaced with
\autoref{thm:a_nice_theorem}
So I think the script could do more by doing less... and that might make
it play very nice with existing F9 completion (that searches through the
TeX).
--Ted
--
Ted Pavlic <te...@te...>
|
|
From: Simon Q. <sim...@gm...> - 2011-02-22 15:27:53
|
Hello Gerd,
I think, your ideas are very good, and since I use/would like to use F9
much more often, I welcome improvement!
Just to make sure to understand from the users view: instead of typing
"\eqref{eq<F9>" and then looking through the list to find the right label
(e.g. "eq:maxwell"), you type the number "(2.4)<F9>" (which has label
"eq:maxwell" before compilation into the aux-file) and it is expanded
automatically into "\eqref{eq:maxwell}".
As far as I see, if you want to ref an equation this way, you have to do
the compilation first, and the numbers probably will change after each
compilation. In case of a replacement, this means you need to have:
1) the up-to-date pdf/dvi file open all the time and
2) knowledge of the numbers, even if they are far away in the document.
For this reasons I would _strongly_ prefer to be able to choose which way
to use at all times.
Your method is very convenient, nonetheless and I would very much like to
use it!
All the best,
Simon
Gerd Wachsmuth wrote:
>> I can see how someone editing a single
>> document would often want to complete both ways.
> In which situation you need to stick to the old tex-based completion? I
> used my aux-based completion since one or two months and I never missed
> the tex-based completion.
>
> The only advantage of the tex-based completion is, that you see some
> neighbourhood (one line before or after) of the \label, but mostly this
> contained no information for me.
>
>
>>> Typing (3.4)<F9> results in \eqref{eq:a_beautiful_equation}
>>
>> [ Note: The need for \eqref can be mitigated with varioref's
>> \labelformat and/or hyperref's \autoref. There is absolutely no reason
>> that equations need to be handled differently within the main LaTeX
>> content than any other reference. ]
>>
>>> Moreover, I also works for theorems etc. Typing theorem.4.5 results in
>>> \autoref{thm:a_nice_theorem}
>>
>> I'm a little confused (I haven't looked at the script) about how the
>> completer picks the \*ref you want. Some people are going to use the
>> \*refs provided by the cleveref package. Others (like me) are going to
>> use \autoref nearly everywhere but other variants (\Autoref) in some
>> places and \ref in some other cases (after "and", for example), and I
>> would never ever use \eqref. How could I configure?
> Currently, this can't be customized, but it is surely possible.
>
>> I also am confused about using "theorem.4.5" some places and "(3.4)"
>> other places.
> For referencing equations you type (equation.number). This does work also
> with (A.1) or (12.23c).
>
> For referencing something which is not an equation you type
> latex-counter-name.number, e.g. section.2 or subsection.2.12,...
>
>> For one, how is the average user going to know for sure
>> exactly which AUX name to use (thm.4.5 vs theorem.4.5)?
> You have to use the name of the latex counter.
>
>> And why the different handling of equations?
> Because I can type (2.2) faster than equation.2.2.
>
>> Furthermore, I think I would much rather type...
>>
>> \autoref{theorem.4.5<F9>}
>>
>> and have that replaced with
>>
>> \autoref{thm:a_nice_theorem}
> This does work.
>
>
> Gerd
>
> ------------------------------------------------------------------------------
> Index, Search& Analyze Logs and other IT data in Real-Time with Splunk
> Collect, index and harness all the fast moving IT data generated by your
> applications, servers and devices whether physical, virtual or in the cloud.
> Deliver compliance at lower cost and gain new business insights.
> Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Vim-latex-devel mailing list
> Vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vim-latex-devel
|
|
From: Gerd W. <ger...@ma...> - 2011-02-23 07:38:57
|
Hi,
On Tue, 22 Feb 2011, Simon Quittek wrote:
> Hello Gerd,
>
> I think, your ideas are very good, and since I use/would like to use F9
> much more often, I welcome improvement!
> Just to make sure to understand from the users view: instead of typing
> "\eqref{eq<F9>" and then looking through the list to find the right
label
> (e.g. "eq:maxwell"), you type the number "(2.4)<F9>" (which has label
> "eq:maxwell" before compilation into the aux-file) and it is expanded
> automatically into "\eqref{eq:maxwell}".
>
> As far as I see, if you want to ref an equation this way, you have to do
> the compilation first, and the numbers probably will change after each
> compilation. In case of a replacement, this means you need to have:
> 1) the up-to-date pdf/dvi file open all the time and
> 2) knowledge of the numbers, even if they are far away in the document.
>
> For this reasons I would _strongly_ prefer to be able to choose which
way
> to use at all times.
> Your method is very convenient, nonetheless and I would very much like
to
> use it!
With my aux-based completion, both methods work:
\eqref{eq:max<F9> => \eqref{eq:maxwell}
(4.1) => \eqref{eq:maxwell}
On Tue, 22 Feb 2011, Ted wrote:
> It's too restrictive for me to need to have the PDF visible at every
time I edit. It's nice sometimes to see a numbered equation, realize you
> want a reference to it, and quickly add a reference without figuring out
its label. However, normally when I'm referring to equations in-line
> with text, I'm writing that text soon after I generated the equation
label (and in close proximity). Moreover, I use a label that has some
> useful meaning. For example, a reference to Newton's Second Law could be
"eq:n2l", and I wouldn't have to open up a PDF to find it.
See above, you can also use the label-based variant, but there is no line
of
context of the tex-file shown.
A comparision: \ref{<F9> with the current tex-based completion results in
something like
2. Modeling of Solid mechanics<<<1
> sec:introduction_mechanics <Dissertation.tex>
: \chapter{Modeling of Solid mechanics}
2.1. Linear Elasticity<<<2
> sec:elasticity <Dissertation.tex>
: \section{Linear Elasticity}
> fig:sketch_of_deformation <Dissertation.tex>
: Sketch of the undeformed and deformed domain.
> eq:definition_of_gradient <Dissertation.tex>
:
the aux-based completion produces:
2 Modeling of Solid mechanics<<<1
> sec:introduction_mechanics
: chapter.2
2.1 Linear Elasticity<<<2
> sec:elasticity
: section.2.1
> fig:sketch_of_deformation
: figure.2.1
> eq:definition_of_gradient
: (2.1)
The aux-based completion does not output the filenames, since I didn't see
any
need for them.
> So I can see some cases where the aux-based completion would be
convenient, but I think most people would need the tex-based completion
most of
> the time.
After giving some clearance, that you still use the labels for completion,
did
you still think, that one needs the tex-based completion?
> A lot of people (especially when journals setup theorem-like
environments for you) won't know the counter name. I suppose they could
assume
> they know the first letter of the counter and use F9 to figure out the
rest<?>.
Yes, that works.
Regards
|
