Re: A few questions(accessing the Vim code in VimL)
On Feb 9, 12:35 am, Tony Mechelynck antoine.mechely...@gmail.com
wrote:
I suspect there's no way to do any of this, but I thought I'd ask before
I took a more...cumbersome route. Oh, also what is this declaration
structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043 list_hashtable_vars(current_funccal-l_vars.dv_hashtab,
2044 (char_u *)l:, FALSE, first);
2045 }
I've never seen that in C before. Declaring variables after the
arguments but before the body?
--Whaledawg
It's not variables, it's the arguments: int *first here means that
first, the argument, is a pointer to int. I'm told doing it this way
rather than static void list_func_vars(int *first) makes the source
more portable among various C compilers.
IIUC, the Vim C source obeys the C89 standard, as shown by this line
which I see in the logfile where I saved the stdout/stderr of configure:
checking for gcc option to accept ISO C89... none needed
not exactly obeys - Vim is relying on C89 to use pre-standard
syntax.
That's called legacy C, and iirc is not supported in the current
standard.
Besides that drawback, using legacy C provides less stringent type-
checking
and other compiler diagnostics.
It was for that reason that I phased out my own use of legacy C ten
years ago.
(of course, if your program has no bugs, you don't need compiler
checking -
but I've never seen an interesting program without bugs)
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
Spencer Collyer wrote:
On Sun, 8 Feb 2009 20:40:09 -0800, Garrett Whelan wrote:
... Oh, also what is this declaration structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043 list_hashtable_vars(current_funccal-l_vars.dv_hashtab,
2044 (char_u *)l:, FALSE, first);
2045 }
I've never seen that in C before. Declaring variables after the
arguments but before the body?
That is the original style of function declaration in C, from back in
the KR first edition days.
Yes. Note, though, they are not variables being defined (or even
declared), but the types of the function arguments being declared. You
can't just define variables there, it is the place to declare the
arguments' types, though.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
RE: A few questions(accessing the Vim code in VimL)
It cannot work reliable with redir. Think of options with possible trailing whitespace, like 'listchars', 'showbreak', 'breakat', etc. There is no backslash for escaping in the output. I see your point. I've changed the script to only parse the option names (much easier to do). The option value is now set via option. See the attached script. Cheers, David --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- temp.vim Description: temp.vim
Re: A few questions(accessing the Vim code in VimL)
Larson, DavidX S schrieb: It cannot work reliable with redir. Think of options with possible trailing whitespace, like 'listchars', 'showbreak', 'breakat', etc. There is no backslash for escaping in the output. I see your point. I've changed the script to only parse the option names (much easier to do). The option value is now set via option. See the attached script. Cheers, David Here is another way to get the option names, it's basically :set C-A func! GetOptionNames() exec sil normal! :set \C-A'\C-B\C-Right\C-U\Dellet str='\r return split(str) endfunc let optionlist = GetOptionNames() The output is almost sorted and includes all and termcap as the first two entries. -- Andy --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: A few questions(accessing the Vim code in VimL)
Here is another way to get the option names, it's basically :set C-A I like it, but I can't find the doc entry for C-A. Do you know where it is? David --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On Mon, Feb 09, 2009 at 03:08:08PM -0800, Larson, DavidX S wrote: Here is another way to get the option names, it's basically :set C-A I like it, but I can't find the doc entry for C-A. Do you know where it is? :help c_CTRL-A You may also want to read :help help-context -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: A few questions(accessing the Vim code in VimL)
On Mon, Feb 9, 2009 at 5:56 PM, Andy Wokula wrote: Here is another way to get the option names, it's basically :set C-A snip The output is almost sorted and includes all and termcap as the first two entries. Wow. That is quite clever, I definitely wouldn't have thought of that. Nicely done. For the termcap options, you'd also want to do a :set t_C-a for getting each of the termcap options... Though I don't see any easy way to use this to get the :set-termcap stuff... Ie, :set M-x=foo Any ideas on that one? I don't have time to play with it ATM, but I'm definitely curious about it. :-) ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On 10/02/09 03:28, Matt Wozniski wrote: On Mon, Feb 9, 2009 at 5:56 PM, Andy Wokula wrote: Here is another way to get the option names, it's basically :setC-A snip The output is almost sorted and includes all and termcap as the first two entries. Wow. That is quite clever, I definitely wouldn't have thought of that. Nicely done. For the termcap options, you'd also want to do a :set t_C-a for getting each of the termcap options... Though I don't see any easy way to use this to get the :set-termcap stuff... Ie, :setM-x=foo Any ideas on that one? I don't have time to play with it ATM, but I'm definitely curious about it. :-) ~Matt :set ^A (without the quotes, and where ^A means press Ctrl-A) gives termcap options (shown as t_xx) and also conventional names: after t_ku (in Console mode) or t_ZR (in GUI mode) I see Space Tab Tab NL etc. until Drop Nul SNR Plug. They don't appear alphabetically, and I've no idea why Tab is shown twice. M-x normally means x + 0x80 (which, in Latin1, means ø) or, sometimes, Escx. You can :set it but if you haven't you can't interrogate it: :set M-x? returns error E518 unless you've explicitly set it to something. I don't expect such a :set statement to have any useful effect for meta+printable keys anyway. For standard keys such as F5, Home, etc., the S- , C- , M- , etc., compounds are not listed but I suppose you can deduce them from the names that are. Best regards, Tony. -- Bell Labs Unix -- Reach out and grep someone. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
A few questions(accessing the Vim code in VimL)
I would like to be able to access all the variables at a given time in Vim
without necessarily knowing what they are. Basically everything you would
see if you typed :let and :set. So in increasing order of difficulty
1. Is there a way to redirect the output from :let and :set? It would be
pretty simple to parse that up, but I can't figure it out.
2. Is there a way to call functions in the Vim code from VimL? Browsing
through the source I see list_hashtable_vars seems to have the info I need.
3. Is there a way to access the actual C data structures from VimL? If I
could read the various hashtables myself I could do what I needed.
I suspect there's no way to do any of this, but I thought I'd ask before I
took a more...cumbersome route. Oh, also what is this declaration structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043 list_hashtable_vars(current_funccal-l_vars.dv_hashtab,
2044 (char_u *)l:, FALSE, first);
2045 }
I've never seen that in C before. Declaring variables after the arguments
but before the body?
--Whaledawg
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On Sun, Feb 8, 2009 at 11:40 PM, Garrett Whelan whaled...@gmail.com wrote: I would like to be able to access all the variables at a given time in Vim without necessarily knowing what they are. Basically everything you would see if you typed :let and :set. So in increasing order of difficulty There's no easy way to get all options, afaik. All variables, though, isn't too tough: you can treat the scopes as a dictionary keyed by names of values in that scope. So, for example: for [var, val] in items(g:) echo Global variable \ . var . \ is \ . val \ The type might change, so we unlet it before it's assigned again unlet val endfor Is there a way to redirect the output from :let and :set? It would be pretty simple to parse that up, but I can't figure it out. Yes. :help :redir - but, again, probably not what you want to do. Is there a way to call functions in the Vim code from VimL? Browsing through the source I see list_hashtable_vars seems to have the info I need. Is there a way to access the actual C data structures from VimL? If I could read the various hashtables myself I could do what I needed. No... those would be awfully strange features for a scripting language... I suspect there's no way to do any of this, but I thought I'd ask before I took a more...cumbersome route. Oh, also what is this declaration structure: KR style C. Vim's old. Back when ANSI C was still not so popular. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On 09/02/09 05:40, Garrett Whelan wrote:
I would like to be able to access all the variables at a given time in
Vim without necessarily knowing what they are. Basically everything you
would see if you typed :let and :set. So in increasing order of difficulty
1. Is there a way to redirect the output from :let and :set? It would
be pretty simple to parse that up, but I can't figure it out.
:help :redir
2. Is there a way to call functions in the Vim code from VimL?
Browsing through the source I see list_hashtable_vars seems to
have the info I need.
You cannot access arbitrary functions in the binary code from vimscript.
The only things you can execute from vimscript are vimscript functions,
ex-commands, and keybindings, see
:help function-list
:help ex-cmd-index
:help index.txt
:help :normal
You can view the C _source_ code if you've downloaded it, but of course
this is done by loading the actual source files in the editor, not by
disassembly.
3. Is there a way to access the actual C data structures from VimL?
If I could read the various hashtables myself I could do what I
needed.
AFAIK, there isn't -- nothing equivalent to the PEEK and POKE functions
available in some versions of BASIC.
I suspect there's no way to do any of this, but I thought I'd ask before
I took a more...cumbersome route. Oh, also what is this declaration
structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043 list_hashtable_vars(current_funccal-l_vars.dv_hashtab,
2044 (char_u *)l:, FALSE, first);
2045 }
I've never seen that in C before. Declaring variables after the
arguments but before the body?
--Whaledawg
It's not variables, it's the arguments: int *first here means that
first, the argument, is a pointer to int. I'm told doing it this way
rather than static void list_func_vars(int *first) makes the source
more portable among various C compilers.
IIUC, the Vim C source obeys the C89 standard, as shown by this line
which I see in the logfile where I saved the stdout/stderr of configure:
checking for gcc option to accept ISO C89... none needed
See an explanation of Vim source coding style at :help coding-style,
and this particular case somewhat below :help style-examples, in the
section starting Functions start with:.
Best regards,
Tony.
--
Pure drivel tends to drive ordinary drivel off of the TV screen.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On Sun, Feb 8, 2009 at 9:13 PM, Matt Wozniski m...@drexel.edu wrote: On Sun, Feb 8, 2009 at 11:40 PM, Garrett Whelan whaled...@gmail.com wrote: I would like to be able to access all the variables at a given time in Vim without necessarily knowing what they are. Basically everything you would see if you typed :let and :set. So in increasing order of difficulty There's no easy way to get all options, afaik. All variables, though, isn't too tough: you can treat the scopes as a dictionary keyed by names of values in that scope. So, for example: for [var, val] in items(g:) echo Global variable \ . var . \ is \ . val \ The type might change, so we unlet it before it's assigned again unlet val endfor Is there a way to redirect the output from :let and :set? It would be pretty simple to parse that up, but I can't figure it out. Yes. :help :redir - but, again, probably not what you want to do. Perfect. Either of those should be able to get me what I want(with a little massaging). And I had no idea that each scope was just a dictionary, genius. Is there a way to call functions in the Vim code from VimL? Browsing through the source I see list_hashtable_vars seems to have the info I need. Is there a way to access the actual C data structures from VimL? If I could read the various hashtables myself I could do what I needed. No... those would be awfully strange features for a scripting language... For a pure scripting language I'd agree, but this is a scripting language in an environment. Allowing direct access to core functions/variables allows huge flexibility *without having to recompile the code*. When using UnrealScipt you can even extend classes from the Unreal Engine. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On 2009-02-09, Matt Wozniski m...@drexel.edu wrote: On Sun, Feb 8, 2009 at 11:40 PM, Garrett Whelan whaled...@gmail.com wrote: I would like to be able to access all the variables at a given time in Vim without necessarily knowing what they are. Basically everything you would see if you typed :let and :set. So in increasing order of difficulty There's no easy way to get all options, afaik. :set all Regards, Gary --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On Sun, 8 Feb 2009 20:40:09 -0800, Garrett Whelan wrote:
... Oh, also what is this declaration structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043 list_hashtable_vars(current_funccal-l_vars.dv_hashtab,
2044 (char_u *)l:, FALSE, first);
2045 }
I've never seen that in C before. Declaring variables after the
arguments but before the body?
That is the original style of function declaration in C, from back in the KR
first edition days.
Spencer
--
Eagles may soar, but weasels don't get sucked into jet engines
7:52am up 56 days 23:12, 1 user, load average: 1.01, 0.97, 0.60
Registered Linux User #232457 | LFS ID 11703
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
