"Ignore" leading/trailing punctuation by converting it to a space, instead of deleting it

[duckwork]

From what I understand of Margin, you need to indent bullet points like this:

parent
  - child
  - child

The like, one thing I like about YAML is that you don't have to indent list items, like this:

parent
- child
- child

If in Margin, you ignored leading punctuation by converting it to a space, instead of just deleting it (pseudocode s/[-*+]/ / vs. `s/[-*+]//', this could be implemented. And I don't think it would muddy up the understanding at all, and it would make it easier to type without any text editor plugins.

[gamburg]

Love this idea.

parent
- child
- child

It implies (correctly, I think) that the indentation thinkers truly care about is where the actual "text" of the child item begins. In the case of the two c characters in the example above, they are offset from the left-hand margin of their parent, so we tend to read them as children (even though their ornamentation aligns with the left-hand margin of the item above them).

I just wonder if going down this path breaks any cases where a document looks correct to the thinker, but is read incorrectly by the parser:

It's rare, but some sentences might begin with a dash--
--Excuse me, I was talking here!
Oh, sorry. But take the case of interrupted speech in a back-and-forth transcript.

The parser would incorrectly treat the --Excuse me... line as a child of the It's rare... line.

Or take the case of a footnote-style asterisk:

I love bananas. In fact, I love all fruits.* Bananas combined with peanut butter are even better. 
* not apples

Although in the above examples the current spec would erroneously ignore the second * (or the -- from two examples up), it would at least keep the hierarchy correct by treating not apples as on the same level as the sentence above it.

I wonder if there's a solution here that involves allowing ornaments to denote child items if-and-only-if there is more than one item immediately below it with the same ornamentation:

item 1
- child
- child

item 2
- not a child
not a child

item 3
- not a child

But this might be getting into territory that's too complicated for Margin, its primary value add being that it is intuitive, flexible and doesn't need to be "learned."

[mtsknn]

@gamburg, you said:

I wonder if there's a solution here that involves allowing ornaments to denote child items if-and-only-if there is more than one item immediately below it with the same ornamentation

Why would the ornamentations have to be the same? And more importantly, why would there need to be more than one child for this syntax/feature to work?

I think that this would make Margin unnecessarily more complex. From the documentation (emphasis added):

Each item can have a single parent and multiple children. Indentation alone determines this hierarchy

This is simple, simple is good.

When indentation alone determines the hierarchy, there's no debate about how this should be interpreted:

item 1
  - child
  - child

item 2
- not a child

I agree with the last sentence of your comment.

[gamburg]

@mtsknn Yep, I think you're right.

I feel increasingly that one of the Margin's primary development challenges exists in the tug of war between intuitive and simple. Intuitive meaning the thinker doesn't need to "learn" anything to use it; and simple meaning that the language doesn't overextend itself, thus cannibalizing its main appeal.

To me, the following is intuitive:

parent
- child
- child

But allowing it removes some simplicity from the language.

I think the saving grace is that, in a plain text editor, the above example is perfectly valid Margin, because the thinker is the only one who really needs to understand the relationships. And the transition to a Margin-based app (whose syntax is more strict) should be relatively painless with the above example too – the thinker would just need to properly indent the child items.

For now I'm closing this as won't fix.