{"action":"created","issue":{"url":"https://api.github.com/repos/abo-abo/lispy/issues/250","repository_url":"https://api.github.com/repos/abo-abo/lispy","labels_url":"https://api.github.com/repos/abo-abo/lispy/issues/250/labels{/name}","comments_url":"https://api.github.com/repos/abo-abo/lispy/issues/250/comments","events_url":"https://api.github.com/repos/abo-abo/lispy/issues/250/events","html_url":"https://github.com/abo-abo/lispy/issues/250","id":145319517,"number":250,"title":"Support for lispy-flatten with common lisp (at least for macros)","user":{"login":"noctuid","id":4250696,"avatar_url":"https://avatars.githubusercontent.com/u/4250696?v=3","gravatar_id":"","url":"https://api.github.com/users/noctuid","html_url":"https://github.com/noctuid","followers_url":"https://api.github.com/users/noctuid/followers","following_url":"https://api.github.com/users/noctuid/following{/other_user}","gists_url":"https://api.github.com/users/noctuid/gists{/gist_id}","starred_url":"https://api.github.com/users/noctuid/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/noctuid/subscriptions","organizations_url":"https://api.github.com/users/noctuid/orgs","repos_url":"https://api.github.com/users/noctuid/repos","events_url":"https://api.github.com/users/noctuid/events{/privacy}","received_events_url":"https://api.github.com/users/noctuid/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-04-02T00:55:24Z","updated_at":"2016-04-02T10:19:57Z","closed_at":null,"body":"I want to continue the discussion started by @liuxueyang in #203.\r\n\r\nIt's true that it's not possible to retrieve the code for every function, but `xf` could work for macros which is what I'd mostly use it for. \r\n\r\nAs for functions, maybe it could be made to work in some cases? [function-lambda-expression](http://clhs.lisp.se/Body/f_fn_lam.htm) can potentially be used for user eval'd functions in some implementations. For example, with sbcl if I define a function in the repl:\r\n```\r\n> (defun test (a b)\r\n    (+ a b))\r\n> (function-lambda-expression #'test)\r\n(SB-INT:NAMED-LAMBDA TEST\r\n    (A B)\r\n  (BLOCK TEST (+ A B)))\r\n```\r\n\r\nAnother problem is that this would require parsing the output differently depending on the compiler.\r\n\r\nAlternatively, I guess the function definition could be grabbed from the actual source files with `slime-edit-definition`. Would that be an okay workaround?\r\n\r\nAlso what is the barrier preventing common lisp support for `lispy-debug-step-in`?\r\n"},"comment":{"url":"https://api.github.com/repos/abo-abo/lispy/issues/comments/204688661","html_url":"https://github.com/abo-abo/lispy/issues/250#issuecomment-204688661","issue_url":"https://api.github.com/repos/abo-abo/lispy/issues/250","id":204688661,"user":{"login":"abo-abo","id":2937359,"avatar_url":"https://avatars.githubusercontent.com/u/2937359?v=3","gravatar_id":"","url":"https://api.github.com/users/abo-abo","html_url":"https://github.com/abo-abo","followers_url":"https://api.github.com/users/abo-abo/followers","following_url":"https://api.github.com/users/abo-abo/following{/other_user}","gists_url":"https://api.github.com/users/abo-abo/gists{/gist_id}","starred_url":"https://api.github.com/users/abo-abo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/abo-abo/subscriptions","organizations_url":"https://api.github.com/users/abo-abo/orgs","repos_url":"https://api.github.com/users/abo-abo/repos","events_url":"https://api.github.com/users/abo-abo/events{/privacy}","received_events_url":"https://api.github.com/users/abo-abo/received_events","type":"User","site_admin":false},"created_at":"2016-04-02T10:19:57Z","updated_at":"2016-04-02T10:19:57Z","body":"> function-lambda-expression\r\n\r\nThanks for the pointer. I've added some rudimentary stuff.\r\n\r\n> Alternatively, I guess the function definition could be grabbed from the actual source files with slime-edit-definition. Would that be an okay workaround?\r\n\r\nYes, it's also a good idea. I think it would be best for the REPL to support it natively, but this way can also work.  For example, Python's Jedi is quite successful in doing this type of stuff, even though Python's REPL is pretty thick.\r\n\r\nThis would mean writing a middleware similar to Jedi for Common Lisp. I'm not really a Common Lisp guy, but if someone else would do this, it would not be hard for me hook up lispy with that middleware.\r\n"}}