Rocks'n'Diamonds

This new feature is working pretty well and provides a new way of generating initial content for new levels.

Since 4.1.1.2 came out I have done a small amount of testing and noticed a couple of things that if fixed or enhanced could really make this feature mature. They are:

1.
"added expanding tabs to spaces when drawing text buffers to the screen"

I'm guessing this refers to how tabs in the text are handled when writing to the level. Apologies if I'm wrong. Currently I don't think this is working, meaning that e.g.

a b
a b

[first line has one tab between a and b,
second line has two tabs between a and b]

is mapped to:




or

char_a,char_question,char_b,sand
char_a,char_question,char_question,char_b

Now I have some ideas for handling of tabs. I think that as with text editors and spreadsheets etc, a tab should be treated as a command to move the insertion point or cursor. But how far?

I would like to expand the Edit tab in the Conf / Global Settings screen,
to include a section for the Paste Text As Elements feature.


#1

'Tab character moves insertion point rightwards by n cells'

- This could default to say 4, or 2, giving a clear 'tab effect'.

But it could also be set to 0, in which case tabs would effectively be purged from the input to the sheet, and if there was a run of tabs, nothing would be written, and writing of characters would only resume when a non-tab is encountered - i.e. a printable character or a new line.

This leaves ambiguous the question of what is done to the skipped cells - i.e. are they left as is, or overwritten with space char elements;
if you favoured the latter, you might want to name the option like this:

'Tab character is handled as n space characters'

I would only favour this option if there is also an option for customizing the handling of space characters:

#2.

'Leave existing cell as-is, and move right, when encounter Space char'

- This could be a checkbox, and could default to being off, so only people who really want to preserve existing content of a level (to a limited extent) would tick this.

- When unticked: space characters are written as space char elements.

- When ticked: space characters are not written as anything, instead the insertion point moves rightwards once per space character, preserving any element that is in the moved-past position.

I really like this idea, as I think it could lead to serendipitous semi-random design outcomes.

So thinking about it, I would vote for #1 (last form) and #2 together, rather than #1 (first form) on its own.


The above two could stand on their own, but dreaming a bit, I would love to also have a third option in the config section for the Paste Text As Elements feature:

#3

'Leave existing cell as-is, and move the insertion point, when encounter any element that is neither Empty Space nor diggable'
OR the same thing written another way:
'Only overwrite Empty Space and diggable elements with characters, otherwise move the insertion point'

- The list of elements would include Space, Sand, Invisible Sand, Grass, Base, etc. Or if that list is a PITA to decide on, just Space and Sand.
In which case:
'Only overwrite Empty Space and Sand with characters, otherwise move the insertion point'

- The insertion point would usually move right, but if at the end of a row, would wrap to the first column in the next row.

- Note this differs from the other options by being affected by what is in the level, rather than what is on the Clipboard.

- This would allow a kind of semi-intelligent 'merge write', which would be a great addition to the features.

Apologies for yet more requests! This seems like a good place to append Mr. Green, but I don't know what he means

John

I am posting this just to bring my later post ahead of an older post, which I believe is completed, but I don't have any way to mark it as such, apart from adding reply to say 'all done'.

Apologies for the confusion between this post and the older bug post "Paste Text from Clipboard feature". That one was mainly about new lines, so should have had "new lines" in the title of the post; this one is mainly about tabs, so should have had "tabs" in the title. Or, since it also covers skipping existing non-Space, non-diggable elements, and posits the idea of a "merge paste", it could be named like this:

Tabs and skipping non-Space, non-diggable elements when pasting text As elements

or for short:

Tabs and skipping elements when pasting text

I will try changing the name of this post in the subject line... bated breath

John


p.s. Background info, can be not read, unless you are deeply interested:

The problem with new lines has been dealt with in release 4.4.1.2, thanks Holger

The release notes for 4.4.1.2 seem to suggest that an attempt was made to handle Tabs - but I might be misunderstanding the release notes; either way, Tabs are currently not working when pasting text. My post above gives my idea on how to handle Tabs (and also adds an idea for skipping non-Space, non-diggable elements when pasting text As elements)

This post is the only currently open bug post about the Paste Text As Elements feature, I believe.

Your observations are correct. The mentioned new feature about drawing tab characters is quite limited to drawing text to the screen (where tabs are currently simply converted to eight spaces, which is, strictly speaking, not the correct solution (*) ), but not used when pasting text to the playfield as text elements.

So I still have to add support for correctly handling tabs when pasting to the playfield!

(*) A better (less simple) approach would of course be to convert tabs to as many spaces as is required to reach the next multiple of eight characters. For example, if you have a string "abc<tab>d", it should translate to "abc<five spaces>c" instead of "abc<eight spaces>c".

Of course, this opens up the gate to the hell of "how many spaces correspond to one tab, how to handle tabs in general, and how to handle mixtures of tabs and spaces". People who have narrowly escaped madness therefore advocate not using tabs at all.

Thanks Holger. When I read your post I deduced that "drawing text to the screen" meant writing text to the screen, by clicking on the A button and then hitting keys, so I did so, typed AB, and then hit the Tab key, expecting the cursor would advance right by 8 elements, leaving 8 space char elements; but it didn't move at all.

So I think I am misunderstanding what "drawing text to the screen" means. Can you explain?

(*) A better (less simple) approach would of course be to convert tabs to as many spaces as is required to reach the next multiple of eight characters. For example, if you have a string "abc<tab>d", it should translate to "abc<five spaces>c" instead of "abc<eight spaces>c".

Yes definitely, tabs are all about alignment to invisible 'tab stops', or some kind of conception of a framework.

Of course, this opens up the gate to the hell of "how many spaces correspond to one tab, how to handle tabs in general, and how to handle mixtures of tabs and spaces". People who have narrowly escaped madness therefore advocate not using tabs at all.

True, at least in text editors, word processors and code editors. Tabs are used in spreadsheets without any problems, except if you want to try to embed tabs within the contents of a cell. In the case, double-quoting the string can be used to handle tabs in strings (such strings are usually obtained from outside of the spreadsheet).

RnD actually seems to me to be more similar to Excel than to any text editor, word processor or code editor; the 'grid' as I call it resembles a spreadsheet, at least the first 128 by 128 cells of a spreadsheet. The difference being that RnD handles fixed-length numerics, whereas Excel can handle numerics or strings of almost any size, so needs tabs to delimit them. It could just as easily be spaces, except that spaces are used internally in strings, whereas Tabs are not, at least not in Excel.

Why am I mentioning the above? Well, just to remark that there is an alternative way of using tabs to the text editor model, and it could be used in Rnd if the text editor model is found to be too hard (because RnD is not really like a text editor, even if can be pushed to act like one).

In that case, a tab just moves one cell to the right. But then what difference from the space character? Options for differentiating include:

#1 Ignore Tab; do nothing in the level, move on to the next character.
- This option is good for spreadsheet data containing only one character per cell - admittedly an edge case, although not for people using spreadsheets to help with their RnD (a pun, of sorts).

#2 Space results in an overwrite of existing cell, Tab does not.

#3 Tab is hardwired to move n cells to the right, i.e. be a run of spaces - I would favour a configurable number, but if hard coded, I would favour 4 over 8.

#4 Since I am hoping to get a 'merge-write', in which some of the existing level is left unchanged, I would vote for my idea of neither Space nor Tab overwriting the existing cell; there is precedent for this, since you have implemented this for New line; New line IS always actioned, as the cursor moves to the next line, but the cell at the cursor point at the time of encountering a new line in the source string is not overwritten. The same thing could be done for Tab, and Space, as an option for some (me )

John