Hello, "Rolf Sander (MPI)" <rolf.san...@mpic.de> writes:
> I'm sorry to say this but this email list has been the most > disappointing experience for me. I asked a simple question and even > provided the code for a possible solution. The answers I received > included phrases like "can of worms", "little benefit" and "barely > scratching the surface of the problem". I think that blaming the whole list is uncalled for. You got helpful answers from other persons than me, yet you only quote parts of my answers. > And now you even wrote: [...] >> I already answered to that question, but you discarded my answer. > > This is not true! You did not answer my question! Without testing, you > just _speculated_ that you expect problems with formulas and export. What makes you think I speculated anything? I tried to show you the weak spots of your model. > So I tested it myself. In my tests I did _not_ experience any problems > with formulas and export. Why do you claim that I discarded your > answer? Exhibiting one example confirming a theory doesn't validate it. Anyway, you can do the following with your patch: - Move point to your "comment row" - M-: (org-element-property :type (org-element-at-point)) If you get `rule', by all means, Org sees your row as a standard table rule. This is not transparent; this is /not/ a comment. You just created a degenerate syntax for table rules. Note that this may be what you really want, but this is not equivalent to the initial example you gave: |--------+-------+--------| | animal | size | number | |--------+-------+--------| | gnus | big | 3 | # don't forget to add elephants here: | gnats | small | 1000 | |--------+-------+--------| If such thing existed, the "gnus" and "gnats" rows wouldn't be separated by a rule, e.g., in export, because Org removes such lines prior to starting the export process. Another example is the following: |--------+-------+--------| | animal | size | number | |-/ whatever | gnus | big | 3 | | gnats | small | 1000 | |--------+-------+--------| In this case, you are creating a table header, so this is not transparent either. I could also add an example where an additional rule has an impact on formulas (@I..@II could have a different meaning depending on the presence or not of another rule). All in all, I think your problem is ill-defined. You wanted comment rows, but you didn't specify how it should behave in various situations involving tables. I stand on my ground : generic comment rows are difficult to implement and "a can of worms". Allowing text within a table rule is easier to achieve, as you proved, but it feels very hackish and limited in use. What if I want to introduce comments without creating a visible rule in the table? Do I need yet another syntax? > I still think orgmode is great code and I would have loved to > participate. However, given the way that you treat me here, I don't treat you in any way. I just suggested your idea was wrong. I understand this can be frustrating. I would be frustrated too. Regards, -- Nicolas Goaziou
