Comments in Variant Definition Table

[honzakutil]

Is it possible to mark some rows and columns in Variant Definition Table as comments, so KiVar will just ignore them?

Example:

	comment for variant	Aspect_A	Aspect_B	Aspect_C	...
comment for choice		this sets the voltage	this sets the current	only C1 is for production, others are for testing during development process	...
Variant_One	low voltage variant	Choice_A1	Choice_B1	Choice_C1	...
Variant_Two	high voltage variant	Choice_A2	Choice_B2	Choice_C2	...
Variant_Three	same as low voltage, but uses different MPNs due to transistors inavailability	Choice_A3	Choice_B3	Choice_C3	...
...	...	...	...	...	...

[markh-de]

Hey Honza,

That's quite a nice idea. My approach would be to mark the table row/column header (i.e. aspect or variant identifier) in some special way so that the whole row/column will be ignored.

Do you have ideas in mind for a marking that does not clash with useful aspect or variant identifiers? A leading # may be a bit too simple; some people might really use a leading hash symbol for numbering.

Other ideas:

{comment_for_foo}
<comment_for_foo>
[comment_for_foo]

I'm open to your suggestions.

[honzakutil]

I am starting aspects and choices with letter or digit, so hash would be fine for me. As you wrote, someone else may use hash for numbering, however I have not seen double hash ##used for anything, so I suggest to ignore every column if cell in the first row begins with ## and ignore every row if cell in first column begins that way. Example:

	##comment for variant	Aspect_A	Aspect_B	Aspect_C	##Aspect D	...
##comment for choice		this sets the voltage	this sets the current	only C1 is for production, others are for testing during development process	we need to use this as free aspect for now	...
Variant_One	low voltage variant	Choice_A1	Choice_B1	Choice_C1	D1	...
Variant_Two	high voltage variant	Choice_A2	Choice_B2	Choice_C2	D2	...
Variant_Three	same as low voltage, but uses different MPNs due to transistors inavailability	Choice_A3	Choice_B3	Choice_C3	D3	...
##Ignored Variant	failed the test, not use it until fixed	choice	choice	choice	choice	...
...	...	...	...	...	...	...

Using only one or two chars to mark the comments will also make easy to comment out part of the table very quickly, which may be also useful in some cases. Using the keyword will make it a little bit harder.

I usually want to fit as much information to the screen as possible and using only several characters instead of whole keyword is better for this purpose.

It may be also possible to set something as default and add ability to change this by setting text variables, similarly to Overriding KiVar Record Keywords. However this would be probably overkill and only adds complexity to code and documentation.

[honzakutil]

One more idea: showing and editing the comments via the GUI would be also nice.

It would require to have only one column and only one row for comments or to distinguish comments and descriptions. The comments are just comments, visible only in the csv table. Descriptions is exactly one row and one column which is visible (and editable) via the GUI. Comments could be two hashes ##, descriptions cloud be three hashes ### or some keyword.

Description for the currently selected variant could be shown and edited under the variant selector dropdown. Description for the aspects could pop-up when mouse hovers over the aspect name. Edit of the aspect description could be done by right-click on the aspect name, or could be hidden under three dost next to the aspect name.