Open hakatashi opened 8 years ago
jinja also has a semi-official set of delimiters for LaTeX:
((*
*))
((=
=))
(((
)))
Perl 6 uses double braces ({{
) as well for long-form strings.
Perl 6 and Polymer.js use the double square brackets ([[
) too (strings and one-way bindings, respectively).
Any idea how any of these should look like?
Brackets/braces could just be squished like exclamation and question marks.
apert from the obvious central line connecting the curlies, we could also try connecting them on top and bottom, like:
flying-sheep's idea is nice. Possible idea: making the outer braces/brackets slightly smaller vertically than the inner ones, which would make it even clearer.
I like that, it looks like ⟦ and ⟧.
The only potential problem I can see with this is that the ligatures might look odd on data structures like [a [b c]]
or {a {b c}}
. The ending ]]
and }}
on those examples might make things look a little uneven if turned into a ligature.
sure, but this already happens.
only solution is to modify your editor’s syntax highlighter to render it appropriately. e.g. in atom, you could tokenize
Vec<Hurr<Durr>>;
y >> z;
(using pseudo-LaTeX instead of HTML to make it clear)
either greedily, which preserves all ligatures
Vec\op{<}Hurr\op{<}Durr\op{>>};
y \op{>>} z;
or lazily, which preserves none
Vec\op{<}Hurr\op{<}Durr\op{>}\op{>};
y \op{>}\op{>} z;
or smartly, which requires more work:
Vec\op{<}Hurr\op{<}Durr\op{>}\op{>};
y \op{>>} z;
That's true, and I'd forgotten about the use of >>
to denote some type signatures.
I'm not sure whether Emacs supports breaking up ligatures in the same way; however, I've just tried Vec<Hurr<Durr>>
in my editor, and the ending >>
is subtle enough that it doesn't appear uneven at all. If the ]]
and }}
etc. ligatures are similarly subtle, then perhaps it doesn't matter.
well, the only way i can imagine that a TUI emacs could do that is by controlling the sequence of color changes: \x1b[31m>>\x1b[39;49m or \x1b[31m>\x1b[39;49m\x1b[31m>\x1b[39;49m (i.e. by resetting the fg color between the symbols or not).
and then the terminal emulator needs to interpret this in the same way and only render ligatures if they are’t interrupted by a color change command
I would add that, if there's going to be ligatures for <?
and <%=
, there must be for <?=
as well. The issue I've just pointed out lists other very used PHP tokens.
I'd really would like to see this.
for the design idea things like <%
could follow the same pattern as <$
or </
that joins both characters.
and for [[
the inner one could be smaller witch also works for "inner structures" like an array of arrays as: [[1,2], [3,4]]
rather the outer one would be enlarged, else it would look unbalanced and confusing
some ideas:
<%=
, <%#
and <%-
depend on the ligatur for <%
on their left.
I’d prefer
<?
: A<?=
and <?=$
: B?>
: A<%
and %>
: B{*
: both are ugly. A bigger *
should be enough like already in <*
Agree with almost all choices by @Blaimi, although for ?>
B sounds more natural - leave the dot where it is, instead of mangling it in the next symbol :)
I'm no designer here nor I understand of fonts, plus, those are sketches... so take my point with a grain of salt haha
Finally: maybe {*
could be done with a bigger asterisk, joining both the top and bottom with the begin and end of the braces line?
This is the coolest coding font ever!
I suggest that it would be nice to have ligatures for some template engines, such as EJS, ERB, ECT, Jinja, Twig, Smarty, and native PHP. It is something like...
<%
,<%=
,<%#
,%>
: Used in EJS, ERB, and ECT<%-
: Used in ECT{%
,%}
,{#
,#}
,{{
,}}
: Used in Jinja and Twig{*
,*}
: Used in Smarty<?
,?>
: Used in PHP