The documentation for scribble (the Racket documentation tool) says that “Cross references within […] documents rendered together are always resolved”, but the file a.scrbl below fails to reference the section in file b.scrbl
a.scrbl:
#lang scribble/base
#secref["sectag" #:doc "b.scrbl"]
b.scrbl:
#lang scribble/base
#section[#:tag "sectag"]{A section}
When compiling them with scribble --html a.scrbl b.scrbl, I get:
Warning: some cross references may be broken due to undefined tags:
(part ("/path/to/b.scrbl" "sectag"))
How do I reference a section in b.scrbl from a.scrbl?
It seems to work if you remove the #:doc argument.
#lang scribble/base
#secref["sectag"]
This might create an ambiguity though if you use the same tags in both documents, so you may have to change tag names or use your own tag prefixes.
I'm not sure why the relative path for #:doc doesn't work as you expect. Maybe it is only used for referring to collection-installed documents.
Related
I am trying to use Racket to "require" a file whose name is in Chinese. The compiler gives an error that test.rkt:2:3: require: bad module-path string at: "./lib/算数.rkt" in: (require "./lib/算数.rkt") #(13 14), but it does work when I rename 算数.rkt into math.rkt. So I am sure that the error occurs because the filename is not in English. Any method I can use to solve the problem?
I was able to replicate this, and while I didn't dig deep into the documentation to see if there's some listed restriction about what codepoints can be in a module path, I did find a workaround:
(require (file "./lib/算数.rkt"))
From the documentation for (file ...):
Similar to the plain rel-string case, but string is a path—possibly absolute—using the current platform’s path conventions and expand-user-path.
Other documentation says
This form is not portable, and it should not be used when a plain, portable rel-string suffices.
Since the normal way doesn't suffice, I guess this is one of the situations where it's okay to use.
I have an orgmode document with a latex codeblock:
So:
#+BEGIN_SRC latex
Hello
#+END_SRC
But when I generate a pdf, I get:
How can I remove this "Latex" description, and have only "So: Hello" shown?
Thank you!
From the comment, I don't think that org-latex-classes is quite correct. In
particular, the \usepackage* bit doesn't look correct.
The C-h v for that variable states
Alist of LaTeX classes and associated header and structure.
If #+LATEX_CLASS is set in the buffer, use its value and the
associated information. Here is the structure of each cell:
(class-name
header-string
(numbered-section . unnumbered-section)
...)
The header string
-----------------
The HEADER-STRING is the header that will be inserted into the
LaTeX file. It should contain the \documentclass macro, and
anything else that is needed for this setup. To this header, the
following commands will be added:
- Calls to \usepackage for all packages mentioned in the
variables ‘org-latex-default-packages-alist’ and
‘org-latex-packages-alist’. Thus, your header definitions
should avoid to also request these packages.
- Lines specified via "#+LATEX_HEADER:" and
"#+LATEX_HEADER_EXTRA:" keywords.
If you need more control about the sequence in which the header
is built up, or if you want to exclude one of these building
blocks for a particular class, you can use the following
macro-like placeholders.
[DEFAULT-PACKAGES] \usepackage statements for default packages
[NO-DEFAULT-PACKAGES] do not include any of the default packages
[PACKAGES] \usepackage statements for packages
[NO-PACKAGES] do not include the packages
[EXTRA] the stuff from #+LATEX_HEADER(_EXTRA)
[NO-EXTRA] do not include #+LATEX_HEADER(_EXTRA) stuff
So a header like
\documentclass{article}
[NO-DEFAULT-PACKAGES]
[EXTRA]
\providecommand{\alert}[1]{\textbf{#1}}
[PACKAGES]
will omit the default packages, and will include the
#+LATEX_HEADER and #+LATEX_HEADER_EXTRA lines, then have a call
to \providecommand, and then place \usepackage commands based
on the content of ‘org-latex-packages-alist’.
So I don't think you should have that \packages* line in there. Also, you are
better off either using the custom interface to set this variable or put it as a
setq in your init file. I don't think there is any reason to have to load it
inside an eval-after-load call.
Use the org variables mentioned in the docs above to add/remove packages. You
need to be careful with this as I've found this to be one area org-mode can be a
little fragile - there are some package dependencies which kick in differently
depending on whether your exporting a whole org file as latex, part of a
file/tree or a block.
I'm trying to write a small example program in Racket's scribble/lp. The source for the project is on Github.
The problem I am experiencing is broken links in the woven html. I've provided it as a gh-page. for the project.
When outputting the document using the command 'Sribble LPexample.scrbl' I get the following warning:
2013 blog > scribble LPexample.scrbl
[Output to LPexample.html]
Warning: some cross references may be broken due to undefined tags:
(dep ((lib "2htdp/image.rkt") ellipse))
(mod-path "racket")
(dep ((lib "2htdp/image.rkt") beside/align))
(dep ((lib "2htdp/image.rkt") rectangle))
(mod-path "scribble/lp")
And the output file places red underlines under the broken links.
The file which gets scribbled is LPexample.scrbl. It's pretty simple:
#lang scribble/manual
#require[scribble/lp-include]
#title{Literate Programming Example}
// snip
#lp-include["LPexample.rkt"]
The section of the literate programming document that sources the broken links is lines 69-86:
which weaves to this:
#chunk[<blue_square>
(rectangle 100 100 "solid" "blue")]
can be composed into other functions this way:
#verbatim|{
#chunk[<blue_square>
(beside/align "bottom"
(ellipse 20 70 "solid" "lightsteelblue")
<blue_square>)]}|
which weaves out to:
#chunk[<example_body>
(beside/align "bottom"
(ellipse 20 70 "solid" "lightsteelblue")
<blue_square>)]
I've been digging through the Racket documentation, of course. But there's really no good example for even cross linking documents using straight scribble/core or scribble/manual, never mind scribble/lp.
I've also tried digging through the source for the Racket documentation, but the scribble files for the the Guide and Reference use so many custom functions and macros and dependencies that I just can't get my brain far enough around it, to dig out a simple "Oh so that's how it's done".
If you want to have the identifiers from your source code automatically hyper-linked, you likely need to do two things.
One is that you need to add for-label requires for any libraries that you want Scribble to recognize. For example, you probably want (require (for-label 2htdp/image)). See this subsection of the docs for more on that.
The other is that if you're hosting the Scribble documents online the documentation links need to point somewhere, and you need to specify where. You can do that with a command-line flag. Something like this:
scribble --html +m --redirect-main http://docs.racket-lang.org/ document.scrbl
You can use different documentation URLs. For example, you might instead link to the pre-release snapshot documentation at http://www.cs.utah.edu/plt/snapshots/current/doc/.
For more details, there is a subsection of the Scribble documentation about handling cross-references: http://www.cs.utah.edu/plt/snapshots/current/doc/scribble/running.html#%28part._xref-flags%29
I'm getting No references found message whenever I use "semantic-symref-symbol" (C-c , g) trying to get all the references to any symbol, whether the symbol is a C++ class member variable or a local variable, it just couldn't find any reference. The gtag database are under my project root. In my .emacs file I have the following:
(require 'semanticdb-global)
(semanticdb-enable-gnu-global-databases 'c-mode)
(semanticdb-enable-gnu-global-databases 'c++-mode)
When I type "global -xs symbol" under command line, it shows all the reference to the symbol correctly. But why semantic couldn't find anything? On the other hand, 'semantic-symref' works fine on looking for references of a class or class member function, but it doesn't work for variables.
Is it simply a bug, or am I missing anything that keeps symbol reference from working?
This problem is with how GNU Global is used in Semantic came up on the mailing list the other day. GNU Global lets you find occurances of tags (with -r) or random symbols (-s), and Semantic uses the -r flag, and the variables you mention are not considered tags by
GNU Global.
In the cedet-global.el support file the function cedet-gnu-global-search, it was proposed to use or add the -s flag when searching for a 'symbol. I don't know what the resolution will be at this time, however.
You can see the whole thread on the cedet-devel mailing list:
http://sourceforge.net/mailarchive/forum.php?forum_name=cedet-devel&max_rows=25&style=ultimate&viewmonth=201103
My emacs version is 23.2.1
Although I used the following to change the backend to use GTAGS.
(require 'semantic/db-global)
(semanticdb-enable-gnu-global-databases 'c-mode)
(semanticdb-enable-gnu-global-databases 'c++-mode)
I tried to generate a GTAGS file to be used as a backend of semantic.
However, everytime when I open a C file, Semantic is still parsing files without using the GTAGS file.
Is it possible to use the GTAGS file instead of the built-in parser of semantic? I found that the built-in parser is not very accurate.
Is it possible to use the GTAGS file without specifying the project scope? In my case, I tried to put GTAGS file in /usr/include which should be the standard include path of emacs. But Semantics is not using it.
Semantic doesn't use the GTAGS file for generating tags that it will use directly for features such as jumping or smart completion. The GNU Global backend to semantic db will use GTAGS instead as a giant name table. Thus if you need to find a symbol by name, GTAGS will tell semantic where it is, and Semantic will then parse those files itself more directly to get the details.
The reason GTAGS is not used directly as a replacement parser is because the information in GTAGS is insufficient for the kinds of operations Semantic needs, as it excludes datatype info, argument parsing, and local context parsing.
Using gtags in /usr/include is an interesting idea, but would probably not get used much. Semantic will only search header files actually used in your code instead of searching all include files. The GNU Global backend is specifically for scanning an entire project for a symbol, or symbol references. If you wanted to search all your includes for a symbol, then it would be useful, but there is no such feature in Semantic at this time.
It is possible to use ebrowse to do what you want, but I found that for C++, the parser was insufficient in subtle ways, and caused some problems.
If you think the Semantic parser is inaccurate, then you should post that as a bug on the cedet-devel mailing list.