minor niggles concerning tables

minor niggles concerning tables

[William Henney]

Hi Carsten

Every time I use org's tables I am amazed at how powerful and easy
they are. There are just a couple of annoyances that I repeatedly come
across, and which I thought I'd better report.

* minor niggles concerning tables
** org-table-toggle-coordinate-overlays
   This is great, but it is less useful than it might be because it
   uses the notation A1, B2, etc, whereas the canonical notation (as
   used by org-table-eval-formula and in the TBLFM line) is @1$1,
   @1$2. This introduces quite a cognitive load in translating between
   the two, especially since one is row-major while the other is
   column-major.
** numbers like "1.e3"
   I am in the (lazy) habit of omitting the zero after the decimal
   point in scientific notation. This causes no problems in most
   programming languages, or for calc.el, but it is misinterpreted in
   table formulae. Is it possible to easily fix this?

Cheers

Will

-- 

  Dr William Henney, Centro de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

Re: minor niggles concerning tables

[Carsten Dominik]

On Jun 4, 2007, at 18:05, William Henney wrote:

> Hi Carsten
>
> Every time I use org's tables I am amazed at how powerful and easy
> they are. There are just a couple of annoyances that I repeatedly come
> across, and which I thought I'd better report.
>
> * minor niggles concerning tables
> ** org-table-toggle-coordinate-overlays
>   This is great, but it is less useful than it might be because it
>   uses the notation A1, B2, etc, whereas the canonical notation (as
>   used by org-table-eval-formula and in the TBLFM line) is @1$1,
>   @1$2.

In fact, org-table-eval-formula understands both kinds of references.

> This introduces quite a cognitive load in translating between
>   the two, especially since one is row-major while the other is
>   column-major.

Yes, I agree, this is hard and a bit unfortunate.  If I could
start from scratch, I would make but the same, but for backward
compatibility I cannot.

If you prefer the @row$column references, have you set

    (setq org-table-use-standard-references nil)

?.  Obviously not, because this also causes the coordinate grid
to change.  However, I now see that there is a little bug - you
should also get the other grid with

    (setq org-table-use-standard-references 'from)

which is probably the best setting if you prefer this type
of references.  However, this does not yet work right.
Will be fixed in 4.77.

The right setting of this variable is important in particular for the
formula editor (C-c ').  Have you ever tried it?

> ** numbers like "1.e3"
>   I am in the (lazy) habit of omitting the zero after the decimal
>   point in scientific notation. This causes no problems in most
>   programming languages, or for calc.el, but it is misinterpreted in
>   table formulae. Is it possible to easily fix this?

Interesting bug!  Fixed as well, thank you very much.

- Carsten

Re: minor niggles concerning tables

[William Henney]

On 6/4/07, Carsten Dominik <dominik@science.uva.nl> wrote:
>
> In fact, org-table-eval-formula understands both kinds of references.
>

Yes, of course, silly me!

> Yes, I agree, this is hard and a bit unfortunate.  If I could
> start from scratch, I would make but the same, but for backward
> compatibility I cannot.

Understood.

> The right setting of this variable is important in particular for the
> formula editor (C-c ').  Have you ever tried it?
>

No. Thanks for the pointer.

> > ** numbers like "1.e3"
> >   I am in the (lazy) habit of omitting the zero after the decimal
> >   point in scientific notation. This causes no problems in most
> >   programming languages, or for calc.el, but it is misinterpreted in
> >   table formulae. Is it possible to easily fix this?
>
> Interesting bug!  Fixed as well, thank you very much.
>

Great.

Cheers

Will

-- 

  Dr William Henney, Centro de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia