Ihor Radchenko writes:
> It has been over one month since the last message in this thread.
> Gavin, may I know if you are still interested to work on the patch?
Apologies for the lack of communication. I do plan on working on this
patch in the near future.
Gavin Downard writes:
> This patch does prioritize named columns over named fields, which can
> break compatibility in tables with a named column and named field with
> the same name. Alternatively, we could prioritize named fields to
> preserve compatibility, but since named columns are prioriti
Gavin Downard writes:
> (*): the issue with `org-table-formula-substitute-names' as it is, is
> that it will replace field names with the field /value/, not the field
> index. Hopefully modifying the function to replace field names with
> their indices won't break anything, so we can use the same
Max Nikulin writes:
> The regexp for parsing formulas does not allow named references after @.
> I have no idea if other code should be modified as well. I consider it
> as more important than detection of duplicated definitions.
Yeah, besides changing the regexp, the main thing that will need to
On 25/07/2023 03:29, Gavin Downard wrote:
Max Nikulin writes:
I have tried the patch. The formula for the named column "$three=" does
not work.
| ! | one | two | three | four |
|---+-+-+---+--|
| # | 1 | 2 | |3 |
#+tblfm: @>$5=$one+$two::@>$three=$one+$two
Yeah,
Max Nikulin writes:
> I have tried the patch. The formula for the named column "$three=" does
> not work.
>
> | ! | one | two | three | four |
> |---+-+-+---+--|
> | # | 1 | 2 | |3 |
>
> #+tblfm: @>$5=$one+$two::@>$three=$one+$two
Yeah, I guess my current patch only
On 19/07/2023 09:36, Gavin Downard wrote:
This patch does prioritize named columns over named fields, which can
break compatibility in tables with a named column and named field with
the same name.
I have tried the patch. The formula for the named column "$three=" does
not work.
| ! | one |
Gavin Downard writes:
> Ihor Radchenko writes:
>> Do we have any tests covering this part of the code?
>
> Not that I know of. I can add a test case for this specific instance,
> but I'm not sure if I should add more comprehensive tests in this patch.
> What do you think?
I'd prefer to see test
Ihor Radchenko writes:
> Do we have any tests covering this part of the code?
Not that I know of. I can add a test case for this specific instance,
but I'm not sure if I should add more comprehensive tests in this patch.
What do you think?
> In Emacs 26, we will need (require 'subr-x), but other
Gavin Downard writes:
>> Notice
>> "Double definition `%s=' in TBLFM line, please fix by hand"
>>
>> below. A bit more code is required to keep this sanity check for named
>> columns.
>>
>
> Oh, good catch. Specifically, I think this should be caught inside of
> `org-table-recalc
Max Nikulin writes:
> On 19/07/2023 09:36, Gavin Downard wrote:
>> +++ b/lisp/org-table.el
>> @@ -2253,8 +2253,7 @@ LOCATION is a buffer position, consider the formulas
>> there."
>> ((not (match-end 2)) m)
>> ;; Is it a column reference?
>>
Max Nikulin writes:
>> I cannot find anything blocking the proposed change.
>
> I have not found anything valuable as well. So the only conflict is
> named cell vs. named column.
> ...
I followed similar trace.
> So names after $ were used in the past, but only named fields are
> currently su
On 22/07/2023 14:25, Ihor Radchenko wrote:
Max Nikulin writes:
Perhaps git blame for the manual may give some hints. If the change is
really old then org.texi (removed at certain moment) should be inspected
as well.
This has been added very, very long time ago. org-table has undergone
through
On 19/07/2023 09:36, Gavin Downard wrote:
+++ b/lisp/org-table.el
@@ -2253,8 +2253,7 @@ LOCATION is a buffer position, consider the formulas
there."
((not (match-end 2)) m)
;; Is it a column reference?
((string-match-p "\\`\
Max Nikulin writes:
> Perhaps git blame for the manual may give some hints. If the change is
> really old then org.texi (removed at certain moment) should be inspected
> as well.
This has been added very, very long time ago. org-table has undergone
through major transformations since that time
On 22/07/2023 01:33, Gavin Downard wrote:
Max Nikulin writes:
When I tried table formulas a couple of years ago I was surprised that it is not
possible to use column names to specify target cells. At first glance it should
be a great feature. Have you searched the mailing list archive whether i
Max Nikulin writes:
> When I tried table formulas a couple of years ago I was surprised that it is
> not
> possible to use column names to specify target cells. At first glance it
> should
> be a great feature. Have you searched the mailing list archive whether it was
> requested earlier? Ther
On 19/07/2023 14:44, Ihor Radchenko wrote:
Do I understand correctly the named columns where not allowed at all in
the left side of the formulas previously?
When I tried table formulas a couple of years ago I was surprised that
it is not possible to use column names to specify target cells. A
Gavin Downard writes:
> This patch does prioritize named columns over named fields, which can
> break compatibility in tables with a named column and named field with
> the same name. Alternatively, we could prioritize named fields to
> preserve compatibility, but since named columns are prioriti
19 matches
Mail list logo
