Hi,
I lost track of the discussion in this thread.
My understanding is that there is no agreement on what feature
should be added to Org regarding "smarter interactive table import"
and a patch is not yet ready for the suggested feature.
I'm marking this as canceled on updates.orgmode.org but
On 06/06/2021 00:50, Utkarsh Singh wrote:
On 2021-06-05, 19:40 +0700, Maxim Nikulin wrote:
This line should be added to org-table.el, but notice "rx ‘not’ syntax
error: (or ". This logical operators have a bit different meaning for
regular expression.
I just "tested" most of them by M-x eval-
On 2021-06-05, 19:40 +0700, Maxim Nikulin wrote:
> This line should be added to org-table.el, but notice "rx ‘not’ syntax
> error: (or ". This logical operators have a bit different meaning for
> regular expression.
>
> Nicolas suggested you to use `list' to avoid `eval'. Certainly `eval'
> sh
On 04/06/2021 11:04, Utkarsh Singh wrote:
On 2021-06-02, 23:44 +0700, Maxim Nikulin wrote:
On 02/06/2021 22:08, Utkarsh Singh wrote:
;;;###autoload
(defun org-table-import (file separator)
@@ -955,12 +971,13 @@ lines. It can have the following values:
- integer When a number, use that m
On 2021-06-02, 23:44 +0700, Maxim Nikulin wrote:
> On 02/06/2021 22:08, Utkarsh Singh wrote:
>> ;;;###autoload
>> (defun org-table-import (file separator)
>> @@ -955,12 +971,13 @@ lines. It can have the following values:
>> - integer When a number, use that many spaces, or a TAB, as field
>
On 02/06/2021 22:08, Utkarsh Singh wrote:
;;;###autoload
(defun org-table-import (file separator)
@@ -955,12 +971,13 @@ lines. It can have the following values:
- integer When a number, use that many spaces, or a TAB, as field separator.
- regexp When a regular expression, use it to match
On 2021-06-02, 19:06 +0700, Maxim Nikulin wrote:
> Notice that for "C-u M-x org-table-import" heuristics is not necessary,
> the separator is specified explicitly. I see that your intention was to
> improve user interface of org-table-import, but actually you broke it by
> the "org-table-impor
On 02/06/2021 00:46, Utkarsh Singh wrote:
Org 9.4.5+patches M-x org-table-import
| 1,Word,66.3e-35 || | |
| 2,Unquoted | cell,2.7 | | |
| 3,"Quoted | cell",3.14 | | |
| 4,"Cell
Hi Maxim,
First of all I would like to thank you for testing out patches and
taking time to write a detailed report about it.
On 2021-06-01, 23:23 +0700, Maxim Nikulin wrote:
> On 17/05/2021 12:29, Bastien wrote:
>> Utkarsh Singh writes:
>>> For now can you review the patches I proposed earlie
On 17/05/2021 12:29, Bastien wrote:
Utkarsh Singh writes:
For now can you review the patches I proposed earlier in this
thread?
Not until both you and Maxim are confident this is useful, complete
and predictable.
I have too many points to object to consider my opinion as objective.
I am un
On 2021-05-18, 19:31 +0700, Maxim Nikulin wrote:
> The question may be risen in emacs-devel but I am unsure if I will
> participate in discussion.
Why?
>> Can you test this function:
>>
>> (defun org-table--comma-as-decimal-sep ()
>>"Return nil or 2 if separator is dot or comma respective
It seems, there is no reliable way to work with numbers in a
locale-aware way in emacs. I am still against hard-coded list of
locales. Requirement to customize a variable is rather inconvenient.
Considering such properties as a part of translation is a little better
but I prefer to avoid it.
On 2021-05-16, 23:24 +0700, Maxim Nikulin wrote:
> On 14/05/2021 21:54, Utkarsh Singh wrote:
>> On 2021-05-13, 00:08 +0700, Maxim Nikulin wrote:
>>
>>> Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is
>>> that order in which separator candidates are tried should depend on
>>
On 2021-05-17, 07:29 +0200, Bastien wrote:
> Hi Utkarsh,
>
> Utkarsh Singh writes:
>
>> For now can you review the patches I proposed earlier in this
>> thread?
>
> Not until both you and Maxim are confident this is useful, complete
> and predictable.
Ok.
> Also, if you resend the patch for re
On 2021-05-16, 23:24 +0700, Maxim Nikulin wrote:
> On 14/05/2021 21:54, Utkarsh Singh wrote:
>> On 2021-05-13, 00:08 +0700, Maxim Nikulin wrote:
>>
>>> Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is
>>> that order in which separator candidates are tried should depend on
>>
Hi Utkarsh,
Utkarsh Singh writes:
> For now can you review the patches I proposed earlier in this
> thread?
Not until both you and Maxim are confident this is useful, complete
and predictable.
Also, if you resend the patch for review, please use a proper commit
message: https://orgmode.org/wor
On 14/05/2021 21:54, Utkarsh Singh wrote:
On 2021-05-13, 00:08 +0700, Maxim Nikulin wrote:
Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is
that order in which separator candidates are tried should depend on
active locale.
I am willing to work on this problem but before t
On 2021-05-15, 12:30 +0200, Bastien wrote:
> Hi Utkarsh,
>
> Utkarsh Singh writes:
>
>> For now can you review the patches I proposed earlier in this
>> thread?
>
> Do these patches provide a complete and predictable solution?
> If so, can you merge them into a single patch against master?
>
He
Hi Utkarsh,
Utkarsh Singh writes:
> For now can you review the patches I proposed earlier in this
> thread?
Do these patches provide a complete and predictable solution?
If so, can you merge them into a single patch against master?
Thanks,
--
Bastien
On 2021-05-15, 11:13 +0200, Bastien wrote:
> Hi Utkarsh and Maxim,
>
> Utkarsh Singh writes:
>
>> On 2021-05-13, 00:08 +0700, Maxim Nikulin wrote:
>>
>>> Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is
>>> that order in which separator candidates are tried should depend on
Hi Utkarsh and Maxim,
Utkarsh Singh writes:
> On 2021-05-13, 00:08 +0700, Maxim Nikulin wrote:
>
>> Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is
>> that order in which separator candidates are tried should depend on
>> active locale.
>>
>> I do not insist that interacti
On 2021-05-13, 00:08 +0700, Maxim Nikulin wrote:
> Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is
> that order in which separator candidates are tried should depend on
> active locale.
>
> I do not insist that interactive preview or smarter approach to guess
> separator hav
On 11/05/2021 01:36, Utkarsh Singh wrote:
What do we mean by interactive preview? Does this mean that we should
present a user with a list of possible delimiters using minibuffer?
I mean something like the dialog that LibreOffice shows on opening of a
csv file. There are various options and t
Hi Maxim,
Sorry for the late reply!
On 2021-04-28, 23:38 +0700, Maxim Nikulin wrote:
> On 28/04/2021 15:37, Utkarsh Singh wrote:
>> +List of preferred separator (in order of preference):
>> +comma, TAB, semicolon, colon or SPACE.
> I will hardly be using this feature heavily, so I do not insist
On 28/04/2021 15:37, Utkarsh Singh wrote:
+List of preferred separator (in order of preference):
+comma, TAB, semicolon, colon or SPACE.
I will hardly be using this feature heavily, so I do not insist that the
following must be taken into account. Just some considerations...
There are locales
Hi,
On 2021-04-27, 22:21 +0200, Nicolas Goaziou wrote:
>> + When using org-table-import interactively if we failed to guess
>> separator then we will be left with a user-error message and an
>> 'unconverted table'. We can make use of 'temp-buffer' to import our
>> file after successfully conver
Hello,
Utkarsh Singh writes:
> I am attaching my patch which also include my previous suggestion of
> including yes-or-no prompt to org-table-import to allow file which don't
> have csv, tsv or txt as extension.
I suggest to make several patches. Do not try to stuff as many changes
as possibl
Hi,
On 2021-04-20, 15:40 +0200, Nicolas Goaziou wrote:
> Again all this needs to extensively tested, as there are a lot of
> dangers lurking around.
I am attaching my patch which also include my previous suggestion of
including yes-or-no prompt to org-table-import to allow file which don't
have
Hi,
On 2021-04-20, 15:40 +0200, Nicolas Goaziou wrote:
> For the problem we're trying to solve, this sounds like over-engineering
> to me. Do we want so badly to guess a separator?
Earlier I took is as an assignment to learn Elisp but now I don't think
we should increase complexity this much.
Hello,
Utkarsh Singh writes:
> At first I was also reluctant in creating a new function but decided to
> do so because:
>
> + org-table-convert-region is currently doing two thing 'guessing the
> separator' and 'converting the region'. I thought it was a good idea to
> separate out function int
On 2021-04-19, 10:19 +0200, Nicolas Goaziou wrote:
>> My previous patch proposed to add support for importing file with
>> arbitrary name and building upon that this patch tries to make use of it
>> by making org-table-import smarter by simply adding more separators
>> (delimiters).
>
> Good idea
Hello,
Utkarsh Singh writes:
> My previous patch proposed to add support for importing file with
> arbitrary name and building upon that this patch tries to make use of it
> by making org-table-import smarter by simply adding more separators
> (delimiters).
Good idea, thank you. Some comments f
Hi,
My previous patch proposed to add support for importing file with
arbitrary name and building upon that this patch tries to make use of it
by making org-table-import smarter by simply adding more separators
(delimiters).
Currently org-table-import 'smartly' guesses only COMMA, TAB and SPACE
a
33 matches
Mail list logo
