[O] beamer export and links with spaces

[David Belohrad]

Dear All,

i'm using org documents export to beamer. Recently I've changed my directory 
structures for the screenshots such, that they are located under date 
subdirectories, e.g.:

screenshots/22 January 2016/140808_21161vUU.png


If I'm going org-type beamer document, I was always using this type of 
declaration to export the figure:

** Summary from previous session
#+BEGIN_CENTER
#+ATTR_LaTeX: :width 0.8\linewidth
[[file:screenshots/22%20January%202016/140808_21161vUU.png]]
#+END_CENTER

as you can see, the spaces are replaced by %20, which is perfectly fine if 
browsing the file in emacs and clicking on the link. The image is correctly 
opened.

This however does not work when beamer/latex is exported, as the org snippet 
gets translated into:


\section{Summary from previous session}
\label{sec:orgheadline2}
\begin{frame}[label={sec:orgheadline1}]{Summary from previous session}
\begin{center}
\includegraphics[width=0.8\linewidth]{screenshots/22%20January%202016/140808_21161vUU.png}
\end{center}
\end{frame}

hence the includegraphics does not contain space, but contains %20. Such file 
cannot be found.

What is the way to make it working? It seems that includegraphics generally 
does not like spaces inside unless one uses e.g. grffile, so the problem could 
be resolved just by replacing %20 in the latex output by an ordinary space and 
including \usepackage[space]{grffile}.

any hint?

thanks
.d.

Re: [O] Icalendar export and contacts

[Simon Thum]

I noticed one more strange thing:

the new exporter fails to resolve links to radio targets (which are 
slightly pointless but worked before). I'm not sure it needs fixing, 
just thought I'd let you know.


I.e. <<>>   <>

[[works]]
[[fails]]

Cheers,

Simon

On 02/12/2016 12:01 AM, Nicolas Goaziou wrote:

Hello,

Simon Thum  writes:


Unfortunately I now get

user-error: Unable to resolve link "tel:xxx"

and the icalendar export full stops. Is there a way to declare the
link type (I am loading org-contact)


