Re: [O] Bug: Corrupted export of tables to LaTeX math mode [8.3.6 (8.3.6-7-g4d7d52-elpaplus @ c:/Users/thoma/.emacs.d/elpa/org-plus-contrib-20161017/)]
thomas.stenh...@gmail.com writes:
> Given an org file with the following contents
>
> ---
> #+ATTR_LATEX: :mode math :environment bmatrix
> | 1 | 2 | 3 |
>
> whops
> ---
>
> when exporting to LaTeX using Org version 8.3.6 from
> http://orgmode.org/elpa/ render to LaTeX as follows:
>
> ---
> \[
> \begin{bmatrix}
> 1 & 2 \\
> \end{bmatrix}
>
> \] whops
> ---
>
> The offending bit is the vertical whitespace before \], which makes it
> incorrect input to pdflatex.
>
> Using the Org version 8.2.10 that ships with Emacs 25.1.1, the
> corresponding LaTeX is as follows
>
> ---
> \[\begin{bmatrix}
> 1 & 2 \\
> \end{bmatrix}\]
>
> whops
> ---
>
> which is valid input to pdflatex.
>
> The 3 files are in their entirety on
> https://gist.github.com/karvus/da4523fdef8f644a6aa183028093d0ca.
>
I can reproduce this and I think the problem is that the table includes the
empty line after it and that
gets carried into the data that org-export-data passes into org-latex-matrices.
I used the following file
--8<---cut here---start->8---
* foo
#+ATTR_LATEX: :mode math
| 1 | 2 |
whoops
--8<---cut here---end--->8---
and the data has a ":beg 8 :end 44" specification that correspond to the '#'
and the 'w' of the whoops.
However, it's hard to debug: when I try to edebug org-export-data I get the
attached backtrace, presumably
because the cl-macrolet in org-export-data confuses edebug:
Debugger entered--Lisp error: (invalid-read-syntax "Failed matching" (&rest
(&define name (&rest arg) cl-declarations-or-string def-body)))
signal(invalid-read-syntax ("Failed matching" (&rest (&define name (&rest
arg) cl-declarations-or-string def-body
edebug-syntax-error("Failed matching" (&rest (&define name (&rest arg)
cl-declarations-or-string def-body)))
apply(edebug-syntax-error ("Failed matching" (&rest (&define name (&rest arg)
cl-declarations-or-string def-body
edebug-no-matchbroken-link-handler (&rest body) (\` (condition-case err
(progn (\,@ body)) (org-link-broken (pcase (plist-get info :with-broken-links)
(... ...) (... ...) (_ nil))) (72447 (72448 . 72467) (72473 (72474 . 72479)
(72480 . 72484) . 72485) (72491 (72491 . 72492) (72492 (72493 . 72507) (72508 .
72511) (72515 (72516 . 72521) (72522 (72522 . 72524) (72524 . 72528) . 72528) .
72529) (72538 (72539 . 72554) (72557 (72558 . 72563) (72564 (72565 . 72574)
(72575 . 72579) (72580 . 72598) . 72599) (72604 (72605 ... ... . 72609) (72610
... ... ... . 72663) . 72664) (72669 (72670 ... ... . 72675) (72676 ... ... ...
. 72744) . 72745) (72750 (72751 . 72752) (72753 . 72756) . 72757) . 72758) .
72759) . 72760) . 72760) . 72761) . 72762) "Failed matching" (&rest (&define
name (&rest arg) cl-declarations-or-string def-body)))
edebug-match-sublistbroken-link-handler (&rest body) (\` (condition-case
err (progn (\,@ body)) (org-link-broken (pcase (plist-get info
:with-broken-links) (... ...) (... ...) (_ nil))) (72447 (72448 . 72467)
(72473 (72474 . 72479) (72480 . 72484) . 72485) (72491 (72491 . 72492) (72492
(72493 . 72507) (72508 . 72511) (72515 (72516 . 72521) (72522 (72522 . 72524)
(72524 . 72528) . 72528) . 72529) (72538 (72539 . 72554) (72557 (72558 . 72563)
(72564 (72565 . 72574) (72575 . 72579) (72580 . 72598) . 72599) (72604 (72605
... ... . 72609) (72610 ... ... ... . 72663) . 72664) (72669 (72670 ... ... .
72675) (72676 ... ... ... . 72744) . 72745) (72750 (72751 . 72752) (72753 .
72756) . 72757) . 72758) . 72759) . 72760) . 72760) . 72761) . 72762) (&rest
(&define name (&rest arg) cl-declarations-or-string def-body)))
edebug-match-list(broken-link-handler (&rest body) (\` (condition-case
err (progn (\,@ body)) (org-link-broken (pcase ... ... ... ...)) (let*
((type (org-element-type data)) (results (cond ((memq data ...) nil) ((eq type
...) (org-export-filter-apply-functions ... ... info)) ((not type) (mapconcat
... data "")) ((or ... ...) (let ... ...)) (t (let ... ...) (puthash data
(cond ((not results) "") ((memq type (quote ...)) results) (t (let (...)
results))) (plist-get info :exported-data (72446 (72447 (72448 . 72467)
(72473 (72474 . 72479) (72480 . 72484) . 72485) (72491 (72491 . 72492) (72492
(72493 . 72507) (72508 . 72511) (72515 (72516 . 72521) (72522 (72522 . 72524)
(72524 . 72528) . 72528) . 72529) (72538 (72539 . 72554) (72557 (72558 . 72563)
(72564 ... ... ... . 72599) (72604 ... ... . 72664) (72669 ... ... . 72745)
(72750 ... ... . 72757) . 72758) . 72759) . 72760) . 72760) . 72761) . 72762)
(72764 (72765 . 72769) (72770 (72771 (72772 . 72776) (72777 (72778 . 72794)
(72795 . 72799) . 72800) . 72801) (72810 (72811 . 72818) (72821 (72822 . 72826)
(72860 (72861 (72862 . 72866) (72867 . 72871) (72872 ... ... ... . 72901) .
72902) (72903 . 72906) . 72907) (72929 (72930 (72931 . 72933) (72934 . 72938)
(72939 ... ... . 72950) . 72951) (72956 (72957 . 72990) (72996 ... ... ... .
73031) (73037 ... .
[O] Bug: clocktable doesn't preserve formulas with :scope file-with-archives
Hi! I've found that the "#+TBLFM:" in a clocktable can get changed or
deleted when used together with ":scope file-with-archives". Here's a
minimal org file to reproduce with:
--8<--
* Test
:LOGBOOK:
CLOCK: [2016-10-20 Thu 17:42]--[2016-10-20 Thu 18:03] => 0:21
:END:
#+BEGIN: clocktable :scope file-with-archives
#+TBLFM: $3=string("foo")
#+END:
--8<--
Steps to reproduce:
1. emacs -Q, load above file with org-mode from Git
2. Update clocktable dblock (move to "#+BEGIN" and C-c C-c)
Expected result: a third column is added with value "foo" in every
row; #+TBLFM line is preserved
Observed result: table has two columns, the second of which contains
"foo" in every row; #+TBLFM line changes from $3=string("foo") to
$2=string("foo")
If you keep updating the block, the formula's "$2" then becomes "$1".
Do it one more time and the "#+TBLFM:" is preserved but now the
formula is gone entirely.
Emacs : GNU Emacs 25.1.1 (x86_64-apple-darwin15.6.0)
of 2016-09-23
Package: Org-mode version 8.2.10 (release_8.2.10 @ /opt/local/share/emacs/25.1/\
lisp/org/)
I have also reproduced this with org-mode from Git as of an hour or so ago.
My hunch is that the problem is in org-clocktable-write-default. It
writes the table (the dblock's contents have already been deleted),
restores any #+TBLFM: line that used to be there pre-update, and then,
if you're using :scope file-with-archives, it deletes the file column,
which is the first column. The order here is the problem:
org-table-delete-column updates the formula in #+TBLFM, decrementing
the column reference to account for the deleted column.
If this sounds right then I'd suggest that the solution may be as
simple as just updating org-clocktable-write-default to insert table
formulas *after* deleting the file column, along with some
I'm attaching a patch but I'm not sure whether you'll be able to use
it because my FSF assignment hasn't been updated for my new employer.
Even if you can't use it, hopefully my description above is still
useful.
Thanks!
Dale
clocktable-formulas.patch
Description: Binary data
Re: [O] [RFC] Change visibility for bracket links
Clément Pit--Claudel writes: > On 2016-10-13 08:30, Nicolas Goaziou wrote: >> I understand what `prettify-symbols-mode' is. My real problem is >> understanding how it can help with links in Org. In particular, I'd like >> to see it, or any other mechanism, turn >> >> [[http://orgmode.org][Org mode]] >> >> displayed as >> >> Org mode >> >> into >> >> [Org mode] >> >> when point is near _any_ of the boundaries and doesn't trigger anything >> on anything not related to an Org link. >> >> I don't know if that would be sufficient to make it useful, but it needs >> to be as subtle as possible. We already have a not-so-subtle solution >> with visible square brackets. > > Hey Nicolas, > > Something like this? > > (defvar-local org-show-link--beg nil) > (defvar-local org-show-link--end nil) > > (defun org-show-link--reveal-at-point (&rest _) > "Possibly reveal link markup around point." > (unless (and org-show-link--beg org-show-link--end) > (setq org-show-link--beg (make-marker) > org-show-link--end (make-marker))) > (when (and (marker-position org-show-link--beg) > (marker-position org-show-link--end)) > (unless (<= org-show-link--beg (point) org-show-link--end) > (save-excursion (font-lock-fontify-region org-show-link--beg > org-show-link--end)) > (set-marker org-show-link--beg nil) > (set-marker org-show-link--end nil))) > (save-excursion > (when (org-in-regexp org-bracket-link-regexp 1) > (set-marker org-show-link--beg (match-beginning 0)) > (set-marker org-show-link--end (match-end 0)) > (with-silent-modifications > (remove-text-properties (match-beginning 2) (1+ (match-beginning > 2)) '(invisible)) > (remove-text-properties (1- (match-end 2)) (match-end 2) > '(invisible) > (message "%S" org-show-link--end)) > > (defun org-show-link-setup () > (add-hook 'post-command-hook #'org-show-link--reveal-at-point t t)) > > (add-hook 'org-mode-hook #'org-show-link-setup) > > Running it before opening an Org buffer with links should be enough to > make it work (links brackets will be hidden until point is next to or > inside the link). It's a quick draft, of course — there are still > small issues. But it should give an idea of what my original proposal > was about. I love this! I have had problems with editing links at the start of lines etc, and this seems to solve it. I would love something similar for *bold* and /italics/ too. Stig
Re: [O] [ANN] [OT] New Android app (Orgzly)
Thomas Koch writes: > I would be happy to help you work out any blockers that hinders you from > releasing the source code. Several people told you that they would be happy > to > sponsor your ongoing work on Orgzly and I would so too. If you think your > code > is not ready yet to be seen by others, don't think so. It will never be ready. > > It would be a shame if all your great work could not be appreciated by a > larger audience. Really people use proprietary lisenses to hide their code quality? I find that hard to belive. Software is never done (at least thats true for free software) if nobody enhances/refactors it anymore there is just no real need for it anymore. So of course you should release early (in a bad state) and often. As long it dont makes the pc of others explode or eats their fs. You get then feedback as return and in this case even some money, at least you get more users for shure. But we did see in the past that some companies used the statement that they wanna open it up as trick to make some people buy it and use it and vendor lockin into it. I dont wanna be a dick or be not constructive, but it becomes harder to belive that you meant what you said about your intentions to release it less day by day. Well I dont care much anymore, had some owncloud / simpletask cloudness solution setup, which was at least good enough to see todo lists on android, but at the moment thats not so much of a priority of me to have at all. But sorry there might be other reasons like no time or something, but hiding bad code is no real reason at best a excuse to not release source code. Sorry I dont buy that. Its just a bit funny people that use emacs will be 90% very sensitive about the lisense/code question. So I cant even imagine that it makes much sense moneywise to make it impossible for 90% of your users to use that software. I get that argument by other software targeted to the avarage user, but in this case its just a loose-loose situation.
