Updated markstat on SSC

[German Rodriguez]

Thanks to Kit Baum markstat 2.4 is now available on SSC. This is a maintenance release fixing a couple of issues: (1) temporary file names are now properly enquoted, so they work when the username includes a space, and (2) generating PDF via LaTeX uses the current linesize setting to accommodate output wider than 80 characters, as was done before for other output formats. Hat tips to Erik Ruzek and Rocío Valdebenito for reporting these issues.

[JeongHoon Min]

I really love markstat since it integrates Stata results into Markdown (not interrupting Markdown workflow at all).

But I think it would be much better if markstat supports:
(1) Markdown GFM compatibility, considering the fact that there do exist Stata users on github;
(2) [TOC] or __TOC__ flags which generate a table of contents & anchors automatically;
(3) option to use custom css file.

For (3), I know I can modify markstat.css in my ado directory but I want to preserve default css file & do not want to lose my custom css via updating package.

Thank you for awesome package, German Rodriguez.

[German Rodriguez]

Thanks JeongHoon Min for the feedback and suggestions for improvement. A few brief comments on the points you raise:

(1) I am not exactly sure what you would like to see here. GitHub-Flavored Markdown (GFM) is supported by Pandoc as input and output, but is also very similar to Pandoc's own dialect. Are there any features of GFM that you would like to use in a -markstat- script, but are not supported at the moment?

(2) I agree that it would be nice to have a -toc- option, particularly for large documents. I would also like to produce an optional list of tables and list of figures, not to mention support for numbering and cross-referencing sections, tables, figures and equations, without having to use LaTeX. These are all features under active consideration for the next major release.

(3) News are better here. You can already use a custom css file without replacing -markstat.css- in the ado plus folder. Just put your customized -markstat.css- in the current working directory. The -markstat- command will look for the css file in the current folder before searching the ado path.

[JeongHoon Min]

Thank you for quick and kind answer, German Rodriguez.

For (1),
when I wrote:

<a id="Headings"></a>
## 1. Headings

markstat does not recognize Headings as headings, i.e., prints black normal-weight ## Headings instead of blue bold Headings.

It was solved by

<a id="Headings"></a>

## Headings

and I thought that this phenomenon regarding line-break has something to do with GFM spec. Sorry for confusing you.

Now I am really looking forward next release of markstat. Thanks for letting me know how to use custom css.

[German Rodriguez]

Good to hear (1) was not a GFM spec issue. As you discovered, headings must be preceded by a blank line. Note that you may specify the id on the heading itself by coding

## Headings {#id}

where -id- is a unique id. If you omit the id, Pandoc will generate one from the heading. This way you don't need the -a- tag, which in HTML5 is used only for hyperlinks, not anchors.

[JeongHoon Min]

Thank you for helpful information, German Rodriguez (though I follow -a- tag because of TOC generator).

I found another problem, not sure this springs from -markstat- or R, but it seems that if R code blocks include non-English comments, -markstat- fails to convert the document.
This error does not occur when I render the exact same document with -rmarkdown- in R. And .rout file generated by -markstat- shows that R code blocks were partly executed(but non-English comments were broken in results and error message of -markstat- also pointed out broken characters). But this is neither important nor urgent problem since non-English comments in Stata code blocks work perfectly. Thanks!

Add: My guess might not be correct and this link is the file in question: https://www.dropbox.com/s/mn0kjmb6w8...nonE.stmd?dl=0 and following links are text data files required within code: (1) https://www.dropbox.com/s/hzd3gen34b...ata01.txt?dl=0 ; (2) https://www.dropbox.com/s/t71yhuuqi6...ata02.txt?dl=0

[German Rodriguez]

Hi JeongHoon Min. I tried downloading your file from dropbox, but my system tells me it is not encoded in UTF-8, and using a Latin 1 encoding doesn't do the trick. I wonder if you could provide a minimal example that causes the problem. If I understand the issue, all I would need is a non-english character in a comment.

So I tried using Yihui Xie's name. The script below includes it in Markdown, a Stata comment and an R comment:

% Non-English Characters

Trying  谢益辉

```s
    // comment  谢益辉
    di 2 + 2
```

```r
    # comment  谢益辉
    2 + 2
```

And all three work fine, producing the output below

Perhaps I misunderstood the problem?

[JeongHoon Min]

German Rodriguez Sorry for confusing you. I splitted & tested code chunks and found that error springs from code when assigning non-English characters not from comments.

```{r}
x<-sample(c("low", "mid", "high"), 10, T, prob=c(0.2,0.5,0.3))
y<-factor(x)
x[10]<-"높음" # this was the source of problem
y[10]<-"높음"
```

But this problem is highly likely to be related to R itself(in Korean community, the fact that R does not handle non-English(i.e., Korean) characters well is a kind of conventional wisdom). Sorry again to bother you...

[German Rodriguez]

I agree with JeongHoon Min that this is an R issue, not related to -markstat-. However, your example suggests that it may not be related to non-english characters either.

You define x as a string vector that takes the values "low", "mid" and "high". Because it is a string vector, one can assign "other" or even "높음" to an element without a problem. In fact, the line you indicate as the source of a problem generates no error on my system.

You then define y as a factor with levels "low", "mid" and "high". If you now try to assign "other" or "높음" to an element of y you will get an error that says "invalid factor level, NA generated". A factor is coded as an integer vector mapped to the levels, and neither "other" nor "높음" is a valid level.

But I think we are getting off subject now