Re: [O] [BUG] hline references on left side of table formula

[Rick Frankel]

On 2013-11-06 15:14, Achim Gratz wrote:
> Achim Gratz writes:
> [...]
> with these formulas:
> #+TBLFM: $=vsum(@address@hidden)
>
> whoops, press C-c C-c in the wrong buffer.
>
> I meant these formulas:
>
> #+TBLFM: @$=vsum(@address@hidden)
> #+TBLFM: @II=vsum(@address@hidden)
> #+TBLFM: @III=vsum(@address@hidden)
> #+TBLFM: @IIII=vsum(@address@hidden)
> #+TBLFM: @II..$2=vsum(@address@hidden)
> #+TBLFM: @III..$2=vsum(@address@hidden)
> #+TBLFM: @IIII..$2=vsum(@address@hidden)
> #+TBLFM: @address@hidden(@address@hidden)
> #+TBLFM: @address@hidden(@address@hidden)
>
> Some of the results are useful when your table has a certain, even
> though in general this does the wrong thing as Carsten said.  I'm not
> really having an opinion on whether this should be an error (as your
> previous patch does, which should then add a correction to the test 
> that
> is now failing) or if some / all of this should stay allowed until
> somebody musters the time to fix it properly (I think this would amount
> to re-implementing a good part of what is org-table).


Ok, i see what's happening in your examples (a testing org file
attached), though i question the usefullness of most of the results ;).

The updated patch attached to the previous email (fixed as pointed out
by michael):

--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -3016,8 +3016,9 @@ known that the table will be realigned a little 
later anyway."
;; Insert constants in all formulas
(setq eqlist
(mapcar (lambda (x)
-             (if (string-match "address@hidden" (car x))
-             (user-error "Can't assign to hline relative reference"))
+             (if (and (string-match "address@hidden" (car x))
+                  (not (string-match "\\.\\.@" (car x))))
+             (user-error "Can't assign to hline relative reference 
without a range specification."))
(when (string-match "\\`$[<>]" (car x))
(setq lhs1 (car x))
(setq x (cons (substring

Both fixes the testing issue and allows what seems to me to be the
most relevant use-case.

I have no real position on whether the best solution is to back out
the change, or modify it as above to make the test pass and allow the
logical usecase.

If the first, I think it would be useful for the documentation to
(somehow) explain what happens if an explicit column specificaton is
made without a corresponding range.

Please chime in on which patch should be applied.

rick

tblref.org
Description: Text document