[O] Loss of Fontification partway through file

[Jacob Gerlach]

Hello List,

I just converted my init file to an init.org to load with babel. I
prefer to view the source blocks with font lock
(org-src-fontify-natively). My problem is that certain parts of the
file don't show the fontification.

I had a lot of trouble narrowing down my init to provide a good
MWE/recipe for the behavior, but I can reproduce it with:

$ emacs -q test.org
M-: (package-initialize) RET
M-: (setq org-src-fontify-natively t) RET

The src block in the level 2 headings of the third heading below
doesn't fontify for me. Minor changes (even changing one of the
commented load paths) fix the issue, but not in any way that seems
predictable to me.

If I move headings around in init.org, the exact location where
fontification stops varies, but once it stops, all remaining src
blocks are un-fontified.

Am I violating some sort of convention that is hanging up the
fontification code?

Thanks for any tips,
Jake

test.org-
* Heading with some add-to-list's (some commented)
#+BEGIN_SRC emacs-lisp :tangle yes
(add-to-list 'foo "bar")
;; (add-to-list 'load-path "~/.emacs.d/jake-lisp/moos-mode/trunk")
;; (add-to-list 'load-path "~/.emacs.d/jake-lisp/moos-mode/devel")
(add-to-list 'load-path "/home/jacob/.emacs.d/jake-lisp/ai-moos/devel")
#+END_SRC
* Heading with Note
Note: Loading and initializing of package is done in .emacs to
ensure that the newer version of org is loaded from elpa in favor of
the version distributed with emacs
#+BEGIN_SRC emacs-lisp :tangle yes
(add-to-list 'package-archives
'("marmalade" .
  "http://marmalade-repo.org/packages/";))
#+END_SRC
* Offending section
** Offending subsection
#+BEGIN_SRC emacs-lisp :tangle yes
(message "foobar")
#+END_SRC
-

org-version is a variable defined in `org.el'.
Its value is "8.2.6"

emacs-version is a variable defined in `C source code'.
Its value is "24.3.1"

Re: [O] Loss of Fontification partway through file

[Jacob Gerlach]

>
> The MWE (with native fontification -> t) looks ok for me,

Thanks for taking time to check this. I should note that if I find a new
file (test.org) and yank the MWE, it is fontified correctly, but if I save
and kill the buffer and then find the file again, that is when the problem
occurs. In general, if I make a change that brings back the fontification,
it doesn't disappear again until freshly finding the file.


> the only
> fontification issue I see (and not only in your MWE) is that headline
>
> ,
> | * Heading with some add-to-list's (some commented)
> `
>
> looses its font due to the "list" in it -> '(some commented)'.
> I see that often in my Org files - as soon as I type parens in a
> headline it turn white.
>
> I do not observe the same. Since it is outside of an emacs-lisp source
block, why would it be interpreted as a "list"?

>

>
> ,
> | Org-mode version 8.2.7 (release_8.2.7-1096-g23496c @
> | /usr/share/emacs/24.3/lisp/org/lisp/)
> `
>
> --
> cheers,
> Thorsten
>
> Thanks,
Jake

[O] Basic Literate Program

[Jacob Gerlach]

Hi List,

I only became aware of literate programming through org and have been
looking for a chance to try it out. I need to write a small command
line utility that parses through a plain text log file and performs
some operations, which I think is a reasonably simple use case for me
to try out this new method.

I have the basics of the program outlined in org mode already, and
envision simply adding SRC blocks to each list item. Tangling the org
file and compiling the result will give me my program.

I have several questions:
- Does this sound like a reasonable use case and approach?
- I am writing this program in C++. I believe that I can interweave
  SRC blocks with different header arguments so that they tangle to my
  .h file and .cpp file as appropriate. Is this correct?
- I may need to share the tangled cpp files with colleagues. Are there
  any ways to control the sequence of code in the resulting files
  other than the sequence of SRC blocks in org mode?
- On a related note, are there any tools to take org content from
  outside the SRC blocks and tangle it into comments in the C++ files?

Thanks,
Jake

Re: [O] Basic Literate Program

[Jacob Gerlach]

On Thu, Jul 10, 2014 at 6:28 PM, Thorsten Jolitz  wrote:

> When I call M-: (outorg-convert-org-to-outshine) on this Org-mode buffer:
>
Thanks for this suggestion. It seems outorg/outshine are not distributed
with org and must be added separately? I have to watch the size of bites I
take when experimenting with org, or otherwise I spend all my time
tinkering instead of getting work done. I'm already reaching a bit to try
tangling this project instead of just writing it, so I want to avoid
setting up additional pieces and parts. If I run in to trouble with good
commenting down the road and there are no other suggestions, I will revisit
this.

[O] Stop export on bad link?

[Jacob Gerlach]

Is it possible to configure the exporter to stop and throw an error for a
bad link?

I found this old thread
 with a patch to make
the format configurable, but I'd rather receive an explicit warning.

Thanks,
Jake

[O] Include lengthy LaTeX in export preamble

[Jacob Gerlach]

I have a lengthy command customization that I want to include in LaTeX
export. Since it must appear in the preamble,
#+BEGIN_LATEX
...
#+END_LATEX

didn't work. I had to prepend
#+LATEX_HEADER:
to each line in order to achieve my result.

I found C-h v org-format-latex-header RET:

"The document header used for processing LaTeX fragments..."

But it seems that when the docstring says "fragments," it is not referring
to exporting.

Are there any customizations to do the same during export?

Thanks,
Jake

Re: [O] Include lengthy LaTeX in export preamble

[Jacob Gerlach]

On Sun, Jul 27, 2014 at 10:08 PM, Ken Mankoff  wrote:

> Hi Jacob,
>
> #+LATEX_HEADER: does work on export (when else would it work?)
>
> Agreed. If I said otherwise it was a mistake.

2) From Aaron Ecay, put your header in a #+BEGIN_SRC latex section, and
> then run a bit of lisp to export that section, and then include the
> exported file in a #+LATEX_HEADER: \include{preamble}. This is the
> approach I use.
>
> ,
> | #+begin_src emacs-lisp
> |   (org-babel-goto-named-src-block "preamble")
> |   (org-babel-tangle)
> | #+end_src
> |
> | #+name: preamble
> | #+begin_src latex :tangle preamble.tex
> |   % code goes here
> | #+end_src
> `
>

This looks handy. Thanks!

My elisp ability is minimal, but if someone can point me towards where I
would look to try to create an export analogue to org-format-latex-header,
I would at least take a look and try to come up with a patch.

Thanks,
Jake

Re: [O] MobileOrg documentation?

[Jacob Gerlach]

This keeps coming up, and while the answers are there if you search in the
right place or ask the list, I wonder if there is a better way.

Would it be feasible to include some sort of test function in the elpa
version of org that checks for the correct installation conditions and
throws an error if org is already loaded?

If someone would point me in the right direction, I'd be happy to take a
stab at implementing it.


On Thu, Aug 7, 2014 at 4:09 PM, Christian Kruse  wrote:

> Hi,
>
> Am 07.08.14 09:13, schrieb David Masterson:
> > Anyone using MobileOrg?
>
> I use the iPhone version, via WebDAV. For exactly two things:
> capturing TODOs and having my todo list at hand when I need it. It
> works pretty well for these two tasks, gladly.
>
> Best regards,
>
> --
> Christian Kruse
> http://ck.kennt-wayne.de/
>
>
>

Re: [O] Stop export on bad link?

[Jacob Gerlach]

On Sun, Jul 27, 2014 at 7:27 AM, Bastien  wrote:

> Hi Jacob,
>
> Jacob Gerlach  writes:
>
> > Is it possible to configure the exporter to stop and throw an error
> > for a bad link?
>
> No.  But what is really a "bad link"?  Is it bad because it cannot be
> exported to a specific backend?
>

By bad, I meant a link that can't be resolved (perhaps because of a typo).
Org already handles this by formatting the "bad" link with texttt in latex.
For example:

-
* First
In [[frst]], we see the ECM.
-
Exports to:
-
\section{First}
\label{sec-1}
In \texttt{frst}, we see the ECM.
-

Whereas

* First
In [[First]], we see the ECM.

exports as:

\section{First}
\label{sec-1}
In \ref{sec-1}, we see the ECM.


After further digging, I found org-latex-link-with-unknown-path-format.
Since I usually export directly to pdf, I can achieve my desired result by
customizing this variable to some undefined control sequence (i.e.
\BADLINK), in which case latex complains, but I have to hunt down the error
in the *Org PDF LaTeX Output* buffer. It would be great if the export would
just quit and move point to the offending link


>
> --
>  Bastien
>

[O] [BUG] Macro Argument Truncation

[Jacob Gerlach]

I am making heavy use of latex strikeout for a report I'm preparing in org
mode. I defined a macro for the necessary latex snippet, but the argument
gets truncated on export.

MWE:

* Section
{{{stk(The argument for this macro is several lines long. It seems
that after a certain length, the macro argument gets truncated, as the
tex output from exporting this org buffer contains a properly
terminated strikeout block with only part of this text.)}}}
#+MACRO: stk @@latex:\sout{$1}@@


C-c C-e l L produces:


\sout{The argument for this macro is several lines long. It seems
that after a certain length}
% Emacs 24.3.1 (Org mode 8.2.7c)


I see no mention of any reason for this in the macro node of the manual or
on list archives. Am I doing something wrong or is it a bug?


Note:
org-plus-contrib is an installed package.

 Status: Installed in `.../.emacs.d/elpa/org-plus-contrib-20140901/'.
Version: 20140901

Re: [O] [BUG] Macro Argument Truncation

[Jacob Gerlach]

Ah, of course. Right under my nose, but since I "knew" I only had one
argument, I didn't even think about it.

Thanks for the quick reply.

On Sun, Sep 21, 2014 at 9:40 PM, Thomas S. Dye  wrote:

> Aloha Jacob,
>
> Jacob Gerlach  writes:
>
> > I am making heavy use of latex strikeout for a report I'm preparing in
> org
> > mode. I defined a macro for the necessary latex snippet, but the argument
> > gets truncated on export.
> >
> > MWE:
> > 
> > * Section
> > {{{stk(The argument for this macro is several lines long. It seems
> > that after a certain length, the macro argument gets truncated, as the
> > tex output from exporting this org buffer contains a properly
> > terminated strikeout block with only part of this text.)}}}
> > #+MACRO: stk @@latex:\sout{$1}@@
> >
> > 
> > C-c C-e l L produces:
> > 
> > 
> > \sout{The argument for this macro is several lines long. It seems
> > that after a certain length}
> > % Emacs 24.3.1 (Org mode 8.2.7c)
> > 
> >
> > I see no mention of any reason for this in the macro node of the manual
> or
> > on list archives. Am I doing something wrong or is it a bug?
>
> Arguments to the macro are separated by commas.  Your text gets
> truncated at the first comma.
>
> From the manual:
>
> /\
> | You can define text snippets with  |
> ||
> |  #+MACRO: name   replacement text $1, $2 are arguments |
> ||
> | which can be referenced {{{name(arg1, arg2)}}}.|
> \/
>
> hth,
> Tom
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>

[O] Toggling Macro Definition

[Jacob Gerlach]

After writing a detailed report in org-mode and submitting it via
latex/pdf, I've found out that for the next version of the report, I am
required to use "track changes" in MS Word.

I thought my best way to approximate this is to submit two versions: one
with removed text in strikeout and new text in red (hence my previous post
where I learned to RTFM on Macro arguments).

The best hack I could think of to generate a "final" pdf was to change the
macro definition so that struckout text isn't included in the output and
new text is no longer red.

i.e.

#+MACRO: stk @@latex:\sout{$1}@@
becomes
#+MACRO: stk

This works for body text, but leaves an empty headline, and in general I
don't really like it. Do any experienced org-folk have recommendations on a
better way to do this?

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Jacob Gerlach]

While I expect that there's no code overlap with macro expansion, I asked
about similar "stop on unresolved content" behavior with respect to links
here: http://article.gmane.org/gmane.emacs.orgmode/90010/

That discussion died off so I thought I'd bring up the topic again here.

Would it be possible to cause export to stop (configurably, as discussed)
when a link can't be resolved instead of just applying a special format
(i.e. org-latex-link-with-unknown-path-format)

On Tue, Sep 23, 2014 at 1:18 PM, Aaron Ecay  wrote:

> Hi Grant,
>
> 2014ko irailak 23an, Grant Rettke-ek idatzi zuen:
> >
> > Aaron may I trouble you to add a flag so that if such errors occur
> > then the export fails?
> >
> > From my perspective, if the document doesn't "compile", then nothing
> > should succeed.
> >
> > Compile includes export from my perspective.
>
> Indeed, that’s the direction that the next iteration of this patch will
> move, motivated by your and Nicolas’s comments.
>
> Thanks,
>
> --
> Aaron Ecay
>
>

[O] Support for table notes?

[Jacob Gerlach]

Hi list,

I'm having trouble with LaTeX export of a table that uses some footnotes.

It seems that export by default uses combinations of \footnotemark inside
the table and \footnotetext after the table.

This gets me in to trouble when the table is pushed to the next page - the
footnotes are left behind on the previous page.

There's a lot of discussion (here
 for
example) on the right way to do this. I'm content with just about anything
- threeparttable, for example, to produce table notes.

