The following is very simple org-mode spreadsheet in which the cells in the second column show the triple of the corresponding cell in the first column due to the "column formula" in its TBLFM row $2=3*$1;N. However the third row (actually row @4) is an exception because of the "cell formula" @4$2=string("Exception") which expectedly overrides the above column formula.

|--------+-----------|
| Number |    Triple |
|--------+-----------|
|      1 |         3 |
|      2 |         6 |
|      3 | Exception |
|      4 |        12 |
|--------+-----------|
#+TBLFM: $2=3*$1::@4$2=string("Exception")

So all is well. Below you will find a copy of the above table, except that, after copying, I have deleted the exceptional formula affecting cell @4$2.

|--------+-----------|
| Number |    Triple |
|--------+-----------|
|      1 |         3 |
|      2 |         6 |
|      3 | Exception |
|      4 |        12 |
|--------+-----------|
#+TBLFM: $2=3*$1

One would expect that, after updating this table with C-u C-c *, or C-c C-c in the TBLFM line, the exceptional value in cell @4$2 would revert to the triple of '3', but instead the string "Exception" stays put. Is this a bug or am I doing something wrong?

I noticed that if I save the file, close it (kill-buffer) and then reopen it, the strange behaviour disapears, namely, updating the table with C-u C-c * causes cell @4$2 to turn to '9', as expected.

I am using GNU Emacs 24.3.1 and the latest version of org-mode.

up vote 3 down vote accepted

The persistence of the string exception has nothing to do with copying. If you recalculate the original table and afterwards remove the field formula from it you also have the problem that exception is not replaced by 9 at the next recalculation.

The reason for that behavior is that the text property :org-untouchable is put on the output of field formulas. The normal function of :org-untouchable is to prevent the modification of cells with field formulas during the evaluation of a column formulas.

In my opinion the :org-untouchable property should be removed at the beginning of calls to org-table-iterate and at the beginning of interactive calls of org-table-recalculate.

You can obtain this behavior with the advices below. These advices are tested with org-version 9.0.5 in emacs 25.1.50.2.

I would agree that the original behavior is faulty. Therefore, I suggest to file a bug-report at https://lists.gnu.org/mailman/listinfo/emacs-orgmode. A proper bug-fix should probably be implemented differently.

(defun org-table-remove-untouchable (&rest _args)
  "Remove `:org-untouchable' property from org-table."
  (save-excursion
    (cl-assert (org-at-table-p) nil "Not in org-table.")
    (remove-text-properties (org-table-begin) (org-table-end) '(:org-untouchable nil))))

(defun org-table-recalculate-remove-untouchable (&optional all _noalign)
  "Remove `:org-untouchable' property at the beginning of `org-table-iterate'.
Use this function as :before advice of `org-table-iterate'."
  (when (and (called-interactively-p 'any)
         all)
    (org-table-remove-untouchable)))

(advice-add 'org-table-iterate :before #'org-table-remove-untouchable)
(advice-add 'org-table-recalculate :before #'org-table-recalculate-remove-untouchable)
  • Hi @Tobias, thanks very much for your clarification! I will file the bug report as you suggest. – Ruy Nov 14 '17 at 11:13
  • My impression is that the implementation of cell-formulas within column-formulas by means of messing with properties is a bad ideal. It would be much better to treat these exceptional formulas by themselves, perhaps after all column formulas are applied, updating the cell entries in the usual way. – Ruy Nov 14 '17 at 11:49
  • The bug report was filed and it has been fixed by Nicolas Goaziou (lists.gnu.org/archive/html/emacs-orgmode/2017-11/msg00183.html). Nicolas also explained to me the purpose of using text properties to deal with cell-formulas within columns affected by column-formulas and I am now convinced that this if indeed a good way to proceed, contrary to my first impression above. – Ruy Nov 16 '17 at 16:20

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.