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.

Sign up for GitHub

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

Jump to bottom

ENLINE doesn't handle block! arguments. #647

Closed
Siskin-Bot opened this issue Feb 15, 2020 · 1 comment
Closed

ENLINE doesn't handle block! arguments. #647

Siskin-Bot opened this issue Feb 15, 2020 · 1 comment
Labels
Test.written Type.bug Waiting for future Issues and wishes which are closed, but will be nice to resolve later

Comments

@Siskin-Bot
Copy link
Collaborator

Siskin-Bot commented Feb 15, 2020 •
edited by Oldes
Loading

Submitted by: BrianH

ENLINE passes through block! arguments instead of enlining them.

enline ["a"]
== ["a"]

Imported from: CureCode [ Version: alpha 33 Type: Bug Platform: All Category: n/a Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#647

Comments:

Rebolbot commented on Jan 26, 2015:

Submitted by: abolka

In the core-tests suite.

Rebolbot added Type.bug and Test.written on Jan 12, 2016

Hostilefork commented on Mar 26, 2018:

[string? enline ["a" "b"]]

Ren-C has DELIMIT and SPLIT, which can fairly easily handle the behavior of ENLINE and DELINE...modulo the platform-dependent aspects. But regarding that, see #2191 ... it may not be a good idea to have functions that are platform-dependent in that way.
@Siskin-Bot Siskin-Bot mentioned this issue Feb 15, 2020
Closed
Oldes added a commit to Oldes/Rebol3 that referenced this issue Jun 2, 2020
@Oldes
FIX: ENLINE does not convert line endings to native OS format (Posix)
f099629 
I've briefly revisited enline/deline code.. renamed internal function so it is more clear its purpose. Fixed one more `enline` related crash (see crash-tests file).

I'm keeping `block!` type as a possible value, but it will just throw `not yet implemented` error instead of silently ignoring it.

Fixes: Oldes/Rebol-issues#2191
Related to: Oldes/Rebol-issues#647
@Oldes Oldes added the Waiting for future Issues and wishes which are closed, but will be nice to resolve later label Sep 24, 2021
@Oldes
Copy link
Owner

Oldes commented Sep 24, 2021

It throws an error now (not implemented).

@Oldes Oldes closed this as completed Sep 24, 2021
Oldes added a commit to Oldes/Rebol3 that referenced this issue Sep 24, 2021
@Oldes
TEST: Oldes/Rebol-issues#647
a68198a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Test.written Type.bug Waiting for future Issues and wishes which are closed, but will be nice to resolve later
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Oldes @Siskin-Bot