I have a macro that slurps a markdown file from resources.
It provides a convenient way to provide some content.
But when I edit the markdown file, Figwheel has no way to know that it needs to re-evaluate the macro.
Putting the markdown in a string inside a cljs file is undesirable because strings with newlines get indented by most Clojure editors, and this causes the markdown to be incorrect (leading spaces are meaningful in markdown).
Is there a way to detect/refresh when the markdown file changes? Or a better solution?
Here is a basic example of what I am trying to do:
https://github.com/timothypratley/figwheel-watch-markdown-example
Figwheel's configs allow you to add ::watch-paths which trigger reloading when modification events come up from the file system. You can also use ::hawk-options to poll the files looking for changes, which apparently might be necessary in some environments.
Related
I have some documentation strings embedded within the source code (C/C++ files) as XML tags and I'd like to know what's the most minimal solution to make vim autoclose the tags (closest matching tag).
I've found closetag.vim but is there away to do this neatly without modifying anything but the .vimrc file?
Vim has no built-in support for that, so the closetag.vim plugin is the proper and easiest solution. (I use it myself, too!) Of course, you can develop your own simple mappings (that search backwards for an open tag, get that, drop the attributes, add the slash, and insert that), but:
that will either be very simplistic and therefore often wrong
or ends up with as much complexity as closetag, becoming a reimplementation of that plugin
If some rather strange restrictions (e.g. a custom primitive sync across systems) only allow you to manipulate the ~/.vimrc itself, you could just append the entire plugin's code to it (though I'd recommend against such an ugly hack).
Question
(run-marginalia {})
produces a single file, docs/uberdoc.html
I would prefer it to produce many files in docs/*, one per *.clj file
Motivation:
I really like marginalia. I have recently started using it, and it's causing me to want to write documentation, as impossible as that sounds.
However, I have this problem that whenever I write docs, and refresh, and reload uberdoc.html, I lose the part of the doc I was previously looking at. Thus, I would prefer a system where each *.clj file had it's on *.html file for documentation. Is this possible with marginalia 0.7.0?
Thanks!
There was a mutlidoc functionality in a previous version, but it is not at command line in the latest version. However, by running something like (multidoc! "./docs" (find-processable-file-paths "./src" #"\.clj$") {}) you should get directory of individual files.
https://github.com/weavejester/codox is another Clojure documentation tool (which gives separate pages - see http://number23.github.com/commons-lib/)
I have seen instructions about creating a "skeleton" file in vim. This involves creating the file, naming it "tmpl" plus the extension of the file type you are targeting (ex: tmpl.html), saving it to the "skeleton" directory, and then editing the vimrc file.
But, in MacVim, I don't see a "skeleton" directory anywhere. Googling, etc., has returned no helpful information.
Can someone point me to a helpful tutorial/white paper/whatever to walk me through this process for MacVim?
I am determined to develop some skills with Vim/MacVim!
Thanks
I feel dirty giving this as an answer (because I've never done it), but googlin' gave me this: Vim Recipes: Using Templates.
Seems like you make your own skeleton directory and point the line for your .vimrc file to it.
There are a multitude of vim plugins that can handle this task. I use snipMate to perform tasks like this. You can define snippets for each file type or globally. The best part about the snippets is that you can keep hitting tab while it takes you to each "variable" within the snippet so that you can fill in the missing information quickly.
I'm working on a logging system for my 2D engine, and I'm confused on how I should go about creating/editing the file, and how I should output that file.
I've learned that XML is more of a data carrier rather than a data displayer like HTML is. I've read that I can use XML to HTML converters. One method I've thought about is writing characters to a file in HTML.
Clarity on these matters is what I ask of you, stack overflow.
Creating an XML (or HTML) file doesn't need any special library. Straightforward string concatenation is usually good enough, you may have to encode some special characters (e.g. > into >.
But as Owen says, plain text is a log more common for log files. One reasonable compromise is comma-separated values in a text file, this gives you a little bit of structure without much overhead. For example, the Windows web server (IIS) uses this format by default, and if you have some fields that are output for each line such as timestamp or source filename and line number, this makes it easy to separate those out again.
Just about every log I've ever worked with has been pure text delimited by newlines. If you're going to depart from that, you may want to ask yourself what it is about your logging needs that you want to accomplish with markup.
If you must go the way of markup, I would suggest an XML format that contains a minimal set of markup that would be useful in your situation. You could use XML to capture structure in your log entries (timestamp, severity, and operational code, for example) that would be inconvenient to code for in HTML.
Note that you could also go hybrid and embed some XHTML tags in an XML element whose purpose is to capture displayable text, if you want.
The problem with XML or HTML files is that you cannot append at any time. You have to close the final tag (document tag) properly at the end of writing.
Therefore, it's not a popular format for logging.
For logging, I suggest using one of the existing log engines, such as Apache logger, or, John Torjo's boost log candidate. They will support log levels, runtime configuration, etc.
If you are considering writing logs in XML files, please, stop.
Log files should be simple plain text files, XML-izing it is introducing needless complexity. They are not structured data, they are meant to be read by people, not automated tools.
It all starts with XML logs, and then it goes downhill from there.
I have many source/text file, say file.cpp or file.txt . Now, I want to see all my code/text in browser, so that it will be easy for me to navigate many files.
My main motive for doing all this is, I am learning C++ myself, so whenever I learn something new, I create some sample code and then compile and run it. Also, along these codes, there are comments/tips for me to be aware of. And then I create links for each file for easy navigation purpose. Since, there are many such files, I thought it would be easy to navigate it if I use this html method. I am not sure if it is OK or good approach, I would like to have some feedback.
What I did was save file.cpp/file.txt into file.html and then use pre and code html tag for formatting. And, also some more necessare html tags for viewing html files.
But when I use it, everything inside < > is lost
eg. #include <iostream> is just seen as #include, and <iostream> is lost.
Is there any way to see it, is there any tag or method that I can use ?
I can use regular HTML escape code < and > for this, to see < > but since I have many include files and changing it for all of them is bit time-consuming, so I want to know if there is any other idea ??
So is there any other solution than s/</< and s/>/>
I would also like to know if there any other ideas/tips than just converting cpp file into html.
What I want to have is,
in my main page something like this,
tip1 Do this
tip2 Do that
When I click tip1, it will open tip1.html which has my codes for that tip. And also there is back link in tip1.html, which will take me back to main page on clicking it. Everything is OK just that everything inside < > is lost,not seen.
Thanks.
You might want to take a look at online tools such as CodeHtmler, which allows you to copy into the browser, select the appropriate language, and it'll convert to HTML for you, together with keyword colourisation etc.
Or, do like many other people and put your documentation in Doxygen format (/** */) with code samples in #verbatim/#endverbatim tags. Doxygen is good stuff.
A few ideas:
If you serve the files as mimetype text/plain, the browser should display the text for you.
You could also possibly configure your browser to assume .cpp is text/plain.
Instead of opening the files directly in the browser, you could serve them with a web server than can change the characters for you.
You could also use SyntaxHighlighter to display the code on the client side using JavaScript.
It is pretty much essential that somewhere along the line you use a program to prevent the characters '<>&' from being (mis-)interpreted by your browser (and expand significant repeated blanks into '` '). You have a couple of options for when/how to do that. You could use static HTML, simply converting each file once before putting it into the web server document hierarchy. This has the least conversion overhead if the files are looked at more often than they are modified. Alternatively, you can configure your web server to server the pages via a filter program (CGI, or something more sophisticated) and serve the output of that in lieu of the file. The advantage is that files are only converted when needed; the disadvantage is that the files are converted each time they are needed. You could get fancy and consider a caching solution - convert the file on first demand but retain the converted file for future use. The main downside there is that the web server needs to be able to write to where the converted file is cached - not necessarily a good idea for security reasons. (A minimalist approach to security requires the document hierarchy to be owned by and only writable by one user, say webmaster, and the web server runs as another user, say webserver. Now the web server cannot do any damage because it cannot write anywhere in the document hierarchy. Simple; effective; restrictive.)
The program can be a simple Perl script or a simple C program (the C source for webcode 1.3 is available here).