For reasons I hinted at in a previous post, a complete list of all
commands is elusive to the point of impossibility. Even if you think I
am exaggerating, I believe neither StataCorp nor any sane user would
undertake to try to compile _and maintain_ such a list.
As a matter of absolute principle, StataCorp are not responsible for
user commands! Making it easier, via -findit-, for you to find what
there is is a different story.
I really don't believe that knowing all possible commands is crucial for
syntax highlighting. Indeed the crudest highlighting schemes based on
command names only are primitive to the point of uselessness. A much
better approach is to highlight everything but command names, so that
commands are implied as the complement.
That is not to say that program name clashes may not and will not occur.
But they will occur because many programmers won't check, regardless of
what resources are available.
In fact, me too: if I start to write a new program, I don't care two
hoots whether the same program name is in else somewhere else on the
planet. And if there is a clash that becomes evident, well, just change
one name or the other when it occurs.
In general, I can see that materials of the kind specified here would
satisfy the curiosity of a few users like Sergiy but I find it difficult
to imagine that the total benefit would match the effort.
Nick
Sergiy Radyakin
maintanance files will help when compiling a list of built-in and
supplied-with commands.
look e.g. at ...\Stata10\ado\base\c\cmddlg.maint
and in general at *.maint
IMHO the lists should be separated into language constructs (program,
end, while, if, etc), built-in commands (basic bricks), and everything
else (ado). I guess the students wanted to know what tools are at
hand, available for work, in an attempt to reduce the open-end
question "which command to use?" to a multiple choice question "which
of these to use?".
-which- and -findfile- are not useful for the purpose. because in
order to check whether the command exists or not you must have an idea
of what it may be called. I've seen a few people who would _suspect_
existence of xtivreg2. (in other words this is precisely the case
where in order to ask a question, you need to know the answer).
About 5 years ago I've seen in library a 3-volume encyclopedia (I
guess about 5000pages in total) of all software released in a
particular year (e.g. in 1990, don't remember now). Although an
immense effort was done to sort and describe all those programs, it
was surely neither complete nor accurate.
However, I see a very practical need for such a list of Stata
commands: for the purpose of syntax highlighting. It would
significantly improve the readability of the programs, because current
highlighters AFAIK are based on Stata's 6-7 syntax (at least mine is).
It may also help preventing name collisions.
Regards, Sergiy Radyakin
On Fri, Sep 19, 2008 at 12:35 PM, Nick Cox <[email protected]> wrote:
> -findit- does not guarantee to find everything in the public domain.
For
> example, -findit- will not find programs published informally within
> Statalist postings, such as yours this week.
>
> Nick
> [email protected]
>
> Martin Weiss
>
> Agreed! Would a combination of -findfile-, -which- and -findit- be
> sufficient?
>
> Nick Cox
>
> -which- tells whether a command is visible to Stata given your Stata
> installation and your current working directory. That is only a subset
> of existence "as we know it, Jim".
>
> Martin Weiss
>
> An alphabetical list is pointless. If it is all about the mere
existence
> of
> a command, -which- is the way to go...
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
