Tim,
Your concerns are well founded. Essentially any cosmetic extension
to the org table syntax will be an unmaintainable, bug ridden
nightmare and would be an eternal burden on any attempts to formalize
correct behavior. I have a draft of a grammar for a significant
portion of Org syntax
On Fr 19 Mär 2021 at 13:33, Eric S Fraga wrote:
> With respect to the topic at hand, I believe it's the result of the same
> tendency that Excel users have of using spreadsheets (aka tables) for
> everything, something I hate when I'm given some Excel sheet that I need
> to modify and where
On Sunday, 21 Mar 2021 at 09:06, Tim Cross wrote:
> However, often now, I'm presented with a spreadsheet (or workbook)
> with not a single calculation or cell formula -it is just about
> formatting.
Exactly. And this is why I am not happy about org being modified to
enable this. Make the path
Hi Samuel,
Samuel Wales writes:
> i like that. such an org edit special type feature could efven in
> principle work for a column or a row all at once.
I like the idea of being able to edit rows or columns as well...
As I mentioned in a previous message, I made this rudimentary proof of
i like that. such an org edit special type feature could efven in
principle work for a column or a row all at once.
On 3/18/21, Juan Manuel Macías wrote:
> Tim Cross writes:
>
>> From watching these discussions in the past, I think the big stumbling
>> block is how easily multi-row columns
Andreas Eder writes:
> On Fr 19 Mär 2021 at 13:33, Eric S Fraga wrote:
>
>> With respect to the topic at hand, I believe it's the result of the same
>> tendency that Excel users have of using spreadsheets (aka tables) for
>> everything, something I hate when I'm given some Excel sheet that I
Tim Cross writes:
> It has also been stated that the Latex exporter won't be a problem as
> tabularx (and other Latex packages) will just handle this. Sadly, I
> don't think it is that simple. I have used that package a lot over the
> years and there have been times I've had to render tables
On Saturday, 20 Mar 2021 at 08:33, Tim Cross wrote:
> That would be an interesting exercise. However, it does add another
> dependency and in some ways breaks the 'everything as text' philosophy
> (though I guess the last 'rendering' in the org file is still all text).
Yes, very true. So let me
Eric S Fraga writes:
> On Friday, 19 Mar 2021 at 08:58, Tim Cross wrote:
>> I am a little concerned about the expansion and addition of features in
>> org mode when there seems to already be a challenge with respect to
>> maintenance and bug fixing. Personally, I would prefer an org mode which
to...@tuxteam.de writes:
> [...] My point was that it probably makes sense to separate concerns
> here.
Yes, that separation is essential. I agree.
> That's right. OTOH, people will try to stretch it in every conceivable
> direction. That's in a way Org's biggest strength (and at the same time
On Fri, Mar 19, 2021 at 11:53:14AM +0100, Juan Manuel Macías wrote:
> to...@tuxteam.de writes:
>
> > For export formats, there could be (yet another) "signal" to convey
> > "new paragraph here" which then is the exporter's job. Perhaps an
> > empty line (as is traditional in TeX) or something
On Friday, 19 Mar 2021 at 08:58, Tim Cross wrote:
> I am a little concerned about the expansion and addition of features in
> org mode when there seems to already be a challenge with respect to
> maintenance and bug fixing. Personally, I would prefer an org mode which
> is consistent and reliable
* sorry for the typo. I meant "...n columns x n rows..."
Juan Manuel Macías writes:
> Anyway, I suspect that Org tables are not originally intended for such a
> 'literary' content :-) ... LaTeX tabular(x) environment and Org tables
> have in common that they are plain text, but that’s where
to...@tuxteam.de writes:
> For export formats, there could be (yet another) "signal" to convey
> "new paragraph here" which then is the exporter's job. Perhaps an
> empty line (as is traditional in TeX) or something else.
I think that signal would be a good solution within a single line. For
On Fri, Mar 19, 2021 at 10:22:20AM +0100, Juan Manuel Macías wrote:
> to...@tuxteam.de writes:
>
> > My post was rather a warning that "multi-line" will mean
> > different things to different people.
>
> Yes I agree. It is not the same as how a table is represented in Org and
> how it should be
to...@tuxteam.de writes:
> My post was rather a warning that "multi-line" will mean
> different things to different people.
Yes I agree. It is not the same as how a table is represented in Org and
how it should be rendered when exported to some typographic format like
(let's say) LaTeX. I think
On Fri, Mar 19, 2021 at 09:44:48AM +0100, Juan Manuel Macías wrote:
> Hi Tomas,
[...]
> I was writing yesterday some rudimentary code (just a proof of concept)
> and I've made this screencast:
>
> https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4
Looks nice. And
Hi Tomas,
writes:
> If the aim is "just rendering in Org" and "breaks have no special
> meaning" (so each render is allowed to re-flow), then your approach
> makes sense (I think Org table has something like that: you can
> set the column width and shrink/expand the column appropriately.
>
On Thu, Mar 18, 2021 at 11:41:11PM +0100, Juan Manuel Macías wrote:
> Tim Cross writes:
>
> > From watching these discussions in the past, I think the big stumbling
> > block is how easily multi-row columns can be added and maintained in the
> > various export formats [...]
> I don't know if
Tim Cross writes:
> My view is 'go for it'. Just create a new feature branch and implment
> the functionality in that branch. We can then try using it and see where
> it works and where it doesn't. Once this is done, a call can be made as
> to whether it should be implemented in the main code
Timothy writes:
> Tim Cross writes:
>
>> In principal, it wold be great to be able to support multi-row columns.
>> However, I'm not sure how easily this can actually be implemented in a
>> consistent and maintainable manner.
>
> Mmmm, this of feels like something where you'll quickly learn
Tim Cross writes:
> In principal, it wold be great to be able to support multi-row columns.
> However, I'm not sure how easily this can actually be implemented in a
> consistent and maintainable manner.
Mmmm, this of feels like something where you'll quickly learn how hard
it is/isn't when
Tim Cross writes:
> From watching these discussions in the past, I think the big stumbling
> block is how easily multi-row columns can be added and maintained in the
> various export formats. Some are easy, like HTML, but others are less
> so. In particular, I know from my many years working
Atlas Cove writes:
> On 18/03/2021 14:26, Timothy wrote:
>>Interesting suggestion you have here.
>>On a related note, I wonder if you might have seen this thread I raised
>>a while ago: https://orgmode.org/list/87k0v361x9@gmail.com/
>>The discussion has died down (unfortunately), but the
Atlas Cove writes:
> In effect, yes. I'm proposing it as a syntax addition to make it easier to
> read, export, and manage, larger tables.
> I'm unsure if this would fit within the scope of org, but
> [[https://github.com/RedBug312/markdown-it-multimd-table][other projects]],
> like
>
On 18/03/2021 14:26, Timothy wrote:
Interesting suggestion you have here.
On a related note, I wonder if you might have seen this thread I raised
a while ago: https://orgmode.org/list/87k0v361x9@gmail.com/
The discussion has died down (unfortunately), but the idea is still on
my mind.
--
Hi!
Interesting suggestion you have here.
On a related note, I wonder if you might have seen this thread I raised
a while ago: https://orgmode.org/list/87k0v361x9@gmail.com/
The discussion has died down (unfortunately), but the idea is still on
my mind.
--
Timothy
On 18/03/2021 03:29, Atlas Cove wrote:
I'd like to propose an addition to the table syntax that would allow for
text wrapping in tables, I personally have myself managing
very large org tables, and having to scroll through them is often
cumbersome. As a result, I often yearn for greater
On 18/03/2021 14:38, Atlas Cove wrote:
>> technically the second table is more space efficient than the first
>
> I was referring to screen space.
Assuming that you are looking at this with a monospaced font (and I
don't see how you could use a variable width font to look at an Org
table
technically the second table is more space efficient than the first
I was referring to screen space.
Should Org understand all the 'concatenated text' as a single row (and not as
multiple rows)?
In effect, yes. I'm proposing it as a syntax addition to make it easier to
read, export, and
Hi,
Atlas Cove writes:
> Code-wise, the use of the '\\' symbol is only tentative, as I
> understand that '\' has special meaning elsewhere in org's syntax, (I
> was even going to submit a patch to add two special symbols somewhere
> down the line). '\\' (or whatever symbol is decided on) would
On 17/03/2021 21:29, Atlas Cove wrote:
> Allow me to give an example of the updated syntax I propose.
>
> ```
> | Name | Description| Price |
> |--++---|
> | Orange Juice | Very Citrusy! Very \\ | 5.00 |
> | | nice
32 matches
Mail list logo