See `org-add-link-type' in particular with the export argument.


or avoid the exporter messing with it?


This is only possible in development version.

Regards,

Re: [O] beamer export and links with spaces

[Eric S Fraga]

On Friday, 12 Feb 2016 at 09:57, David Belohrad wrote:

[...]

> What is the way to make it working? It seems that includegraphics
> generally does not like spaces inside unless one uses e.g. grffile, so
> the problem could be resolved just by replacing %20 in the latex
> output by an ordinary space and including \usepackage[space]{grffile}.
>
> any hint?

Avoid tilting at windmills and change the naming convention to, say,
.../2016-02-12/...?  I know this is not the answer you were wanting but
sometimes it's easier to make minor adjustments to a workflow than
trying to bend other tools to the workflow.

Spaces in file names cause all kinds of problems with many non-GUI tools
unfortunately.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-565-g4f499f

Re: [O] Columnview *** is exported as *

[Axel Kielhorn]

> Am 12.02.2016 um 00:46 schrieb Nicolas Goaziou :
> 
> Hello,
> 
> Axel Kielhorn  writes:
> 
>> When I overwrite the ITME with a custom text it doesn’t:
>> :COLUMNS:  %ITEM(Item) %6Zeit{+} %6Effort(Plan){+} %6Kosten{+} %10Fällig 
>> %Fertig{X/} %8TAGS(Verant.):
> 
> Fixed. Thank you.

Verified, thanks.

Axel

Re: [O] Errors get suppressed by org-babel-execute-src-block

[Aaron Ecay]

Hi Nick,

2016ko otsailak 11an, Nick Dokos-ek idatzi zuen:
> 
> Not sure if there are tests for remote babel execution, 

AFAIK no.  It would be useful to have these.  All the machines I use run
Linux and are configured very similarly.  Many of the problems in remote
execution come from differences in environments.  So it would be good if
someone could figure out how to test common configurations.  Until that
happens, we have to rely on ad hoc testing or user reports.

> but if not, please make sure to test that (with :dir set to some
> directory on a different machine). Michael Albinus had done some work
> to get that working a few years ago:

AFAICS my patch does not affect the work Michael did.  I will test some
simple remote execution scenarios before I push the patch, just in case.

> BTW, I tried to test, but applying the patch to current master
> (8eff64cffee8627578edc33de485201ae579fafe) fails:

Nicolas pushed some big changes to babel just after I sent my patch.
(Big in terms of the diff to the code, not necessarily in terms of
changing user behavior).  I haven’t looked in detail, but it’s almost
guaranteed that the patch now needs to be rebased, which I’ll do as
soon as I can.

-- 
Aaron Ecay

Re: [O] Errors get suppressed by org-babel-execute-src-block

[Aaron Ecay]

Hi Nicolas,

2016ko otsailak 10an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay  writes:
> 
>> I’d like to install the attached patch to master, if there are no
>> objections.  That should resolve your concern as well as cleaning up the
>> dead code.
> 
> No objection, but...
> 
>> +(require 'subr-x)   ; For `if-let'
> 
> ... you are not using `if-let' anywhere if this patch. 

Good catch.  I had used it in a previous version, then refactored it
away but forgot to remove the require.  I’ll push the patch once I have
a chance to rebase it on top of your recent babel changes.

> Besides, we still cannot use subr-x, since it is a 24.4 library, and,
> AFAIR, we didn't drop support for 24.3 yet.

I’ll keep that in mind.

Thanks,

-- 
Aaron Ecay

Re: [O] Orgmode slow on windows on startup [8.3.2 (8.3.2-10-g00dacd-elpa @ c:/Users/Michael/AppData/Roaming/.emacs.d/elpa/org-20151005/)]

[Michael Ziems]

Hello Nicolas,

i did the update but there is no change to my issue.
Actually the archiving / unarchiving is solving the issue.

Even the agenda building in the state before and after i do the 
archive/unarchive once is exremely different.


Everything is unusable slow before, but afterwards it works fine again.

It is all very strange, but i have it on two different windows machines 
and it is identical:


1. slow on startup
2. archive / unarchive of huge parts of my two big org files
3. system is fast again

to be honest, im absolutely clueless.
Archive / unarchive is doing something that speeds everything up.
Im glad that i found it because if not orgmode would not be usable for 
me at all anymore.


Am 11.02.2016 um 01:00 schrieb Nicolas Goaziou:

Hello,

Michael Ziems  writes:


im using orgmode and emacs on Windows.
When starting emacs, orgmode is extremely slow.
Pushing headlines arround, opening headlines and moving columns in
org-tables is a pain.
When i archive a big section in my org file through C-c C-x a and
unarchive it afterwards, then org gets really fast again.
just to show the issue i added the archiving as a profiler report
here:

I'm not sure why it gets faster on the second attempt, but
`org-toggle-archive-tag' is needlessly slow. I fixed the slowdown on
maint.

Does it fare better with the fix?


Regards,






smime.p7s
Description: S/MIME Cryptographic Signature

[O] problem with babel and dot

[Eric S Fraga]

Hello,

I have the following emacs lisp code to build up a dot input for a
dependency graph:

#+begin_src org
  ,#+name: graph-from-tables
  ,#+header: :var options="" :var nodes='() graph='()
  ,#+BEGIN_SRC emacs-lisp 
(org-babel-execute:dot
 (concat
  "digraph {\n"
  options "\n"   ;; "//rankdir=LR;\n" ;; remove comment characters '//' 
for horizontal layout; add for vertical layout
  (mapconcat
   (lambda (x)
 (format "%s [label=\"%s\" shape=%s style=\"filled\" 
fillcolor=\"%s\"]"
 (car x)
 (nth 1 x)
 (if (string= "" (nth 2 x)) "box" (nth 2 x))
 (if (string= "" (nth 3 x)) "none" (nth 3 x))
 )) nodes "\n")
  "\n"
  (mapconcat
   (lambda (x)
 (format "%s -> %s [taillabel=\"%s\"]"
 (car x) (nth 1 x) (nth 2 x))) graph "\n")
  "}\n") params)
  ,#+END_SRC
#+end_src

This used to work but was last used probably a year ago or more.

I invoke this function elsewhere in the document with a call like this:

#+begin_src org
  ,#+call: graph-from-tables[:file 
dependency-graph.pdf](options="rankdir=LR;",nodes=subtasks-table[2:-1],graph=dependency-table[2:-1])
 :results file :exports results
#+end_src

Two tables are used to describe the dependency graph and the information
passed to the function above works just fine.  The input file for dot
also looks perfect (and if I run dot on it, I get the graph I
want).  However, the result of the call here is a file,
dependency-graph.pdf, which has 3 bytes: "nil".

