Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

EsGeh opened this issue Sep 3, 2019 · 4 comments


Copy link

@EsGeh EsGeh commented Sep 3, 2019

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


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

(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.

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

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.

@EsGeh EsGeh changed the title [textfile] inconsistency: drops multiple spaces when reading from disk [textfile] inconsistency: drops consecutive spaces when reading from disk Sep 3, 2019

This comment has been minimized.

Copy link

@umlaeute umlaeute commented Sep 4, 2019

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


This comment has been minimized.

Copy link

@EsGeh EsGeh commented Sep 4, 2019

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?


This comment has been minimized.

Copy link

@Spacechild1 Spacechild1 commented Sep 4, 2019

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]


This comment has been minimized.

Copy link

@umlaeute umlaeute commented Sep 5, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.