I use the library-of-babel to consolidate common org-babel blocks and make them callable from elsewhere in org-mode.
The source blocks feed into the library-of-babel (via org-babel-ingest) from a few different files.
Is there a way to get a listing of available library entries?
This will help to know:
what's there (and available for use), and
what isn't, (and should be added).
How can I view and edit the contents of the library-of-babel?
The variable org-babel-library-of-babel contains all functions.
If you only want the names of the functions, get the first element of each entry:
(mapcar 'car org-babel-library-of-babel)
Related
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 want to keep a list of required modules of a particular module (let's say the current-module).
I feel like there are some other options (such as parsing the module?) that could be tried, but I started playing with the idea of shadowing (require) and adding the required items to a hash-table with the module-name. The problem is I cannot figure how to write a syntax definition for it.
Although not working, a function definition equivalent would be like below:
(define require-list (make-hash))
(define require
(lambda vals
; add vals to hash-table with key (current-namespace)
(let ([cn (current-namespace)])
(hash-set! require-list cn
(append vals (hash-ref require-list cn))))
(require vals)))
.. it seems the last line call should be modified to call the original (require) as well?
A correct version or a pointer to how to do it, or any other way of achieving the original goal highly appreciated.
If you just want to get a list of imports for a particular module, there is a convenient built-in called module->imports that will do what you want. It will return a mapping between phase levels and module imports—phase levels higher than 0 indicate imports used at compile-time for use in macro expansion.
> (require racket/async-channel)
> (module->imports 'racket/async-channel)
'((0
#<module-path-index:(racket/base)>
#<module-path-index:(racket/contract/base)>
#<module-path-index:(racket/contract/combinator)>
#<module-path-index:(racket/generic)>))
Note that the module in question must be included into the current namespace in order for module->imports to work, which require or dynamic-require will both do.
This will inspect the information known by the compiler, so it will find all static imports for a particular module. However, the caveats about dynamic requires mentioned by John Clements still apply: those can be dynamically performed at runtime and therefore will not be detected by module->imports.
Short short version:
Have you tried turning on the module browser?
Short version:
You're going to need a macro for this, and
It's not going to be a complete solution
The existing require is not a function; it's a language form, implemented as a macro. This is because the compiler needs to collect the same information you do, and therefore the required modules must be known at compile time.
The right way to do this--as you suggest--is definitely to leverage the existing parsing. If you expand the module and then walk the resulting tree, you should be able to find
everything you need. The tree will be extremely large, but will contain (many instances of) a relatively small number of primitives, so writing this traversal shouldn't be too hard. There will however be a lot of fiddling involved in setting up namespace anchors etc. in order to get the expansion to happen in the first place.
Regarding your original idea: you can definitely create a macro that shadows require. You're going to want to define it in another file and rename it on the way out so that your macro can refer to the original require. Also, the require form has a bunch of interesting subforms, and coming up with a macro that tries to handle all of these subforms will be tricky. If you're looking at writing a macro, though, you're already thinking about an 80% solution, so maybe this won't bother you.
Finally: there are forms that perform dynamic module evaluation, and so you can't ever know for sure all of the modules that might be required, though you could potentially annotate these forms (or maybe shadow the dynamic module-loading function) to see these as they happen.
Also, it's worth mentioning that you may get more precise answers on the Racket mailing list.
For example, standard libraries in C/C++ are used very often, and it's very inefficient to go to the web browser, search for the code example how to use a library component, copy the source code and modify to suit your need; a few month later, you need to use that library component again but forgot how to use it, and you have to repeat the whole process again!
This process is not very productive for me because after we learn something the first time, we do not need to fully study the same thing again; just part of it can help us recall how to use it. I want my written code or example code copied from the web site to be stored for later reference and modification.
Emacs macro is an option, but I think you have to type the whole source code to make a desired template. What if I found a well written code, and I want to store that code segment for future reference? Macro won't be productive because I have to type the whole thing.
Is there Emacs plugin for doing this?
I wouldn't recommend snippets for the task that you described.
Snippets are meant to be repeated often. You can't have a lot of them.
What you need is something that you use rarely, but can have a lot of.
I'm using org-mode for this task. With org-mode you can:
Organize your knowledge by language/library etc.
Include small code snippets directly via babel.
Attach any number of files to any heading.
This way you get the overview/description via the headings,
and the actual code via code blocks / attachments.
Another advantage is that you can easily grep your org-file / your attachments.
Other advantages are timestamps, TODOs and all kinds of export that org-mode provides.
UPD
Just to give you a sample of what it can do (open in in emacs, otherwise it looks ugly):
https://gist.github.com/abo-abo/6040382/raw/1be55e30a9ed8d81cc1b2b752b7d498d05e72978/hyper.org
There is quite a list on the EmacsWiki: Templates.
Personally I know TempoMode and Yasnippets. I prefer Yasnippets. The snippets are very easy to write and have support for variable fields which you enter on snippet insertion.
This should provide a command inserting the last item of current kill-ring.
(defun my-code ()
(interactive "*")
(insert "(defun ")
(save-excursion (insert (concat "()
(interactive \"*\")
(insert \"" (car kill-ring) "\"))"))))
Remains to specify the name of the command when done - and installing it.
In the past I have used Else-Mode to do just that sort of thing, especially when the project I was working on had a very rigid and long, required function header comments.
You can look to SRecode from CEDET package. Besides standard templates, like yasnippet, etc., it also provides support for content-aware templating, like some templates could be expanded only inside the classes, some only as top-level declaration, etc.
The example below is given in Paul Grahams ANSI Common Lisp as an example of doing encapsulation:
(defpackage "CTR"
(:use "COMMON-LISP")
(:export "COUNTER" "INCREMENT" "CLEAR"))
(in-package ctr)
;function definitions here
However in Peter Seibels Practical Common Lisp, link here, he says:
Because packages are used by the reader, a package must be defined
before you can LOAD or COMPILE-FILE a file that contains an IN-PACKAGE
expression switching to that package. Packages also must be defined
before other DEFPACKAGE forms can refer to them...
The best first step toward making sure packages exist when they need
to is to put all your DEFPACKAGEs in files separate from the code that
needs to be read in those packages
So he recommends creating two files for every package, one for the defpackage and one for the code. The files containing defpackages should start with (in-package "COMMON-LISP-USER").
To me it seems like putting the defpackage in the same file, before the in-package and code, is a good way to ensure that the package is defined before used. So the first method, collecting everything into one file seems easier. Are there any problems with using this method for package creation?
I think that using a separate file for defpackage is a good habit
because:
You don't « pollute » your files with defpackage.
It makes it easier to find the exported/shadowed/... symbols, you
know you just have to look at package.lisp.
You don't have to worry about the order when you use ASDF.
(defsystem :your-system
:components ((:file "package")
... the rest ...))`
Peter Seibel says so ;)
EDIT:
I forgot to mention quickproject which facilitates the creation of
new CL projects.
REPL> (quickproject:make-project "~/src/lisp/my-wonderful-project/"
:depends-on '(drakma cl-ppcre local-time))`
This command will create a directory "~/src/lisp/my-wonderful-project/"
and the following files:
package.lisp
my-wonderful-project.asd (filled)
my-wonderful-project.lisp
README.txt
And thus, I think it's good to use the same convention.
I tend to use multiple source code files, a single "packages.lisp" file and a singe "project.asd" system definition file for most of my projects. If the project requires multiple packages, they're all defined in "packages.lisp", with the relevant exports in place exported.
There is this reason for putting DEFPACKAGE in its own file: if you have a large package, then you might have several groups of related functions, and you might want to have separate source files per function group. Then all the source files would have their own IN-PACKAGE at the top, but they would all "share" the external DEFPACKAGE. Then as long as you get the DEFPACKAGE loaded first, it doesn't matter the order you load the other source files.
An example I'm currently working on has multiple classes in the package, and the source files are broken up to be per class, each having a class definition and the related generic function and method definitions.
I started using defaultcontent.el to fill newly-created buffers with content.
Apparently this module is not widely used. I think there are 3 people including me and the author who use it, because when I do a search on it, my published emacs.el comes up as the first hit.
Despite that, I find it useful. I specify a template for each file type, and every time I create a new file of that type (or extension), it gets filled with the content in the template file. The template supports well-known tags set off with "##", that get substituted at runtime:
AUTHOR inserts the user name;
DATE (obvious);
FILENAME, inserts the name of the file being created;
ENV(xxx), inserts the value of the environment variable xxx;
and there are a few other tags.
eg, whereever ##AUTHOR## is found in the template, it gets replaced with your user name at runtime in the newly created file.
ok, this isn't an advertisement for defaultcontent.el, I just thought I'd explain it a little.
here's the question.
One of the well-known tags in the template is LISP - it purports to run arbitrary elisp code to generate content to insert into the new buffer. (usage: ##LISP(lisp content here)##). It depends on a function read-closest-sexp, which I guess would just read the sexp at point.
I can't find this function. It's not included in defaultcontent.el, and I'm not up enough on elisp to create it easily. I looked in emacs-lisp\lisp.el for hints but it seemed non obvious.
Question: how can I read the sexp at point into a variable?
I'm guessing this is 2 lines in elisp...
Try thing-at-point:
(require 'thingatpt)
(let ((sexp (thing-at-point 'sexp)))
(do-something-with sexp))
Indeed two lines if you ignore the do-something :)