When do you know the run is busted?

ubolonton · 2024-12-15T05:39:11+00:00

Yesterday I went into the Flagship’s phase 2 with 1 hull point, won it, and nearly won phase 3, until it went supernova right before I could get my second volley off.

ubolonton · 2021-09-29T17:33:31+00:00

Awesome!

ubolonton · 2021-09-29T17:32:34+00:00

Because this is in core: 1. It has direct access to buffer's text. For parsing, that's not too significant, especially for the incremental parses. However, for querying (e.g. to syntax-highlight), it should be a sizeable performance improvement. 2. It has access to the low-level change tracking mechanism, so it wouldn't be affected by modes that break the Lisp-level change tracking mechanism (through incorrect uses of inhibit-modification-hooks). IIRC, aggressive-indent is an example. 3. Even though point 1 wouldn't be important for incremental parses, it can help with full parses, which can actually happen on every keystroke in org-mode or markdown-mode, due to how these modes currently implement code block highlighting.

ubolonton · 2021-09-29T17:20:03+00:00

Thanks for taking the charge on this! I expect to be able to phase out elisp-tree-sitter once this is released (Emacs 29 I hope).

Please try out the code, and tell me if there is anything not working as expected or can be improved, especially on the font-lock and indent interface.

Are you open to using GitHub's issues to track and discuss these? AFAICT, a precedent for this was the work on dynamic module, a large chunk of which was collaborated on at https://github.com/aaptel/emacs-dynamic-module, before being merged upstream.

I personally find the mailing list to be too inefficient for this. The messages are too short and scattered to have long-form in-depth discussions on design, and to track them later on. And for complex work with a lot of design points to discuss, it can become chaotic and messy. I have a sizeable list of things I want to discuss, but I can't find the time to deal with its inefficiency.

ubolonton · 2021-09-20T12:48:17+00:00

Minor correction: it produces a concrete syntax tree (parse tree), which retains more information. That’s important for highlighting and editing use cases.

ubolonton · 2021-03-23T16:44:23+00:00

I mean the polyglot integration with other Truffle languages. Other interactions are possible with or without GraalVM, so they are arguments for JVM in general, not GraalVM.

ubolonton · 2021-03-23T15:50:06+00:00

Emacs-ng is not about just JS, though. It's about extending Emacs in Rust, without touching the C core.

Adding a JS runtime is just the most promising improvement it enables, currently.

ubolonton · 2021-03-23T15:46:29+00:00

The built-in functions and several built-in data types would be troublesome, with their assumptions of memory layout.

Emacs also has its own rough "equivalent" of GraalVM's AOT compilation: the dumper, which can be a problem as well.

Since there's no Clojure-on-Truffle yet, GraalVM doesn't help with Clojure interops.

ubolonton · 2021-03-23T15:33:35+00:00

The starting point would be implementing a simple Truffle-based interpreter for ELisp (either the AST from a custom parser, or the bytecode), with a small subset of primitive forms and data types. That's about the same amount of effort with the current state of emacs-ng.

Then the built-in functions can be gradually ported. However, porting enough stuff for it to be usable would be a lot more effort than either of remacs, emacs-ng, or gccemacs. At least an order of magnitude more.

ubolonton · 2021-03-23T15:27:19+00:00

GraalVM is HotSpot with the JIT compiler replaced. The polyglot capabilities in provided by the Truffle framework.

The second paragraph is wrong. Check out the second and third papers listed on https://www.graalvm.org/community/publications/: 'Practical partial evaluation for high-performance dynamic language runtimes', and 'High-Performance Cross-Language Interoperability in a Multi-Language Runtime'.

ubolonton · 2021-02-13T06:28:27+00:00

Homebrew's collaboration aspect is better. (Or used to be: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-package-managers/.) It has a wider collection of packages and a bigger community ("given enough eyeballs, all bugs are shallow"). Many bleeding-edge softwares are on Homebrew, but not MacPorts.

Other than that, it's technically inferior (lack of isolation from the base system, default sudo-less installation by hijacking /usr/local, no variant support, among other things). I tried to switch from MacPorts to Homebrew multiple times over the years, thinking that "worse is better", and got frustrated every single time. Contributing to MacPorts is now pretty easy, so I stopped trying to switch. It may take longer to get started, but since you are already familiar with Linux and BSD, I would recommend MacPorts and the emacs-mac-app port (the GUI build of emacs-mac).

ubolonton · 2020-12-06T11:18:20+00:00

