There is no equivalent of Emacs' `eval-defun`

[sogaiu]

It was pointed out on Zulip that there is no command to send a top-level expression.

[sogaiu]

Some points of consideration include:

• Behavior within top-level (comment ...) forms. It's not that useful to return nil and it's not likely what a user intends.
• Handling non-tuple constructs like tables, arrays, keywords, etc. These may not come up much, but it might be nicer to function appropriately.
• How to behave when point is not contained in a top-level form (e.g. it's between two top-level (defn ...)s).

If tree-sitter functionality is used, the cost involved to account for the above points may be reasonable.

A non-tree-sitter-based implementation that tries to handle the items above seems like it would be (much?) more costly. One idea is to provide something simpler.

Another consideration is how to handle detection of tree-sitter capabilities and behave appropriately.

[sogaiu]

Here is an initial attempt (note: this is on a separate branch).

A new command named ajrepl-send-top-level-expression is provided. It is bound to C-M-x (what eval-defun's keybinding is locally). It's also exposed via the Ajrepl menu.

The following method was used to provide an alternate implementation in case tree-sitter functionality is not available:

;; https://emacs.stackexchange.com/a/30086
(when (not (require 'ajrepl-ts nil 'noerror))
  (defun ajrepl-send-top-level-expression ()
    "Send top-level expression containing point."
    (interactive)
    (save-excursion
      (let ((beg nil)
            (end nil))
        (ajrepl--column-zero-target-backward)
        (setq beg (point))
        (forward-sexp)
        (setq end (point))
        (ajrepl-send-region beg end)))))

Some rearrangement of code was done to get the above to work out.

[sogaiu]

The mechanism of checking the return value of require:

(when (not (require 'ajrepl-ts nil 'noerror))

does not seem appropriate. Apparently it only works when the file being required does not exist.

[sogaiu]

An alternative approach is to attempt to produce a functional enough non-tree-sitter-based implementation and just use that.

[sogaiu]

janet-mode (ALSchwalm's version) and janet-ts-mode may not have the same setup with respect to syntax tables:

• janet-mode's syntax table
• janet-ts-mode's syntax table

This might lead to differences in behavior between the modes with respect to results returned from functions like syntax-ppss and friends.

It may be that relying on such machinery is not a good approach.