Are there any capabilities built in to org mode to handle footnotes in
tables differently or is this something I can only do through more direct
LaTeX tweaking?

Regards,
Jake

Re: [O] Best way to include references/license

[Jacob Gerlach]

On Wed Nov 05 2014 at 4:22:06 AM Julien Cubizolles 
wrote:

> Bracket links (like <>) create a \texttt{} \hypertarget{} pair
> instead of a \label{} \ref{} pair in the latex file. Should I go with
> explicit \label{} \ref{} in the org file ?
>
The \texttt{} is probably because org could not resolve a target from your
link. I can't help much with your problem, but see
C-h v org-latex-link-with-unknown-path-format RET
for an idea of where the \texttt{} comes from.

>
> Julien.
>
>
> Jake

Re: [O] Best way to include references/license

[Jacob Gerlach]

On Wed, Nov 5, 2014 at 9:11 AM, Sebastien Vauban 
wrote:

> Jacob Gerlach wrote:
> > On Wed Nov 05 2014 at 4:22:06 AM Julien Cubizolles wrote:
> >
> >> Bracket links (like <>) create a \texttt{} \hypertarget{} pair
> >> instead of a \label{} \ref{} pair in the latex file. Should I go with
> >> explicit \label{} \ref{} in the org file ?
> >
> > The \texttt{} is probably because org could not resolve a target from
> > your link. I can't help much with your problem, but see C-h
> > v org-latex-link-with-unknown-path-format RET for an idea of where the
> > \texttt{} comes from.
>
> FWIW, the value I set in my .emacs file is "\\colorbox{red}{%s}", so
> that it stands out in the exported document.
>
I take it one step further and use \BADLINK. This causes pdflatex to
complain, so the export fails. No need to then try to catch it in the
exported document.

There was some recent discussion of patching the exporter to report errors
on unresolved links:
http://lists.gnu.org/archive/html/emacs-orgmode/2014-09/msg00880.html

Jake

[O] Large LaTeX project in single file or using publishing

[Jacob Gerlach]

Hello list,

I'm starting writing my thesis, for which I hope to remain in org-mode
rather than regular LaTeX.

I am working on adapting a thesis LaTeX template into org-mode. The
template is set up with a main.tex having several individual files
(chapters, appendices, etc) \include'd.

