* lisp/org-table.el (org-table-convert-region): don't continue csv
importation which the point catches the end, this fixes an infinite
loop which was caused by the (point) never catching up with the
"end" marker
Hi,
I've just noticed that I get an infinite loop when importing csv tables
into Org-mode tables. For example calling
(org-table-convert-region (point-min) (point-max) '(4))
from inside of a simple text file containing the following
--8<---------------cut here---------------start------------->8---
1,2,3
1
2
3
5
--8<---------------cut here---------------end--------------->8---
results in an infinite loop. The attached patch fixes this issue [1],
however it seems weird that this would just surface now, given that the
code in question has been in the repo since last fall
,----
| commit 59c9c4cdd4
| Author: Carsten Dominik <carsten.dominik@gmail.com>
| Date: Mon Oct 26 12:31:16 2009 +0100
|
| Correctly interpret CVS tables with quoted fields
|
| The csv parser was very primitive, ignoring quoted fields. This is
| now fixed.
`----
Has anyone else noticed this problem? Should I go ahead and apply this
patch?
Best -- Eric
Footnotes:
[1]
>From 3c3f4ca9a34dca23051ca2f4e4518b416338d4f4 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Mon, 19 Jul 2010 13:45:25 -0700
Subject: [PATCH] org-table: fix infinite loop in table importation
* lisp/org-table.el (org-table-convert-region): don't continue csv
importation which the point catches the end, this fixes an infinite
loop which was caused by the (point) never catching up with the
"end" marker
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
Dan Davison writes:
> If a file contains "-1" followed by a newline and nothing else,
> org-table-import on that file fails. The first commit with this
> property is a commit (below) to do with CVS tables made a few
> days ago. I have given up trying to work out a good solution to
> this :) In case it is useful, the failure occurs when
> org-table-align is called at the end of
> org-table-convert-region. I think it is long-standing behaviour
> that hitting tab inside of
>
> |-1|
>
> doesn't make a table containing "-1", so presumably there is
> something different about the context in which org-table-align is
> now being called.
Francesco Pizzolante writes:
> I'm using orgmode 6.30c and I still have this problem: if
> the #+TBLNAME: tag is not located in column 0, the remote
> reference does not work.
>
> Here's my little test:
>
> #+TBLNAME: A
> | | T |
> |---+-------|
> | | 2.00 |
> | | 5.00 |
> |---+-------|
> | # | 9.00 |
> | ^ | total |
> #+TBLFM: $2=vsum(@-I..@-II);%.2f
>
> #+TBLNAME: price
> | T | PU | Total |
> |------+-------+-------|
> | 9.00 | 10.25 | 92.25 |
> |------+-------+-------|
> #+TBLFM: @2$1=remote(A,$total);%.2f::@2$3=$1*$2;%.2f
>
>
> Just add a few spaces at the first line and when you recompute
> the second table you get a "Can't find remote table A" message.
>
> Moreover, in a LaTeX environment, using the orgtbl minor mode,
> the highlighting (font locking) does not work on the #+TBLNAME:
> line, even if located in column 0.
Michael Brand writes:
> First, when I open a file with the content
>
> -*- eval: (org-mode) -*-
> #+STARTUP: align
> | <l8> |
> | 3.14 |
> | 3.1415926535897932384626433832795 |
>
> and answer yes, I get
>
> -*- eval: (org-mode) -*-
> #+STARTUP: align
> | <l8>| <l8> |
> | 3.14 |
> | 3.1415=> |
>
> but would expect
>
> -*- eval: (org-mode) -*-
> #+STARTUP: align
> | <l8> |
> | 3.14 |
> | 3.1415=> |
>
> Second, when I delete the last line and save the file, the file content
> will be
>
> -*- eval: (org-mode) -*-
> #+STARTUP: align
> | <l8>| <l8> |
> | 3.14 |
>
> as I can see e. g. with emacs itself when I close the file and open it
> again declining org-mode with answering no. But the file content should
> be
>
> -*- eval: (org-mode) -*-
> #+STARTUP: align
> | <l8> |
> | 3.14 |
>
> Can someone please confirm with a more stable and recent emacs version?
Karl Stump writes:
> Table Editing Cycle With Multiple Windows On One Buffer Does Not
> Return to Start State
>
> When I have two windows open on two buffers, one to a table in a
> file that I'm editing, the other to some other file of interest,
> the editing cycle of C-` ... C-c C-c works great, meaning that
> when the cycle is finished, the windows are restored to the start
> state.
>
> But when I have two windows open on the same buffer, one window
> on the table, and the other window somewhere else, the editing
> cycle does not restore to the beginning state.
Gregory Grubbs writes:
I like to make org-mode tables in arbitrary buffers, then
save them as CVS files. The export fails when done from a
buffer with no associated file.
Here's a little patch that allows exporting a table from
any buffer (org-mode version 6.28trans):
A relative row reference like @-1 in a table may now reach across a
horizontal separator line. I hope this will not break any important
tables out there, but I think it is the right thing to do.
The original reason for not-crossing was to implement running
averages of one column in the next. This can now be done using field
formulas near the beginning and end of the column, and a column
formula for the central part.
See the variable `org-table-relative-ref-may-cross-hline' for more
details.
