Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by Tobias Bergsmann View Post
    One feature that I highly enjoy from other IDEs (e.g. VS Code) is the ability to highlight similar strings in my code with selection:
    when I select a string within my code with mouse click-drag or double-click:
    e.g. "variable_temperature" every other instance of that string "variable_temperature" gets highlighted too which is usefull to quckly navigate through my code or check if I used this somewhere already without losing my workflow. This can also be achived with already existing Str+F (find) which shows me other instances of that string but jumps around in the code, which I find rather distracting. I would very much welcome this feature when I edit my do files in the do-file Editor.

    Code:
    gen variable_temperature =. //highlighted when other, similar string is selected
    
    (do other stuff)
    
    rename variable_temperature temp //selected via double-click or mouse drag
    INFO: please remark that here I don't refer to "string" as a datatype, but rather just a piece of text from my code.
    I think this might be one of the new editor features in StataNow 18.5. Not having this version, I can’t confirm.

    Comment


    • @ 435/436. Yes, it is a new do-file-editor feature in StataNow 18.5. There has already been at least one post here on Statalist expressing dislike for it (I happen to agree)--but those of us who don't like it can turn it off by editing our do-editor preferences. Anyway, it's already there for those who want it.

      Comment


      • It would be nice to have something like sdmxuse integrated to download data directly from the source and adjusting it. Unfortunately sdmxuse is not maintained anymore.

        Comment


        • Not disputing #438 in any way, but there's a long history of loosely similar commands breaking because some body changed their protocol, or whatever. Sometimes the change is for good reason and sometimes there is a not so hidden agenda of preferring that users pay for non-trivial downloads and even of trying to frustrate work-arounds.

          The implication of all that is that StataCorp are, and indeed in my view should be, reluctant to implement download commands unless there is every likelihood that a connection is free and simple and stable. Otherwise StataCorp get hassle and bad publicity for a command failing when it is not their fault.

          User-programmers can more easily shrug their shoulders and say "It's broken because the protocol was changed".

          Comment


          • George Ford suggested that I wish I could :

            egen mpg_b = resample(mpg) [ , noreplace block(#) n(#) by(varname) weight(varname) ]

            Also perhaps best to drop 'meta' and replace with something more advanced like the user written 'metan'
            Regards
            Suhail Doi

            Comment


            • Re #438, I tried to recode it, but I never got it to work. I don't think it would be terribly difficult to change. AI could probably do most of it.

              Comment


              • It would be great to have a command in Stata 19 to easily produce dumbbell plots like in R ( https://r-statistics.co/Top50-Ggplot...umbbell%20Plot )

                Comment


                • Originally posted by Bert Lloyd View Post
                  Improvements to graph text, e.g.

                  Aligning subscripts and superscripts in graphs' text elements as requested by John Mullahy

                  allowing "hats" and other decorations over characters as requested by Michael Anbar

                  Ideally there would be a simple way to enter "latex mode", e.g.
                  title("{latex: $\hat{\beta}_{0}^{i}$}")
                  or
                  title("{latex: $\hat{\beta}_{0}^{i}$}")
                  I recently learned that the equivalent of "latex mode" is available in R (in ggplot2 using latex2exp and tikzdevice) and python (using matplotlib). I would love to see this in Stata.

                  Comment


                  • Originally posted by Otavio Conceicao View Post
                    It would be great to have a command in Stata 19 to easily produce dumbbell plots like in R ( https://r-statistics.co/Top50-Ggplot...umbbell%20Plot )
                    For various sollutions see https://journals.sagepub.com/doi/pdf...867X0900900408
                    ---------------------------------
                    Maarten L. Buis
                    University of Konstanz
                    Department of history and sociology
                    box 40
                    78457 Konstanz
                    Germany
                    http://www.maartenbuis.nl
                    ---------------------------------

                    Comment


                    • Make "Execute selection (include)" the default way in which a file is executed when using the "do" keyboard shortcut for a subset of code in a do-file. At least in my work, this is almost always what I want, and people new to Stata almost always trip up on this (and do not get any especially helpful error messages either, to direct them towards the fix) because they expect macros etc defined earlier in the code to remain in memory when they execute a selection. Of course, this should be complemented with an option in the Settings to turn off the behaviour for those who don't like it.

                      Comment


                      • I understand the intent behind #445. This is something that trips up new users all the time, and sometimes even very experienced users. But I wonder how Stata could implement it. For the simple case where a local macro is defined early in a file, perhaps setting the value of a constant, and used later in the selected subset. The do file could scan the file and identify commands that define local macros, and execute them before running the selected subset of code. But what if, between the place where the local macro is defined and the selected subset of code, other code modifies the local macro? And what if those modifications depend on the results of other calculations that do not explicitly use any local macros? I don't see how this could be implemented without silently executing all of the code in the do-file preceding the selected subset--which kind of defeats the purpose of selecting the subset in the first place.

                        Maybe I'm missing something and there is a simple, efficient way to implement this, but I don't think so.

                        FWIW, I think the real problem is the decision that was made in the earliest days of Stata to allow references to undefined local macros, and interpret them as null strings. Had that not been allowed, it would have been possible to give a very informative error message in the situation where a local macro in a selected subset is encountered, but its definition is not in the selected subset: "local macro whatever undefined." While that would still leave some inconvenient situations in very long do-files, at least the user wouldn't be left puzzled by some other error message that is downstream of the interpretation of the undefined local as a null string.

                        To be clear: had I been Bill Gould, I would never have allowed references to undefined local macros in the first place. (Of course, explicitly defining a local macro to be a null string would be perfectly fine.) But I do think it is too late to change that now: too much existing code depends on this behavior and would be broken were it changed.

                        Comment


                        • Clyde Schechter What I am requesting is more trivial than what you are perhaps imagining. I am merely asking for existing functionality to be implemented as a default (when you use the keyboard shortcuts for "do" or "run" -- which I imagine is what the vast majority of people use to execute do-files, rather than clicking on the button) rather than by having to manually select the relevant option from the "Do" button at the top-right of the editor window. And yes, it would not solve the entire problem (as you have pointed out), but it would be a considerable improvement over the current scenario: intuitively, I think people understand why some code is not running correctly when elements of it depend on preceding code that they have not executed. However, the especially puzzling thing they encounter in the current scenario is that they have just executed (piece-wise) every preceding line of code they wrote, and so they expect all local macros to be in memory, just like it is with variables, matrices and other constants, but this is not actually so.

                          And I completely agree -- I have never been fond of the design choice to evaluate undefined locals as empty strings, though I have often tried to defend it as a feature rather than a bug while teaching Stata. But yes, it's too late to change that.

                          Comment


                          • Like in any other compiler or editor:
                            In the command module - Re-paste the last command with the <cursor up> key or any other key.

                            This would save endless copying from above and re-pasting commands when you want to make similar statements with small edits or when correcting typos in commands.

                            Comment


                            • The Command window already has this functionality, Mathias Brandt . For instance, on a Mac, I can do it by pressing Fn + the up/down keys. There would be similar possibilities on a Windows or Linux machine -- perhaps Page Up / Page Down?

                              Comment


                              • Hemanshu Kumar is right. see
                                Code:
                                help keyboard
                                PrevLine ---- PgUp or Ctrl+R ---- Retrieves a previously typed line. You may press PrevLine multiple times to step back through previous commands.
                                NextLine ---- PgDn or Ctrl+B ---- The inverse of PrevLine.

                                Comment

                                Working...
                                X