This is primarily for StataCorp, but I've sprinkled
a few comments.
Nick
[email protected]
Gawrich Stefan
> 10)
> Partial selection & copy of the review window content. No big
> hassle but
> sometimes I would like to copy some lines from the review window to a
> do-file, without having to copy the whole bunch. "#review" is
> of some help
> but the result comes with line numbers.
I can do this fairly easily under Windows.
> 8)
> Not necessary, but nice: Improved editor features for the Stata editor
> (syntax highlighting, advanced search and replace...).
The word is that syntax highlighting is not going to happen. It
conflicts with the idea(l) of -doedit- as a minimal editor and
arguably the people who want it most are already using serious
editors. (Don't shoot the messenger on this one!)
> 7)
> .ex
> "no; data in memory would be lost"
> "Stata, please leave that to me, please close whenever I want to."
> (It is certainly no big thing to write "ex,clear" or click
> twice. But I
> don't want software to hinder my PC to shut down when I shut
> it down. This
> might be o.k. with office software or a editor as the user
> must decide to
> save or discard changes after each working session. But for
> me working with
> data is different: I don't want to save every change in the
> dataset I need
> for some analysis. So most of the time at the end of a
> session I have an
> altered dataset but I don't care.)
Sure, but StataCorp aren't going to hand you a gun.
More importantly, it is easy to do it yourself.
Here is -bye-, written once, used thousands of times by me.
*! NJC 1.0.0 3 June 1998
program define bye
exit, clear STATA
end
> 6)
> Nearly same thing as (7)
> To my mind all options (like ",force", ",clear", or
> ",replace") to prevent
> data loss are of no real use. Or does anybody use e.g. "save" without
> ",replace" on a regular basis? When I write a command I want it to be
> executed. So options to hinder the execution under certain
> circumstances
> should be options, not standard. An alternative especially
> for beginners
> would be a general "Warn me, if a command does destructive
> altering of data"
> Stata setting, that could be switched on or off. Right now I need a
> "security option" to drop duplicates or overwrite data files
> but I'm able to
> "collapse" or even "erase" files without.
Hmm, but I think you really are wrong on this. The fact that you
too want some things to be safe shows that there is a need. Why
should the line be drawn just where you want it? But as you say, it
is the same as 7), so write your own wrappers to live dangerously.
> 4)
> Improvement of the Stata website search engine. (because of
> (3) I depend on
> it)
> Recently I did a research on "parallel lists" and the Stata
> main page search
> gave me nothing of value. Later I was pointed out to the
> Stata-FAQ-Article
> "How do I process parallel lists?" It seems that each part
> (website, FAQ,
> statalist archiv, bookstore) can be searched, but only one
> after another.
I guess the main issue is upstream of this, in keywords. StataCorp
are _always_ willing to fix keywords.
> 3)
> My working place is part of a statewide network with a
> central firewall,
> which does not allow any net install or search (Error R672).
> I don't know how frequent this problem or if and how it can
> be solved (our
> firewall config cannot be altered).
> Ado-updates from Stata come as zip-files, so local installation is no
> problem. Perhaps third party ado-provider like the
> ssc-archive could also
> provide a cumulative zip-archive of ado-files at least once a
> year or so if
> they experience a lot of manual downloads.
No on SSC. This really twists the understanding of what SSC
is for. It is less than the sum of its parts! That is, there
really is a lot of stuff on SSC that you wouldn't (shouldn't) want
messing up your Stata. (The most frequent downloads include
much stuff _long since in official Stata_.)
Nor should you inflict on anyone the
responsibility of deciding what is valuable. Archivists are
not historians, still less politicians.
> 2)
> Improved partial do-file processing: During data analysis I
> often run only
> parts or single commands of do-files. Especially when macros
> are involved I
> often need more than one part of the do-file (so the locals
> definitions from
> the beginning and some commands from somewhere in the file).
> So I have to
> copy&paste the parts together to get them running.
>
> I would like to have the opportunity to declare some kind of do-file
> modules, which could be referenced from the command line, a
> second do-file
> or even from the top of the same do-file.
> Something like this:
> do test.do [, {run|hide}(definitions, regress, outfile)]
> where "definitions" is the content between "module
> definitions start" and
> "end module" in test.do
>
> Without the run/hide option everything should be executed.
> Todays workaround
> would be to turn each module into a do-file and reference
> them from another
> do-file but personally I prefer to have it all in one well
> documented file.
Sounds like lots of minuses as well as pluses to that.
> Not to forget my Stata top ten list:
>
> 10)reshape
> 9) levelsof
> 8) egen
> 7) graphs
> 6) foreach, forvalues, for
> 5) _n & _N
> 4) epitab
> 3) it's so fast...
> 2) all the kind people here a Statalist
> 1) Tmap !!!
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
