vim-latex-devel Mailing List for Vim-Latex (Page 28)
Brought to you by:
srinathava,
tmaas
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(120) |
Dec
(118) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(145) |
Feb
(23) |
Mar
(30) |
Apr
(50) |
May
(88) |
Jun
(49) |
Jul
(41) |
Aug
(13) |
Sep
(51) |
Oct
(30) |
Nov
(80) |
Dec
(43) |
2004 |
Jan
(15) |
Feb
(25) |
Mar
(48) |
Apr
(12) |
May
(37) |
Jun
(52) |
Jul
(16) |
Aug
(10) |
Sep
(7) |
Oct
(19) |
Nov
(17) |
Dec
(19) |
2005 |
Jan
(15) |
Feb
(5) |
Mar
(7) |
Apr
(3) |
May
(2) |
Jun
(4) |
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
(16) |
Dec
(16) |
2006 |
Jan
(15) |
Feb
(27) |
Mar
(49) |
Apr
(31) |
May
(24) |
Jun
(12) |
Jul
(23) |
Aug
(13) |
Sep
(22) |
Oct
(6) |
Nov
(8) |
Dec
(10) |
2007 |
Jan
(3) |
Feb
(13) |
Mar
(19) |
Apr
(1) |
May
(5) |
Jun
(10) |
Jul
(2) |
Aug
(13) |
Sep
(10) |
Oct
(2) |
Nov
(30) |
Dec
(15) |
2008 |
Jan
(11) |
Feb
(9) |
Mar
(27) |
Apr
(27) |
May
(22) |
Jun
(29) |
Jul
|
Aug
(21) |
Sep
(6) |
Oct
(4) |
Nov
(9) |
Dec
(2) |
2009 |
Jan
(52) |
Feb
(21) |
Mar
(9) |
Apr
(41) |
May
(13) |
Jun
(8) |
Jul
(5) |
Aug
(31) |
Sep
(14) |
Oct
(10) |
Nov
(17) |
Dec
(17) |
2010 |
Jan
(25) |
Feb
(22) |
Mar
(22) |
Apr
(24) |
May
(35) |
Jun
(23) |
Jul
(22) |
Aug
(10) |
Sep
(6) |
Oct
(29) |
Nov
(8) |
Dec
(6) |
2011 |
Jan
(12) |
Feb
(89) |
Mar
(41) |
Apr
(8) |
May
(17) |
Jun
(11) |
Jul
(3) |
Aug
(13) |
Sep
(14) |
Oct
(23) |
Nov
(8) |
Dec
(9) |
2012 |
Jan
(15) |
Feb
(27) |
Mar
(6) |
Apr
(17) |
May
(29) |
Jun
(9) |
Jul
(50) |
Aug
(15) |
Sep
(11) |
Oct
(12) |
Nov
(22) |
Dec
(7) |
2013 |
Jan
(24) |
Feb
(32) |
Mar
(6) |
Apr
(5) |
May
(2) |
Jun
(15) |
Jul
(20) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(7) |
Dec
(4) |
2014 |
Jan
(3) |
Feb
(7) |
Mar
(4) |
Apr
|
May
(4) |
Jun
(5) |
Jul
(4) |
Aug
(3) |
Sep
(9) |
Oct
|
Nov
(2) |
Dec
(3) |
2015 |
Jan
|
Feb
(4) |
Mar
(9) |
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
(6) |
Sep
(2) |
Oct
|
Nov
(6) |
Dec
|
2016 |
Jan
(1) |
Feb
(11) |
Mar
(4) |
Apr
(2) |
May
(8) |
Jun
(9) |
Jul
|
Aug
(9) |
Sep
(2) |
Oct
(7) |
Nov
|
Dec
|
2017 |
Jan
(7) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Mike R. <ri...@um...> - 2011-02-21 16:50:20
|
Hi all, I always sort of just took the auxiliary files for granted, but now I like the idea of avoiding the clutter. I compile all of my documents using latex -> dvips -> ps2pdf. Now I adjusted my g:Tex_CompileRule_pdf so that it stores all the auxiliary files in the .build/ subdirectory. It just copies the files out of there to do the compile, and moves the new versions back into .build afterwards. The subdir is created automatically. Here's the relevant section in my ~/.vim/ftplugin/tex.vim: let g:Tex_DefaultTargetFormat='pdf' let g:Tex_MultipleCompileFormats='pdf' let g:Tex_CompileRule_pdf='mkdir -p .build' \.'&& cp .build/* .' \.'; latex -interaction=nonstopmode -shell-escape $*.tex' \.'&& dvips -P pdf -q $*.dvi' \.'&& rm -f $*.dvi' \.'&& ps2pdf $*.ps' \.'&& rm -f $*.ps' \.'&& mv *.aux *.bbl *.bl *.blg *.lof *.log *.lot *.nav *.out *.toc' \.' .build/' Hope someone finds this useful too :) -Mike Richman |
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: Mike R. <ri...@um...> - 2011-02-21 16:25:52
|
On Mon, Feb 21, 2011 at 11:06 AM, Germain Vallverdu <ger...@un...> wrote: > Hi, > > First thanks a lot for your vim-latex plugins. > > I had got a strange behavior. My OS is an linux ubuntu. In my home > directory I have a directory named "dev" where I put current jobs which > are not achieved. If I write latex file inside the "dev" directory the > compilation abort without any error message. It just seems to start and > stop just at begin. Latex file like .log .aux or other are not modified. > I do not know if the name of the directory is the origin but I do not > have that problem in neither other directory ... If y copy my latex > source in another directory or in a subdirectory of the directory "dev" > it works well. > > But at the end, I can simply rename my directory :) > > Thanks > > Germain > Hi Germain, That is strange behavior. I created a directory ~/dev, wrote a minimal LaTeX input, and it compiles fine on both the command line and in gvim with \ll. What happens if you try running "latex" or "pdflatex" on your source code from the command line? -Mike Richman |
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: 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: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: Germain V. <ger...@un...> - 2011-02-21 16:07:12
|
Hi, First thanks a lot for your vim-latex plugins. I had got a strange behavior. My OS is an linux ubuntu. In my home directory I have a directory named "dev" where I put current jobs which are not achieved. If I write latex file inside the "dev" directory the compilation abort without any error message. It just seems to start and stop just at begin. Latex file like .log .aux or other are not modified. I do not know if the name of the directory is the origin but I do not have that problem in neither other directory ... If y copy my latex source in another directory or in a subdirectory of the directory "dev" it works well. But at the end, I can simply rename my directory :) Thanks Germain -- Maître de Conférence Université de Pau et des pays de l'Adour Institut Pluridisciplinaire de Recherche sur l'Environnement et les Matériaux Équipe de Chimie Physique email : ger...@un... Tel : 05 59 40 78 51 page : http://gvallver.perso.univ-pau.fr |
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: Gerd W. <ger...@ma...> - 2011-02-19 07:42:46
|
>> The only potential issue I see is that after the splitting of the >> repository, they will have different commit ids than the original >> repository had. Since the repository is not published that long, I tend >> to think that this is not important. > > That probably won't be much of an issue... Aside from the fact that it > will create a new head when anyone pulls down the new repo (hopefully > that wouldn't confuse any automated package managers, like Arch Linux's > yaourt (there is already a vim-latex-git on AUR)). > > Alternatively, you could keep the htdocs in the history. Clone the > current repo into two, and then (within each clone) move the files to > their desired locations and commit the changes. Of course, you probably > don't need to maintain the changelog within the new "vim-latex-htdocs" > repo, and so that one could be split out regardless. I think, one could separate both repos with "git filter-branch". For the vimfiles a "--subdirectory-filter vimfiles/" will work and for the remaining part one has to use '--tree-filter "rm -rf vimfiles"'. This split the repo into two and preserves all commit/log entries. Both repos do not know the history of the other one - thus there is no "history overhead". Regards Gerd |
From: Ted P. <te...@te...> - 2011-02-18 19:56:22
|
>> It would make sense to split out the web and the vimfiles into two >> separate repos. However, is that really necessary? > > What disadvantages do you see? I am pretty sure that most of vim-latex None aside from the grunt work. My comment was sort of an "in the meanwhile, symlinks with pathogen should work." > The only potential issue I see is that after the splitting of the > repository, they will have different commit ids than the original > repository had. Since the repository is not published that long, I tend > to think that this is not important. That probably won't be much of an issue... Aside from the fact that it will create a new head when anyone pulls down the new repo (hopefully that wouldn't confuse any automated package managers, like Arch Linux's yaourt (there is already a vim-latex-git on AUR)). Alternatively, you could keep the htdocs in the history. Clone the current repo into two, and then (within each clone) move the files to their desired locations and commit the changes. Of course, you probably don't need to maintain the changelog within the new "vim-latex-htdocs" repo, and so that one could be split out regardless. --Ted -- Ted Pavlic <te...@te...> |
From: Till M. <ope...@ti...> - 2011-02-18 19:43:40
|
On Fri, Feb 18, 2011 at 01:52:37PM -0500, Ted Pavlic wrote: > > I'm looking forward when Till will put vimfiles/ in a separate repo (or > > branch). Then I can use the method described in > > It would make sense to split out the web and the vimfiles into two > separate repos. However, is that really necessary? What disadvantages do you see? I am pretty sure that most of vim-latex users are only interested in the vimfiles directory. With svn it was straight-forward to checkout only that part of the repository. The only potential issue I see is that after the splitting of the repository, they will have different commit ids than the original repository had. Since the repository is not published that long, I tend to think that this is not important. Regards Till |
From: Ted P. <te...@te...> - 2011-02-18 18:52:48
|
> I'm looking forward when Till will put vimfiles/ in a separate repo (or > branch). Then I can use the method described in It would make sense to split out the web and the vimfiles into two separate repos. However, is that really necessary? I haven't used pathogen before, but it looks like you could just symlink the vimfiles directory from vim-files into your ~/.vim/bundle. At least in the near term, I think that would work. <?> > http://vimcasts.org/episodes/synchronizing-plugins-with-git-submodules-and-pathogen/ (regarding hosting on github, you could still manage your conf in Mercurial (with the imported changesets from vim-latex.git) and publish it on Google Code/etc.) --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: Gerd W. <ger...@ma...> - 2011-02-18 18:09:38
|
Hi, I'm looking forward when Till will put vimfiles/ in a separate repo (or branch). Then I can use the method described in http://vimcasts.org/episodes/synchronizing-plugins-with-git-submodules-and-pathogen/ This sounds very handy. I think I will also publish my configuration at github. Best Regards Gerd On Fri, 18 Feb 2011, Ted Pavlic wrote: >> I know more about hg than git. In hg, there is a "convert" that allows > > In fact, if you were willing to manage your conf repo with Mercurial, > you could probably use convert to do all of the work for you. The > simplest thing you'd want would be: > > hg convert --filemap vimfiles_only /path/to/vim-latex ~/conf > > where the "filemap" is a file that looks like: > > include path/to/file-or-dir > exclude path/to/file-or-dir > rename path/to/source path/to/destination > > In particular, the file "vimfiles_only" contacts > > include "vimfiles" > rename "vimfiles" "vim" > > But you could tweak things a bit (branchsort or datesort, for example). > I don't know of a way to "squash" in hg convert, and so you'd end up > with a bunch of heads corresponding to each of the unclosed heads of the > vim-latex. You could --close-branch on each of them if you prefer. > Otherwise, you can just merge with the most recent head, and I think you > would be on your way. Run the convert periodically to pull new revisions > in, and then merge again. That is.. > > hg update -C old_conf_head > hg merge -r latest_vimfiles_head > hg commit -m "Merge" > > I would recommend naming the old branch and the branch holding the > latest vimfiles head. That will make future merges easier > (alternatively, you can close the several old vimfiles branches that are > dead). > > I gave it a test run on my system, and it seemed to work. > > --Ted > > |
From: Ted P. <te...@te...> - 2011-02-18 17:55:13
|
> I know more about hg than git. In hg, there is a "convert" that allows In fact, if you were willing to manage your conf repo with Mercurial, you could probably use convert to do all of the work for you. The simplest thing you'd want would be: hg convert --filemap vimfiles_only /path/to/vim-latex ~/conf where the "filemap" is a file that looks like: include path/to/file-or-dir exclude path/to/file-or-dir rename path/to/source path/to/destination In particular, the file "vimfiles_only" contacts include "vimfiles" rename "vimfiles" "vim" But you could tweak things a bit (branchsort or datesort, for example). I don't know of a way to "squash" in hg convert, and so you'd end up with a bunch of heads corresponding to each of the unclosed heads of the vim-latex. You could --close-branch on each of them if you prefer. Otherwise, you can just merge with the most recent head, and I think you would be on your way. Run the convert periodically to pull new revisions in, and then merge again. That is.. hg update -C old_conf_head hg merge -r latest_vimfiles_head hg commit -m "Merge" I would recommend naming the old branch and the branch holding the latest vimfiles head. That will make future merges easier (alternatively, you can close the several old vimfiles branches that are dead). I gave it a test run on my system, and it seemed to work. --Ted -- Ted Pavlic <te...@te...> |
From: Ted P. <te...@te...> - 2011-02-18 16:33:57
|
Since no one else has responded to this yet, I'll add my probably useless comments... > I fiddled arround with git subtree, but I can't get it work. Does anybody > know, how I can merge the subdirectory vimfiles into my subdirectory vim?? Personally, I'm just using rsync (actually, there's an old Makefile.in in the vimfiles directory that includes "install", "stallin", and "sync" targets and is already configured for ~/.vim). I know more about hg than git. In hg, there is a "convert" that allows you to map changesets from one repo into changesets in another repo while also moving files into an alternate location (of course, this process destroys the original changeset ID, and so the id-to-id mapping is stored in a file in the target repo). I don't know how to do "convert" in git, but I have a feeling you aren't interested in that. [There's probably a better way to do what you're talking about doing even in Mercurial, but I happen to know about convert because I use it to create public versions of some of my private repositories with certain files/directories stripped from the change history.] It does appear like "git submodule" is what you would want to use, but I have no experience with using it. Have you tried posting to the git mailing list? It's very active. --Ted -- Ted Pavlic <te...@te...> |
From: Gerd W. <ger...@ma...> - 2011-02-17 16:48:24
|
Hi, after vim-latex changed to git, I want to put my vim configuration in a local git repo located at ~/conf. I would like to link ~/.vim to ~/conf/vim. Therefore, I have to merge the commits at vim-latex/master:vimfiles/ into my local repo at the point master:vim/. I fiddled arround with git subtree, but I can't get it work. Does anybody know, how I can merge the subdirectory vimfiles into my subdirectory vim?? Does anybody else have his vim configuration in a git and merge it with the upstream vim-latex? Regards Gerd |
From: Ng Oon-Ee <ng...@gm...> - 2011-02-17 08:58:23
|
On Wed, 2011-02-16 at 14:16 +0800, Ng Oon-Ee wrote: > On Wed, 2011-02-16 at 01:11 -0500, Ted Pavlic wrote: > > >> :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' > > >> > > >> inside your latexmain file. The latexmain files get sourced. If you > > > What would a 'view rule with jobname included' look like? > > > > > > My current view rule is simple 'okular', and I assume 'blah.dvi' is > > > automatically appended. How do I change what is appended? Or should I > > > simply put 'okular foo.dvi' where foo is the jobname? > > > > Yes, > > > > okular foo.dvi > > > > would probably be what you would want. That way \lv executes it > > directly. Unfortunately, that will likely break Vim-LaTeX's ability to > > view temporary files generated by compiling fragments (i.e., temporary > > targets generated when using \ll while you have highlighted a block of > > LaTeX code). > > > > --Ted > > > Looks like its best just to skip 'jobname' entirely and simply rename > the file myself for final submission =). Thanks Ted and the rest who > have replied. > And as a final closure for this, nope this method won't work. vim-latex doesn't know where to find foo.aux for bibtex, so won't run it, and you won't get your bibliography. Quite a pity, really. Back to having all files in the root folder =). |
From: Ted P. <te...@te...> - 2011-02-16 16:46:21
|
> If someone has a good idea for a patch, then > git-format-patch/git-send-email them to the list for review and > application. Of course, using the "Patches tracker" on the SF site is also a good alternative. https://sourceforge.net/tracker/?group_id=52322&atid=466458 Patches can be uploaded, commented on, and eventually accepted (and committed) through the web interface. I am a bigger fan of the old-fashioned mailing list interface (i.e., using 'git send-email' to post a message with "[PATCH]" in the subject to the mailing list where it can be publicly viewed and scrutinized and announced -- that's how the Git development team does it); however, SF has a history of doing these things through a tracked web interface. --Ted -- Ted Pavlic <te...@te...> |
From: Ted P. <te...@te...> - 2011-02-16 06:24:03
|
>> My current view rule is simple 'okular', and I assume 'blah.dvi' is >> automatically appended. How do I change what is appended? Or should I >> simply put 'okular foo.dvi' where foo is the jobname? >> > Oh, and while that would work for \lv, doesn't seem to be a > corresponding function for \ls \ls looks at Viewer to try to determine if it knows of a way to pass the corresponding source special hook to the viewer. If a viewer doesn't know anything about source specials, then there's no hope. So an override for \ls like the override for \lv would have to have a way of passing in the line number to hookup with the source specials and possibly enough information to the editor to then reverse search back to the vim document after browsing. This is why I think the ultimate solution would be to build jobname support directly into compiler.vim (that would default to jobname=filename) so all of these little hacks wouldn't be needed. It shouldn't be hard to do... It would just require... (a) Determining how to pass the jobname in (via a variable? via another filename? both?) (b) Going through and using the jobname in compiler.vim whenever it is available (probably only 9 or 10 different places) If someone has a good idea for a patch, then git-format-patch/git-send-email them to the list for review and application. --Ted -- Ted Pavlic <te...@te...> |
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 06:16:45
|
On Wed, 2011-02-16 at 01:11 -0500, Ted Pavlic wrote: > >> :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' > >> > >> inside your latexmain file. The latexmain files get sourced. If you > > What would a 'view rule with jobname included' look like? > > > > My current view rule is simple 'okular', and I assume 'blah.dvi' is > > automatically appended. How do I change what is appended? Or should I > > simply put 'okular foo.dvi' where foo is the jobname? > > Yes, > > okular foo.dvi > > would probably be what you would want. That way \lv executes it > directly. Unfortunately, that will likely break Vim-LaTeX's ability to > view temporary files generated by compiling fragments (i.e., temporary > targets generated when using \ll while you have highlighted a block of > LaTeX code). > > --Ted > Looks like its best just to skip 'jobname' entirely and simply rename the file myself for final submission =). Thanks Ted and the rest who have replied. |
From: Ted P. <te...@te...> - 2011-02-16 06:11:38
|
>> :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' >> >> inside your latexmain file. The latexmain files get sourced. If you > What would a 'view rule with jobname included' look like? > > My current view rule is simple 'okular', and I assume 'blah.dvi' is > automatically appended. How do I change what is appended? Or should I > simply put 'okular foo.dvi' where foo is the jobname? Yes, okular foo.dvi would probably be what you would want. That way \lv executes it directly. Unfortunately, that will likely break Vim-LaTeX's ability to view temporary files generated by compiling fragments (i.e., temporary targets generated when using \ll while you have highlighted a block of LaTeX code). --Ted -- Ted Pavlic <te...@te...> |
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 05:17:03
|
On Wed, 2011-02-16 at 13:11 +0800, Ng Oon-Ee wrote: > On Tue, 2011-02-15 at 23:28 -0500, Ted Pavlic wrote: > > > So you could set g:Tex_ViewRuleComplete_dvi for your particular project > > > to use the right jobname. Otherwise, it would be difficult for vim-latex > > > to figure out the right jobname. > > > > Connecting this with the response I just sent, you can of course put > > something like... > > > > :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' > > > > inside your latexmain file. The latexmain files get sourced. If you > > don't like the extra buffer that gets opened, then make sure the > > latexmain file looks like "main.latexmain" as opposed to > > "main.tex.latexmain". Both should get sourced though. > > > > --Ted > > > What would a 'view rule with jobname included' look like? > > My current view rule is simple 'okular', and I assume 'blah.dvi' is > automatically appended. How do I change what is appended? Or should I > simply put 'okular foo.dvi' where foo is the jobname? > Oh, and while that would work for \lv, doesn't seem to be a corresponding function for \ls |
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 05:11:40
|
On Tue, 2011-02-15 at 23:28 -0500, Ted Pavlic wrote: > > So you could set g:Tex_ViewRuleComplete_dvi for your particular project > > to use the right jobname. Otherwise, it would be difficult for vim-latex > > to figure out the right jobname. > > Connecting this with the response I just sent, you can of course put > something like... > > :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' > > inside your latexmain file. The latexmain files get sourced. If you > don't like the extra buffer that gets opened, then make sure the > latexmain file looks like "main.latexmain" as opposed to > "main.tex.latexmain". Both should get sourced though. > > --Ted > What would a 'view rule with jobname included' look like? My current view rule is simple 'okular', and I assume 'blah.dvi' is automatically appended. How do I change what is appended? Or should I simply put 'okular foo.dvi' where foo is the jobname? |
From: Ted P. <te...@te...> - 2011-02-16 04:32:26
|
> and have each \l* command respond to g:jobname if found. So that's > another way it could be done. I didn't mean to imply that the \l* commands already respond to such a variable. They could be modified to respond to it though, and that variable could be set within the .latexmain project file. --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-16 04:28:12
|
> So you could set g:Tex_ViewRuleComplete_dvi for your particular project > to use the right jobname. Otherwise, it would be difficult for vim-latex > to figure out the right jobname. Connecting this with the response I just sent, you can of course put something like... :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' inside your latexmain file. The latexmain files get sourced. If you don't like the extra buffer that gets opened, then make sure the latexmain file looks like "main.latexmain" as opposed to "main.tex.latexmain". Both should get sourced though. --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. |