[PATCH]: Fix to spreadsheet ranges in A1 style

[PATCH]: Fix to spreadsheet ranges in A1 style

[Bake Timmons]

A simple elisp formula in the spreadsheet indicated a couple of errors
in the handling of ranges:

'(car '(A4..C4))

This was using org.el from the latest Emacs cvs MAIN branch.  I have
appended a patch against this as one possible fix.  Thanks.

--- src/emacs/lisp/textmodes/org.el	2007-08-18 20:37:11.000000000 -0400
+++ build/emacs/lisp/textmodes/org.el	2007-08-19 22:27:06.000000000 -0400
@@ -8839,6 +8839,7 @@
 	   (if (eq lispp 'literal)
 	       x
 	     (prin1-to-string (if numbers (string-to-number x) x))))
+	 elements
 	 " ")
       (concat "[" (mapconcat
 		   (lambda (x)
@@ -9131,8 +9132,11 @@
        ((match-end 3)
 	;; format match, just advance
 	(setq start (match-end 0)))
-       ((and (> (match-beginning 0) 0)
-	     (equal ?. (aref s (max (1- (match-beginning 0)) 0))))
+       ((let ((pos (match-beginning 0)))
+	  (and (> pos 0)
+	       (equal ?. (aref s (1- pos)))
+	       ;; not using .. for a range reference
+	       (or (< pos 2) (not (equal ?. (aref s (1- pos)))))))
 	;; 3.e5 or something like this.  FIXME: is this ok????
 	(setq start (match-end 0)))
        (t

Re: [PATCH]: Fix to spreadsheet ranges in A1 style

[Carsten Dominik]

On Aug 20, 2007, at 4:46, Bake Timmons wrote:

> A simple elisp formula in the spreadsheet indicated a couple of errors
> in the handling of ranges:
>
> '(car '(A4..C4))
>
> This was using org.el from the latest Emacs cvs MAIN branch.  I have
> appended a patch against this as one possible fix.  Thanks.
>
> --- src/emacs/lisp/textmodes/org.el	2007-08-18 20:37:11.000000000 -0400
> +++ build/emacs/lisp/textmodes/org.el	2007-08-19 22:27:06.000000000 
> -0400
> @@ -8839,6 +8839,7 @@
>  	   (if (eq lispp 'literal)
>  	       x
>  	     (prin1-to-string (if numbers (string-to-number x) x))))
> +	 elements
>  	 " ")


Yes, this was a bug.

>        (concat "[" (mapconcat
>  		   (lambda (x)
> @@ -9131,8 +9132,11 @@
>         ((match-end 3)
>  	;; format match, just advance
>  	(setq start (match-end 0)))
> -       ((and (> (match-beginning 0) 0)
> -	     (equal ?. (aref s (max (1- (match-beginning 0)) 0))))
> +       ((let ((pos (match-beginning 0)))
> +	  (and (> pos 0)
> +	       (equal ?. (aref s (1- pos)))
> +	       ;; not using .. for a range reference
> +	       (or (< pos 2) (not (equal ?. (aref s (1- pos)))))))
>  	;; 3.e5 or something like this.  FIXME: is this ok????
>  	(setq start (match-end 0)))
>         (t

Could you please explain this part of the patch to me?
Thanks.

- Carsten

Re: [PATCH]: Fix to spreadsheet ranges in A1 style

[Bake Timmons]

Carsten Dominik <dominik@science.uva.nl> writes:

> On Aug 20, 2007, at 4:46, Bake Timmons wrote:
>>        (concat "[" (mapconcat
>>  		   (lambda (x)
>> @@ -9131,8 +9132,11 @@
>>         ((match-end 3)
>>  	;; format match, just advance
>>  	(setq start (match-end 0)))
>> -       ((and (> (match-beginning 0) 0)
>> -	     (equal ?. (aref s (max (1- (match-beginning 0)) 0))))
>> +       ((let ((pos (match-beginning 0)))
>> +	  (and (> pos 0)
>> +	       (equal ?. (aref s (1- pos)))
>> +	       ;; not using .. for a range reference
>> +	       (or (< pos 2) (not (equal ?. (aref s (1- pos)))))))
>>  	;; 3.e5 or something like this.  FIXME: is this ok????
>>  	(setq start (match-end 0)))
>>         (t
>
> Could you please explain this part of the patch to me?
> Thanks.

After fixing the mapconcat bug, I reloaded the code and observed an
erroneous conversion of a range in an elisp formula.  E.g., during
formula debugging A1..B1 becomes @1$1..B1 instead of @1$1..@1$2.  More
debugging showed that A1 match correctly takes the final branch of the
cond within the org-table-convert-refs-to-rc function and is
converted, but that the match for B1 erroneously matched the second
condition of the cond form, i.e., it is treated as something in
scientific notation and is incorrectly skipped over.  Thus, I changed
the test to ensure that no additional "." is adjacent to the already
recognized ".".  Moreover, I eliminated the max function call, since a
positive number minus one is already nonnegative.  Thanks.