I believe that I could parallel this using org's publishing mechanism. An
alternate approach would be to use one single file, since I can simply fold
chapters to focus my workflow.

My first concern is losing the ability to use internal links if I use
separate files. Another thought is compilation time if I use one file and
must always run pdflatex over the entire document. I'm sure there are
pitfalls either way that I'm not yet aware of.

Any input or advice you can provide would be greatly appreciated.

Regards,
Jake

Re: [O] Large LaTeX project in single file or using publishing

[Jacob Gerlach]

Wow, I expected a little help, but never to spark such a conversation.
Thanks to all for the comments.

Thanks to all who suggested sticking with one file. That was the main
issue I needed to sort out, and I'm glad I have a way foward

On Wed, Nov 26, 2014 at 2:31 PM, Scott Randby  wrote:
> You don't have to compile the whole document every time. You can
> export a subtree: C-c C-e, C-s changes the export scope.

I had never tried out this feature before. I had previously customized
org-latex-link-with-unknown-path-format to help me catch link
typos [1], which causes subtree (pdf) export to fail if it includes a link
that is out of scope. Nevertheless, I may come back to this and adjust
the behavior if I end up having problems with export time.

On Thu, Nov 27, 2014 at 2:51 AM, Marcin Borkowski  wrote:
> On Wednesday, 26 Nov 2014 at 19:00, Jacob Gerlach wrote:
>> I am working on adapting a thesis LaTeX template into org-mode. The
>> template is set up with a main.tex having several individual files
>> (chapters, appendices, etc) \include'd.
>
> Is that required in any way?  I'd be surprised if it was.

Not at all required. I'm working from an already-created template
that meets the format requirements. The template is set up with
separate files. All that's required is the final pdf format.

> (FYI: you can also fold things in AUCTeX.)
Didn't realize that, but I'll probably stick with Org for now!

On Thu, Nov 27, 2014 at 5:09 AM, Eric S Fraga  wrote:
> For me, the killer feature is the ability to put inline tasks in the
> document so that I know what I need to work on without having to have a
> separate task list or todo items within my general day to day task
> list.  Then a simple "C-c / t" shows me all the tasks for the current
> document.

Thus far I've mostly used Org as a LaTeX editor and haven't really
taken the time to learn and use the task tracking, but I really like
this idea. I haven't looked, but I'm sure there are variables to
control whether TODO state gets exported.

On Thu, Nov 27, 2014 at 6:43 AM, Rainer M Krug  wrote:
> Don't forget latexmk which runns in an emacs shell or even a
> different terminal, monitors file changes, and if a file changes
> compiles the latex file - so exporting from org is exporting to latex
> only, and the pdf is creqated in the background.

Inded, I have org-latex-pdf-process set to:
("latexmk -f -pdf %f" "latexmk -f -pdf %f")
And I always export directly to pdf.

> I use it daily and it works perfectly.
I often find that latexmk fails to resolve links after I've made some
minor changes to a document. I haven't put much effort into troubleshooting
this - I end up running pdflatex over the file 2 extra times. I
suppose I should add that to org-latex-pdf-process...

On Fri, Nov 28, 2014 at 12:40 PM, Richard Lawrence
 wrote:
> Here are a couple of other things to think about.  When I decided to go
> with Org, I took a few steps to ensure that if I ever need to switch to
> pure LaTeX, I will be able to do so with minimal pain, just by exporting
> my Org document to .tex and going from there.  (The big sticking point
> here for me was making sure I could produce human-readable, stable
> labels and refs for things like sections.  See the variable
> org-latex-custom-id-as-label, which was introduced by a patch I wrote.)

This sounds helpful. I'm using ELPA (tracking maint?) and don't see
this variable. Was your patch applied to master?

> Another thing to think ahead about is how you want to deal with your
> bibliography.  People on this list use different approaches.  I
> personally keep my reading tasks and notes in Org, then generate a .bib
> file from this as needed during compilation of my thesis.  Others keep
> bibliographic information directly in .bib.  I think you'll find there
> are good tools for either approach, but one or the other will probably
> fit better into your workflow, and may affect how easily you can export
> to other formats.

Yes, I know I have a lot to figure out in this arena. That's another day...

[1] http://lists.gnu.org/archive/html/emacs-orgmode/2014-08/msg00681.html

[O] Latex code before maketitle

[Jacob Gerlach]

Hi List,

I am using a custom Latex class that requires some code between
\begin{document} and \maketitle.

It seems from looking at ox-latex.el that there is nothing between document
start and title command available for me to customize.

I suppose I could customize the title command to include the extra code,
but I'd like to find an alternate approach if possible so I don't have to
manage org-latex-title-command on a per-document basis.

Are there any convenient alternatives?

Regards,
Jake

Re: [O] Latex code before maketitle

[Jacob Gerlach]

On Wed Feb 11 2015 at 4:01:47 PM Rasmus  wrote:

> Maybe something like AfterPreamble, AfterEndPreamble, AtEndPreamble etc.
> from etoolbox?


Ah, a Latex solution to an Org problem. I was looking for a final filter
and didn't realize it, but used your approach before I saw Chuck's reply.

Since I was already defining a custom org-latex-class, I was able to add
the necessary code inside the class definition:

(add-to-list 'org-latex-classes
...
[NO-DEFAULT-PACKAGES]
[EXTRA]
\\AfterPreamble{
...
}

This works great.

On Wed Feb 11 2015 at 7:24:43 PM Charles C. Berry  wrote:

> (info "(org) Advanced configuration") has a heading called 'Filters' that
> may interest you.
>
Indeed, this is what I was missing. I would have used this if I hadn't
already figured it out with AfterPreamble

I started creating a filter to move the TOC (which I need to come after
"Acknowledgments"), but it turned out to be easier just to set toc:nil and
put the TOC and lists of figures/tables where I wanted them as raw Latex
commands

Thanks both for the help.

Regards,
Jake

[O] Escape individual underscore?

[Jacob Gerlach]

Hi List,

I want to include a literal underscore in LaTeX export, like FOO_BAR. Right
now I get:
FOO$_{\text{BAR}}$

Contrary to this stackexchange question
, if I try to escape the
underscore with a backslash, I get:
FOO$\backslash$$_{\text{BAR}}

I've found that I can set org-export-with-sub-superscripts to "{}" to avoid
this problem, but I'd rather escape individual underscores on a case by
case basis. Is this possible?

As an aside, section 11.7.2 of the org info says "Configure the variable
`org-use-sub-superscripts' to
change this convention." Fortunately the docstring for
org-use-sub-superscripts points out that display and export functionality
are now controlled by separate variables. I would propose a patch to update
the info to clarify that two variables are used, but I'm not currently set
up to do so.

Regards,
Jake

[O] Internal Links with Spaces

[Jacob Gerlach]

Hi List,

I'd like to re-raise the issue discussed here
. In short, storing
and inserting an internal link to a headline containing spaces using
org-store-link and org-insert-link causes export to fail because the space
is "hexified" into %20.

It seems like the thread died because hexifying links to support external
URL's conflicted with internal links containing spaces with no clear path
forward.

Am I missing further discussion where this was resolved?

If not, is a fix still possible or is this a "won't fix" because of the
clash with external links?

If it's "won't fix", is it possible for me to advise org-insert-link (or
some other function) or configure some other individual hack to work around
the problem? I never use org-insert-link for URL's, so I'd be glad to
blindly stop hexifying even if it breaks that functionality.

Regards,
Jake

Re: [O] Internal Links with Spaces

[Jacob Gerlach]

On Mon, Mar 9, 2015 at 10:38 AM, Leo Ufimtsev  wrote:
> On the side, if of any help:
>
> I generally use ID's for linking to headings.
> The benefit is that headings can be re-named safley and links still work.

A great suggestion. I wasn't aware of the feature, and renaming safety
is a great benefit while also solving my space problem.

I don't suppose there's a trick to automatically update descriptions
for links whose target has been renamed?

When exploring this, I found the function org-id-store-link. This
seemed like what I wanted - it creates a custom ID if one doesn't
exist, but it doesn't actually store a link (or at least, it wasn't
available when I then ran org-insert-link). The docstring is pretty
light, but it seems like this might be a bug. Is this the expected
behavior?

Thanks for the pointer in any case.

Regards,
Jake

Re: [O] Internal Links with Spaces

[Jacob Gerlach]

On Mon, Mar 9, 2015 at 7:28 PM, John Kitchin  wrote:
> I think you need to set
>
> (setq org-id-link-to-org-use-id 'create-if-interactive)

Indeed, this is a variation of what Leo suggested and customizing
org-id-link-to-org-use-id is almost working for me...

Unfortunately, I want the links to export to latex using latex
\ref{}'s and section labels. A link stored with a custom id has to
have a description to have a reasonably readable org buffer, but links
with descriptions are exported using the headline text instead of the
section number. Is there a workaround for this?

On Mon, Mar 9, 2015 at 4:50 PM, Jacob Gerlach  wrote:
> When exploring this, I found the function org-id-store-link. This
> seemed like what I wanted - it creates a custom ID if one doesn't
> exist, but it doesn't actually store a link (or at least, it wasn't
> available when I then ran org-insert-link). The docstring is pretty
> light, but it seems like this might be a bug. Is this the expected
> behavior?

After perusing the source code further, I think that my confusion
about org-id-store-link arose because this function isn't intended to
be called on it's own (it's called by org-store-link when appropriate
based on the value of org-id-link-to-org-use-id).

I've seen a double hyphen in function names to sometimes indicate
internal functions. Would this function be more appropriately named
org-id--store-link or am I misunderstanding the convention?



Regards,
Jake

Re: [O] Internal Links with Spaces

[Jacob Gerlach]

On Tue, Mar 10, 2015 at 12:12 PM, John Kitchin  wrote:
> As far as I know you have only two options to use refs to a headline in
> Latex export.
>
> 1) Use a CUSTOM_ID property on a heading and then use [[#your-custom-id]] as
> your link. You have to put relevant text in like: see section
> [[#your-custom-id]]. If you want readable custom-ids you should make
> them yourself, e.g. C-c C-x p CUSTOM_ID your-custom-id, or craft an
> elisp function that prompts you for the custom-id and sets it for you,
> maybe even copying it to the kill-ring so it is easy to insert later.
>
> 2) Put \label{some-name} in the heading (yes, it is not pretty), e.g.
>
> * Results \label{sec-results}
>
> and use \ref{some-name} where you want the link to export to (or, if you
> use org-ref you can use ref:some-name which will be a clickable link,
> and also label:sec-results which is also a functional link). You still
> have to put relevant text in, e.g. see section ref:some-label.

Thanks to John for the recommendations, but given these options, I'm
more attracted to solving the original problem with the % escaped
spaces.

I came up with the following wrapper function - it successfully
replaces the hex encoded spaces (elisp feedback welcome):

(defun jg/insert-link-unescape-spaces ()
  (interactive)
  (org-insert-link)
  (save-excursion
(let ((beg (point)))
  (org-previous-link)
  (let ((end (point)))
(replace-string "%20" " " nil beg end)

After finally getting this function to work, I discovered that I had
the same problem as when I used org-id: the link description causes
exported latex references to use the headline text instead of the
\label{}.
Any (of several) attempts to insert a link so that it has no
description is foiled. I think this is done by org-make-link-string,
which just re-uses the link text for the description when none is
given.

In any case, here's an ugly hack to manually remove the description.
This works for me, but I'd love to find a more elegant approach:

(defun jg/insert-link-unescape-spaces ()
  (interactive)
  (org-insert-link)
  (save-excursion
(let ((beg (point)))
  (org-previous-link)
  (let ((end (point)))
(replace-string "%20" " " nil beg end
  ;expose the link so that search can see brackets
  (delete-char -1)
  (let ((end (point))
(beg (search-backward "[")))
(delete-region beg end)
(insert "]")))

Alternatively, if someone has a latex export hack that forces links to
reference labels instead of headline text (even when the org link has
a description), I'd be interested in that. It seems like this would be
a common request for exporting scientific writing to latex (unless
those users prefer one of the approaches John suggested above).

Regards,
Jake

Re: [O] [PATCH] Internal Links with Spaces

[Jacob Gerlach]

Hi,

On Wed, Mar 11, 2015 at 9:41 AM, Nicolas Goaziou  wrote:
> I'm not sure to understand the problem you're trying to solve. Would you
> mind giving a simple example and motivation?
(Did I break the thread by adding "[PATCH]" to the subject? Apologies
if so, original thread was [1])

The motivation is to allow generating standard "see section
\ref{some-label}" references using org-store/insert-link.

In more detail (repeating/summarizing the prior messages on original thread):

Internal Links stored with org-store-link and inserted with
org-insert-link fail on export for headlines with spaces because of %
encoding the spaces. (This is orthogonal to the patch, just the
original motivation that led to it).

One solution is to use org-id. I also came up with a hack to unhex the
link after it is inserted.

In either case, the links inserted have descriptions. Links with
descriptions always export as hyperref's using the headline text
(instead of regular \ref's using the label).

There is no (?) way to force links with descriptions to export using
regular latex \ref{}'s. John Kitchin offered two workarounds (using a
custom id for every headline or manually \label'ing the headlines and
\ref'ing them instead of using org links).

Regards,
Jake

[1] https://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00348.html

Re: [O] [PATCH] Internal Links with Spaces

[Jacob Gerlach]

On Wed, Mar 11, 2015 at 10:17 AM, Nicolas Goaziou
 wrote:
> This is where I don't follow you. You can insert links without
> description, using `org-insert-link'. What makes you think you cannot?

I thought that I had tested `(org-insert-link nil nil "")' and found
that a description (repeating the headline text) was still inserted,
but I just tried again and it does in fact insert a link with no
description. (In the meantime I switched from ELPA to git, so perhaps
this behavior has changed?). This solves my problem, so sorry if this
was all noise.

> That's intended, indeed. If you added a description to a link, Org
> should use it.

At least in the case of org-id, I can imagine that the description
might only be used to control appearance in the org buffer, not to
express desired export behavior.
A link that uses org-id really begs for a description for readability,
but then you can't get \ref{label} on export. Perhaps this is a corner
case that doesn't justify another customization.

Regards,
Jake


[1] https://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00350.html

[O] Resolving Test Failures

[Jacob Gerlach]

Hi List,

I'm trying to write a patch and getting test failures from `make test'. The
backtrace on the command line is hard for me to parse.

If I try running ert interactively by:
M-x load-file org-test.el
M-x load-file test-ox.el
M-x ert RET applicable/test

It reports that the test passes.

Do I just need to get better at reading the backtrace or are there any
recommendations on figuring out exactly which part of a test is failing?

Regards,
Jake

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Jacob Gerlach]