I have no idea how to get this working again.  ob-dot.el provides no
clues to me unfortunately.

Any pointers please?

Many thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-565-g4f499f

Re: [O] problem with babel and dot

[Eric S Fraga]

I've had a suggestion to use ":wrap src dot" for my elisp code, to avoid
using internal API calls.  This is a good suggestion but I cannot figure
out how to actually accomplish what I want.

Basically, I want to #+call: a src block which takes my tables as
arguments, uses my elisp code to generate a suitable DOT input and then
invokes DOT on that input to generate an image file specified on the
call invocation:

  tables -> emacs lisp -> dot -> pdf file

I think that a creative use of :post may do it but I cannot get my head
around how to invoke the various bits and/or pass the data I need.

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-565-g4f499f

[O] Integrating Skewer with org-babel-js

[Bill Burdick]

Hey there,

My skewer/org babel searches turned up nothing, so I made a simple hack
that redirects JS block evaluation in org mode through skewer when you are
connected (otherwise it uses standard org-js behavior).

I posted it to the skewer repo, but I have no idea whether it will be
integrated, so here it is:

https://gist.github.com/zot/0dd34b50acf81416dd88


-- Bill Burdick

Re: [O] Errors get suppressed by org-babel-execute-src-block

[Nick Dokos]

Aaron Ecay  writes:

> Hi Nick,
>
> 2016ko otsailak 11an, Nick Dokos-ek idatzi zuen:
>> 
>> Not sure if there are tests for remote babel execution, 
>
> AFAIK no.  It would be useful to have these.  All the machines I use run
> Linux and are configured very similarly.  Many of the problems in remote
> execution come from differences in environments.  So it would be good if
> someone could figure out how to test common configurations.  Until that
> happens, we have to rely on ad hoc testing or user reports.
>
I think tramp is pretty good at handling environment differences (and if
not, Michael is pretty responsive at modifying it to fix whatever
breakage people uncover), so for org-mode even simple tests in homogeneous
environments should be useful (e.g. using localhost as the "remote", or
the name of the machine that runs the test: not sure how much
optimization is done at various levels, but it might be enough to test
the remote code paths.)

>> but if not, please make sure to test that (with :dir set to some
>> directory on a different machine). Michael Albinus had done some work
>> to get that working a few years ago:
>
> AFAICS my patch does not affect the work Michael did.  I will test some
> simple remote execution scenarios before I push the patch, just in case.
>

OK - good!

>> BTW, I tried to test, but applying the patch to current master
>> (8eff64cffee8627578edc33de485201ae579fafe) fails:
>
> Nicolas pushed some big changes to babel just after I sent my patch.
> (Big in terms of the diff to the code, not necessarily in terms of
> changing user behavior).  I haven’t looked in detail, but it’s almost
> guaranteed that the patch now needs to be rebased, which I’ll do as
> soon as I can.

Thanks! If you post the patch, I'll try out some simple tests over the
weekend too.

--
Nick

Re: [O] ox-tufte-latex

[Eduardo Mercovich]

Dear Thomas.

> I've cobbled together an exporter for the Tufte LaTeX classes, which I'd
> like to contribute to Org mode contrib/. [...]

Having started with Org, Latex and Tufte-latex just a very little time
ago, I'd really like to thank you for your efforts. :)

However, I would appreciate some help with little details that I'm not
getting clear, mostly sure because of my ignorance.

+ what is the difference between using the :ignore: tag and add
"COMMENT" as the first characters in the line (the native Org mechanism
to prevent export)? I tried them and didn't saw the difference.

+ if I put a plain text link in a sidenote (like
"\sidenote{see http://AgileManifesto.org};), it doesn't get
automagically converted to a link as it is in the text body. It appears
as normal text and without the \url{...}, so it doesn't look and doesn't
act as a link. 

+ using links as specific Latex markup seems a great idea. However, the
links face definition makes it specially visible, and impossible to
separate from any other URL since the properties are hidden. Can that be
tweaked (maybe not it your class, of course, but in the .emacs file or
similar), so as to keep the writing flow unperturbed?

In any case, thank you very much for sharing. Org as writing environment
+ tufte-latex as export really help to make great looking documents. :)

Best...


