alhadis/language-emacs-lisp

Emacs Lisp and YASnippet support for Atom and GitHub.

Emacs Lisp Support

Hand-crafted syntax highlighting and editor commands for Emacs Lisp in Atom.

Commands

This package includes two commands to run Lisp code in Emacs from Atom:

• language-emacs-lisp:run-selection
• language-emacs-lisp:run-file

These aren't attached to any keybindings by default. You'll need to assign them shortcuts yourself.

NOTE: These require Emacs to be in your $PATH, and probably don't work on Windows.

language-emacs-lisp's Issues

Muse: support literal HTML

Emacs Muse supported this syntax for literal HTML blocks:

<literal style="html">
<h1>Header</h1>
</literal>

Literal HTML blocks can be highlighted using existing HTML grammar.

Add more tags to the repo

muse, amusewiki, textmate-grammar

Muse: support underline

Emacs Muse supported underline syntax:

This is _underlined_ text

Amusewiki removed it, mostly for the reason that there is no semantic difference between underline and emphasis and underline is usually a typewriter version of emphasis. But for syntax highlighting it may be worth to support both. Also, pandoc supports both Emacs Muse underline and Amusewiki extensions.

Problem with defgeneric and defmethod

Hi,

thank you for your excellent work. I've just noticed that defgeneric, cl-defgeneric, defmethod and cl-defmethod are not recognized as keywords (at least in Github, I haven't checked Atom):

(defgeneric my/entity-name (entity)
  "Return the name of ENTITY.")

(defmethod my/entity-name ((entity person))
  (person-name entity))

(cl-defgeneric my/entity-name (entity)
  "Return the name of ENTITY.")

(cl-defmethod my/entity-name ((entity person))
  (person-name entity))

Muse: any block markup should stop list parsing

For example, the second line here is a verse:

 - foo
> bar

Currently it is highlighted as paragraph.

VS Code Support

I'm not sure how hard or easy it would be to port this package over to VS Code, but I would love to have this package available there. I'm beginning to use VS Code alongside Atom these days and surely miss the Elisp syntax highlighting.

Also, forgive me if there already exists a package and that if one does exist, I simply missed it during my search.

Strings with a percent sign

There seems to be potential issue with the % sign in strings. In the following snippet:

The grammar seems to consider this invalid as it colors both the percent sign and the closing double quote. In GNU Emacs (with emacs-lisp-mode) though this is not the case:

The string "%" is a valid string in Emacs Lisp. I suppose this grammar tries to identify format specifications which is ofcourse fine but the issue is not every string will be passed to a function which will interpret format specifications.

I happened to run into this issue in one of my commits. As you can see I happen to use a string which ends in %" and it messes up the formatting on GitHub.

Let me know if there's any way I can help.

"View Code" button doesn't work

Not sure what the issue is (if its on my end or a fault of the package), but clicking "view code" in this package's settings does not launch a new instance of atom with the code for this package, as it should. I think this is the only package of mine that has this issue, but I can't conclude where the fault is.

I'm on:
macOS v10.13.6
Atom v1.30.0
language-emacs-lisp v1.3.0

Muse: do not allow letters after closing "*"

This is unclosed emphasis:

Foo *bar*x baz

This too:

Foo *bar*0 baz

`**foo***bar**` is not highlighted correctly

**foo***bar** is parsed as

<strong>foo</strong><em>bar</em>*

Emacs Muse does not highlight it at all and publishes it as

<strong>foo</strong>*bar**

which seems to be wrong.

Text::Amuse and pandoc compile it to

<strong>foo***bar</strong>

Make a release

Muse highlighting is already good enough for all practical uses, makes sense to tag a release so users can install it.

Muse: "===" is not code

Currently ===foo bar= is parsed as two code spans.

=== should not be treated as markup at all, because opening = should be preceded by whitespace and followed by alphanumeric character. Otherwise, <code> tag should be used.

Add CI testing

Once spec is added (see #12), add CI to check for regressions automatically.

https://github.com/atom/ci contains working configurations for most CI services.

Muse: strong inside emphasis is not supported

This is highlighted properly:

**foo *bar* baz**

But this is not, bar is simply emphasized:

*foo **bar** baz*

Muse: do not allow newlines after opening and before closing "*"

This should not be highlighted as emphasized:

*
foo bar*

This is unclosed emphasis:

*foo bar
*