On Sun, Sep 28, 2014 at 3:03 AM, Nicolas Goaziou  wrote:
> Aaron Ecay  writes:
>> The links issue (re-)raised by Jacob in
>> <http://mid.gmane.org/caa6uvufm-1nwd06a5o3hwsveqmgqljncfk_ptohsehcvdjt...@mail.gmail.com>
>> is a bit harder to deal with, since each backend currently does
>> something a little different. It would be possible to make every
>> backend’s org-X-link function error out at the end, but I’m not sure
>> if that’s the right thing to do or not.
>
> A more workable solution would be to focus on internal links only and
> patch `org-export-resolve-id-link', `org-export-resolve-fuzzy-link',
> `org-export-resolve-coderef' (not needed for radio links).

Patch attached for fuzzy links.

I don't really use code blocks, so I wasn't sure what to do with
org-export-resolve-coderef. Should the final

(when (re-search...
  (cond ...

become

(or (re-search...
   (cond ...
 (error

ID links are tricky. AFAICT, an invalid id link will always resolve to
the file it's contained in. The last check in
org-export-resolve-id-link is looking for the id in `:id-alist'. Is
this the same `:id-alist' built in org-export-get-environment?

If so, is it desirable for org-id-find-id-file to fall back on the
current buffer (the current behavior)? It seems like this will
mistakenly cause org-export-get-environment to think that the bad link
is valid and pointing to an "external" file. IIUC, the fall back
behavior doesn't occur inside org-test-with-parsed-data because
buffer-file-name returns nil.

I don't know the implications of changing
org-id-find-id-file. The fall back behavior was introduced in ac83bc01
when org-id was mostly rewritten. Removing the fall back behavior
doesn't cause any failures on `make test'. If it's acceptable to
remove the fall back, I can provide a similar patch for
org-export-resolve-id-link.

Example, foo.org:

[[id:points-nowhere]]

[[id:this-one-too][also bad]]

Exports (latex) to:

\url{foo.org}

\href{foo.org}{also bad}

Regards,
Jake
From 20f84420a84997fc0e15df5af2e65b3cfde87ac1 Mon Sep 17 00:00:00 2001
From: Jacob Gerlach 
Date: Wed, 11 Mar 2015 22:39:11 -0400
Subject: [PATCH] ox.el: Issue error for unresolved fuzzy link

* lisp/org-capture.el (org-export-resolve-fuzzy-link): throw error
  instead of returning nil when link can't be resolved.

* testing/lisp/test-ox.el (test-org-export/resolve-fuzzy-link): change
  last test from should-not to should-error

In addition to throwing an error, don't store the failed match in the
link cache.

TINYCHANGE
---
 lisp/ox.el  | 7 ---
 testing/lisp/test-ox.el | 4 ++--
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 0c7728f..a28a227 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -4068,7 +4068,7 @@ significant."
  ;; Last case: link either points to a headline or to nothingness.
  ;; Try to find the source, with priority given to headlines with
  ;; the closest common ancestor.  If such candidate is found,