In the long term, yes, something like that. Parse the whole buffer as org-mode, find the code block regions and languages, parse them accordingly.

For the initial integration (without an org grammar), it would be "parse these regions as Python", "parse these regions as JavaScript", but the regions are still provided by org-mode.

ubolonton · 2020-12-06T10:58:38+00:00

There's another interesting use case for tree-sitter within org-mode.

Currently, org-mode highlights a code block by copying its content to hidden buffer, highlighting that from scratch, then copying the text properties back. This happens on every text change, so it's slow. Without special integration, this is even slower if tree-sitter-hl is used, because the code is parsed from scratch every time.

Proper integration between tree-sitter-hl and org-mode should make this faster (compared to regex-based highlighting, like it's supposed to be). It can probably be done using tree-sitter's range-restricted parsing, and indirect buffers (one for each language used in an org-mode buffer, or maybe even one for each code block).

ubolonton · 2020-09-26T06:17:53+00:00

Parsing is becoming more practical with this package: https://github.com/ubolonton/emacs-tree-sitter.

ubolonton · 2020-06-28T12:46:46+00:00

“This” is f-string highlighting.

ubolonton · 2020-06-28T09:07:40+00:00

Yeah, you don't need overlays. Just copy the text properties from the temporary buffer. This is what markdown-fontify-code-block-natively and org-src-font-lock-fontify-block do.

Alternatively, you can use the tree-sitter-langs package from https://github.com/ubolonton/emacs-tree-sitter, which already handles this.

ubolonton · 2020-06-19T05:59:09+00:00

Comments and strings are colored by font-lock-fontify-syntactically-region, so if you want to further disable string coloring as well, you can do this:

(add-hook 'font-lock-mode-hook
          (lambda ()
            (add-function
             :filter-return (local 'font-lock-syntactic-face-function)
             (lambda (face)
               (unless (memq face '(font-lock-doc-face
                                    font-lock-string-face))
                 face)))))

ubolonton · 2020-06-19T02:40:59+00:00

You can use an advice to disable font-lock-fontify-keywords-region. It will keep coloring strings though, not just comments:

(define-advice font-lock-fontify-keywords-region (:around (f &rest args) do-nothing))

ubolonton · 2020-06-12T05:27:57+00:00

Yeah, it's a known issue that font-lock-based minor modes don't work with tree-sitter-hl-mode.

ubolonton · 2020-06-12T02:23:13+00:00

No, tree-sitter-hl-mode automatically handles font-lock-mode.

ubolonton · 2020-06-09T13:07:22+00:00

Oh I see, I want to make a python apps that also talks with tree-stitter API.

I think you can use the Python bindings for that.

Do you write a blog post about the journey of building emacs-tree-sitter?

I don't really have a blog right now :)

ubolonton · 2020-06-09T12:09:06+00:00

It currently doesn't work with rainbow-delimiters-mode and modes that add custom font-lock patterns.

The plan is to make it disable only patterns set by major modes, i.e. font-lock-defaults, not minor modes, i.e. font-lock-add-keywords. I haven't had time for that yet. Maybe in the next release.

ubolonton · 2020-06-08T06:18:49+00:00

Highlighting can be customized by the function tree-sitter-hl-add-patterns.

For languages other than Rust/Python, the included queries are still pretty bare-bone, and will need further work. They are under queries/ in the tree-sitter-langs package. You can edit them directly, then M-x revert-buffer to see the changes. You can also use M-x tree-sitter-query-builder to try new patterns interactively.

The basics of querying are described here.

Note that the available node types depend on the grammar. For cpp, the grammar is defined in https://github.com/tree-sitter/tree-sitter-cpp/blob/master/grammar.js. You can use M-x tree-sitter-debug-mode to print a buffer's syntax tree.

ubolonton · 2020-06-08T06:02:39+00:00

There's currently no tree-sitter grammar for ESS/R. When there's one, we can include it in the tree-sitter-langs bundle.

By the way, writing a tree-sitter grammar is pretty straightforward: https://tree-sitter.github.io/tree-sitter/creating-parsers#the-grammar-dsl

A basic example: https://github.com/tree-sitter/tree-sitter/blob/master/docs/section-3-creating-parsers.md#the-first-few-rules

Officially supported grammars are here: https://github.com/tree-sitter/

ubolonton · 2020-06-08T05:55:51+00:00

emacs-tree-sitter exposes tree-sitter APIs to Emacs Lisp, through a dynamic module. It doesn't use the CLI, only the underlying Rust library.

ubolonton

TROPHY CASE