Thread: [Vim-latex-devel] Completion of Tcommands
Brought to you by:
srinathava,
tmaas
Menu
▾
▴
vim-latex-devel
|
From: Mikolaj M. <mi...@wp...> - 2003-07-12 18:01:31
|
Hello, I'd like to add completion of commands similar to those implemented yesterday in TPackage. I would improve usability of Tcommands. Candidates are: TTemplate TSection \ TSectionAdvanced - 1 function TMacro \ TMacroEdit > 1 funtion TMacroDelete / BTW I am curious if it would be possible to rewrite current system of hints basing on input() (PromptFor...) to command :Enter_your_choice It would enable completion of commands with <Tab> or <C-D> m. |
|
From: Luc H. <her...@fr...> - 2003-07-12 19:38:07
|
Hello,
* On Sat, Jul 12, 2003 at 07:41:11PM +0200, Mikolaj Machowski <mi...@wp...> wrote:
> I'd like to add completion of commands similar to those implemented
> yesterday in TPackage. I would improve usability of Tcommands.
> Candidates are:
>
> TTemplate
> [...]
>
> BTW I am curious if it would be possible to rewrite current system of
> hints basing on input() (PromptFor...) to command :Enter_your_choice
> It would enable completion of commands with <Tab> or <C-D>
I know you decided to maintain a TeX-specific templates plugin, but I
think that the version of µTemplate I'm working on already proposes the
kind of completion mecanism you are looking for.
For instance, with it (see my sig for its address), try to type in
insert-mode (within a latex document):
fig<c-r><tab> (or <c-r><space> which is the same for TeX files)
or ce<c-r><tab>
(the only two LaTeX-templates proposed for now: figure and center)
If there were two templates with similar names like for instance
`tabular' and `table', a confirm-box would popup on "tab<c-r><tab>" so
we can choose which template we want to expand.
BTW, why developping a feature concurrent to templates ? I'm thinking to
latexSuite's macros which looks like more restricted templates than the
ones we could have with a templates-expander.
What did I miss ?
The only thing missing to my version of µTemplate is a better support of
non-latin1 files -- I think I will incorporate something like the
"!comp!" you are using.
However, it is a very big plugin with many features; it may sometimes be
considered as (as we would say in French): "une enclume pour écraser
des mouches" (-> an anvil to crush flies) -- I don't remember the
idiomatic expression in English.
HTH
--
Luc Hermitte
http://hermitte.free.fr/vim/ressources/ mu-template.tar.gz
|
|
From: Mikolaj M. <mi...@wp...> - 2003-07-13 21:37:43
|
On Sat, Jul 12, 2003 at 09:40:09PM +0200, Luc Hermitte wrote: > Hello, > * On Sat, Jul 12, 2003 at 07:41:11PM +0200, Mikolaj Machowski <mi...@wp...> wrote: > > I'd like to add completion of commands similar to those implemented > > yesterday in TPackage. I would improve usability of Tcommands. > > Candidates are: > > > > TTemplate > BTW, why developping a feature concurrent to templates ? I'm thinking to > latexSuite's macros which looks like more restricted templates than the > ones we could have with a templates-expander. > What did I miss ? TTemplate here is a command to source skeleton of file (with various \documentclass, preambles, etc.). What you described looks like replacement/enhancement for <F5>. Macros and Templates are very similar and created to separate two things. Mechanisms are similar (or even the same) but purpose different. m. |
|
From: Luc H. <her...@fr...> - 2003-07-13 23:39:59
|
Hello, * On Sun, Jul 13, 2003 at 11:28:28PM +0200, Mikolaj Machowski <mi...@wp...> wrote: > > BTW, why developping a feature concurrent to templates ? I'm > > thinking to latexSuite's macros which looks like more restricted > > templates than the ones we could have with a templates-expander. > > What did I miss ? > > TTemplate here is a command to source skeleton of file (with various > \documentclass, preambles, etc.). What you described looks like > replacement/enhancement for <F5>. What I described is one of the ways for using µTemplate. (others beeing: -menus (automatically built), -command :MuTemplate, -autocommand on BufNewFile). The template-expansion function(s) and the search within directories (visible from 'runtimepath') have been implemented only once. > Macros and Templates are very similar and created to separate two > things. Mechanisms are similar (or even the same) but purpose different. From the outside, it looks like it is (technically) the same thing. Thus my question: why not develop only a single generic function that can used to insert general-templates, ``macros'' (or even packages ?) ? May be I am wrong and you don't have to maintain three times the same things -- which differs only by final names and directories. My idea is that TTemplate, TMacros, ... would invoke the same function but with different built-in parameters. Cheers, -- Luc Hermitte http://hermitte.free.fr/vim/ |
|
From: Srinath A. <sr...@fa...> - 2003-07-14 06:36:41
|
Hi Luc, > From the outside, it looks like it is (technically) the same thing. > Thus my question: why not develop only a single generic function that > can used to insert general-templates, ``macros'' (or even packages ?) ? > May be I am wrong and you don't have to maintain three times the same > things -- which differs only by final names and directories. > > My idea is that TTemplate, TMacros, ... would invoke the same function > but with different built-in parameters. > As of now, the templates, custom macros and IMAP() functions in latex-suite are all handled by a central IMAP_PutTextWithMovement() function with differing arguments and wrapper functions (for example, TTemplate provides a prompt for the template files etc). So we do not really repeat any work. The jump function and marker functionality is all in plugin/imaps.vim. Also, one sufficiently important implementation issue in the IMAP() function is that you do not have to bind all expansions to non-keyword characters like <C-r><space> or <C-r><tab> etc. Most expansions in latex-suite are for example triggered just as :imaps work except for being able to correct, no timeout etc. Basically, only the last character of the first argument of an IMAP() is actually :map'ped to a LookupCharacter() function. A reverse lookup over previously typed characters is made whenever such a character is encountered and if there is a possible completion, it is used... This enables you to have 2-key mappings like `8 -> \infty which would have been pretty annoying to use if we had to type 8<C-r><tab> each time... BTW, very recently I started to have to compile some files multiple times and therefore quickly felt the need for a function like TKMakeDVI in tex-tools.vim (part of your latex ftplugin package). I looked at it and have been extracting parts of it to use in latex-suite. I wish to borrow the basic logic of the multiple compilations, but I wish to implement various things like TKFilesDiffer() differently to make it cross-platform without a lot of platform detection logic... I have a very rough (and incomplete) draft of this on a non-MAIN branch in the vim-latex cvs tree. Another implementation issue is that I have a parallel python implementation of the same thing and the script should automatically detect python and use the python function instead so all the things like filediff's etc can be handled via python much more cleanly than in viml. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/vim-latex/vimfiles/ftplugin/tex/Attic/latexm.vim?rev=1.1.2.3&only_with_tag=latex-multi-compile&content-type=text/vnd.viewcvs-markup (one big URL) Thanks, Srinath |
|
From: Luc H. <her...@fr...> - 2003-07-15 00:30:51
|
Hello,
* On Sun, Jul 13, 2003 at 11:36:28PM -0700, Srinath Avadhanula <sr...@fa...> wrote:
> > My idea is that TTemplate, TMacros, ... would invoke the same
> > function but with different built-in parameters.
> >
> As of now, the templates, custom macros and IMAP() functions in
> latex-suite are all handled by a central
> IMAP_PutTextWithMovement() function with differing arguments and
> wrapper functions (for example, TTemplate provides a prompt for the
> template files etc). So we do not really repeat any work. The jump
> function and marker functionality is all in plugin/imaps.vim.
OK.
But the expansion of "!com!...!com!" and "!exe!...!exe!", ...
are unique to templates, if I am correct. Feature which would be very
interresting to have with macros/packages/...
<adv.>
> Also, one sufficiently important implementation issue in the IMAP()
> function is that you do not have to bind all expansions to non-keyword
> characters like <C-r><space> or <C-r><tab> etc. Most expansions in
> latex-suite are for example triggered just as :imaps work except for
> being able to correct, no timeout etc. Basically, only the last
> character of the first argument of an IMAP() is actually :map'ped to a
> LookupCharacter() function. A reverse lookup over previously typed
> characters is made whenever such a character is encountered and if
> there is a possible completion, it is used... This enables you to have
> 2-key mappings like `8 -> \infty which would have been pretty annoying
> to use if we had to type 8<C-r><tab> each time...
That is not really an issue, µTemplate is easy to enhance with
something like (syntax not tested):
function s:BindTemplate(file)
let the_map = fnamemodify(a:file, ":e")
call IMAP_smart_bind(s:the_leader.the_map,
\ "\<c-o>:MuTemplate tex/".the_map)
" IMAP_smart_bind() beeing the core of the IMAP_... functions.
endfunction
command! BindTemplate :call s:BindTemplate("<args>")
SearchInRuntime! :BindTemplate template/tex/template.*
As a result, if you type "`figure", it will get expanded with the right
template-file -- it is also possible to automatically build more
complex/specific keybindings than this simplistic one.
But, it is already (at this time) possible to use it a stubs-expander
that expands on back-quotes (like Dr Chip Campbell's stubs-expander) --
by just mapping the expansion to "`" instead of "<c-r><tab>", ...
=> :imap <buffer> ` <Plug>MuT_cword
(if you'd rather use <F5> ... it is easy to adapt ... ; for personal
reasons, I've chosen <c-r><tab>)
Which is IMHO more interresting than "`figure" because "f`", "fi`",
..."figure`" also work -- and if several choices are available ... they
will be proposed to the end-user.
[Little remark: the back-quote is not a French-friendly character as it
is hard-binded to <altgr-7>. French keyboards are definitively
CS-unfriendly :(
]
</adv.>
But that was not my initial point.
My main point is: wouldn't it be more interresting to
- concentrate on building a really powerfull templates-expander,
- and wrap its calls into functions/commands/menus for
macros/templates/packages.
BTW, i fixed some little problems from the original µTemplate plugin ;
even one (and a half) i personnaly introduced (two :<range>substitute
calls for "compute" and "execute" was a awkward! ; several "execute"
commands have no reasons to be on a same line.)
<adv.>
Last parenthesis. The only things you may consider as a lack in my
current version on µTemplate:
- a little patch is still to be applied regarding non-latin1 issues
- placeholders are not converted by the plugin, but instead inserted
through a call to a dedicated function.
- the filenames of the templates are quite heavy
({rtp}/template/template.{the_real_name})
</adv.>
______________
> BTW, very recently I started to have to compile some files multiple
> times and therefore quickly felt the need for a function like
> TKMakeDVI in tex-tools.vim (part of your latex ftplugin package). I
> looked at it and have been extracting parts of it to use in
> latex-suite.
Feel free to do so !
> I wish to borrow the basic logic of the multiple compilations, but I
> wish to implement various things like TKFilesDiffer() differently to
> make it cross-platform without a lot of platform detection logic...
This function was definitivelly an headache ! I made minor modifications
on Tomer Kol's initial function, but still it is not perfect :-(
> I have a very rough (and incomplete) draft of this on a non-MAIN
> branch in the vim-latex cvs tree.
> Another implementation issue is that I have a parallel python
> implementation of the same thing and the script should automatically
> detect python and use the python function instead so all the things
> like filediff's etc can be handled via python much more cleanly than
> in viml.
Sounds like a good idea!
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/vim-latex/vimfiles/ftplugin/tex/Attic/latexm.vim?rev=1.1.2.3&only_with_tag=latex-multi-compile&content-type=text/vnd.viewcvs-markup
After a quick check:
- [adv.] I have dedicated a plugin to portability issues. For instance
it defines a function SysCat() that returns the name of the external
program to use according to the current system -- and the path to the
parameter-files is correctly converted!
-> system_utils.vim
- Why
exec 'silent! 0r! '.g:Tex_CatCmd.' '.a:filename
and not just:
if fileexists(a:filename)
exec 'silent! 0r '.a:filename
endif
?
It would reduce the problems we can experience because of external
programs -- another source of headaches.
- Why
if search(a:regexp, 'w')
let retVal = 1
else
let retVal = 0
endif
instead of:
let reVal = search(a:regexp, 'w') > 0
?
I'm a militant for the direct use of boolean expressions whenever we
have "if expression then a=true else a=false endif" :)
_________
Otherwise, I would have a request (partly implemented in my ftplugin).
I'd like to have the choice of the way used to define the main TeX
document between:
- using a [bg]:dedicated_variable_for_this (whatever the final name is)
- or using mainfile.{theproject} (or another name i don't remember) as
you originally planned
- or using a Makefile (if the right conditions are fulfilled)
- or using the name of the current buffer.
--
Luc Hermitte
http://hermitte.free.fr/vim/
|
|
From: Srinath A. <sr...@fa...> - 2003-07-15 01:46:07
|
Hi Luc,
I will reply to the other points later (several very helpful hints
there...), but I couldn't resist replying to the very last point now...
On Tue, 15 Jul 2003, Luc Hermitte wrote:
> Otherwise, I would have a request (partly implemented in my ftplugin).
> I'd like to have the choice of the way used to define the main TeX
> document between:
> - using a [bg]:dedicated_variable_for_this (whatever the final name is)
> - or using mainfile.{theproject} (or another name i don't remember) as
> you originally planned
> - or using a Makefile (if the right conditions are fulfilled)
> - or using the name of the current buffer.
>
>
For a while now, I have been thinking of a way to let the user be able
to very easily specify the main file name in whatever way he chooses...
Right now, a central function Tex_GetMainFileName() is called whenever
a function needs the main tex file name (there are quite a few functions
which need this info). Right now, Tex_GetMainFileName() checks for
a {fname}.latexmain file and returns {fname} if possible, otherwise it
just returns '' (the calling function is supposed to handle the case
when it returns ''). There are various ways in which we could make this
customizable.
Let the user define a variable g:Tex_MainFileExpr ('' by default)
which latex-suite will use as:
if g:Tex_MainFileExpr != ''
exec 'let retval = '.g:Tex_MainFileExpr
return retval
endif
You could then define g:Tex_MainFileExpr to be whatever you like. For
instance, you could use your extended let-modeline function here (if
I remember the nomenclature correctly).
How does this sound? Is it sufficient? Or were you thinking of something
else entirely?
Srinath
|
|
From: Srinath A. <sr...@fa...> - 2003-07-15 07:14:43
|
A bit more discussion...
On Tue, 15 Jul 2003, Luc Hermitte wrote:
> - Why
> exec 'silent! 0r! '.g:Tex_CatCmd.' '.a:filename
> and not just:
> if fileexists(a:filename)
> exec 'silent! 0r '.a:filename
> endif
> ?
> It would reduce the problems we can experience because of external
> programs -- another source of headaches.
I tried doing :r {fname} before but found that it actually creates a new
buffer in the process. I think that creating unused buffers is a greater
evil than spawning a shell command. If you notice, I take a lot of care
to only create one temporary buffer in a session. Also r! {fname} seems
to spawn the shell in the background in gvim, so its not too
intrusive... I submitted a feature request about a function
filecontents() in vim which would basically return a <NL> seperated
string of the contents of a file, but I have a feeling its going to be
neglected like always. Sometimes I really wish viml had a few more basic
building blocks.
> - Why
> if search(a:regexp, 'w')
> let retVal = 1
> else
> let retVal = 0
> endif
> instead of:
> let reVal = search(a:regexp, 'w') > 0
> ?
> I'm a militant for the direct use of boolean expressions whenever we
> have "if expression then a=true else a=false endif" :)
>
Heh :) I guess it does make things more compact. I would go so far as to
say that I should have simply done:
let retVal = search(..., ...)
I have only rarely used booleans in places other than if statements
etc... But I guess logical expressions are not really consistent across
languages. For example, in vim:
echo 2 && 3
prints 1
whereas in python (which is becoming my favorite language),
print 2 and 3
will print 3 (which seems more logical actually as far as expression
short-circuiting goes... for example, you could do
something = istrue and file.readlines()
will make something contain the contents of the file if istrue is true,
a sort of if then statement.
)
So whats correct? Depending on return values from boolean algebra might
lead to inconsistencies, so be warned.
BTW, Luc: how did you get the logic for what steps to follow to generate
the DVI file correctly? I notice that TKMakeDVI first runs bibtex if
file.aux contains \bibdata even before running latex. But this seems to
be incorrect in situations where the modification is to remove
a bibliographic entry... i.e, if initially the file contained
\bibliography{fname}
and I removed this line or changed fname and then did TKMakeDVI, then it
would wrongly make bibtex scan fname... I hope you see the problem.
Thanks,
Srinath
|
|
From: Luc H. <her...@fr...> - 2003-07-15 08:58:39
|
* On Tue, Jul 15, 2003 at 12:13:51AM -0700, Srinath Avadhanula <sr...@fa...> wrote:
> On Tue, 15 Jul 2003, Luc Hermitte wrote:
> > - Why
> > exec 'silent! 0r! '.g:Tex_CatCmd.' '.a:filename
> > and not just:
> > if fileexists(a:filename)
> > exec 'silent! 0r '.a:filename
> > endif
> > ?
>
> I tried doing :r {fname} before but found that it actually creates a
> new buffer in the process. I think that creating unused buffers is a
> greater evil than spawning a shell command. If you notice, I take a
> lot of care to only create one temporary buffer in a session.
What the hell ?!
I wonder why ":r" and ":r! cat" differ so much. And what is the need of
keeping an unused buffer ...
Anyway. Thanks for the info!
> Also r! {fname} seems to spawn the shell in the background in gvim,
> so its not too intrusive...
But, problem: what are the correct external-program amiga, macos, ... ?
> I submitted a feature request about a function filecontents() in vim
> which would basically return a <NL> seperated string of the contents
> of a file, but I have a feeling its going to be neglected like always.
> Sometimes I really wish viml had a few more basic building blocks.
So do I.
> > - Why
> > if search(a:regexp, 'w')
> > let retVal = 1
> > else
> > let retVal = 0
> > endif
> > instead of:
> > let reVal = search(a:regexp, 'w') > 0
> > ?
> Heh :) I guess it does make things more compact. I would go so far as to
> say that I should have simply done:
>
> let retVal = search(..., ...)
Yes and no. "search(...)" is not "boolean-like" as it is an int.
"search(...)>0" is ; as it values 0 or 1.
> [...]
> So whats correct? Depending on return values from boolean algebra might
> lead to inconsistencies, so be warned.
I am. :)
> BTW, Luc: how did you get the logic for what steps to follow to
> generate the DVI file correctly?
Mainly from Tomer Kol's initial program. So I will not be surprised to
learn that it differs from the ones we can find in others
Makefile/scripts.
> I notice that TKMakeDVI first runs bibtex if file.aux contains
> \bibdata even before running latex.
> But this seems to be incorrect in situations where the modification is
> to remove a bibliographic entry... i.e, if initially the file
> contained
>
> \bibliography{fname}
>
> and I removed this line or changed fname and then did TKMakeDVI, then it
> would wrongly make bibtex scan fname... I hope you see the problem.
Yes indeed.
However, bibtex is also run after latex. And if the .bbl file has
changed then we know that latex must be re-run.
May be to much compilations and bibtex executions are made. But the
result will be correct.
I don't remember why I/we considered the execution of bibtex after latex
wasn't enough. Probably that sometimes bibtex need to be run twice. But
I don't remember when -- I haven't use LaTeX for a while.
So far, it seems that the following may be enough:
0.0- need_to_rerun = 1
x.0- while need_to_rerun
x.1- latex
1.2- if !grep(\bibdata, mainfile.'.tex') => 1.3
if fileexists(mainfile.'.bbl') => backup
bibtex
if .bbl and .bll.bak differs => need_to_rerun = 1
x.3- if grep(Rerun, mainfile.'.log')
x.0- while need_to_rerun
x.1- latex
y.2- nothing
...
BTW: there is a thing i think is a strench of tex-tools: bibtex,
makeindex, dvips, ... are used as 'makeprogram's => the errors can be
seen in a :cwindow.
This requires that compiler/tex.vim defines a function/command that
reset &efm to (pdf)(La)TeX settings -- without having to resource this
file.
--
Luc Hermitte
http://hermitte.free.fr/vim/
|
|
From: Luc H. <her...@fr...> - 2003-07-15 08:58:46
|
Hello Srinath.
* On Mon, Jul 14, 2003 at 06:46:01PM -0700, Srinath Avadhanula <sr...@fa...> wrote:
> On Tue, 15 Jul 2003, Luc Hermitte wrote:
> > Otherwise, I would have a request (partly implemented in my
> > ftplugin). I'd like to have the choice of the way used to define
> > the main TeX document between:
> > - using a [bg]:dedicated_variable_for_this (whatever the final name
> > is)
> > - or using mainfile.{theproject} (or another name i don't remember)
> > as you originally planned
> > - or using a Makefile (if the right conditions are fulfilled)
> > - or using the name of the current buffer.
> >
> >
> For a while now, I have been thinking of a way to let the user be able
> to very easily specify the main file name in whatever way he
> chooses...
> Right now, a central function Tex_GetMainFileName() is called whenever
> a function needs the main tex file name (there are quite a few
> functions which need this info). Right now, Tex_GetMainFileName()
> checks for a {fname}.latexmain file and returns {fname} if possible,
> otherwise it just returns '' (the calling function is supposed to
> handle the case when it returns ''). There are various ways in which
> we could make this customizable.
>
> Let the user define a variable g:Tex_MainFileExpr ('' by default)
> which latex-suite will use as:
>
> if g:Tex_MainFileExpr != ''
> exec 'let retval = '.g:Tex_MainFileExpr
> return retval
> endif
If these 4 lines of code are present within Tex_GetMainFileName(), it
sounds perfect.
> You could then define g:Tex_MainFileExpr to be whatever you like. For
> instance, you could use your extended let-modeline function here (if I
> remember the nomenclature correctly).
Well ... This is the nomenclature I used, but I am not sure it is
English-proof.
> How does this sound? Is it sufficient? Or were you thinking of
> something else entirely?
I was thinking of a function that centralizes all this
mainfile-determination heuristic.
=> the functions depending on the project's main-file are easy to
write/maintain.
--
Luc Hermitte
http://hermitte.free.fr/vim/
|
|
From: Srinath A. <sr...@fa...> - 2003-07-25 01:39:38
|
Hi Luc, > > if g:Tex_MainFileExpr != '' > > exec 'let retval = '.g:Tex_MainFileExpr > > return retval > > endif > > If these 4 lines of code are present within Tex_GetMainFileName(), it > sounds perfect. I wonder if I already told you about this, but I implemented the Tex_MainFileExpression we discussed before. I have updated the relevant documentation. Take a look at: http://vim-latex.sourceforge.net/documentation/latex-suite/latex-master-file.html It tells how to use Tex_MainFileExpression. > I was thinking of a function that centralizes all this > mainfile-determination heuristic. > => the functions depending on the project's main-file are easy to > write/maintain. > This is an excellent idea. Initially I was thinking that Tex_GetMainFileName() will always return a filename unlike the present way in which it returns a non-empty string only if a .latexmain file is present. In the future, it will just return expand('%') if a .latexmain is not found... However, there is no good way to make Tex_GetMainFileName also contain logic of whether a 'makefile' exists etc. Srinath |
|
From: Srinath A. <sr...@fa...> - 2003-07-14 06:51:02
|
On Sat, 12 Jul 2003, Mikolaj Machowski wrote: > Candidates are: > I'd like to add completion of commands similar to those implemented > yesterday in TPackage. I would improve usability of Tcommands. > The completion for :TPackage was a good idea. Please update the documentation for the same... Dont worry about the typos :) I will correct the grammar etc. But its important it gets into the manual in some manner. I would think that having custom completion functions for the ones below is also a good idea. But once again, please first write the documentation if possible... I am pretty sure just a single line will do... BTW, we need to sometime finalize the whole part-viewing thing. Its pretty half-baked right now. Also the project thing. Since I ripped out the old code from texviewer.vim, project files are absolutely unused. We should either remove the rest of the code supporting projects or find some other use for it. There is even a non-function menu item under the main latex-suite menu called Project which basically does nothing right now. Thanks, Srinath |
|
From: Mikolaj M. <mi...@wp...> - 2003-07-14 16:57:14
|
On Sun, Jul 13, 2003 at 11:50:50PM -0700, Srinath Avadhanula wrote: > On Sat, 12 Jul 2003, Mikolaj Machowski wrote: > > Candidates are: > > I'd like to add completion of commands similar to those implemented > > yesterday in TPackage. I would improve usability of Tcommands. > > > The completion for :TPackage was a good idea. Please update the > documentation for the same... Dont worry about the typos :) I will > correct the grammar etc. But its important it gets into the manual in > some manner. Really doc entries are necessary? I implemented it because completion was the natural thing. Before making it for TTemplate and TMacro- I think Luc has valid point. Many functions there are redundant, also commands behave inconsistently with commands elsewhere (eg. introduce PromptFor... commands for fast choosing of macros). Proposition: - merge custommacros.vim and templates.vim in one file: macros.vim - move stuff for menus into texmenuconf.vim - add PromptFor system - unify functions. > BTW, we need to sometime finalize the whole part-viewing thing. Its > pretty half-baked right now. Also the project thing. Since I ripped out > the old code from texviewer.vim, project files are absolutely unused. We > should either remove the rest of the code supporting projects or find > some other use for it. There is even a non-function menu item under the > main latex-suite menu called Project which basically does nothing right > now. OK. What project should do: 1. Show in explorer window only project files 2. Could shorten scanning files - scan only files in project (lS cannot "think" about all combinations of placement of files, in more complex situations project will help). 3. Load, unload all files in project, eg. for :bufdo commands 4. Some help in compilation? m. |
|
From: Srinath A. <sr...@fa...> - 2003-07-14 21:57:07
|
On Mon, 14 Jul 2003, Mikolaj Machowski wrote: > Really doc entries are necessary? I implemented it because completion > was the natural thing. BTW, I just found out that the -complete=custom,Foo works only for vim 6.2+. Do we still want to implement this? We will be generating errors for the majority of users now... On vim 6.1, I get an error if I do :com -nargs=1 -complete=custom,Foo Bar E180: Invalid complete value: custom,Foo Bar Srinath |
|
From: Luc H. <her...@fr...> - 2003-07-15 00:30:51
|
* On Mon, Jul 14, 2003 at 02:57:01PM -0700, Srinath Avadhanula <sr...@fa...> wrote:
> BTW, I just found out that the -complete=custom,Foo works only for vim
> 6.2+. Do we still want to implement this? We will be generating errors
> for the majority of users now...
Nice to know!
> On vim 6.1, I get an error if I do
>
> :com -nargs=1 -complete=custom,Foo Bar
>
> E180: Invalid complete value: custom,Foo Bar
IMHO, It is not really an issue. Something like this will do the trick.
if version < 602
:com -nargs=1 Bar
else
:com -nargs=1 -complete=custom,Foo Bar
endif
And i'm sure it is easy to write a wrapper function/command to ease the
definition of such commands.
As a consequence, the auto-completion would be a feature of vim 6.2+
only...
--
Luc Hermitte
http://hermitte.free.fr/vim/
|
|
From: Mikolaj M. <mi...@wp...> - 2003-07-16 08:52:51
|
On Tue, Jul 15, 2003 at 01:20:28AM +0200, Luc Hermitte wrote: > * On Mon, Jul 14, 2003 at 02:57:01PM -0700, Srinath Avadhanula <sr...@fa...> wrote: > > BTW, I just found out that the -complete=custom,Foo works only for vim > > 6.2+. Do we still want to implement this? We will be generating errors > > for the majority of users now... > Nice to know! > > On vim 6.1, I get an error if I do > > > > :com -nargs=1 -complete=custom,Foo Bar > > > > E180: Invalid complete value: custom,Foo Bar > IMHO, It is not really an issue. Something like this will do the trick. > if version < 602 > :com -nargs=1 Bar > else > :com -nargs=1 -complete=custom,Foo Bar > endif I just committed it to the CVS :) m. |
|
From: Mikolaj M. <mi...@wp...> - 2003-07-15 11:46:25
|
On Mon, Jul 14, 2003 at 02:57:01PM -0700, Srinath Avadhanula wrote: > On Mon, 14 Jul 2003, Mikolaj Machowski wrote: > > Really doc entries are necessary? I implemented it because completion > > was the natural thing. > BTW, I just found out that the -complete=custom,Foo works only for vim > 6.2+. Do we still want to implement this? We will be generating errors > for the majority of users now... > On vim 6.1, I get an error if I do > :com -nargs=1 -complete=custom,Foo Bar > E180: Invalid complete value: custom,Foo Bar Ah, yes I checked docs for 6.1 and there is no mention about -complete=custom. But I think this is nice feature and we can have it both ways. Just add checking for v:version. if v:version >= 602 command! ... -complete,custom else command! ... endif BTW I think with 6.3 we should think with breaking backward compability. There will be nice features: - :popup menu (it is already) - "DualHead" editing But we had plenty of time :) m. |
×
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