-- 
eduardo mercovich 

 Donde se cruzan tus talentos 
 con las necesidades del mundo, 
 ahí está tu vocación. (Aristóteles)

Re: [O] ox-tufte-latex

[Thomas S . Dye]

Aloha Eduardo,

Eduardo Mercovich writes:

> However, I would appreciate some help with little details that I'm not
> getting clear, mostly sure because of my ignorance.
>
> + what is the difference between using the :ignore: tag and add
> "COMMENT" as the first characters in the line (the native Org mechanism
> to prevent export)? I tried them and didn't saw the difference.

With the :ignore: tag the headline is ignored, but the text below it is
exported.  This is useful for situations like the front matter of a
book, which is mostly assembled by LaTeX.  The :ignore: tag allows you
to isolate the various LaTeX commands in your document so they are
separate from the headings with text that you'll write, but still
contribute to the export.

>
> + if I put a plain text link in a sidenote (like
> "\sidenote{see http://AgileManifesto.org};), it doesn't get
> automagically converted to a link as it is in the text body. It appears
> as normal text and without the \url{...}, so it doesn't look and doesn't
> act as a link.

IIUC, I think you need to tell Org mode that this is a link:
\sidenote{see [[http://AgileManifesto.org]]}.

> + using links as specific Latex markup seems a great idea. However, the
> links face definition makes it specially visible, and impossible to
> separate from any other URL since the properties are hidden. Can that be
> tweaked (maybe not it your class, of course, but in the .emacs file or
> similar), so as to keep the writing flow unperturbed?

I agree that it would be useful to make the appearance of links in the
Org mode buffer configurable on a per-link basis.  Different colors for
different kinds of link might go some way to resolving the visual
ambiguities you describe.  However, I don't think this is currently
possible. 

Expanding link functionality is something that has been discussed on the
mailing list every once in a while for the last several years, but this
is an idea that fails to find traction with the Org mode developers.  I
reckon they know best.

In practice, I mouse over the link to see the link type in the minibuffer.

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

[O] Help understanding what's imported from a #+SETUPFILE file

[Kaushal Modi]

Hi,

I have a common setup file for all my org files which configure the way the
latex and HTML files are exported.

#+SETUPFILE: ~/org/common/config.org

One of the snippets in my config.org is

# Allow multi-page code listings by wrapping the `minted' environment with
`mdframed' environment
# http://tex.stackexchange.com/a/30524/52678
#+LaTeX_HEADER: \usepackage{mdframed}
#+LaTeX_HEADER: \mdfsetup{%
#+LaTeX_HEADER: topline=true, bottomline=true,leftline=true,
rightline=true, %
#+LaTeX_HEADER: innerleftmargin=15pt, %
#+LaTeX_HEADER: leftmargin=-5pt, %
#+LaTeX_HEADER: rightmargin=-5pt, %
#+LaTeX_HEADER: linewidth=1pt, backgroundcolor=yellow!20!white %
#+LaTeX_HEADER: }

#+LaTeX: \BeforeBeginEnvironment{minted}{\begin{mdframed}}
#+LaTeX: \AfterEndEnvironment{minted}{\end{mdframed}}

The #+LaTeX_HEADER lines get imported into the exported .tex file but the
#+LaTeX lines do not.

>From "C-h i g (org) In-buffer settings", I see that

‘#+SETUPFILE: file’
 This line defines a file that holds more in-buffer setup.  Normally
 this is entirely ignored.  Only when the buffer is parsed for
 option-setting lines (i.e., when starting Org mode for a file, when
 pressing ‘C-c C-c’ in a settings line, or when exporting), then the
 contents of this file are parsed as if they had been included in
 the buffer.  In particular, the file can be any other Org mode file
 with internal setup.  You can visit the file the cursor is in the
 line with ‘C-c '’.

But I did not find anything that explains which "#+" lines from SETUPFILE
are ignored.

I thought of using #+SETUPFILE as a clean way to import a common org setup
for exports. But should #+INCLUDE be used in this case instead?

Or what method would you guys suggest (may be using some elisp) so that I
do not need to manually enter the below in all my org files.

#+LaTeX: \BeforeBeginEnvironment{minted}{\begin{mdframed}}
#+LaTeX: \AfterEndEnvironment{minted}{\end{mdframed}}


--
Kaushal Modi

Re: [O] Help understanding what's imported from a #+SETUPFILE file

[Kaushal Modi]

Actually, I just realized that changing those 2 lines to:

#+LaTeX_HEADER: \BeforeBeginEnvironment{minted}{\begin{mdframed}}
#+LaTeX_HEADER: \AfterEndEnvironment{minted}{\end{mdframed}}

in the SETUPFILE works too. I don't recall the reason why I did not have
them as LaTeX_HEADER earlier.

But the question still remains.. is SETUPFILE designed to not export lines
beginning with #+LaTeX? Or a general question would be.. what stuff doesn't
SETUPFILE export?

Re: [O] Icalendar export and contacts

[Nicolas Goaziou]

Hello,

Simon Thum  writes:

> do you refer to master, maint or something else? I'm on 8.3 but am
> considering an upgrade.

Development version = master.

> Also I think org-contacts should declare the link type if it has
> support for it (in the vcard export). I'd be happy to do that if it
> can be done as a TINYCHANGE.

org-contacts is in contrib/ directory. TINYCHANGE tag is not required.

Regards,

-- 
Nicolas Goaziou

Re: [O] Help understanding what's imported from a #+SETUPFILE file

[Nicolas Goaziou]

Hello,

Kaushal Modi  writes:

> Actually, I just realized that changing those 2 lines to:
>
> #+LaTeX_HEADER: \BeforeBeginEnvironment{minted}{\begin{mdframed}}
> #+LaTeX_HEADER: \AfterEndEnvironment{minted}{\end{mdframed}}
>
> in the SETUPFILE works too. I don't recall the reason why I did not have
> them as LaTeX_HEADER earlier.
>
> But the question still remains.. is SETUPFILE designed to not export lines
> beginning with #+LaTeX? Or a general question would be.. what stuff doesn't
> SETUPFILE export?

SETUPFILE exports keywords defined in `org-export-options-alist' and in
back-end specific options (i.e. :options-alist). For example, in latex
back-end the latter category is

  LATEX_CLASS, LATEX_CLASS_OPTIONS, LATEX_HEADER, LATEX_HEADER_EXTRA,
  DESCRIPTION, KEYWORDS, SUBTITLE, LATEX_COMPILER, DATE

Regards,

-- 
Nicolas Goaziou

Re: [O] Icalendar export and contacts

[Nicolas Goaziou]

Hello,

Simon Thum  writes:

> I noticed one more strange thing:
>
> the new exporter fails to resolve links to radio targets (which are
> slightly pointless but worked before). I'm not sure it needs fixing,
> just thought I'd let you know.
>
> I.e. <<>>   <>
>
> [[works]]
> [[fails]]

It doesn't need to be fixed. Radio targets bring their own linking
mechanism.

Regards,

-- 
Nicolas Goaziou

Re: [O] Help understanding what's imported from a #+SETUPFILE file

[Kaushal Modi]

> SETUPFILE exports keywords defined in `org-export-options-alist' and in 
> back-end
specific options (i.e. :options-alist).

I tried "C-h v org-export-options-alist" but the result seemed cryptic to
me:

((:title "TITLE" nil nil parse) (:date "DATE" nil nil parse) (:author
 "AUTHOR" nil user-full-name parse) (:email "EMAIL" nil
 user-mail-address t) (:language "LANGUAGE" nil
 org-export-default-language t) (:select-tags "SELECT_TAGS" nil
 org-export-select-tags split) (:exclude-tags "EXCLUDE_TAGS" nil
 org-export-exclude-tags split) (:creator "CREATOR" nil
 org-export-creator-string) (:headline-levels nil "H"
 org-export-headline-levels) (:preserve-breaks nil "\\n"
 org-export-preserve-breaks) (:section-numbers nil "num"
 org-export-with-section-numbers) (:time-stamp-file nil "timestamp"
 org-export-time-stamp-file) (:with-archived-trees nil "arch"
 org-export-with-archived-trees) (:with-author nil "author"
 org-export-with-author) (:with-broken-links nil "broken-links"
 org-export-with-broken-links) (:with-clocks nil "c"
...

> For example, in latex back-end the latter category is
>   LATEX_CLASS, LATEX_CLASS_OPTIONS, LATEX_HEADER, LATEX_HEADER_EXTRA,
>   DESCRIPTION, KEYWORDS, SUBTITLE, LATEX_COMPILER, DATE

That helps. Thanks!

Re: [O] Help understanding what's imported from a #+SETUPFILE file

[Eric S Fraga]

On Friday, 12 Feb 2016 at 15:11, Kaushal Modi wrote:
> Actually, I just realized that changing those 2 lines to:
>
> #+LaTeX_HEADER: \BeforeBeginEnvironment{minted}{\begin{mdframed}}
> #+LaTeX_HEADER: \AfterEndEnvironment{minted}{\end{mdframed}}

This is indeed the solution.

> in the SETUPFILE works too. I don't recall the reason why I did not have
> them as LaTeX_HEADER earlier.
>
> But the question still remains.. is SETUPFILE designed to not export lines
> beginning with #+LaTeX? Or a general question would be.. what stuff doesn't
> SETUPFILE export?

I think you'll find that anything before the first headline (other than
header lines and document settings) is ignored when exporting to
LaTeX and that applies to all text, whether in the main file or from an
included file.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-565-g4f499f

Re: [O] Help understanding what's imported from a #+SETUPFILE file

[Nicolas Goaziou]

Hello,

Kaushal Modi  writes:

>> SETUPFILE exports keywords defined in `org-export-options-alist' and in 
>> back-end
> specific options (i.e. :options-alist).
>
> I tried "C-h v org-export-options-alist" but the result seemed cryptic to
> me:

Quoting its docstring:

  Alist between export properties and ways to set them.

  The key of the alist is the property name, and the value is a list
  like (KEYWORD OPTION DEFAULT BEHAVIOR) where:

  KEYWORD is a string representing a buffer keyword, or nil.
  ...

So you're looking for all string next to the keys, e.g. "TITLE".


Regards,

-- 
Nicolas Goaziou

Re: [O] Export org file to pdf: unable to resolve link

[Vikas Rawal]

> On 11-Feb-2016, at 6:36 pm, John Hendy  wrote:
> 
> On Thu, Feb 11, 2016 at 4:36 AM, Nicolas Goaziou  
> wrote:
>> Hello,
>> 
>> Sergio Bacelar  writes:
>> 
>>> Yes, that will work but I hoped that the file
>>> won't need to be changed to be exported to
>>> pdf.
>> 
>> You may ask for an upstream update, the syntax used in the document is
>> invalid (i.e., an internal link pointing to no active location).
> 
> Echoing this, and I think Vikas would want to know as well since it
> looks like a [awesome] document designed for reproducibility.
> 

My apologies to all for not being able to attend to the fix promptly. As it 
turned out, I had sometime noticed the bug, fixed it in my local copy and 
forgotten to push it to the remote. So my local copy was happily compiling.

I have now pushed my latest version. Please see if it compiles for you now.

Since I wrote this manual, I have learnt a few more things, and would like to 
update the manual. I hope to be able to do it in a few days.

Thanks everyone,

Vikas

[O] bug#22635: 25.1.50; wrong-type-argument when using org-beamer-select-environment

[Kyle Meyer]

Derek Feichtinger  writes:

> When executing C-c C-b (org-beamer-select-environment) in an org beamer
> using the current emacs head (git hash ae928ae), I reproducibly get
> the following
> error and backtrace, independent of the org beamer file used:
>
> ###
> Debugger entered--Lisp error: (wrong-type-argument listp t)
>   delete((org-filtered) t)
>   remove((org-filtered) t)
>   org-move-to-column(79 t)
>   org-fast-tag-show-exit(t)
>   org-fast-tag-selection(("B_note") nil ((:startgroup) ("B_againframe"
> . 65) ("B_appendix" . 120) ("B_column" . 99) ("B_columns" . 67)
> ("B_frame" . 102) ("B_fullframe" . 70) ("B_ignoreheading" . 105)
> ("B_note" . 110) ("B_noteNH" . 78) ("B_block" . 98) ("B_alertblock"
> . 97) ("B_verse" . 118) ("B_quotation" . 113) ("B_quote" . 81)
> ("B_structureenv" . 115) ("B_theorem" . 116) ("B_definition" . 100)
> ("B_example" . 101) ("B_exampleblock" . 69) ("B_proof" . 112)
> ("B_beamercolorbox" . 111) (:endgroup) ("BMCOL" . 124)) nil)
>   org-set-tags()
>   org-beamer-select-environment()

This was reported on the Org list and fixed in commit 34f3260 of the Org
repo.

  http://permalink.gmane.org/gmane.emacs.orgmode/104703

-- 
Kyle