Re: OT: M-S-$ Not Working
Marcin Borkowski writes: > Hi Bo, > > I know your problem is resolved now, but in case you don't know, check > also what `C-h c' does (and `C-h k' is also useful at times). In > general, spending 20 minutes on looking through what `C-h C-h' says > might save you some trouble later;-). > This is good advice. I would add that if you find that Emacs does not respond, even to say that the key is not bound or defined, it is typically a sign that something in the environment e.g. window manager or X (or Wayland) layer is not passing the key press through. These are layers which are often overlooked and I've seen people spend hours inside Emacs trying to work out what the issue is, only to later find it is at a different layer (OS, windowing environment, window manager, etc). In general, standard Emacs key bindings are robust and reliable. If a standard key binding like M-S $ doesn't work, first step is to try emacs -Q. If that still does not work, odds are high it is an issue outside of Emacs. Most common causes are WM shortcuts, modified input device definitions (as seems to be the culprit here) and modified modmap settings. Utilities like 'xev' can be useful here (not sure what wayland has). When I install a new system (regardless of platform, linux, mac, windows), my first task is usually to remove or remap shortcuts. These days, most environments use super, alt, meta and control based shortcuts, many of which interfere with my Emacs. I rarely use super in my Emacs key bindings, so often I remap useful WM shortcuts to use super. -- Tim Cross
[SOLVED] Re: [ISSUE] org-agenda with clocktable infinite on logbook which has text-propertize links
<#secure method=pgpmime mode=sign> Problem solved by adding an condition to detect current mode whether it is org-agenda-mode. -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: OT: M-S-$ Not Working
Hi Bo, I know your problem is resolved now, but in case you don't know, check also what `C-h c' does (and `C-h k' is also useful at times). In general, spending 20 minutes on looking through what `C-h C-h' says might save you some trouble later;-). Hth, mb On 2021-02-05, at 00:25, Bo Grimes wrote: > I beg your indulgence. I am confident this isn't an Emacs problem, let > alone an org problem, but my eyes hurt from searching for an answer, > and this list, the only one I subscribe to, is populated with gurus. I > promise never to use it this way again. > > OS: PopOS 20.10, DE: GNOME 3.38.2 WM: Mutter > GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) > > M-S-$ does not spellcheck word. It will work from the menu bar, and it > will work if I drop into a tty and run Emacs. Emacs gives no > response in the minibuffer in the GUI when I press M-S-$. M-x > describe-key M-S-$ does nothing. C-h b C-s 'spell' reveals that indeed > M-S-$ is bound to spellcheck word. And other M-S- keys work like M-S-> > just fine. > > There has to be some keybinding outside Emacs taking precedence. I have > gone through dconf-editor until my eyes bleed. Done gsettings > list-recursively org.gnome.desktop.wm.keybindings | sort | more and > gone line by line. I have done dconf dump / > dconf.dump and read > through them all, in addition to checking PopOS' keybindings in > Settings. And trying a different keyboard. > > Nothing in Tweeks, dconf, or Settings uses M-S-$, but I disabled > anything that uses Shift anyway (nothing uses $). No joy. I don't want > to rebind it for this machine only, nor do I want to go through the > hassle of installing a different DM/WM. > > StackExchange, et.al are full of problems with the the M key, but not > one specific keychord only. > > Any ideas? I will accept rebukes. I'm desperate. TIA! > > Bo Grimes -- Marcin Borkowski http://mbork.pl
Re: [WDYT, mini] key h in agenda for quick help
i guess i was merely saying: instead of h, which a new user might not try, something that works for everything in emacs might be a possibility. but c-h m and c-h b could perhaps be improved a bit and include mode-specific text [details left to reader as exercise]. On 2/5/21, Marco Wahl wrote: > Samuel Wales writes: > >> are there precedents? calc? h in dired does c-h m. > > Looks to me like calc shines brightest with its help system which btw > one enters with key h. > > Up to now I see the precedents > > - dired > - help-mode > - view-mode > - Buffer-menu-mode > > They all have h be the same as C-h m (describe-mode) AFAICS. > >> just a brainstorm but maybe c-h m and c-h b can be more friendly for all >> modes? > > I don't get this. Would you like to elaborate, please? > > > Ciao, > -- Marco > > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [WDYT, mini] key h in agenda for quick help
Samuel Wales writes: > are there precedents? calc? h in dired does c-h m. Looks to me like calc shines brightest with its help system which btw one enters with key h. Up to now I see the precedents - dired - help-mode - view-mode - Buffer-menu-mode They all have h be the same as C-h m (describe-mode) AFAICS. > just a brainstorm but maybe c-h m and c-h b can be more friendly for all > modes? I don't get this. Would you like to elaborate, please? Ciao, -- Marco
Re: [WDYT, mini] key h in agenda for quick help
are there precedents? calc? h in dired does c-h m.
just a brainstorm but maybe c-h m and c-h b can be more friendly for all modes?
On 2/5/21, Marco Wahl wrote:
> Robert Pluim writes:
>
>>> On Fri, 05 Feb 2021 11:34:41 +0100, Marco Wahl
>>> said:
>>
>> Marco> Hi all!
>> Marco> What do you think about binding key h to function describe-mode
>> in Org
>> Marco> agenda? Basically pressing key h would open a window showing
>> the key
>> Marco> bindings in the agenda. There would also be additional
>> information.
>>
>> Marco> The implementation could be just the line
>>
>> Marco> (org-defkey org-agenda-mode-map (kbd "h") #'describe-mode)
>>
>> Marco> Also not that key h has no default binding in Org agenda yet!
>>
>> Itʼs bound to 'org-agenda-holidays'
>
> OMG! How could I not see this? Thanks!
>
>> Marco> The connoisseur of course knows that describe-mode is already
>> just a
>> Marco> {C-h m} away from the Org agenda. Anyway I think having {h} in
>> the
>> Marco> agenda would be nice. This would also be consistent with
>> Marco> e.g. help-mode.
>>
>> Meh. People should learn. Bah humbug ;-)
>
> :)
>
> I just see that with the Org default org-agenda-holidays can be called
> with either key h or key H.
>
> What luxury for org-agenda-holidays is this?!
>
> I recreate this suggestion and propose to sacrifice the current default
> binding of h. Let h open the quick help!
>
>
> Ciao,
> --
> Marco
>
>
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Free up C-c SPC/org-table-blank-field?
Carsten Dominik writes: > On Fri, Feb 5, 2021 at 11:13 AM Christian Moe wrote: > >> >> Tim Cross writes: >> >> > Eric Abrahamsen writes: >> > >> >>> Does it actually need a key binding? I've never used it and just use >> >>> to move to the next field, leaving the field blank. >> >> >> >> I assume it's meant for blanking a field you've already typed something >> >> into. But yes, I can't imagine it's a heavily-used command, and I >> >> suspect the C-c binding is mostly mnemonic: "make this field >> >> contain only blanks". >> >> >> > >> > I guess that makes sense, but not convinced the use of a valuable key >> > binding is justified given the need. Then again, others probably have >> > vastly different use cases to mine. >> >> One can also blank a field by pressing immediately after tabbing >> into it. So C-c isn't strictly needed. >> > > Hi, > > I think there would be minimal impact from releasing this key binding. So > I think we could remove it. Well that would be pretty nice, if you don't think it would be too disruptive. Shall I prepare a patch? Thanks, Eric
[Resolved]Re: OT: M-S-$ Not Working
On Fri, 5 Feb 2021 21:40:25 +0700 Maxim Nikulin wrote: > On 05/02/2021 06:25, Bo Grimes wrote: > > > > OS: PopOS 20.10, DE: GNOME 3.38.2 WM: Mutter > > GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) > > > > M-S-$ does not spellcheck word. > > Does C-h l view-lossage show something useful after an attempt to > perform spellcheck? Is there anything in the *Message* buffer? Thanks! I didn't know C-h l, and I never thought to check messages. Sorry, I'm a non-tech, learn-what-I-need-as-I-go-but-committed-to-FOSS guy. Unfortunately, messages doesn't show anything, and here's the output of C-h l, which I ran first as a marker, then typed a commonly misspelled word, did M-S-$, and then ran it again: C-h l [view-lossage] m [org-self-insert-command] i [org-self-insert-command] s [org-self-insert-command] p [org-self-insert-command] e [org-self-insert-command] l [org-self-insert-command] l [org-self-insert-command] C-h l [view-lossage] Nothing between the last two, which is when I did M-S-$ > > I could not suggest something in the case of wayland session, but if > it is X11 then attempt to acquire key grab should fail if another > application already set this shortcut. So you could try if e.g. > xbindkeys would report a conflict if such keystroke is added to its > config. I have never used it, but there is an interesting feature > XF86LogGrabInfo: > https://askubuntu.com/questions/406543/unable-to-set-a-shortcut-to-grab-screenshot-area > > Due to global shortcut emacs should lose focus for a moment and it > should be noticeable. I would also check if xev reports expected key > symbol. Just to be sure that $ is in its usual place yet. > So, that took me down a rabbit hole that led me nowhere in terms of understanding wayland, Xorg, or X11 configs, BUT, somewhere down there I got to thinking about how one of the first things I do on a new system is remap Ctrl to Caps Lock. I usually just do setxkbmap -layout us -option ctrl:nocaps, but in attempting to see if there was a problem there I was led to closely examine Tweeks Additional Layout Options, where I saw Shift Does Not Cancel Num Lock, choose 3rd lvl instead. I have no idea what 3rd level is, but before I ticked it I turned off my number lock, and C-S-$ worked! So I ticked it and it stopped working. So I unticked it and ticked Number keypad always enters digits, which is, of course, why I use Num Lock to begin with. With that ticked Emacs behaves as expected. I have always used Num Lock and never had that problems Wow! Thanks for taking the time to put me in the rabbit hole on an OT message!!! Frustrating, but less frustrating than a new distro or DM, and I learned some things! I am really grateful! Cheers, Bo Grimes
Re: use-package mistake?
Sorry, this was meant for emacs.stackexchange.
On Thu, Feb 4, 2021 at 2:49 PM Lawrence Bottorff wrote:
> Each time I call up list-package and update, I get this message after the
> updates
>
> Operation finished. Packages that are no longer needed: 43. Type ‘M-x
> package-autoremove’ to remove them
>
> Below is my init.el concerning use-package
>
> (require 'package)
> (setq package-enable-at-startup nil)
>
> (setq package-archives '(("ELPA" . "http://tromey.com/elpa/;)
> ("gnu" . "http://elpa.gnu.org/packages/;)
> ("melpa" . "https://melpa.org/packages/;)
> ("org" . "https://orgmode.org/elpa/;)))
>
> (package-initialize)
>
> ;;; Bootstrapping use-package, i.e., if use-package isn't installed
> ;;; then install it
> (unless (package-installed-p 'use-package)
> (package-refresh-contents)
> (package-install 'use-package))
>
> ;;;This will ensure all packages are installed if not already
> (require 'use-package-ensure)
> (setq use-package-always-ensure t)
>
> ;;;This will make sure packages are updated
> (use-package auto-package-update
> :config
> (setq auto-package-update-delete-old-versions t)
> (setq auto-package-update-interval 1)
> (setq auto-package-update-hide-results t)
> (auto-package-update-maybe))
>
>
> I obviously don't want to uninstall all the packages on my system. What
> have I done wrong? Can you critique my setup here?
>
> LB
>
bug? Newline inserted when referencing a block result with ":cache yes" in a "noweb" reference
* The context Let's suppose we have two code blocks whose results we want to use in multiple code blocks. The result of this code block is cached. #+NAME: test-cache #+begin_src sh :cache yes printf "%s" 5 #+end_src #+RESULTS[4981a8c18361e02d50b4d3ac3677e0c56e9ba9c0]: test-cache #+begin_example 5 #+end_example while the results of this one isn't cached. #+NAME: test-no-cache #+begin_src sh :cache no printf "%s" 5 #+end_src #+RESULTS: test-no-cache #+begin_example 5 #+end_example Let's insert each result in a different code block through a =noweb= reference so that we can get to the issue. #+begin_src sh :eval no :noweb yes :tangle ./test-cache.sh echo "Hello <>. Lorem ipsum." #+end_src #+begin_src sh :eval no :noweb yes :tangle ./test-no-cache.sh echo "Hello <>. Lorem ipsum." #+end_src The tangling of the files mentioned above would result in #+begin_src dash cat test-cache.sh #+end_src #+RESULTS: #+begin_example echo "Hello 5 echo "Hello . Lorem ipsum." #+end_example #+begin_src dash cat test-no-cache.sh #+end_src #+RESULTS: #+begin_example echo "Hello 5. Lorem ipsum." #+end_example As we could see above, a newline is inserted when referencing the results of the code block which had the =:cache= header argument set to =yes=. This didn't happen with the code block which had =:cache= set to no. * The questions 1. Is this normal behavior or is it a bug? 2. How can I make a newline not to be inserted when referencing the result of a code block which had =:cache= set to =yes= -- Greetings, Rodrigo Morales.
Re: Bug: (org-release) returns empty string on Elpa [ ( @ /home/pierre/.guix-profile/share/emacs/site-lisp/)]
> Based on tested in a `git clone --no-tags ...` repo, should be fixed by > 61336f80d. Looks like it works: the `version.el` in https://elpa.gnu.org/devel/org-9.5snapshot0.20210205.62105.tar now says: (defun org-release () "The release version of Org. Inserted by installing Org mode or when a release is made." (let ((org-release "9.5-dev")) org-release)) ;;;###autoload (defun org-git-version () "The Git version of Org mode. Inserted by installing Org or when a release is made." (let ((org-git-version "9.5-dev-g2512fd")) org-git-version)) Thanks, Stefan
Re: OT: M-S-$ Not Working
On 05/02/2021 06:25, Bo Grimes wrote: OS: PopOS 20.10, DE: GNOME 3.38.2 WM: Mutter GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) M-S-$ does not spellcheck word. Does C-h l view-lossage show something useful after an attempt to perform spellcheck? Is there anything in the *Message* buffer? I could not suggest something in the case of wayland session, but if it is X11 then attempt to acquire key grab should fail if another application already set this shortcut. So you could try if e.g. xbindkeys would report a conflict if such keystroke is added to its config. I have never used it, but there is an interesting feature XF86LogGrabInfo: https://askubuntu.com/questions/406543/unable-to-set-a-shortcut-to-grab-screenshot-area Due to global shortcut emacs should lose focus for a moment and it should be noticeable. I would also check if xev reports expected key symbol. Just to be sure that $ is in its usual place yet.
Re: OT: M-S-$ Not Working
On Fri, 05 Feb 2021 14:20:46 +1100 Tim Cross wrote: > Do you see the same behaviour if you run emacs -Q? I hadn't tried that, which should have been a first step, but I just did, and yes. Nothing happens and Emacs gives no feedback. I did go ahead and try a new DM (Regolith, because it's built on Ubuntu and Gnome, so I thought it would easily integrate), and M-S-$ works fine, so it has to be somewhere in Pop or Gnome shell, but I'll be danged if I can figure it out. At this point I'll probably either rebind it or install a DM like Mate that won't require too much adaptation. Thanks for the suggestion!
Bug: Double quotes in tables and arguments
Hi,
I'm working with tokenized texts in org-mode tables including single
characters such as double quotes. When trying to read a cell with an
(unpaired) double quote at the beginning, the cell cannot be read ("End
of file during parsing"). I've looked a bit into this (see attached
file). At first, I thought it's a mere documentation issue: Double
quotes probably have a special meaning. The documentation of
org-bable-read (ob-core.el) does not mention a double quote as special
character:
> "Convert the string value of CELL to a number if appropriate.
> Otherwise if CELL looks like lisp (meaning it starts with a
> \"(\", \"\\='\", \"\\=`\" or a \"[\") then read and evaluate it as
> lisp, otherwise return it unmodified as a string. Optional
> argument INHIBIT-LISP-EVAL inhibits lisp evaluation for
> situations in which is it not appropriate."
This is how cells with double quotes at the beginning are read:
> ((eq (string-to-char cell) ?\") (read cell))
I don't know why double quotes are handled as special characters and I
did not find any documentation on it.
This issue also exists when caching results from code blocks: If a
result starts with an (unpaired) double quote and it is cached, it
cannot be read anymore.
Best,
Christine
#+NAME: print
#+begin_src emacs-lisp :var data=""
(print data)
#+end_src
Double quotes are preserved as long as there is no double quote as
first character:
#+NAME: ex1
| a" |
Sourrounding double quotes are stripped:
#+NAME: ex2
| "a" |
#+CALL: print(data=ex2)
#+RESULTS:
| a |
This is unexpected:
#+NAME: ex2b
| "this_stays"this_has_to_go |
#+CALL: print(data=ex2b)
#+RESULTS:
| this_stays |
(Unpaired) double quote at beginning results in "End of file during
parsing":
#+NAME: ex3
| " |
#+CALL: print(data=ex3)
Passing an argument with (unpaired) double quote as first character to
code blocks works...
#+NAME: ex-code1
#+begin_src emacs-lisp
'("\"")
#+end_src
#+CALL: print(data=ex-code1)
#+RESULTS:
| " |
... as long as it's not from a cached result.
#+NAME: ex-code3
#+begin_src emacs-lisp :cache yes
'("\"")
#+end_src
#+RESULTS[f8bc0a680e2f0b8e579b262a13747cef1522cd72]: ex-code3
| " |
This results in "End of file during parsing":
#+CALL: print(data=ex-code3)
Re: [WDYT, mini] key h in agenda for quick help
Robert Pluim writes:
>> On Fri, 05 Feb 2021 11:34:41 +0100, Marco Wahl
>> said:
>
> Marco> Hi all!
> Marco> What do you think about binding key h to function describe-mode in
> Org
> Marco> agenda? Basically pressing key h would open a window showing the
> key
> Marco> bindings in the agenda. There would also be additional
> information.
>
> Marco> The implementation could be just the line
>
> Marco> (org-defkey org-agenda-mode-map (kbd "h") #'describe-mode)
>
> Marco> Also not that key h has no default binding in Org agenda yet!
>
> Itʼs bound to 'org-agenda-holidays'
OMG! How could I not see this? Thanks!
> Marco> The connoisseur of course knows that describe-mode is already just
> a
> Marco> {C-h m} away from the Org agenda. Anyway I think having {h} in the
> Marco> agenda would be nice. This would also be consistent with
> Marco> e.g. help-mode.
>
> Meh. People should learn. Bah humbug ;-)
:)
I just see that with the Org default org-agenda-holidays can be called
with either key h or key H.
What luxury for org-agenda-holidays is this?!
I recreate this suggestion and propose to sacrifice the current default
binding of h. Let h open the quick help!
Ciao,
--
Marco
Re: [WDYT, mini] key h in agenda for quick help
> On Fri, 05 Feb 2021 11:34:41 +0100, Marco Wahl
> said:
Marco> Hi all!
Marco> What do you think about binding key h to function describe-mode in
Org
Marco> agenda? Basically pressing key h would open a window showing the key
Marco> bindings in the agenda. There would also be additional information.
Marco> The implementation could be just the line
Marco> (org-defkey org-agenda-mode-map (kbd "h") #'describe-mode)
Marco> Also not that key h has no default binding in Org agenda yet!
Itʼs bound to 'org-agenda-holidays'
Marco> The connoisseur of course knows that describe-mode is already just a
Marco> {C-h m} away from the Org agenda. Anyway I think having {h} in the
Marco> agenda would be nice. This would also be consistent with
Marco> e.g. help-mode.
Meh. People should learn. Bah humbug ;-)
Robert
Re: Free up C-c SPC/org-table-blank-field?
On Fri, Feb 5, 2021 at 11:13 AM Christian Moe wrote: > > Tim Cross writes: > > > Eric Abrahamsen writes: > > > >>> Does it actually need a key binding? I've never used it and just use > >>> to move to the next field, leaving the field blank. > >> > >> I assume it's meant for blanking a field you've already typed something > >> into. But yes, I can't imagine it's a heavily-used command, and I > >> suspect the C-c binding is mostly mnemonic: "make this field > >> contain only blanks". > >> > > > > I guess that makes sense, but not convinced the use of a valuable key > > binding is justified given the need. Then again, others probably have > > vastly different use cases to mine. > > One can also blank a field by pressing immediately after tabbing > into it. So C-c isn't strictly needed. > Hi, I think there would be minimal impact from releasing this key binding. So I think we could remove it. Carsten > > (Though since you typically discover you want to blank a field only when > you're actually in it, it can help shave a few seconds off your day that > you'd otherwise use to move out of the field you want to blank and tab > back in ... which is how I've done this until now, being unaware of C-c > ). > > Yours, > Christian > >
[WDYT, mini] key h in agenda for quick help
Hi all!
What do you think about binding key h to function describe-mode in Org
agenda? Basically pressing key h would open a window showing the key
bindings in the agenda. There would also be additional information.
The implementation could be just the line
(org-defkey org-agenda-mode-map (kbd "h") #'describe-mode)
Also not that key h has no default binding in Org agenda yet!
The connoisseur of course knows that describe-mode is already just a
{C-h m} away from the Org agenda. Anyway I think having {h} in the
agenda would be nice. This would also be consistent with
e.g. help-mode.
Thanks for reading and best regards,
--
Marco
Re: Free up C-c SPC/org-table-blank-field?
Tim Cross writes: > Eric Abrahamsen writes: > >>> Does it actually need a key binding? I've never used it and just use >>> to move to the next field, leaving the field blank. >> >> I assume it's meant for blanking a field you've already typed something >> into. But yes, I can't imagine it's a heavily-used command, and I >> suspect the C-c binding is mostly mnemonic: "make this field >> contain only blanks". >> > > I guess that makes sense, but not convinced the use of a valuable key > binding is justified given the need. Then again, others probably have > vastly different use cases to mine. One can also blank a field by pressing immediately after tabbing into it. So C-c isn't strictly needed. (Though since you typically discover you want to blank a field only when you're actually in it, it can help shave a few seconds off your day that you'd otherwise use to move out of the field you want to blank and tab back in ... which is how I've done this until now, being unaware of C-c ). Yours, Christian
[PATCH] ox-bb.el: Add BBCode exporter
Hi,
after getting an encouraging reply to my initial proposal[1], I went
forward and finished the patch to include the BBCode exporter in Org.
The patch applies to current master and includes a suite of tests.
Please review and/or apply this patch.
Best regards,
Christian
[1] https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00151.html
--
Christian.Garbshttps://www.cgarbs.de
It seemed like a good idea at the time.
>From 04888bb0146d0f0cf3bf82cea4f0ea1b761c1d08 Mon Sep 17 00:00:00 2001
From: Christian Garbs
Date: Fri, 8 Jan 2021 20:39:29 +0100
Subject: [PATCH] ox-bb.el: Add BBCode exporter
* lisp/ox-bb.el: Add export backend for BBCode format.
* testing/lisp/test-ox-bb.el: Add tests for ox-bb.el.
* doc/org-manual.org (Exporting): Add section about BBCode export.
* etc/ORG-NEWS: Announce BBCode exporter as a new feature.
---
doc/org-manual.org | 29 +++
etc/ORG-NEWS | 10 +
lisp/ox-bb.el | 423 +++
testing/lisp/test-ox-bb.el | 503 +
4 files changed, 965 insertions(+)
create mode 100644 lisp/ox-bb.el
create mode 100644 testing/lisp/test-ox-bb.el
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 20a0d1d7a..ff19b5111 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12281,6 +12281,35 @@ It's just a jump to the left...
,#+END_JUSTIFYRIGHT
#+end_example
+** BBCode Export
+:PROPERTIES:
+:DESCRIPTION: Exporting to BBCode.
+:END:
+#+cindex: BBCode export
+
+BBCode export produces an output file containing BBCode markup. Code
+sections are exported as =[code]= blocks for the GeSHI formatter found
+in some web forums.
+
+*** BBCode export commands
+:PROPERTIES:
+:UNNUMBERED: notoc
+:END:
+
+#+attr_texinfo: :sep ,
+- {{{kbd(C-c C-e b f)}}} (~org-bb-export-to-bbcode~) ::
+ #+kindex: C-c C-e b f
+ #+findex: org-bb-export-to-bbcode
+
+ Export as a BBCode formatted text file with a =.bbcode= extension,
+ overwriting without warning.
+
+- {{{kbd(C-c C-e b b)}}} (~org-bb-export-to-bbcode~) ::
+ #+kindex: C-c C-e b b
+ #+findex: org-bb-export-as-bbcode
+
+ Export to a temporary buffer. Does not create a file.
+
** Beamer Export
:PROPERTIES:
:DESCRIPTION: Producing presentations and slides.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ba769224f..035abba1b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -156,6 +156,16 @@ tags including from both buffer local and user defined persistent
global list (~org-tag-alist~ and ~org-tag-persistent-alist~). Now
option ~org-complete-tags-always-offer-all-agenda-tags~ is honored.
+*** New BBCode export backend
+
+A new export backend generates BBCode as used in many internet forums.
+Code blocks will be exported as =[code]= blocks for the GeSHi
+formatter. There are no configurable options.
+
+You can export to a temporary buffer using == or to a
+file with extension =.bbcode= (overwritten without warning) via ==.
+
** Miscellaneous
*** =org-goto-first-child= now works before first heading
diff --git a/lisp/ox-bb.el b/lisp/ox-bb.el
new file mode 100644
index 0..50271e675
--- /dev/null
+++ b/lisp/ox-bb.el
@@ -0,0 +1,423 @@
+;;; ox-bb.el --- BBCode Back-End for Org Export Engine -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2017-2021 Free Software Foundation, Inc.
+;; Author: org, wp, bbcode
+
+;; This file is part of ox-bb.
+
+;; GNU EMacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs. If not, see
