Multi-line embedded lisp-code

[joergdw]

Sometimes, embedded lisp-expressions can become quite large. (E.g. 12 lines by ordinary formatting.)

Could we add a way to make multiline-lisp-definitions. I am aware of the expand-env-section. However it looks as it would not be multiline-aware. Additionally I was not able to bring in a let* definition there. Is it supposed to support access to previous definitions within the same section (as in let*)?

[monnier]

Sometimes, embedded lisp-expressions can become quite large. (E.g. 12 lines by ordinary formatting.) Could we add a way to make multiline-lisp-definitions. I am aware of the [expand-env](<https://joaotavora.github.io/yasnippet/snippet-development.html#orga37203f>)-section. However it looks as it would not be multiline-aware. Additionally I was not able to bring in a `let*` definition there. Is it supposed to support access to previous definitions within the same section (as in [let*](<https://www.gnu.org/software/emacs/manual/html_node/elisp/Local-Variables.html#index-let_002a>))?

BTW this (and your regexp example in #1181) would be better served by the kinds of snippets that were to be supported by the snippet-engine (see the `snippet-engine` branch).

[joergdw]

That branch looks quite aged, hmmm 🤔. I would be surprised if I were the only one asking about multiline-capability. Self-contained snippets (for easy sharing, which is an important thing from my point of view) otherwise tend to have a unnecessarily poor readability. At least if they do some (non-trivial?) work for the user.

[monnier]

That branch looks quite aged, hmmm 🤔.

Yes, it was abandoned before reaching fruition. But it allows (well: was designed to allow) writing snippets directly in Lisp (a bit like `define-skeleton` but with the full power of YASnippet snippets), which would make sense in your case where you have more Lisp code than "text". Stefan

[monnier]

Sometimes, embedded lisp-expressions can become quite large. (E.g. 12 lines by ordinary formatting.)

Embedded where? Inside the snippet (i.e. in a `${...}`) or in the header?

Could we add a way to make multiline-lisp-definitions. I am aware of the [expand-env](<https://joaotavora.github.io/yasnippet/snippet-development.html#orga37203f>)-section. However it looks as it would not be multiline-aware.

It should be fairly easy to allow headers to span multiple lines. I'm not completely sure what format we could/should use. One natural option would be to do like RFC822, i.e. consider that a subsequent line that's more indented than the header to be part of the same header, so you could write: # name: my-snip # expand-env: ((a 1) (b 2) # (c 3) (d 4) (e 5)) # group: my-group # -- ... but that would break for those who like to align their colons, since something like: # name: my-snip # expand-env: ((a 1) (b 2) # (c 3) (d 4) (e 5)) # group: my-group # -- ... would treat the `group:` as being part of the `expand-env` header.

Additionally I was not able to bring in a `let*` definition there. Is it supposed to support access to previous definitions within the same section (as in `let*`)?

No, indeed it's like a "plain let".

[joergdw]

Embedded where? Inside the snippet (i.e. in a ${...}) or in the header?
Inside the snippet (in a ${…}).

It should be fairly easy to allow headers to span multiple lines. I'm not completely sure what format we could/should use. One natural option would be to do like RFC822, i.e. consider that a subsequent line that's more indented than the header to be part of the same header, so you could write: # name: my-snip # expand-env: ((a 1) (b 2) # (c 3) (d 4) (e 5)) # group: my-group # -- ... but that would break for those who like to align their colons, since something like: # name: my-snip # expand-env: ((a 1) (b 2) # (c 3) (d 4) (e 5)) # group: my-group # -- ... would treat the group: as being part of the expand-env header.

Three ideas:

• We anyway start with the snippet only after a line containing # --, when we have a large one. That means, we can do line-breaks before and don't need to start the next line with a # in which case (but only before # --) lines starting without # are treated as belonging to the same header as the last one.
• Lines starting with #^ (or any other suitable additional symbol) belong to the header before. This looks at least to me, simple. (Inspiration from Rust, where you add a ! to the comment-prefix to indicate that it belongs to the super-elemenet instead of the subsequent element.)
• If the line is further indented than the one above and starts with $#[[:space:]]+ followed by a known header, then it belongs to the element before. This does not require additional syntax but perhaps may be a bit more complicated to implement.

[monnier]

> Embedded where? Inside the snippet (i.e. in a `${...}`) or in the header? Inside the snippet (in a `${…}`).

Hmm.... I thought they could already be multi-line. Can you give an example?

[joergdw]

The subsequent snippet lets you create an org-mode code-block and offers proposals for all modes that registered in a suitable list in emacs. Btw: org-mode should work and set the correct editing mode for all proposals by yasnippet.

# -*- mode: snippet -*-
# name: code-block
# key: #src
# --
#+CAPTION: ${1:Caption}
#+NAME: ${2:anchor}
#+BEGIN_SRC ${3:sh$(yas-choose-value (let* ((empty-choice (list "")) (source-ids-from-org-mode (seq-map 'symbol-name (seq-map 'car (progn (require 'ox-man) org-man-source-highlight-langs)))) (source-ids-from-alists (seq-filter (lambda (elt) (not (eq 'cons (type-of elt)))) (seq-map (lambda (sym) (replace-regexp-in-string "\\\\(-ts\\\\)?-mode" "" (symbol-name sym))) (seq-filter (lambda (elt) (not (eq 'cons (type-of elt)))) (seq-map 'cdr (append auto-mode-alist interpreter-mode-alist magic-mode-alist))))))) (cl-sort (delete-dups (append empty-choice source-ids-from-org-mode source-ids-from-alists)) 'string-lessp)))}
  `yas-selected-text`$0
#+END_SRC

Actually my snippet does more, for other options after BEGIN_SRC, but this is by far the largest thing among them.