[textfile] inconsistency: drops consecutive spaces when reading from disk

[EsGeh]

pd version: 0.50.0
Problem: [textfile] obj drops spaces when reading a file.

Example:

[set 1 \ 3, write /tmp/temp, bang(
|
|    [read /tmp/temp, rewind, bang(
|   /
| /
[textfile]
|
[print]

(This patch tries to write and read a message containing 2 consecutive spaces to/from disk.)

• Expected behaviour:
  Hitting the 1. msg. box (sets the textfile and then writes the content to a temporary file) should output

  1  3
  

  (2 spaces between)).

  Hitting the 2. msg. box reads from the temporary file and should output

  1  3
  

  (with 2 consecutive spaces between) too.

• Actual behaviour:
  Hitting 1. msg box behaves as expected and outputs:

  1  3
  

  (2 spaces between)).
  Hitting 2. msg box outputs

  1 3
  

  with just 1 space between.

Why this is bad:
Consecutive spaces carry important information.
In many contexts in pd they are used to represent empty symbols. This might be a bit awkward, but works, since pd in most contexts is consistent in this.
For example, this patch creates a list of 3 elements, where the second one is an empty symbol.

              [loadbang]
              |
(bang)        [symbol]
|                |
_         _      _       _
[pack     1      s       3]
|
[print]

One might want to write and read such lists to and from disks. With the current state of [textfile] (and probably also [text]), this wont work without additional hacks.

[umlaeute]

it's consistent with how Pd reads data into binbufs (e.g. how a patch-file is read).

[EsGeh]

But do you see the problem?
Dealing with lists that contain empty symbols works fine everywhere in a patch during runtime.
Only wanting to write/read them to/from disk doesn't work.
I can imagine that the current behavior is part of the fundamental conceptual basis of pd.
From a practical side it appears as an inconsistency.
In my pd external I have tools manage state of instruments, also saving them to/from disk. But even in a very simple scenario where someone stores lists on disk can turn problematic.
A list containing empty symbols stored and reloaded from disk even drops entries in the sense of [list length] returning less than before loading!

Is there a chance to change the behavior into not dropping consecutive spaces?
Are there good reasons not to?
Would it break something?

[Spacechild1]

Generally it's possible to escape Pd's special characters with a backslash, e.g. \, \; or \$. I think this should be also possible with whitespace.

In the meantime: if you want to preserve a symbol as is, read/write it as a list of ASCII characters with [list fromsymbol] / [list tosymbol]

[umlaeute]

Am 4. September 2019 19:10:37 MESZ schrieb EsGeh <notifications@github.com>:

But do you see the problem?

yes of course. sorry if this didn't come across.

From a practical side it appears as an inconsistency.

for "consistency" you need a reference system. i pointed out that i consider Pd's binbuf loader this reference and that i don't see any inconsistency.

Is there a chance to change the behavior into not dropping consecutive spaces? Are there good reasons not to? Would it break something?

depends on how it is implemented. naively outputting a string `a b` (with multiple spaces) as something else than two symbols `a` and `b` will most likely break things. otoh, allowing [textfile] (or better: the binbuf save function) to escape spaces in symbols (when saving) should fix a couple of problems