libera/#commonlisp - IRC Chatlog

8:39:27 deeppandya_1162 ** NICK deep-pandya

9:04:37 deeppandya_5374 ** NICK deep-pandya

11:25:59 simyager Yes lem is interesting, unfortunately sdl2 backend is deprecated in favor of webkit which looks and feels worse to me, also less performant.

11:27:14 simyager But I respect the developers a lot especially after looking at emacs source code the other day. 600k lines of C and 600k lines of elisp, not even counting stuff like calendar, irc, email, org-mode and so on.

11:29:46 simyager stumpwm is pretty awesome, I've been daily driving it for 3 years at this point.

11:30:29 beach But doesn't Lem use SLIME for Common Lisp programming just like Emacs does?

11:33:21 simyager I believe it uses micros which is slightly modified version of slime so dev environment is pretty much identical to Emacs.

11:33:46 jackdaniel it seems that lem has embraced llms for development

11:34:15 simyager Not sure what is missing compared to the smalltalk environments mentioned frequently, I never experienced it.

11:34:54 beach simyager: Yes, I see. So it had the same issues with syntax highlighting and indentation as Emacs+SLIME.

11:36:19 jackdaniel I think that lem uses tree sitter for highlight, while slime uses something else. but yes, either is inaccurate for languages with dynamic syntax

11:36:37 beach I see. Interesting.

11:36:41 Lord_of_Life_ ** NICK Lord_of_Life

11:42:06 beach simyager: I also don't know what it is missing compared to smalltalk, but I know lots of things that it is missing that I would like to have.

11:44:55 simyager It must be easier to write an extension to improve those problems in lem compared to emacs, no ?

11:46:48 beach Well, the entire way of analyzing the buffer contents would have to be changed. So, sure, that would be easier to do if the editor is written in Common Lisp.

11:48:05 beach I think jackdaniel summed it up. Common Lisp is a language with "dynamic syntax", so any fixed way of analyzing the buffer contents is bound to fail sometimes.

11:49:54 jackdaniel I think that tree-sitter like approach should work fine for standard readtable if we assume that all operators are highlighted and indented the same

11:50:10 jackdaniel while regexps always break, disregrading of a domain

11:50:48 beach Would it be able to distinguish between a Common Lisp symbol used as a Common Lisp operator and a Common Lisp symbol used as a lexical variable?

11:52:19 jackdaniel if I understand correctly, tree-sitter converts the source code into AST, so operators can be discerned from values; distinguishing roles of symbols is another story (except from special operators that are known)

11:52:39 jackdaniel s/values/arguments/

11:52:47 beach I see.

11:54:21 jackdaniel CST it seems, but yes - it is context free parsing

12:02:02 beach I was thinking of a case like (LET ((PROG1 ...)) (SOME-MACRO (PROG1 ...))) where the argument to the macro is not a form. It seems to me that one would have to expand the macro in order to determine the role of the second occurrence of PROG1.

12:06:32 jackdaniel with context-free grammar the moment you encounter unknown operator (or when you know that the operator is an arbitrary), figuring out the role of a symbol is a futile effort

12:06:55 jackdaniel that said, an arbitrary macro can expand PROG1 to be both a variable and an operator

12:07:15 jackdaniel so I don't think that the problem is solvable even when you can fully analyze the macro expansion (because the editor highlight becomes ambiguous anyway)

12:08:47 beach Indeed, the symbol can be used in both ways in the macro body. But if it is not, then it should be possible to highlight it right.

12:08:54 jackdaniel perhaps some hint that allows the programmer express whether macro arguments are treated as forms, destructured, or are hairy, would help with highlighting in the editor but I don't know how that would look like in the source code

12:09:59 beach I think expanding the macro would take care of almost all cases.

12:10:45 jackdaniel another thing I'm curious about is how editor would know that the macro has been redefined to update its inference - some compiler hook perhaps?

12:11:48 jackdaniel I agree that for unambiguous situations having correct highlight is nice; I don't think that /not/ highlighting arguments to macros at all is the worst thing imaginable to do. using regexp that always catches (prog1 ) as a special oeprator though seems to be the worst

12:29:43 simyager Even before that, when you change a macro definition, you have to go through and update the places that expanded the old definition and still uses that. Is there a hook that automatically recompiles everything that macroexpands ?

12:31:02 beach I don't think that would be semantically correct.

12:31:33 dlowe huh, I thought slime would query the inferior lisp for syntax highlighting

12:31:42 simyager Just realized my sly-who-macroexpands doesn't even work at all.

13:20:21 simyager What about coalton editor ? Does it also use swank/slynk/micros ?

13:21:58 simyager https://coalton-lang.github.io/mine/ this one

13:25:59 deep-pandya ** NICK deeppandya

14:16:01 RSBach ** NICK RMSBach

14:46:04 Visen simyager: Yes the webview frontend for lem still seems a bit janky to me

14:46:12 Visen I've just been using the ncurses version

14:47:35 Visen I believe the reason for using a web browser for the ui is that they want to be able to render the html embedded in markdown documents

14:54:40 deep-pandya ** NICK deeppandya

15:14:18 dlowe if you want that, you can either embed a browser in your editor or embed your editor into your browser

15:53:32 deep-pandya ** NICK deeppandya

16:16:47 Visen dlowe: I think this issue explains the reasoning if you want more details https://github.com/lem-project/lem/issues/1867

16:16:57 Visen Like I said, I just use the ncurses version

17:26:54 deep-pandya ** NICK deeppandya

18:09:46 deep-pandya ** NICK deeppandya