I would like to have a function that insert a citation with format “First_Author (1998)” using reftex, add an org footnote and fill the description with format “All_Authors, “title”, journal (1998)”. My current unworking atempt is:
(defun cite-footnote()
(interactive)
(let (ENTRY)
(setq ENTRY (reftex-citation t))
(message (reftex-format-citation ENTRY "%A (%y)"))
(org-footnote-new)
(insert (reftex-format-citation ENTRY "%a, “%t”, %j, (%y)"))
))
The problem is that the output of reftex-citation is not what is expected a first argument for reftex-format-citation. What would be the proper combination of commands?
I have hacked reftex so that it can insert references into asciidoc or markdown, which is similar to what you want.
https://github.com/phillord/phil-emacs-packages/blob/master/greycite.el
It really is a hack -- I fills my needs and I never got around to doing it properly, but it should give you the idea.
There appears to be another solution here.
http://blog.modelworks.ch/?p=379
Related
I'd like to quickly generate text in a buffer that looks like this:
(fact "This is some text which will hang out
only on this part of the screen, ideally
automatically flowing to the correct
margins as I type."
(+ 1 1) => 2
;; more Clojure tests...
)
I have an Elisp keybinding which quickly spits out a starting template and puts my cursor in the right place:
(global-set-key "\C-of" (lambda ()
(interactive)
(insert "(fact \"\"\n\n )")
(backward-char 6)))
Now, when I am typing in the string portion ("This is some text..."), it'd be awesome if I could get Emacs to automatically flow text to the "correct" margins. Is there some way Emacs can be made to adjust margins and wraparound behavior based on where you're typing? At least, the first time you are typing there?
Barring that, for a given selection of text, how can I do the equivalent of fill-region, but with the desired left and right margins? Currently fill-region deletes all space between fact and "This is...., and left-justifies the rest.
There might be a simpler way that I'm overlooking now, but I would just do this:
Configure the text block in a temporary buffer, by doing this there:
a. Set fill-column to the width of the text block that you want.
b. Put the text at the beginning of the line, i.e., not indented.
c. Fill the text.
d. Use indent-rigidly to indent the text to the column you want, except for the first line.
Insert into your target buffer (fact followed by the indentation you want for the first line of the text block. Then insert the contents of the temporary buffer. Then insert whatever other text/code you need.
IOW, I would separate filling the text block from indenting it.
The following seems to work for the moment for my alternative (weaker) case:
;; Set up Midje fact with mark inserted at beginning of comment text
;; (refill as needed in appropriate columns, using C-oF).
(global-set-key "\C-of" (lambda ()
(interactive)
(insert "(fact \"\"\n\n )")
(backward-char 6)
(set-mark (point))))
;; Perform the refill operation to properly reformat the text string
;; in a Midje fact, started with C-of:
(global-set-key "\C-oF" (lambda ()
(interactive)
(set-left-margin (mark) (point) 37)
(fill-region (mark) (point))))
I expect I'll have to tweak this as I get experience using it, but it is pretty close. Still, it'd be nice to figure out how to have this happen automatically, while I'm typing inside the string.
I'm wondering I if there's any functionality in org-mode that can make me able to operate with secret structure, that is: structure that I can see when I'm editing but that is treated as if it wasn't there when exporting. It's mainly importing when I export to ascii.
Example:
I would like this in the .org file:
* Normal heading
** Secret heading 1
Some text 1
** Secret heading 2
Some text 2
** Secret heading 3
Some text 3
To be exported to this:
Normal heading
--------------
Some text 1
Some text 2
Some text 3
What makes the headings secret can be anything like a tag, a property or something else but the secret headings should be foldable.
Edit:
Found this solution (from here) (I'm using org-mode 7.9.3 f. It doesn't work. Headlines with the :ignoreheading: tag are still displayed:
;; backend aware export preprocess hook
(defun sa-org-export-preprocess-hook ()
"My backend aware export preprocess hook."
(save-excursion
(when (eq org-export-current-backend 'latex)
;; ignoreheading tag for bibliographies and appendices
(let* ((tag "ignoreheading"))
(org-map-entries (lambda ()
(delete-region (point-at-bol) (point-at-eol)))
(concat ":" tag ":"))))))
(add-hook 'org-export-preprocess-hook 'sa-org-export-preprocess-hook)
You can use the EXCLUDE_TAGS property and tag certain sections, then export with org-export-exclude-tags. E.g:
#+EXCLUDE_TAGS: noexport
* Public Section
* Secret Section :noexport:
Documentation here.
What you want is addressed here -- and here's the answer (repeated):
Add the following to your .emacs file:
(require 'ox-extra)
(ox-extras-activate '(ignore-headlines))
Use the ignore tag on headlines you'd like to have ignored (while not ignoring their content)
I upgraded to org-mode 8.2.5h and with that this works:
(defun sa-ignore-headline (contents backend info)
"Ignore headlines with tag `ignoreheading'."
(when (and (org-export-derived-backend-p backend 'latex 'html 'ascii)
(string-match "\\`.*ignoreheading.*\n"
(downcase contents)))
(replace-match "" nil nil contents)))
(add-to-list 'org-export-filter-headline-functions 'sa-ignore-headline)
But only if you don't have the options: #+OPTIONS: tags:nil. Guess it's sort of obvious that tags shouldn't be filtered away before a filtering that relies on a certain tag is invoked - but that bugged me for quite some time.
Note: when exporting to ascii the headline underlining will remain without the headline, so you need this setting too:
(setq org-ascii-underline (quote ((ascii) (latin1) (utf-8))))
... to remove headlines all together.
In the linked question about the ignoreheading tag I posted a working, simpler org-export-before-parsing-hook solution for Org 8.2.10 in Emacs 24.1.1.
It is based on the documentation of the org-map-entries function which also states that it wraps it in save-recursion automatically. It is simpler than using concat because the second argument to org-map-entries is an agenda-style match string.
While trying to solve the same problem I found this thread describing how to extend ox-extra.el using a notignore tag. This method does not export any headings unless explicitly tagged notignore. Content of the heading are exported normally.
For most of my documents the notignore approach is more useful than the 'ignore' approach because the majority of headings are 'secret structure' not intended for export.
Presently I have notignore-headlines activated in my init.el file. Can anyone suggest a way to activate this on a per document basis.
I'm using org-mode to write a report which I then export to LaTeX.
I have a few different .org files (one per chapter), which I export as "headless" LaTeX and then combine in a master .tex file.
This works nicely, except that the generated .tex files contain labels with conflicting numbers. So both a.tex and b.tex contain \label{sec-1}, for example.
As long as I never actually use these references then it's not much of a problem I think, although the warnings do annoy me. Is there any way to turn off the generation of these labels? It should be simple but I cannot find anything about this in the documentation.
I have written a bit of Lisp which will remove said labels after the export to LaTeX, which looks like this:
(defun remove-orgmode-latex-labels ()
"Remove labels generated by org-mode"
(interactive)
(let ((case-fold-search nil))
(goto-char 1)
(replace-regexp "\\\\label{sec-[0-9][^}]*}" "")
)
)
(add-hook 'org-export-latex-final-hook 'remove-orgmode-latex-labels)
This seems to do the job without removing my own custom labels.
Why not writing your full report as one big Org file?
Anyway, if your prefer having multiple smaller files, I would advice "including" them in one Org master file, as this:
* Chapter 1
#+INCLUDE: "chapter1.org"
* Chapter 2
#+INCLUDE: "chapter2.org"
That way, Org sees only one file (then, I guess that your problem simply disappears), while you edit them as you wish.
As of now (18. 05. 2021) correct solution is this:
(defun my-latex-filter-removeOrgAutoLabels (text backend info)
"Org-mode automatically generates labels for headings despite explicit use of `#+LABEL`. This filter forcibly removes all automatically generated org-labels in headings."
(when (org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "\\\\label{sec:org[a-f0-9]+}\n" "" text)))
(add-to-list 'org-export-filter-headline-functions
'my-latex-filter-removeOrgAutoLabels)
Only slight modification of previous answer.
This is what worked for me with recent (2020) Org-Mode:
(defun rm-org-latex-labels (text backend _info)
"Remove labels auto-generated by `org-mode' export to LaTeX."
(when (eq backend 'latex)
(replace-regexp-in-string "\\\\label{sec:org[a-f0-9]+}\n" "" text)))
(add-to-list #'org-export-filter-headline-functions
#'rm-org-latex-labels)
I'm using GNU Emacs 23.3 on Windows. I work in a very large codebase for which I generate a TAGS file (using the etags binary supplied with Emacs). The TAGS file is quite large (usually hovers around 100MB). I rarely need to use any functionality beyond find-tag, but there are times when I wish I could do completion out of the TAGS table.
Calling complete-tag causes Emacs to make a completion table automatically. The process takes quite a bit of time, but my problem isn't in the amount of time it takes, but rather the fact that right at the end (around 100% completion), I get a stack overflow (sorry about the unprintable chars):
Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
re-search-forward("^\\(\\([^]+[^-a-zA-Z0-9_+*$:]+\\)?\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:]*\\)\\(\\([^\n]+\\)\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n" nil t)
etags-tags-completion-table()
byte-code(...)
tags-completion-table()
Has anyone else run into this? Know of a way to work around it?
EDIT: Stack output after turning on debug-on-error
EDIT: Removed stack, since I now know what the failing entries look like:
^L
c:\path\to\some\header.h,0
^L
c:\path\to\some\otherheader.h,0
My tags file contains quite a few entries in this format. Looking at the headers involved, it's clear that they couldn't be correctly parsed by etags. This is fine, but I'm surprised that tags-completion-table doesn't account for this format in its regex. For reference, here's what a real entry looks like:
^L
c:\path\to\some\validheader.h,115
class CSomeClass ^?12,345
bool SomeMethod(^?CSomeClass::SomeMethod^A67,890
The regexp in question is used to match a tag entry inside the TAGS file. I guess that the error can occur if the file is incorrectly formatted (e.g. using non-native line-endings), or if an entry simply is really, really large. (An entry is typically a line or two, which should not be a problem for the regexp matcher.)
One way of tracking down the problem is go to the TAGS buffer and see where the point (cursor) is, after the error has occurred. Once you know which function it is, and you could live without tags for it, you could simply avoid generating TAGS entries for it.
If the problem is due to too complex entry, I would suggest that you should send bug report to the Emacs team.
If you load the tags table (open the TAGS table with Emacs, then bury-buffer), try M-x dabbrev-expand (bound to M-/). If the present prefix is very common, you might end up running through many possible completions before reaching the desired one.
I don't use Windows, but on the Mac and Linux machines I use, I have not faced this issue.
This looks like a bug in Emacs, see:
https://groups.google.com/d/msg/gnu.emacs.help/Ew0sTxk0C-g/YsTPVEKTBAAJ
https://debbugs.gnu.org/db/20/20703.html
I have applied the suggested patch to etags-tags-completion-table (copied below in completeness for your convenience) and trapped an error case.
I'm triggering the error in an extremely long line of code (46,000 characters!). I presume somebody programmatically generated the line and pasted it into the source. A workaround could be to simply filter such lines at the ctag building or loading stage, just something that deletes "long" lines, whatever that may mean. Probably 500 characters is long enough!
I could also look at adding maximum sizes to my regexes in ctags, but that really isn't a general solution because many ctags patterns do not have such limits.
(defun etags-tags-completion-table () ; Doc string?
(let ((table (make-vector 511 0))
(progress-reporter
(make-progress-reporter
(format "Making tags completion table for %s..." buffer-file-name)
(point-min) (point-max))))
(save-excursion
(goto-char (point-min))
;; This monster regexp matches an etags tag line.
;; \1 is the string to match;
;; \2 is not interesting;
;; \3 is the guessed tag name; XXX guess should be better eg DEFUN
;; \4 is not interesting;
;; \5 is the explicitly-specified tag name.
;; \6 is the line to start searching at;
;; \7 is the char to start searching at.
(condition-case err
(while (re-search-forward
"^\\(\\([^\177]+[^-a-zA-Z0-9_+*$:\177]+\\)?\
\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:\177]*\\)\177\
\\(\\([^\n\001]+\\)\001\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n"
nil t)
(intern (prog1 (if (match-beginning 5)
;; There is an explicit tag name.
(buffer-substring (match-beginning 5) (match-end 5))
;; No explicit tag name. Best guess.
(buffer-substring (match-beginning 3) (match-end 3)))
(progress-reporter-update progress-reporter (point)))
table))
(error
(message "error happened near %d" (point))
(error (error-message-string err)))))
table))
Is there a way to get all of the tags from the files defined in your tags table list? I've set my tags file like this:
(setq tags-table-list '("~/project/TAGS"))
I've tried (tags-completion-table), but it doesn't contain all the tags.
If you got only one TAGS file, M-x visit-tags-table ~/project/TAGS or (visit-tags-table "~/project/TAGS") should load the TAGS table into a buffer which means it becomes accessible to Emacs in the same way it would be used for, M-x tags-search.
If you add more TAGS files to the project or have more than one project, (setq tags-table-list '("~/project1/TAGS" "~/Project2/TAGS" ...)) and doing (visit-tags-table-buffer t) should visit the next table each time it is called, until the end of the list.
EDIT:
(defvar buffer-in-string)
(defvar string-list)
(defun write-buffer-to-string ()
(interactive)
(setq buffer-in-string (buffer-substring (point-min) (point-max)))
(kill-buffer) ;; If the buffer is big, it makes sense to kill it,
;; since its contents are copied into the string anyway
(setq string-list (split-string buffer-in-string " "))
)
That should bring the buffer into a string. There should be a more elegant way, but at the moment, this is the most I could write with my very limited elisp fluency.
Function tags-completion-table gives you a completion table to use. From the doc string:
Build 'tags-completion-table' on demand.
The tags included in the completion table are those in the current
tags table and its (recursively) included tags tables.
And tags-lazy-completion-table gives you a completion function to use. It uses tags-completion-table.