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.
Michael Brand writes:
> 2) One could like to have configurable left/right alignment, even
> combinable with column width, e. g.
>
> | <l10> | <r> |
> | 3.14 | 0x10 |
> | 3.141592=> | 0x32 0x10 |
Good idea, I would say.
When yasnippet is active, it is the official binding of TAB. That
means, the org-mode self-insert command must know that it may blank
table fields if the last command was yas/expand.
Rares Vernica writes:
> I think the standard references do not work correctly in the
> "remote" function. Moreover, the "edit all formulas" (C-c ')
> window replaces the internal references with standard
> references. Even if I toggle the references back to internal
> ones, the references in the "remote" function do not get
> updated.
>
> Here is an example:
>
> #+TBLNAME: TableA
> | 101 |
> #+TBLFM: @1$1=remote(TableC,@1$1)
>
> #+TBLNAME: TableB
> | A1 |
> #+TBLFM: @1$1=remote(TableC,A1)
>
> #+TBLNAME: TableC
> | 101 |
>
> If I do C-c * in TableA, it works correctly. In TableB it
> doesn't. If I do C-c ' in TableA and then (with or without
> C-c C-r) C-c C-c and C-c *, then the contents of TableA will
> be equivalent to the ones of TableB and the reference will
> be broken.
Standard references like A1 are now allowed in call to
remote().
Rares Vernica writes:
> I think I found another bug related to remote
> references. When I insert/remove a row/column using the
> table commands, the remote references to other tables are
> also updated. I think org treats "remote" as a regular
> function and updates the references inside it.
>
> Here is an example:
>
> #+TBLNAME: TableA
> | 101 |
> #+TBLFM: @1$1=remote(TableB,@1$1)
>
> #+TBLNAME: TableB
> | 101 |
>
> If I go in the cell of TableA and do M-S-down arrow, I get
> the following:
>
> #+TBLNAME: TableA
> | |
> | 101 |
> #+TBLFM: @2$1=remote(TableB,@2$1)
> ^^^^
>
> As you can see the remote reference has been updated. I
> similar update happens when I remove a row or insert/remove
> a column.
This commit makes sure that references inside calls to
remote() are not touched.