- ;; return it, otherwise return nil.
+ ;; return it, otherwise signal an error.
  (t
   (let ((find-headline
 	 (function
@@ -4094,8 +4094,9 @@ significant."
 		   (org-element-lineage parent-hl nil t
 	(let ((foundp (funcall find-headline path parent)))
 	  (when foundp (throw 'exit foundp
-	  ;; No destination found: return nil.
-	  (and (not match-title-p) (puthash path nil link-cache
+	  ;; No destination found: error.
+	  (unless match-title-p
+	(error (format "Unable to resolve link \"%s\"" raw-path)
 
 (defun org-export-resolve-id-link (link info)
   "Return headline referenced as LINK destination.
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 1b70a78..7cf1e1d 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -2478,8 +2478,8 @@ Another text. (ref:text)
 	 (org-element-type
 	  (org-export-resolve-fuzzy-link
 	   (org-element-map tree 'link 'identity info t) info)
-  ;; Return nil if no match.
-  (should-not
+  ;; Error if no match.
+  (should-error
(org-test-with-parsed-data "[[target]]"
  (org-export-resolve-fuzzy-link
   (org-element-map tree 'link 'identity info t) info)))
-- 
1.9.1

Re: [O] [PATCH] Internal Links with Spaces

[Jacob Gerlach]

On Tue, Mar 10, 2015 at 3:47 PM, Jacob Gerlach  wrote:
> After finally getting this function to work, I discovered that I had
> the same problem as when I used org-id: the link description causes
> exported latex references to use the headline text instead of the
> \label{}.
...
> This works for me, but I'd love to find a more elegant approach:

I had been waffling on whether to switch to the git version of org.
This was motivation to make the switch, so I decided to give a shot at
patching this.

Attached patch introduces `org-latex-prefer-section-references'. If
non-nil, links will use the generated \label even if the link has a
description.

I believe I did everything right - commit message, no failures on make test...

Regards,
Jake
From 50829ce7891bd9cd5c654da346ae1981fe6339f7 Mon Sep 17 00:00:00 2001
From: Jacob Gerlach 
Date: Wed, 11 Mar 2015 09:15:46 -0400
Subject: [PATCH] ox-latex.el: Customize link export behavior

* lisp/ox-latex.el (org-latex-prefer-section-references): Add new
  defcustom.
  (org-latex-link): Use customization when resolving links to
  headlines.

  TINYCHANGE
---
 lisp/ox-latex.el | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 6cec8a1..e1b2647 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -510,6 +510,17 @@ and resolve links into section references."
   :version "25.1"
   :package-version '(Org . "8.3"))
 
+(defcustom org-latex-prefer-section-references nil
+   "Toggle use of link descriptions for generating section labels.
+
+When this variable is non-nil, Org will resolve links into
+section references even when the link has a description."
+
+  :group 'org-export-latex
+  :version "25.1"
+  :package-version '(Org . "8.3")
+  :type 'boolean)
+
  Footnotes
 
 (defcustom org-latex-footnote-separator "\\textsuperscript{,}\\,"
@@ -2075,14 +2086,15 @@ INFO is a plist holding contextual information.  See
 	  ;; LINK points to a headline.  If headlines are numbered
 	  ;; and the link has no description, display headline's
 	  ;; number.  Otherwise, display description or headline's
-	  ;; title.
+	  ;; title depending on the value of 
+	  ;; org-latex-prefer-section-references
 	  (headline
 	   (let* ((custom-label
 		   (and (plist-get info :latex-custom-id-labels)
 			(org-element-property :CUSTOM_ID destination)))
 		  (label (or custom-label
 			 (org-export-get-headline-id destination info
-	 (if (and (not desc)
+	 (if (and (or (not desc) org-latex-prefer-section-references)
 		  (org-export-numbered-headline-p destination info))
 		 (format "\\ref{%s}" label)
 	   (format "\\hyperref[%s]{%s}" label
-- 
1.9.1

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Jacob Gerlach]

Hello,

Thanks for the feedback.

On Sun, Mar 15, 2015 at 4:44 AM, Nicolas Goaziou  wrote:
>> I don't really use code blocks, so I wasn't sure what to do with
>> org-export-resolve-coderef.
[...]
> No, the whole body could be wrapped with an `or':
>
>   (or (org-element-map ...)
>   (user-error "Unable to resolve code reference: %s" ref))
I tried this, or more specifically:
(or ((org-element-map
...
info 'first-match))
  (user-error ...
 and got a failure on test-org-export/resolve-coderef. It's not
obvious to me from reading the tests if there is a test that needs to
be changed, or if it's a legitimate failure and a different approach
is needed (or if I made a mistake). I asked in [1] for some guidance
on tests, and I'm still lost.

>> If so, is it desirable for org-id-find-id-file to fall back on the
>> current buffer (the current behavior)?
>
> According to its docstring, `org-id-find-id-file' returns nil when
> search failed. Isn't it the case?
Are you looking at `org-id-find-id-in-file' rather than
`org-id-find-id-file'? The docstring for `org-id-find-file' only says:
"Query the id database for the file in which this ID is located."

[...]
> `org-export-resolve-id-link' could throw an error, indeed.
I'm not clear on the way forward for id links. I propose removing the
fall back behavior in `org-id-find-id-file'. If that's acceptable, I
can provide a patch for `org-export-resolve-id-link'.

>> Subject: [PATCH] ox.el: Issue error for unresolved fuzzy link
[...]
Commit message fixed. I also updated the docstring for
org-export-resolve-fuzzy link.
>> +   ;; No destination found: error.
>> +   (unless match-title-p
>> + (error (format "Unable to resolve link \"%s\"" raw-path)
>
> You don't need to check `match-title-p' here. Also, it should be
> `user-error' instead of `error'.
OK.

Updated fuzzy link patch attached.

Regards,
Jake

[1] http://thread.gmane.org/gmane.emacs.orgmode/96017
From a9221500b721a501f7b7f05519dfc0d6f30f23d0 Mon Sep 17 00:00:00 2001
From: Jacob Gerlach 
Date: Wed, 11 Mar 2015 22:39:11 -0400
Subject: [PATCH] ox.el: Issue error for unresolved fuzzy link

* lisp/ox.el (org-export-resolve-fuzzy-link): Throw an error instead
  of returning nil when link can't be resolved.

* testing/lisp/test-ox.el (test-org-export/resolve-fuzzy-link): Change
  last test from should-not to should-error

In addition to throwing an error, don't store the failed match in the
link cache.

TINYCHANGE
---
 lisp/ox.el  | 8 
 testing/lisp/test-ox.el | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 0c7728f..9461117 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -4021,7 +4021,7 @@ Return value can be an object, an element, or nil:
   will be given to the one with the closest common ancestor, if
   any, or the first one in the parse tree otherwise.
 
-- Otherwise, return nil.
+- Otherwise, report an error.
 
 Assume LINK type is \"fuzzy\".  White spaces are not
 significant."
@@ -4068,7 +4068,7 @@ significant."
  ;; Last case: link either points to a headline or to nothingness.
  ;; Try to find the source, with priority given to headlines with
  ;; the closest common ancestor.  If such candidate is found,
- ;; return it, otherwise return nil.
+ ;; return it, otherwise signal an error.
  (t
   (let ((find-headline
 	 (function
@@ -4094,8 +4094,8 @@ significant."
 		   (org-element-lineage parent-hl nil t
 	(let ((foundp (funcall find-headline path parent)))
 	  (when foundp (throw 'exit foundp
-	  ;; No destination found: return nil.
-	  (and (not match-title-p) (puthash path nil link-cache
+	  ;; No destination found: error.
+	(user-error (format "Unable to resolve link \"%s\"" raw-path
 
 (defun org-export-resolve-id-link (link info)
   "Return headline referenced as LINK destination.
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 1b70a78..7cf1e1d 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -2478,8 +2478,8 @@ Another text. (ref:text)
 	 (org-element-type
 	  (org-export-resolve-fuzzy-link
 	   (org-element-map tree 'link 'identity info t) info)
-  ;; Return nil if no match.
-  (should-not
+  ;; Error if no match.
+  (should-error
(org-test-with-parsed-data "[[target]]"
  (org-export-resolve-fuzzy-link
   (org-element-map tree 'link 'identity info t) info)))
-- 
1.9.1

[O] [RFC][PATCH] Store links to named elements

[Jacob Gerlach]

In [1], storing links to named elements was discussed. AFAICT, no
patches came from that discussion. The current behavior is that given:

* Headline

#+Name: foo

org-store-link will store a link to `*Headline' rather than `foo'.

Attached is a very rough first attempt at patching org-store-link to
recognize and link to the name.

Is this approach worth fleshing out or are there problems associated
with this type of link? Using the above example, [[foo]] seems to be a
valid link, recognized by both export and org-open-at-point.

If doable, a couple of specific questions:
This attached patch makes no attempt to store the file name as
currently done for headlines. Would it be better to check for a name
in the headline linking code (the final "t" in the org-mode-p `cond'
in org-store-link) or rather reproduce file name code separately.

Does a context string make sense for links to element names?

Regards,
Jake

[1] http://permalink.gmane.org/gmane.emacs.orgmode/91935
From f1166d30ccabdb208b0263d87fd9366fa9a2f325 Mon Sep 17 00:00:00 2001
From: Jacob Gerlach 
Date: Wed, 18 Mar 2015 09:58:00 -0400
Subject: [PATCH] Add support to link to named elements

* lisp/org.el (org-store-link): Store links to named elements.

Before falling back to the current headline, check if point is at a
named element, and if so store the element name as the link.

TINYCHANGE
---
 lisp/org.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index b1999dc..0a37a2f 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9838,6 +9838,11 @@ active region."
 			 (concat "file:"
  (abbreviate-file-name
   (buffer-file-name (buffer-base-buffer
+
+	  ((org-element-property :name (org-element-at-point))
+	   ;; At a named element, link to the name
+	   (setq cpltxt (org-element-property :name (org-element-at-point
+
 	  (t
 	   ;; Just link to current headline
 	   (setq cpltxt (concat "file:"
-- 
1.9.1

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Jacob Gerlach]

On Tue, Mar 17, 2015 at 6:38 PM, Nicolas Goaziou  wrote:
(re unresolved ID links)
>See e0b19dedb99d3c01199a159a2da8f9aa4adb2f6f

>> Updated fuzzy link patch attached.
> Applied (with minor tweaks). Thank you.

Thanks for the changes.

I had some issues using the error messages to track down bad links
with descriptions since the link path is hidden. (isearch doesn't
search the hidden text.) If anyone else is similarly challenged,
`org-toggle-link-display' is very helpful here.

Regards,
Jake

Re: [O] Possible bug: Can not search for text in links - only description

[Jacob Gerlach]

On Fri, Mar 20, 2015 at 9:44 AM, Rainer M Krug  wrote:
> Hi
>
> I got an error as follow when I tried to export:
>
> ,
> | org-babel-exp process R at line 5495...
> | Evaluation of this R code-block is disabled.
> | user-error: Unable to resolve link "*uLELFit"
> `
>
> I thought "OK - I'll search for uLELFit and just fix this link - but I
> could do what I wanted, I did not manage to find the link.
>
> I figured out that I can not search for text in the link.

`org-toggle-link-display' is very helpful here. See [1] for a
discussion of the patch and new behavior.

It is perhaps worth considering to change the error message to show
the link description (when it exists) rather than the link itself to
make it easier to find the bad link.

Regards,
Jake

[1] http://comments.gmane.org/gmane.emacs.orgmode/90891

Re: [O] Possible bug: Can not search for text in links - only description

[Jacob Gerlach]

org-show-context-detail may also be relevant:

org-show-context-detail is a variable defined in `org.el'.
Its value is ((isearch . lineage)
 (bookmark-jump . lineage)
 (default . ancestors))


Documentation:
Alist between context and visibility span when revealing a location.

Some actions may move point into invisible
locations.  As a consequence, Org always expose a neighborhood
around point.  How much is shown depends on the initial action,
or context.  Valid contexts are

  agenda when exposing an entry from the agenda
  org-goto   when using the command `org-goto' (C-c C-j)
  occur-tree when using the command `org-occur' (C-c / /)
  tags-tree  when constructing a sparse tree based on tags matches
  link-searchwhen exposing search matches associated with a link
  mark-goto  when exposing the jump goal of a mark
  bookmark-jump  when exposing a bookmark location
  isearchwhen exiting from an incremental search
  defaultdefault for all contexts not set explicitly
...


but I haven't followed through to see exactly how to use it.

Re: [O] Possible bug: Can not search for text in links - only description

[Jacob Gerlach]

On Sat, Mar 21, 2015 at 7:34 PM, Alexis  wrote:
>
> On 2015-03-21T01:59:07+1100, Richard Lawrence
>  said:
>
> RL> I am not sure if this counts as a bug or not, so someone else
> RL> should still address this question.  Maybe this is the desired
> RL> behavior, given that the link text is hidden?  Or maybe it's just
> RL> not possible to search in hidden text?
>
> Cf. the `search-invisible` variable:

`search-invisible' is less helpful that one might think.

I think that the difficulty arises from the fact that links use the
invisibility text property. Folded trees, OTOH, use an invisibility
overlay. Overlay invisibility is searched (and expanded for matches)
when `search-invisible' is set to `open' (the default). While you can
/search/ invisible text, AFAICT, isearch has no machinery to /show/
invisible text (just to "open" invisibility overlays). You can set
`search-invisible' to `t', but then your search is likely to end up on
the ellipses for a folded subtree (since it will no longer unfold).

With `search-invisible' set to `t', point does end up on (still
invisible) matches. I tried cobbling together a hack like:

(add-hook 'isearch-update-post-hook
  (lambda ()
(if isearch-hidden
(org-remove-from-invisibility-spec '(org-link))
  (add-to-invisibility-spec '(org-link)

(defun jg/isearch ()
  (interactive)
  (let ((search-invisible t))
(isearch-forward)))

But besides not opening overlays, I think you'd need a similar
function on a couple more isearch hooks to make this work.

On Fri, Mar 20, 2015 at 2:06 PM, Charles C. Berry  wrote:
> You *can* search in links without changing modes.
>
> Exa RET
>
> runs nonincremental-search-forward on "Exa" and  finds Rainier's `*Example'
> if point preceeds it.

search-forward suffers from the same problem as setting
`search-invisible' to `t' - folded subtrees don't open. I suppose you
could expand the whole tree first and then use it.

> M-x occur RET Exa RET

This worked well for me.

On Sat, Mar 21, 2015 at 7:45 PM, Randomcoder  wrote:
> In terms of searching through all open buffers,
> here is what I use (helm and helm-multi-occur):
Can you comment on the capability to search invisible text (such as
the invisible path for an org link)? For the problem at hand, there's
no need to search multiple buffers, just to search the invisible text
in a given buffer.

For the (hopefully) infrequent case of finding a mistyped link,
`org-toggle-link-display' or M-x occur should be adequate.

Re: [O] Possible bug: Can not search for text in links - only description

[Jacob Gerlach]

On Mon, Mar 23, 2015 at 8:45 AM, Rainer M Krug  wrote:
> First I must say it makes sense to give the error message, although I
> was quite surprised.
>
> But the message should contain a string one can easily search for. And I
> guess the most used search function is C-s I think the message should be
> changes to the description of the link and the target in brackets. This
> would make searching easier.

FWIW, I completely agree. I would be happy to provide a patch for
this, but I'm not sure how to get the link's description inside
org-export-resolve-fuzzy-link. AFAICT, the `link' object passed to
this function has properties as determined by
`org-element-link-parser'. The properties listed in the docstring
don't include the description.

Could anyone provide a hint on how to get the link's description?

Regards,
Jake

Re: [O] :ignoreheading: works with LaTeX export, but not HTML

[Jacob Gerlach]

On Fri, Mar 27, 2015 at 6:53 AM, Nicolas Goaziou  wrote:
> :ignoreheading: is a feature implemented in "ox-beamer.el" only. This is
> not a common feature for all back-ends.

IIUC, this question is about performance of the filter shown in the
OP, not about the built in feature in ox-beamer.

Removed the escaped backquote from the string-match regexp seems to
work for both Latex and HTML, but I can't comment on why this is the
case or whether it might have unintended consequences.

Regards,
Jake

[O] [RFC] Repeat Heading movement commands

[Jacob Gerlach]

Hi List,

I often find myself wanting to move up by several headings:

C-c C-p, C-c C-p, C-c C-p...
(I don't usually know ahead of time how many I want to move, so I
can't use a numeric prefix arg)

I like how `set-mark-command' works with non-nil `set-mark-repeat-pop'
to avoid the need to repeat a prefix key and wanted to try something
similar for C-p. I came up with the following:

(define-key org-mode-map
 (kbd "C-p")
 (lambda (arg)
   (interactive "p")
   (if (not (eq last-command 'org-previous-visible-heading))
   (previous-line arg)
 (org-previous-visible-heading arg)
 (setq this-command 'org-previous-visible-heading

So now I can do:
C-c C-p, C-p, C-p...
And repeatedly move by headlines.

This (with a similar definition for C-n) is working well for me. If I
fleshed this out into a patch with a defcustom to control the
behavior, might it be applied? Or is this too far in the weeds of
individual user preference to warrant modifying org.el?

Thanks for any comments.

Regards,
Jake

Re: [O] [RFC] Repeat Heading movement commands

[Jacob Gerlach]

On Sun, Mar 29, 2015 at 4:05 PM, Kyle Meyer  wrote:
> With org-use-speed-commands set to t, this could be "C-c C-p p p".

Well, this is much better. Should have thought to check the info, of
course there's already something like this built in...

On Sun, Mar 29, 2015 at 4:09 PM, John Kitchin  wrote:
> This kind of repeated command seems to be a good application for hydra.

I suppose I'll stick with speed commands for org-mode, but hydra looks
interesting.

Thanks for the tips.

Regards,
Jake

[O] [BUG?] Blank line required between text and short caption

[Jacob Gerlach]

Hello,

Is it required by org syntax to separate short captions from body text?

In the following example:

* ECM
Some text that introduces this table.
#+CAPTION[Short caption]:
#+CAPTION: Longer caption
| Foo |


Latex export gives:

...
Some text that introduces this table.
\#+CAPTION[Short caption]:
\begin{table}[htb]
\caption{Longer caption}
...


Adding an empty line between the text and short caption produces the
expected results:

* ECM
Some text that introduces this table.

#+CAPTION[Short caption]:
#+CAPTION: Longer caption
| Foo |

...
Some text that introduces this table.

\begin{table}[htb]
\caption[Short caption]{Longer caption}
...


A regular (i.e. non-short) caption works regardless of the empty line:

* ECM
Some text that introduces this table.
#+CAPTION: A caption
| Foo |

Some text that introduces this table.
\begin{table}[htb]
\caption{A caption}


Regards,
Jake

Re: [O] [BUG?] Blank line required between text and short caption

[Jacob Gerlach]

On Mon, Apr 27, 2015 at 4:29 PM, Nicolas Goaziou  wrote:
> No, it is a genuine bug from parser. This should be fixed in
> eb77fed33fa0306ebed2224f7895b688320847b2.
Confirmed that it is fixed. Thank you.

Regards,
Jake

[O] Restart tablenote numbering by section?

[Jacob Gerlach]

Hello,

Latex export explicitly specifies the footnote number when using
\footnotetext for a footnote in a table:
---
| One[fn:1] |
* Footnotes
[fn:1] Footnote in the table
---
becomes:
---
\begin{center}
\begin{tabular}{l}
One\footnotemark\\
\end{tabular}
\end{center}\footnotetext[1]{Footnote in the table}
---

My latex class restarts footnote numbering in each chapter (org top level
headlines), so in a real document the resulting numbering is incorrect (the
tablenote is numbered according to it's overall sequence in the entire org
document, as opposed to the chapter).

Am I stuck manually tweaking the exported latex or is there a solution to
get correct numbering from within org?

Regards,
Jake

[O] [Bug?] Link fontification in captions

[Jacob Gerlach]

Hello,

A link in a caption:

#+CAPTION: [[link]]

Initially receives org-link face when I type it. After some action (moving
to the next line or saving the buffer), it is redrawn with org-block face.

In neither case does [[ and ]] receive the invisibility attribute typically
given to links.

In both cases, it receives the typical overlay when moused-over. It also
exports correctly, which is what I really care about.

Could links in captions be given the same treatment as in the rest of the
buffer?

Regards,
Jake

[O] [Bug?] Smart quotes and latex environments

[Jacob Gerlach]

Hello,

--
#+OPTIONS: ':t
\begin{myenvironment}
"Foo"
\end{myenvironment}
--
Exports "Foo" rather than ``foo''. Is this expected?

I tried this instead:
--
#+Latex:\begin{myenvironment}
"Foo"
#+Latex:\end{myenvironment}
--
which exports to:
--
\begin{myenvironment}
``Foo''
\#+Latex:\end{myenvironment}
--
This seems like a bug.

Mixing the two:
--
#+Latex:\begin{myenvironment}
"Foo"
\end{myenvironment}
--
gives the desired result:
--
\begin{myenvironment}
``Foo''
\end{myenvironment}
--
but this seems like a hack.

Regards,
Jake

[O] org-latex-custom-lang-environments

[Jacob Gerlach]

Hello,

I thought I had successfully used this variable, but after restarting
emacs, I can no longer reproduce the documented behavior.

Given the following org file:
--
#+BEGIN_SRC sh :exports code
echo "Hello"
#+END_SRC

# Local Variables:
# org-latex-listings: t
# org-latex-custom-lang-environments: (quote ((sh "myverbatim")))
# END:
--

I expect to export
--
\begin{myverbatim}
echo "Hello"
\end{myverbatim}
--
(and I thought I had observed this behavior the first time I tried it).
Instead, I get
--
\lstset{language=sh,label= ,caption= ,captionpos=b,numbers=none}
\begin{lstlisting}
echo "Hello"
\end{lstlisting}
--

Am I missing something?

Regards,
Jake

Re: [O] org-latex-custom-lang-environments

[Jacob Gerlach]

Hello,

On Tue, May 19, 2015 at 11:29 AM, Rasmus  wrote:
> If I explicitly eval:
>
> (org-babel-do-load-languages 'org-babel-load-languages '((sh . t)))
> (setq org-latex-custom-lang-environments '((sh "myverbatim"))
>   org-latex-listings t)
>
> And export
>
> #+BEGIN_SRC sh :exports code
> echo "Hello"
> #+END_SRC
>
> I get the the block wrapped in the desired environment.  I don't know why
> your local variables are ignored, but it seems the result is the same when
> using the Org-specific BIND keyword...


Yes, I see the same - setting them with setq gives the desired
behavior. I must have done this during my initial experimentation
which is why it worked until I restarted emacs.

I know the local variables are parsed - I get asked for confirmation
on potentially unsafe values, and after confirming, C-h v ... shows
that the value has been set correctly.

Does this maybe have to do with export happening in a temporary
buffer? I would assume that file local variables get copied over to
the temp buffer as buffer local variables. Is that the case?

Regards,
Jake

[O] Export code and results in one environment

[Jacob Gerlach]

Hello,

I'd like to export a source block and it's results together in one latex
environment. I came up with a solution using the final filter below.

Is there a better way?

Thanks,
Jake

  #+BEGIN_SRC emacs-lisp :exports none :results silent
(defun combine-verb-final-filter (s backend info)
  (when (eq backend 'latex)
  (replace-regexp-in-string "end{verbatim}\n*begin{verbatim}"
""
s nil t)))
(add-to-list 'org-export-filter-final-output-functions
'combine-verb-final-filter)
  #+END_SRC

Works, given:
--
#+BEGIN_SRC sh :exports both
echo "Hello"
#+END_SRC

#+RESULTS:
: Hello
--
Produces (desired effect):
--
\begin{verbatim}
echo "Hello"

Hello
\end{verbatim}
--

[O] Treat custom environment as verbatim on export

[Jacob Gerlach]

Hello,

I want to use a one of several custom environments for some babel
results using, for example, ":wrap myverbatim" as a header argument.
(Since I have several possible environments, I think I need to use
:wrap rather than, say, replacing "verbatim" using an export filter).

However, since this block isn't recognized as an actual verbatim
environment, markup gets processed in undesirable ways.

For example:

-
#+BEGIN_SRC sh :exports results :wrap myverbatim
echo "Hello_world"
#+END_SRC

#+RESULTS:
#+BEGIN_myverbatim
Hello_world
#+END_myverbatim
-
exports to
-
\begin{myverbatim}
Hello\(_{\text{world}}\)
\end{myverbatim}
-
instead of
-
\begin{myverbatim}
Hello_world
\end{myverbatim}
-

A couple questions:

- Is there any way I've missed to specify verbatim export as an option
for an arbitrary block/environment?

- If not, I think that I need a derived exporter to achieve this, but
the `contents' of a special-block have already had markup transcoded
by the time the derived backend function sees them. What functions
would my derived backend need to replace to allow applying verbatim
formatting to block types of my choosing?

Thanks for any tips,
Jake

Re: [O] Treat custom environment as verbatim on export

[Jacob Gerlach]

Hello,

On Sun, May 24, 2015 at 3:43 PM, Charles C. Berry  wrote:
> Currently, :wrap allows this:
>
> #+begin_src emacs-lisp :wrap "src latex :wrap my-verbatim"  :exports results
...

This is sufficient for my use case. Thanks for the tip.

A special block ":raw" parameter, as Rasmus suggested, is what I was
really asking for (without realizing it), but as Nicolas said it isn't
worth implementing, Charles's solution works fine.

While obvious in hindsight, it didn't occur to me that marking the
results as LaTeX would protect them from interpretation just as
"verbatim" does.

Thanks for the help,
Jake

Re: [O] babel setup

[Jacob Gerlach]

I think this has to do with autoload, but I am not an emacs or org expert.

Try making sure that (package-initialize) comes before any org functions in
your .emacs (from the answer here

).

HTH,
Jake


On Mon, Jun 9, 2014 at 1:18 AM, Shiyuan  wrote:

> Hi all,
>   I am using Emacs 24.3.9 + org-mode 8.2.6(from ELPA)
>   I followed this instruction
> http://orgmode.org/worg/org-contrib/babel/languages.html#configure
>
> and added the following to my .emacs file.
>
> (org-babel-do-load-languages
>   'org-babel-load-languages
>   '((python . t)
> (emacs-lisp . t)))
>
> After that, org-mode mysteriously switched back to the old version 7.9.
>  Another problem is that export command C-c C-e no longer works and
> generates error: Symbol's function definition is void: org-defvaralias. Is
> there any step I missed? Thanks.
>
> Shiyuan
>
>
>
>

Re: [O] Only on my computer, Invalid function: org-with-silent-modifications

[Jacob Gerlach]

I have no idea if it relates to what you describe with cask and
dependencies, but I had the same error and found several old threads
stating that it's caused by installing org when it's already initialized.

I solved it by Emacs -q and reinstalling from elpa. If you search for the
old threads there was a link to documentation that explains why this occurs
which may be of some help addressing with cask.
On Jun 17, 2014 3:38 PM, "Grant Rettke"  wrote:

> Good afternoon,
>
> Just upgraded to 8.2.7 and was surprised to get the
> "org-with-silent-modifications" error. Here is what happened.
>
> The first time that I set up my Emacs libraries, using Cask, which
> uses the Emacs package manager, it install org2blog which has org
> 8.2.6 as a dependency. Then, Cask installed org-plus-contrib 8.2.6 and
> life went on. Then I can cask update to get the 8.2.7 release (Cask
> just pulls from the org repo).
>
> Started up Emacs and got that aforementioned error. The issue seemed
> to revolve around load-path or
> load-order, and I didn't understand any further than that. It was very
> strange because my whole approach
> had been to automate everything so it would "just work".
>
> Poking around, I eventually saw that org2blog depends on "org" (yes
> now I admit that I didn't know this when
> at first, but that is not relevant here I believe). That just didn't
> look right to have both orgs in there, so I deleted plain old "org"
> and commented out the org2blog load. Now Emacs works again.
>
> The issue seems to be that org-plus-contrib doesn't satisfy "org" from
> a package manager perspective.
>
> This surprised me because the former is a superset.
>
> My next step now is to figure out what to do from a package
> perspective, because I would like to keep
> org2blog in there.
>
> Anyone else encountered this and want to share the solution?
>
> I'm going to think about this some more and see.
>
> Kind regards,
>
> Grant Rettke | AAAS, ACM, ASA, FSF, IEEE, SIAM, Sigma Xi
> g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
> “Wisdom begins in wonder.” --Socrates
> ((λ (x) (x x)) (λ (x) (x x)))
> “Life has become immeasurably better since I have been forced to stop
> taking it seriously.” --Thompson
>
>