I am working on a Firefox extension it is a context menu for automating bbCode, HTML, MarkDown, etc.
It is functional now, but I have a file which is the size of the rest of the code combined, an Excel spreadsheet. (Yes, I know, lame)
I use it as a database for organizing the menu IDs, arguments, internationalization, etc.
It's useful, for me at least, and I want to make it available, but it is not properly a part of the application, it should be a part of the background documentation.
Is there a way in Github/Git to separate documentary files from those that a part of execution of the code?
I've looked through Github, and I haven't found a spot (with revision control) to put this.
Related
To manage your bibliography and in-text citations, which tools are best to use in Emacs? I am pretty confused about for instance helm-bibtex, org-ref, and ebib. Are these different packages for the samae thing? Thanks!
org-ref: a reference management system that integrates tightly with org-mode. I think of it like a lightweight Zotero but fully inside emacs (eg you can edit bibtex files, insert citations, search/download PDFs for references, insert bibliographies, etc). The youtube video on the Github page does a pretty good job explaining what it does and its intended workflow.
helm-bibtex: a search tool for .bib files. Execute helm-bibtex and it presents a list of whatever .bib files you configure it to search. When you 'select' something you have the option of navigating to the URL, opening the PDF, inserting the entry as a citation, inserting the BibTeX entry, etc. Also there is another command called ivy-bibtex which is confusingly part of the helm-bibtex package which does the same thing but with ivy. Furthermore, org-ref depends on helm-bibtex so consider the features of the latter to be a subset of the former.
ebib: as far as I can tell this is separate from the other two but looks like it overlaps with org-ref (or at least it has the ability to download PDFs, insert citations, follow URLs, search .bib files, etc). The main difference is that it appears the intention for ebib is to provide a nice tool for editing .bib files themselves, although it can do more than just that.
FWIW I personally use Zotero for managing my .bib files and then search/insert from them with ivy-bibtex/helm-bibtex when writing. I have ebib and org-ref half-configured but I never really needed to use them given that Zotero makes up for alot of the features that don't directly involve writing a manuscript. I also prefer to write in straight LaTeX rather than use org-mode's export functionality (just personal preferences), so this also removes the incentive for me to use org-ref since it seems geared toward writing in org-mode itself.
You can obviously do whatever you want just using Emacs packages and not rely on Zotero at all, but that should give a sense of what functionality each package provides.
I am using libHaru (by including the source in my C++ code) to generate PDF files. I am hoping to make these PDF files accessible by adding "tags" (aka "structure tags"). From what I can see in the documentation and source code, libHaru does not support this. Can someone confirm that libHaru indeed does not support tags? And if it's not supported directly, I wonder if there is a way to add tags by modifying the libHaru code? Has anybody done this?
I looked through the 22 page manual for libHaru, and there was no mention of tags, so I think it's safe to assume that it doesn't support tagging.
Attempting to make any library tag PDFs (and do it well) would be a non-trivial task. You'd essentially be re-inventing the wheel. Consider the fact that Adobe Acrobat Pro is only just mediocre at tagging PDFs and requires a ton of human intervention to get it right.
There is a product called CommonLook Dynamic that is made for creating accessible PDFs from live data on a webserver, but I can't vouch for it myself. I have used other products from this company, and they've been very good, but they're not at all cheap.
Generally speaking, PDF tagging is often a very complex thing. To make it work with an automated algorithm, the source code formatting has to be perfectly formed and dead simple. If your source material is at all complex or malformed, it won't come out right.
As an example, it's not possible for PDF generation software to do a good job at things like crafting good alt text for images, creating useful PDF metadata, or tagging complex tables. These are things that require human intervention.
I want to upload a class-diagram to a public repository on GitHub.
Is there any tool which is considered to be a convention for this purpose?
Currently, I am using Google Docs, from which I can export a PDF.
Someone has suggested for me to use https://www.draw.io/, from which I can export an XML (which would be a lot more suitable for version control, since it is pure text), but I don't know whether or not this tool is "well accepted" across the community.
All versions control systems work with text files. PDF is not a text file. Forget it. It is the same as putting exe files under version control. VCSs work with source files, don't forget this.
All diagrams editors has inner representations of diagrams in some sort of text file. Eclipse UML editors use XML. So, the versions control systems can easily take these files and work with them.
The problem comes when you have conflicts. You will have to resolve them reading and understanding the inner language of the diagram representation. It could be very difficult.
So, it is possible, but try to minimize the conflicts.
I'd really like to get a CRM solution under source control but there are a lot of issues. I was excited to see the SolutionPackager tool - thinking MS finally gave us a way to do this. However the tools to export the solution, extract it to files and check it into source control are not integrated. I'm working on a C# project that ties everything together because it's easier to work with the APIs in a single C# solution than deal with a combination of command line utilities such as tf.exe, PowerShell commandlets and plain old .cmd files.
Source files for plugins and Silverlight pages are easy to deal with but I'm looking to get all of the customizations under source control. SolutionPackager works well for tracking customizations made in the CRM interface, but fails in a lot of other areas. I want to create VS solutions for my web resources and reports but I have issues with the VS project and solution structures. SolutionPackager expects to find things where it puts them for repackaging and I'm sure it would not like to see a bunch of .sln, .csproj and .vspscc files interspersed with them.
I figured putting the VS solutions in a separate folder would be the answer but it's not easy. If I create a project for my web resources and try to put my existing .html, .css and .js files into it it wants to copy those into the project folder. I have to remember to use "Add As Link" each time. Worse yet, if I try to do the same with SSRS reports, the "Add As Link" feature isn't even available.
Has anyone done this successfully? I'm open to any suggestions.
I have seen below link but i have not get chance to implement it.when i have try it will post information.
http://blogs.msdn.com/b/crm/archive/2013/05/17/release-alm-for-microsoft-dynamics-crm-2011-crm-solution-lifecycle-management.aspx
hey everyone, we just added a nightly action to process the entire source tree with doxygen and place the output onto development webserver.
We also already have a sharepoint structure which holds design documents for various modules/projects. Currently, the level at which we are keeping this documentation is relatively high. We discuss structures of modules and talk about the major classes, but never go down to the individual method level. I wanted to bridge that gap by having hyperlinks in the SDS word documents that would point to doxygen output.
I noticed the links look like this:
http://example.com/docs/ProjectName/d4/d98/class_c_reader.html
http://example.com/docs/ProjectName/d4/d16/class_c_stream.html
The part that sketches me out a bit is "d4", "d98" and "d16" strings in the path. If I copy these links and create the hyperlinks, does anyone know if these URLs are guaranteed be preserved in the future. As I said, entire doxygen output gets regenerated nightly.
You can disable the d4/d98 subdirectories by disabling CREATE_SUBDIRS in the doxygen configuration.
Whether the name of the HTML files will stay the same I do not know for sure but from what I have seen when using doxygen it seems so. If you want to know for sure you can always look at the doxygen source.
Probably these links will not stay permanent.
Furthermore, Doxygen has a XML representation of the generated documentation but even this interface resp. the corresponding DSD has been changed with new releases of doxygen. This is quite frustrating, as we had used the XML representation for a similar application with the assumption that the structures would be kept identical with every new release.