Re: first draft of an RMarkdown export plugin
Hi, I second the suggestion by Thomas. I had the pleasure to use it. For me it was working will. Wouldn't it be nice to have this available via the RKWard git tool you have developed? Kind regards Stefan On October 30, 2018 5:54:43 AM UTC, Thomas Friedrichsmeier wrote: >Hi, > >On Wed, 24 Oct 2018 21:04:18 +0200 >meik michalke wrote: >> did you have the chance to have a look at the most recent version of >> the export plugin? > >sorry, I delayed this, and now the seafile link has expired. > >But why don't you just add it to our git repo. It's not like we cannot >apply any further tweaks once it's in. It's clearly something we want >to have in the main distribution. > >Regards >Thomas
Re: first draft of an RMarkdown export plugin
Hi, On Wed, 24 Oct 2018 21:04:18 +0200 meik michalke wrote: > did you have the chance to have a look at the most recent version of > the export plugin? sorry, I delayed this, and now the seafile link has expired. But why don't you just add it to our git repo. It's not like we cannot apply any further tweaks once it's in. It's clearly something we want to have in the main distribution. Regards Thomas pgpLXWvFCGUXf.pgp Description: OpenPGP digital signature
Re: first draft of an RMarkdown export plugin
hi, Am Freitag, 19. Oktober 2018, 13:30:30 CEST schrieb Thomas Friedrichsmeier: > > when the plugin starts with one of those two options and targenFile > > is not set yet, you can't submit although i believe i've defined the > > "required" rules accordingly. notably, you only have to scroll to any > > other format option and back again to make the submit button > > available. how can i fix that? > > bug. Now fixed in git. yes, awesome. also the new overwrite checkbox in the browser control is exactly what i had in mind. did you have the chance to have a look at the most recent version of the export plugin? viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf signature.asc Description: This is a digitally signed message part.
Re: first draft of an RMarkdown export plugin
Hi, On Mon, 15 Oct 2018 00:55:14 +0200 meik michalke wrote: > Am Sonntag, 14. Oktober 2018, 21:01:22 CEST schrieb meik michalke: > > check out the new version of the plugin, it's pretty great already: > > https://galactica.psycho.hhu.de/seafile/f/37d018e8bb554c3385b2/ > [...] > > - i've also added both "first format" and "all formats" > > features of render() to not be limited by the menu; in fact, i > > think the first is a better default than picking one of the formats > > statically > > i've now also replaced output_file with output_dir for those cases. > but there's one issue i can't resolve: > > when the plugin starts with one of those two options and targenFile > is not set yet, you can't submit although i believe i've defined the > "required" rules accordingly. notably, you only have to scroll to any > other format option and back again to make the submit button > available. how can i fix that? bug. Now fixed in git. Regards Thomas pgp5Z3IjBBvVx.pgp Description: OpenPGP digital signature
Re: first draft of an RMarkdown export plugin
hi,
some further tweaks to the export plugin, most significantly it exports HTML
vignettes properly:
https://galactica.psycho.hhu.de/seafile/f/37d018e8bb554c3385b2/
you should also upgrade XiMpLe and then rkwarddev one more time to the most
recent develop branch:
library(devtools)
install_github("rkward-community/XiMpLe", ref="develop")
install_github("rkward-community/rkwarddev", ref="develop")
(i fixed an issue in XiMpLe autoreplacing "&", "<" and ">" with HTML entities
in the generated XML code, which rendered embedded JavaScript useless if those
symbols are used. code in nodes is now save.)
btw: i noticed that the preview of vignettes produces a fine HTML document,
but RKWard doesn't really render it as a vignette. as far as i know, by
convention vignettes should be configured like
output:
rmarkdown::html_vignette
in the YAML header, and render() should also use "rmarkdown::html_vignette" as
output format. if the two don't match, all further configuration in that
context is skipped, like the presence of a TOC. so the preview can be very
confusing, if you correctly defined a TOC but it just won't show. could you
parse the header between the two "---" for the presence of
"[[:space:]]*rmarkdown::html_vignette" and adjust the rendering accordingly?
also, could you have a look at this:
Am Montag, 15. Oktober 2018, 00:55:14 CEST schrieb meik michalke:
> i've now also replaced output_file with output_dir for those cases. but
> there's one issue i can't resolve:
>
> when the plugin starts with one of those two options and targenFile is not
> set yet, you can't submit although i believe i've defined the "required"
> rules accordingly. notably, you only have to scroll to any other format
> option and back again to make the submit button available. how can i fix
> that?
viele grüße :: m.eik
--
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf
signature.asc
Description: This is a digitally signed message part.
Re: first draft of an RMarkdown export plugin
Hi, On Sat, 13 Oct 2018 21:01:45 +0200 meik michalke wrote: > Am Samstag, 13. Oktober 2018, 13:48:48 CEST schrieb Thomas > Friedrichsmeier: > > - Unless a lot more options get added, I'd suggest to merge the two > > tabs of the plugin. > > yes, i thought about it. i mainly hid the version selection in > another tab to not confuse people with a choice they probably don't > fully understand. support for v1 is there for backwards compatibility > only, it looked like "too important" if it was on the same tab. does > that make sense? I had guessed as much. Well, let's leave it like this for now. Do add a on the second tab, though, to fix the layout. > > - But perhaps you intend to add options for style and colors, for > > instance? > > adding more options would either mean tinkering with the document > itself somehow, or probably use the configuration parameter of > pandoc(), i.e. generating a temporary configuration file. As far as I understand, you can override those using the output_format parameter in render(). Of course that may be more work than it's worth. I was just wondering what further options the plugin _might_ get, eventually. > the browser element currently has it's drawbacks for use as a "save > file" option. i was missing an "overwrite" checkbox for existing > files, and it would have helped to append file extensions > automatically (although that can be kind of worked around by > pre-filling the field as suggested). > > also, even though the element has file extensions set for the input > script, it doesn't apply them to files that were automatically added > because the plugin was launched with the file currently opened. i'm > sure this can be dealt with with JavaScript logic, but i think this > actually belongs to the element features itself -- it should be > marked red when the defined file extensions don't fit the given file, > and the submit button deactivated. I'll have to look into those. Regards Thomas pgpwJEkVtLtz5.pgp Description: OpenPGP digital signature
Re: first draft of an RMarkdown export plugin
Hi, actually I had to look a bit found it because I didn't find it. Then I read the source code and finally 'found' it. Maybe others may have also some thoughts about that. ''special context menu'' is certainly the best practise IMHO. This would keep the interface lean and elegant. BTW, thanks Thomas and Meik that you are working on this! Highly appreciated! Kind regards Stefan On October 13, 2018 8:59:00 PM GMT+02:00, meik michalke wrote: >hi, > >Am Samstag, 13. Oktober 2018, 13:59:34 CEST schrieb Stefan Rödiger: >> indeed a great thing! All tests worked well here. > >that's great to know! > >> A general remark on RMarkdon in RKWard. Methinks, RMarkdown is more >like a >> method/philosophy than just a functionality. Rmarkdown is in data >science >> with R very intensively used. Why not put it as separate menu entry >on a >> prominent place? Right now there is great functionality (the preview >& and >> plugin) and more seems to come. > >interesting thought. but doesn't it make more sense to have the export >menu >for RMarkdown files where all other export options usually are? i.e., i >didn't >even tell you where to look but it seems you were able to find and use >it. > >i can however see that it can be helpful to have a special context menu >if the >currently active editor window is markdown, including a direct launcher >for >the export plugin. so i wouldn't add a new permanent menu category, but >rather >let RKWard detect the file type and produce a context sensitive submenu >like >it already does for R code, help pages or data frames. > > >viele grüße :: m.eik > >-- > dipl. psych. meik michalke > institut f"ur experimentelle psychologie > abt. f"ur diagnostik und differentielle psychologie > heinrich-heine-universit"at d-40204 d"usseldorf -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: first draft of an RMarkdown export plugin
hi, Am Samstag, 13. Oktober 2018, 13:59:34 CEST schrieb Stefan Rödiger: > indeed a great thing! All tests worked well here. that's great to know! > A general remark on RMarkdon in RKWard. Methinks, RMarkdown is more like a > method/philosophy than just a functionality. Rmarkdown is in data science > with R very intensively used. Why not put it as separate menu entry on a > prominent place? Right now there is great functionality (the preview & and > plugin) and more seems to come. interesting thought. but doesn't it make more sense to have the export menu for RMarkdown files where all other export options usually are? i.e., i didn't even tell you where to look but it seems you were able to find and use it. i can however see that it can be helpful to have a special context menu if the currently active editor window is markdown, including a direct launcher for the export plugin. so i wouldn't add a new permanent menu category, but rather let RKWard detect the file type and produce a context sensitive submenu like it already does for R code, help pages or data frames. viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf signature.asc Description: This is a digitally signed message part.
Re: first draft of an RMarkdown export plugin
Hi, indeed a great thing! All tests worked well here. A general remark on RMarkdon in RKWard. Methinks, RMarkdown is more like a method/philosophy than just a functionality. Rmarkdown is in data science with R very intensively used. Why not put it as separate menu entry on a prominent place? Right now there is great functionality (the preview & and plugin) and more seems to come. Regards Stefan On Samstag, 13. Oktober 2018 13:48:48 CEST Thomas Friedrichsmeier wrote: > Hi, > > great! > > On Fri, 12 Oct 2018 21:33:53 +0200 > meik michalke wrote: > > i'm open to suggestions what's missing most or should be done totally > > different. > > First impressions: > - Unless a lot more options get added, I'd suggest to merge the two > tabs of the plugin. > - But perhaps you intend to add options for style and colors, for > instance? > - It would be cool (if possible) if the "Save as"-control was pre-filled > with the input filename + appropriate filename extension. That would > make it so much easier to use in many simple cases. > - Maybe a bit out-of-scope for the time being, but as an idea: Offer to > render a PDF to a temporary file and open it in okular. That would > essentially make it a print (preview) feature. > > Regards > Thomas
