| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
For example, script[src defer.] expands to <script src="" defer></script>.
This notation is not documented in the cheet sheet, but you can use it in the playground.
We should support boolean attributes for the other filters as well, say, haml.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Changes to emmet-default-filter
|
| |\
| |/
|/| |
|
|\ \
| | |
| | | |
Update to latest CSS snippets from 'github.com/emmetio/emmet'
|
| | |
| | |
| | |
| | |
| | |
| | | |
```
$ make clean; make;
```
|
| | |
| | |
| | |
| | | |
Copy from <https://github.com/emmetio/emmet/blob/master/lib/snippets.json>.
|
|/ /
| |
| | |
Probably going to update README more thoroughly as I have time, but this needs to be there I think.
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Two minor fixes for emmet-wrap-with-markup
|
| | |
| | |
| | |
| | | |
This makes emmet-wrap-with-markup more useful for keyboard macros
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
elisp manual 22.2.1 Major Mode Conventions:
“The key sequences bound in a major mode keymap should usually start
with ‘C-c’, followed by a control character, a digit, or ‘{’, ‘}’,
‘<’, ‘>’, ‘:’ or ‘;’. The other punctuation characters are reserved
for minor modes, and ordinary letters are reserved for users.”
‘C-c C-c’ is already a prefix map for sgml-mode, the ‘w’ fits nicely
there without a conflict.
|
|/
|
|
|
|
|
| |
Added variables emmet-fallback-filter and emmet-file-filter.
These can be used to configure the behaviour of emmet-default-filter.
Also added "hic" as the default filter for .cljs-files.
|
|\
| |
| | |
Add emmet-preview-mode
|
|/ |
|
|\
| |
| |
| |
| | |
Added multi-line * wrap functionality as per #81
With a multi-line region, expanding something like `div>ul>li*` will wrap each line in the terminating *'d expression.
|
| |
| |
| |
| |
| |
| | |
Previous commit borked regular multplied markup, this one doesn't.
Also, tests were there!
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It itched at me, so I cleaned it up and rewrote to make it do the token
replacement. Would be more performant to do the sha1 once, but
realistically, it's not going to be meaningfully slow for the use-case.
This is essentially complete, but needs tests - I'll add them as soon as
I can get testing working on my computer.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a proof-of-concept - it needs to do the token-replacement jazz the original
version did, because right now this will fail if the content of the
txt/lines includes unmatched braces in various configurations.
I think the overall plan is sound: split expression into leading and
terminal components, render the text as a list (either a one-element
list of all text or a multiline list, depending on trailing *), and
create a terminal phrase consisting of "terminal-element{TOKEN}" joined
on "+"
To do: render list into a-list of '((hash-of-txt . txt), ...), mapconcat
the hash replacement instead of the text, then run replace over result.
Write tests. Also, tests appear to be broken on master, at least on my machine.
|
| |
|
| |
|
|\
| |
| | |
Add self-closing tags style customization
|
|/
|
|
|
| |
People use different styles in different projects. Allow user to
customize it.
|
| |
|
|\
| |
| | |
fixes #69
|
|/ |
|
| |
|
|\
| |
| | |
Add jsx support for className
|
|/ |
|
| |
|
|\
| |
| | |
Refs #61 - Escape using backslash inside { text }
|
|/
|
|
|
|
|
|
|
|
| |
This fixes half the problem specified in #61. The doc change
is technically inaccurate - opening brackets don't actually NEED to
be escaped - p{{\}} works as well as p{\{\}}. But they CAN be escaped,
so I used the most regular version.
The part that is NOT fixed is that a | character, escaped or not, will
prevent the expression from being parsed AT ALL.
|
| |
|
| |
|
|\
| |
| | |
typo in README.md - still needs some attention, which I'm about to give it
|
|/ |
|
|
|
|
| |
skip-chars-forward does not take a regexp, it takes a pseudo-char-class string.
|
| |
|
|\
| |
| | |
Fixes #54 - Uses looking-back to check if there is a tag immediately pre...
|
|/
|
|
| |
preceding in cases where ">" is before-char
|
|\
| |
| | |
typo: "expandin" -> "expanding"
|
|/ |
|