Common Lisp formatting changes the code

[simendsjo]

There's something strange when formatting my lisp code. Certain characters is
escaped, and some is split. Notice how (.>) becomes (\.>) and #\space
becomes #\s pace.

(define get-list
  (.> get
      (map (split #\space))))

(define get-list
  (\.> get
       (map (split #\s pace))))

[RuijieYu]

Please check if #642 fixes the #space issue -- it should. It has been recently merged to master.

OTOH, what is .>? I haven't used clisp for long, and haven't heard of this one yet. Do you have its documentation URL handy? Thanks.

[simendsjo]

OTOH, what is .>? I haven't used clisp for long, and haven't heard of this one yet. Do you have its documentation URL handy? Thanks.

EDIT: It's not clisp, it's common lisp. Or rather coalton, but it's just regular common lisp.

It's a custom macro, ref https://github.com/coalton-lang/coalton/blob/main/src/language-macros.lisp#L41

But should lispy format ever change/escape the code?

[RuijieYu]

Correct me if I'm wrong, but isn't "clisp" just an acronym for common lisp? At least that was my impression because I think "Emacs Lisp" ≈ "elisp" and therefore "Common Lisp" ≈ "clisp"?

---

From the look of your issue, I'm pretty sure lispy reads the s-exp correctly, while deciding that quoting the "." is necessary when it is about to convert its internal data structure back to (formatted) common lisp code. Since I currently don't have access to a functional Emacs, can you confirm the following two for me:

(lispy--read "your code to be formatted")

should return a string containing the .> unmodified. If this claim is false, then something should be done in lispy--read. Please paste it in your reply if it's not too inconvenient.

Then, go to a spare buffer, and run:

(lispy--insert (lispy--read "your code"))

And observe that it outputs the same incorrect result as in your initial report. This means some logic should be tweaked in lispy--insert, although I can't figure out what exactly with only my eyes rather than a functional Emacs available.

[simendsjo]

Correct me if I'm wrong, but isn't "clisp" just an acronym for common lisp? At least that was my impression because I think "Emacs Lisp" ≈ "elisp" and therefore "Common Lisp" ≈ "clisp"?

Might well be, I'm not that into Common Lisp. Thinking about it, I've heard
CLISP is a dead implementation of Common Lisp. I thought you we're referring to
some other lisp I haven't heard of -- there's quite a lot of them :)

(lispy--read "your code to be formatted")
should return a string containing the .> unmodified. If this claim is false, then something should be done in lispy--read. Please paste it in your reply if it's not too inconvenient.

It doesn't, (lispy--read "(.>)") returns (\.>).

Then, go to a spare buffer, and run:
(lispy--insert (lispy--read "your code"))

This keeps the escaped dot, yes:
(lispy--insert (lispy--read "(.>)")) ;; (\.>)

[simendsjo]

Please check if #642 fixes the #space issue -- it should. It has been recently merged to master.

Yes, thanks, upgrading lispy worked!

[simendsjo]

Not sure if it helps, but here are some test-cases

before	after
(.)	(\.)
( .)	(\.)
(. )	(.)
( . )	(.)
(f .)	(f \.)
(f . )	(f .)
(. f)	(. f)

[RuijieYu]

Found the issue. Everything is fine in lispy--read, until when we hit the call (read str) at the end, which escapes the ..

I think the solution is to identify unconventional yet valid symbol names, then wrap them with ly-raw symbol. We already have facilities handling this internal representation.

The problem remains, though, that different variants define valid symbols differently -- but maybe we can err on the side of caution and say that any valid symbol according to the syntax table in effect, but containing any chars that might have special reader syntax (like "#", ".", ",", "@", "?", etc), should be wrapped.

Thoughts?