Before we implement SDL package format for DUB

[Nick Sabalausky via Digitalmars-d]

On 8/29/2014 7:37 AM, Kagamin wrote:
> On Thursday, 28 August 2014 at 19:47:13 UTC, Nick Sabalausky wrote:
>> The differences (off the top of my head, there may be more):
>>
>> - Nobody has to actually write the closing
>
> True for XML too:
> 1. many editors already autocomplete it, no need to wonder, why nobody
> implemented it;

Personally, I don't like that auto-insert stuff, it just trips me up.

In any case, I don't see how that feature provides much benefit over my 
suggestion. If you don't mind the auto-inserted text, then it's pretty 
much on par with my suggestion.


> 2. if you need a new document fragment, you just copy existing one and
> tweak it to new needs; and it's easier and faster this way with succinct
> languages too;
>

Yea, I do that to. But stuff, would you be ok with this (not rhetorical)?:

while(cond)
   if cond
     ...
   end if
end while

etc.

Yea, obviously I *can* use a language like that. I prefer not to.


>> - Nobody had to keep the opening/closing in sync
>
> Huh? Never needed that.

(Just to be clear we're on the same page here, I'm not sure if I was 
clear enough) You've never needed to change the name of a tag? Change 
one, gotta change the other to match.

> And it's the same with json and sdl: if you add
> new brace you need to go find the appropriate brace,

Not what I'm talking about with "keep the opening/closing in sync"

> after which to
> insert new brace, and there you see lisp-style stairway of indiscernible
> braces (with commas, yay).
>

Didn't I just suggest a simple editor feature to eliminate that problem? 
Isn't that proposed feature exactly what we're currently debating?

>> - The closing takes up zero bytes
>
> I'd say, it's dwarfed by everything else especially indentation.
>

Fine.

>> - Nobody has to actually look at the closing if they want to reduce
>> the visual clutter: Ie, viewing it is an optional thing.
>
> And get lost, when it doesn't cut it.

If that doesn't always cut it, then neither do XML-style matching end tags.

>
> Oh and it makes no sense to add a non-trivial editor support for json,
> because it's a format buried in a dark corner of javascript ecosystem,
> and even there it's used as a serialization format for data exchange
> (that's because it doesn't have comments) instead of long-living
> manually written documents.

JSON's extremely common, and I never intended the idea as being 
exclusively for JSON alone.

This is the part that I don't understand why people seem to be either 
missing or disagreeing with:

-----------------------------------
(XML-style) Matching end-tags:
     Have to type, always visible even when it's clutter.

(JSON-stye) Dedicated one-char end-tags:
     Visually indistinct, can't see which is which at a glance even when 
you want to.

Auto-inserted text (if you like that sort of thing), and a feature to 
optionally hide/collapse end tags:
     ***Eliminates cons of XML-style matching end-tags.***

Feature to optionally show the tag name at the closing brace:
     ***Eliminates cons of JSON-stye dedicated one-char end-tags.***

Result:
     ***Feature parity and everyone's happy.*** Except...somehow they're 
*not* and still complain and nitpick anyway...? I don't get it.
-----------------------------------