This is the fifth patch in a series that makes some straightforward
corrections to a number of docstrings. Each change is normally to:
- correct a typo, or
- fix up hyperlinks to function or variable names, or
- ensure slightly better conformance with the documentation guidelines
and tips given in the Elisp manual
No attempt is made to provide missing docstrings or document arguments.
Cheers,
Phil
This patch changes the functionality of orgtbl-to-orgtbl so that it will
remove newline characters from the text of table cells and replace them
with "\n". This protects the final table from such newlines.
This patch will probably only have any noticeable effect for tables
imported form external files, or from the results of code blocks.
Best -- Eric
>From 34aacc9aa037e8f17c8d32ed61a25f0a350713a0 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Fri, 18 Jun 2010 12:38:26 -0700
Subject: [PATCH] org-table: will now strip newlines from the text of table cells
* lisp/org-table.el (orgtbl-to-generic): added the :remove-newlines
option which will strip newline characters from the text of table
cells and replace then with "\n"
(orgtbl-to-orgtbl): now using the new :remove-newlines option to
orgtbl-to-generic
* lisp/org.el (org-edit-special): Make sure source code editing goes
before table formula editing.
* lisp/org-table.el (org-table-fedit-map): "C-c '" will now also exit
the formula editor.
* lisp/org-compat.el (org-string-match-p):
(org-looking-at-p): New functions.
* lisp/org-table.el (org-table-align): Handle raised text with
invisible characters.
* lisp/org.el (org-script-display): Add raise properties for tables.
(org-raise-scripts): Handle raising differently inside tables.
Pretty display of subscripts and superscripts no longer messes up
table alignment. This is achieved by two things:
1. Inside tables, the raised characters are not made smaller, they
remains at the same size. Instead they are raise/lowered more, by
a full half character height to still be clearly readable as
subscript or superscript.
2. The invisible characters are taken into account when computing the
field width.
Karl Eichwalder writes:
> Consider the following two files:
>
> * 2009
> #+TBLNAME: 2009
> :PROPERTIES:
> :ID: ea32e5b5-31ba-468e-8e31-3e0d09696bb0
> :END:
> |-----+-------|
> | mm | km |
> |-----+-------|
> | all | 946.8 |
> |-----+-------|
>
> * 2010
> #+TBLNAME: 2010
> :PROPERTIES:
> :ID: e0df84c4-8abc-458f-a1ee-eb53eb71b4f0
> :END:
> |-----+-------+-------+-------|
> | mm | km | B km | G km |
> |-----+-------+-------+-------|
> | all | 249.4 | 429.2 | 678.6 |
> |-----+-------+-------+-------|
>
> * all
> :PROPERTIES:
> :ID: 44751a7f-73a4-4c07-b3c2-e3edb9042acd
> :END:
> #+TBLNAME: all
> |------+--------|
> | yyyy | km |
> |------+--------|
> | 2009 | |
> | 2010 | 678.6 |
> |------+--------|
> | all | 1625.4 |
> |------+--------|
> #+TBLFM: @2$2=remote(ea32e5b5-31ba-468e-8e31-3e0d09696bb0,$LR2);%.1f::@3$2=remote(2010,$LR4);%.1f::$LR2=vsum(@2$2..@-1);%.1f
>
> Then, in the 2010 file, eval the formula of the "all" table by pressing
> C-c C-c.
> ==>
>
> It takes the km value from the 2009 file, but also puts the cursor
> (point) into the 2009 file in front of the ID:
>
> * 2009
> #+TBLNAME: 2009
> :PROPERTIES:
> :ID: -!-ea32e5b5-31ba-468e-8e31-3e0d09696bb0
> :END:
> |-----+-------|
> | mm | km |
> |-----+-------|
> | all | 946.8 |
> |-----+-------|
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=- cut here -=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> I'd prefer if the point would stay in the 2010 file.
Willian Henney writes:
> The following is using today's git trunk of org-mode with emacs
> 23.1.94.1 (aquamacs 2.0preview5)
>
> Consider the following table
>
> | -8 |
> | |
> | |
> | |
> #+TBLFM: $1=@-1 - 1::@1$1=-8
>
> Evaluate formulas once (C-u C-c *):
>
> | -8 |
> | -9 |
> |----|
> | -1 |
>
> Evaluate formulas again (C-u C-c *):
>
> | -8 |
> | -9 |
> |----|
> |----|
>
> What I expected:
>
> | -8 |
> | -9 |
> | -10 |
> | -11 |
>
> The problem always seems to start at -10. When I turn on table
> debugging, it first calculates the -10 value correctly, but then fails
> to recognise the -10 cell as a number when calculating the next row,
> using 0 instead, which results in -1. This is because during the
> intermediate formatting of the cell the minus sign in -10 abuts the
> column separator: "|-10 |", and the "|-" part is then interpreted as
> the beginning of an hline.
William Henney writes:
> Anyone have a clue what is going on here?
>
> Cheers
>
> Will
>
> * Arctan2 bug
> Activate the formula editor for the following table with =C-c '=, then
> exit without changing anything. Note what happens to the arctan2
> formula. For me, "arctan2" changes to "@2$20173232".
> | x | y | arctan | arctan2 |
> |---+---+--------+---------|
> | 1 | 1 | 45 | 45. |
> #+TBLFM: $3=arctan($1/$2)::$4=arctan2($1,$2)
>
> ** Versions
> Org 6.34trans, Aquamacs 2.0preview4, Emacs 23.1.92.1
Carsten Dominik
Philip Rooke
Eric Schulte