Thread: [Vim-latex-devel] Re: [Vim-latex-cvs] A little review...
Brought to you by:
srinathava,
tmaas
From: Benji F. <be...@me...> - 2003-01-17 14:11:32
|
Srinath Avadhanula wrote: > ... of the large number of changes I made recently. > > The initial way latex-suite used to get triggered was: > > 1. tex_latexSuite.vim would get sourced everytime. > 2. It would source main.vim once for every buffer. > 3. The first time it was sourced, main.vim would source each of the > other files and from the second time on, just call SetTeXOptions(). > Components which needed to set buffer local mappings would create > globally visible functions which SetTeXOptions() would need to call. > > This had one obvious flaw because of point 2. > > It doesn't work with components which needed to do something every time > we entered a buffer irrespective of whether its the first or the n^th > time. For example, its not possible to write elegantly the > functionality where the packages menu gets updated on every Filetype > event. For example, if we do something like: > 1. open a.tex > 2. :e b.tex > 3. :e a.tex > > in the original setup, hen after step 3, the packages menu would still > show the stuff for b.tex... > > Apart from this obvious flaw which could have been solved with a little > less effort, from a "do the right thing" point of view, it was just > plainly bad design. There is too much inter dependency between the > various modules, which means main.vim would need to be modified every > time we wanted to change some other module. > > It might seem that one way to avoid interdependencies would have been to > reduce tex_latexSuite.vim to: > > execute 'so '.s:path.'/latex-suite/*.vim' > > This is however not possible because we want to source the files in a > certain order. > > There are ofcourse more obvious ways to overcome this problem. (like the > brute force way of just making package/babel scan for whether the user > uses babel with the 'german' option), but I think the present setup is > the most scalable. > > Let me know if what I've done is not too clear or if you have other > concerns. > > In summary, what I have done makes latex-suite behave like: > > 1. tex_latexSuite.vim gets sourced by vim every time a tex filetype > event occurs. > 2. It sources main.vim only once. _never again_ > 3. It then just throws a LatexSuiteFileType event every time (including > the first time). > > When main.vim gets sourced, it: > > 1. Sources each file in some nice order. > 2. Sets up an au to catch the LatexSuiteFileType event to call > SetTeXOptions() each time. Thus buffer local mappings are created for > each tex file being edited. > > Other files which also need to set buffer local mappings follow the same > procedure. > > packages.vim however does something extra > > 1. It sets up an au to call Tex_pack_updateall() on every > LatexSuiteFileType event (which means it gets called for every buffer > every time). > 2. Tex_pack_updateall throws a LatexSuitePackagesScanned event after it > is done "supporting" all the \usepackage's found. > > > Finally, packages/babel catches the LatexSuitePackagesScanned event to > customize the smart quotes setting. > > So to summarize, after about 5 hours of coding, I have a system which > enables german users to edit both english and german files in the same > vim session using some pretty nifty event handling mechanisms. I am > absolutely sure that not more than about 1 person will find this useful. > Ho well, if I was concerned with the value of my time, I wouldn't have > started this thing in the first place... Besides, my meeting tomorrow > got postponed, so I went a little overboard. I think this "little" > programming binge has eaten up my quota for the coming week :( > > Hopefully, we will have some use for all this flexibity in the future. > > > Srinath I redirected this from Vim-latex-cvs to Vim-latex-devel . I think this is going to be helpful in the long run. In the short run, I am afraid that the whle system may be unstable for a while. I would have started a new branch for this. We should document how the system works. Parts of your e-mail, quoted above, can serve as a draft. See :help syntax-loading for one model. The rest of my comments are pretty minor. You did not (yet) take my suggestion about packages/german-babel and so on. Is this because you did not like the idea, or just because you had a lot of other things on your mind? Again, the point is that packages/german does nothing more than set smart-quote options, but (1) this may change and (2) polski already does much more. If you have already declared :augroup LatexSuite then you do not have to include LatexSuite (the augroup) in the :au lines. I find it easier to read without this repetition. Do you disagree, or were you just following the cvs plugin model? If "ngerman" is given as an option to the babel package, then the "german" package will be :source'd. This will work fine. Do we want it to work this way in general? I think there are (at least) two versions of french; can they also be treated the same way? I would rather parse g:Tex_babel_options and, for each option given (Is it legal to give more than one?) :source the appropriate file if it exists. What is the format of the g:Tex_package_detected and g:Tex_{pack}_options variables? If it is something like "pack1,pack2", then it is pretty easy to parse; in particular, your match with '\<babel\>' should work reliably. --Benji |
From: Srinath A. <sr...@fa...> - 2003-01-17 19:06:18
|
On Fri, 17 Jan 2003, Benji Fisher wrote: > I think this is going to be helpful in the long run. In the short > run, I am afraid that the whle system may be unstable for a while. I > would have started a new branch for this. > I am sorry I didn't start a branch... This thing just snowballed from what was supposed to be not too big a change... > We should document how the system works. Parts of your e-mail, > quoted above, can serve as a draft. See > > :help syntax-loading > > for one model. > Yup... That looks good... > You did not (yet) take my suggestion about packages/german-babel > and so on. Is this because you did not like the idea, or just because > you had a lot of other things on your mind? Again, the point is that > packages/german does nothing more than set smart-quote options, but (1) > this may change and (2) polski already does much more. > I just had too many things on my mind... Please go ahead and change things as needed. Note however that there does need to exist a babel package because packages/polski is never going to be used if \usepackage{polski} is not detected. Did you have something else in mind? Maybe instead of just defining all these dummy package files, just make a function Tex_SetLanguageSettings() and an au which calls this on the LatexSuitePackagesScanned event? Maybe as in vim, put this in a packages/allpackage.vim file which gets sourced once when latex-suite starts? > If you have already declared > > :augroup LatexSuite > > then you do not have to include LatexSuite (the augroup) in the :au > lines. I find it easier to read without this repetition. Do you > disagree, or were you just following the cvs plugin model? > I was just following the cvscommand model... The way you suggests looks better because User is highlighted too... > If "ngerman" is given as an option to the babel package, then the > "german" package will be :source'd. This will work fine. Do we want it > to work this way in general? I think there are (at least) two versions > of french; can they also be treated the same way? I would rather parse > g:Tex_babel_options and, for each option given (Is it legal to give more > than one?) :source the appropriate file if it exists. > Yes... The present packages/babel is just a prototype for the general event handling mechanism... I haven't actually invested time in the actual options setting part of it... I would be glad if someone with knowledge of the babel package could take over... > What is the format of the g:Tex_package_detected and > g:Tex_{pack}_options variables? If it is something like "pack1,pack2", > then it is pretty easy to parse; in particular, your match with > '\<babel\>' should work reliably. > Yes. g:Tex_package_detected is guarenteeed to be of the form 'pack1,pack2' g:Tex_{pack}_options is however just yanked from between the [ ]'s of the \usepackage[options]{pack}. Since latex is quite a bit more forgiving about commas, we cannot guarantee a fixed sytnax here. Srinath |
From: Mikolaj M. <mi...@wp...> - 2003-01-18 18:33:21
|
On Fri, Jan 17, 2003 at 09:22:33AM -0500, Benji Fisher wrote: > I redirected this from Vim-latex-cvs to Vim-latex-devel . > I think this is going to be helpful in the long run. In the short > run, I am afraid that the whle system may be unstable for a while. I > would have started a new branch for this. > We should document how the system works. Parts of your e-mail, > quoted above, can serve as a draft. See > :help syntax-loading > for one model. > The rest of my comments are pretty minor. > You did not (yet) take my suggestion about packages/german-babel > and so on. Is this because you did not like the idea, or just because > you had a lot of other things on your mind? Again, the point is that > packages/german does nothing more than set smart-quote options, but (1) > this may change and (2) polski already does much more. It looks like german package is part of babel system which is responsible for i18n of LaTeX. Babelization makes only few (but important) things: hyphenation, local letters, renew sectioning and similar commands maybe typographic rules. You can for example do that: ------------------ \documentclass[a4paper]{book} \usepackage[german,polish]{babel} \begin{document} \selectlanguage{polish} \chapter{Halo to ja} <- Here will be Rozdział (Chapter) Hello world. Here you can use Polish letters. \selectlanguage{german} \chapter{Halo} <- Here will be Kapitel Hello another world. Here will be umlauts. \end{document} ------------------ But preamble can be defined in other manner: \usepackage{babel} \usepackage{polish} \usepackage{german} Or according to docs even \documentclass[a4paper,german,polish]{book} \usepackage{babel} But latter two styles don't work flawlessy for me. Only first gives no errors. Second gives errors but work as expected and third works no at all. I am uploading "regular" babel package file - with latex commands and options without specialized functions. About 'polski'. 'polski' is not a part of 'babel' system. This is completely separate, standalone package wich makes much more than option polish in 'babel' package. There is no option polski in 'babel', only polish. > If "ngerman" is given as an option to the babel package, then the > "german" package will be :source'd. This will work fine. Do we want it > to work this way in general? I think there are (at least) two versions > of french; can they also be treated the same way? I would rather parse > g:Tex_babel_options and, for each option given (Is it legal to give more > than one?) :source the appropriate file if it exists. Here is problem. For some languages, are separate files which works alone (german, ngerman, french). I am not mentioning 'polski' here because its name is different from babel option. IMO here stuff should be duplicated. Create separate file german, which is sourced after \usepackage{german} is detected (normal behaviour), and section in babel file package (if..elseif..endif) which will be triggered after detecting an option for babel package. Options for ther rest of languages would be in 'babel' file. But what about 2nd or 3rd types of declarations? I think we should drop it. Too much work for something which is kinda broken (at least for me...). Maybe other non-english users could say something about their usage of LaTeX? Luc, Fabio? Mikolaj |
From: Luc H. <her...@fr...> - 2003-01-20 03:16:09
|
* On Sat, Jan 18, 2003 at 07:05:13PM +0100, Mikolaj Machowski <mi...@wp...> wrote: > Maybe other non-english users could say something about their usage of > LaTeX? Luc, Fabio? The French packages I'm aware of are: `french', `frenchle', `francais' (used to exist), and `babel'. There might exist another package, but now I use `babel' -- almost the same as frenchle. 'french' is the most advanced, but not free of charges. So far, I have never written any text having significant passages in more than one language -- except code. -- Luc Hermitte http://hermitte.free.fr/vim/ |