This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-19
Channels
- # adventofcode (44)
- # announcements (2)
- # aws (9)
- # beginners (166)
- # braveandtrue (16)
- # calva (170)
- # cider (14)
- # cljdoc (9)
- # cljs-dev (4)
- # cljsrn (1)
- # clojars (1)
- # clojure (150)
- # clojure-dev (15)
- # clojure-europe (4)
- # clojure-india (3)
- # clojure-italy (93)
- # clojure-nl (18)
- # clojure-serbia (1)
- # clojure-spec (5)
- # clojure-uk (45)
- # clojurescript (54)
- # cursive (19)
- # data-science (8)
- # datomic (83)
- # emacs (6)
- # events (1)
- # hoplon (3)
- # hyperfiddle (3)
- # jobs (6)
- # jobs-discuss (1)
- # klipse (1)
- # lein-figwheel (6)
- # leiningen (15)
- # lumo (1)
- # nrepl (1)
- # pedestal (15)
- # re-frame (48)
- # reagent (4)
- # reitit (2)
- # remote-jobs (1)
- # rum (2)
- # shadow-cljs (111)
- # spacemacs (10)
- # sql (16)
- # testing (10)
- # tools-deps (5)
@mattly in the vsix I packaged there is another, similarly named command, Indent Current Form.
@pez, realised I can store the delta for parens in a line. For every (, +1, for every ), -1. giving me some total value.
this means that doesn't need to be recomputed unless the text changes, and I can scan up and down lines rapidly until I find the appropriate depth from a given point, and then look at the line itself to fine tune the position!
@mattly That was what I had in mind anyway. But it does sound strange with the behaviour you get.
it dramatically simplifies the implementation, and should hopefully make it far more amenable to clojure porting down the line.
I noticed that vscode seems to know what the enclosing forms are for any given cursor position. (If I place the cursor at column zero and visit some different lines vscode highlights the right enclosing lines with a slightly thicker vertical indent-line. Have you seen that?
speaking of which, I've noticed I have subtle colouring bugs with parenthesis with the clojure highlighter
nope, not running anything clojure related other than calva, but I suspect it's a problem with the grammar that ships with vscode.
I see. Well, I have a soon to be two months old PR on that grammar, so it is probably not something that is easily fixed.
In fact I suspect tonsky's paren matcher would actually 'fix' it since it adds decorations to parens
Indeed. I wasn't thinking about that particular glitch, but rather in general and also the PR I filed.
yeah, I think especially with atom no longer supporting textmate grammars it's probably easier to just maintain our own copy looking forward
I think most of Tonsky's features should be ported to Calva Formatter once you have got your lexer/parser together.
yeah he has a nice bunch of stuff there, and I already have all the data I need to do it.
I also think we could maybe wipe that grammar totally and do the highlighting with your stuff.
I would advise against that directly, because vscode has a very, very fast highlighter https://code.visualstudio.com/blogs/2017/02/08/syntax-highlighting-optimizations
it is silly that we have to redo the work vscode does, but there it is. perhaps one day they will expose a sane api.
But, really, I was just trying to save some kittens. I guess I can live with the knowledge that we are redoing the same stuff. 😃
but honestly I figure 25k lines is already hitting the limits of sanity for a clojure file anyway, unless it's an edn file.
the main result of this upcoming PR will be to make indentation etc instant for larger files.
Even then I don't think I'd want to read 25k lines of that. better than 10k of JSON, sure..
yeah. but you wouldn't expect any editor to really enjoy working with a huge file like that
However, if the file was lots of small forms, this would be just as fast as a 5 line file once it's done the first lex pass
there are tradeoffs at every turn building a datastructure to handle things at that scale
There are. We should log some telemetrics to measure how common things like this are. To get informed on what to optimize on.
growing selection to next sexpr (or the whole document) is now robust. I can add the paren-delta stuff if needed (I realise i need 3 values, minDelta/maxDelta/totalDelta per line to avoid losing information), but I think I'll stick with what I have for now and see how it fares
Just rationalizing the api a little so it is easy to write emacs-like save-excursion
walks
If you can shrink it from an arbitrary selection then you also beat the current Calva Paredit command for shrinking. (it can only shrink something thatvwas previously expanded).
yeah. I am currently looking at the emacs operators that are used to mess around with lisp in various packages
I figure if we can get a small core together we can push most of the interesting stuff into calva-lib
so, okay the api as far as you can see it currently is called TokenCursor
, which is a pointer into the document that navigates at the granularity of lexical tokens.
it handles 'smart' movement around the structure. I have some cheesy low-level functions in there currently, but I thought I'd steal a bunch from emacs. forward-sexp
backward-sexp
forward-list
backward-list
up-list
down-list
backward-up-list
so from there, in a perfect world we can have calva-lib
handle that structure and expose those functions to other plugins
and then it follows similar a design that the excellent lisp handling emacs has and we save 40 years of trial and error 🙂
although the JS side of TokenCursor
is actually mutable, the clojure wrappers can be immutable, so using it won't feel too ugly.
I notice a lot of these primitives (possible all?) are also already exposed by calva-paredit
given the following selection (foo (bar baz) (frob)), which of the 3 expressions should it shrink to?
I could select all of them with a multiple selection, but that is probably not 'beating' Calva Paredit meaningfully 😉
grow selection is missing again, because I want to add some 'auto-balance selection' logic and do it nicely, but given an empty, (or balanced) selection a call to backwardUpList()
and upList()
on the left and right positions will perform that stupidly.
oh and all those primitives should be completely identical to emacs (except emacs treats insides of strings slightly differently)- so if you see any discrepancies, that is a bug.
same as before, nothing really happens. it takes hitting o
twice for it to even insert the line
@mattly I get this in the dev console error: ModeHandler: error handling key=o. err=Error: command 'editor.action.insertLineBelow' not found
So maybe that is what is going on. It doesn’t find that command and does not remap correctly.
Here’s another way to do it:
"vim.normalModeKeyBindings": [
{
"before": [
"o"
],
"after": [
"A",
"\n"
]
}
],
I think that with @mseddon’s new take on on-type-formatting we shouldn’t need any reconf of VIM key bindings. (Maybe I have already said that yesterday? Anyway, I said it again, if so. 😄 )
hopefully not, but once the basics are ready I will try to make that so if it isn't 🙂
It's been quite a slog, but it looks hopeful I will have something roughly working by the end of the week or beginning of next, so that's nice.
there are some further optimizations I could do, too, but if I don't draw a line somewhere this will never ship...
It is already a >10X improvement so Peter Thiel would say it is worthwhile proceeding w/o further optimizations. 😃
exactly. and it should hopefully address some of the things mentioned in https://github.com/BetterThanTomorrow/calva-fmt/issues/4
Terminal
interface seems too dumb, but perhaps it could be either a WebView or a different edit mode.
My thoughts are that it would be awesome. And I think quite possible if we use regular editors.
Yeah, regular editor seems the sanest way, because that way people can use their favorite extensions in it
I am slowly poking my way around how they do things, in the hope that one day we achieve feature parity with cider, many moons from now...
Not sure what that means, but in vscode it might be that we have some dirty editors that the user needs to save.
ah, a 'major-mode' is just a set of keybindings and syntax highlighting rules that are active in a buffer in emacs
The work you are doing is again probably going to come in handy when we control the contents of such a repl editor.
yes, I hope so. Basically if we can make regions in the file 'read only' in some way, we should have an okay time.
ah, well, you don't want to start editing previous output. it wants to sort of be a console
or at least, you want to know which areas are output, which may be just some println, vs the command line
but that would mean kinda hosting our own command line editor with all the trimmings etc, so quite a struggle
I think that would risk loosing much of the benefits from the edior being Calva powered out-of-the-box.
well, i'd settle for more public commands for things like "delete next word" or the like
With Calva Paredit you can delete the next sexp, with ctrl+shift+backspace
. It often makes more sense in a clojure file than deleting a word.
@pez on cool lighttable/protorepl goodness, perhaps helping along https://github.com/Microsoft/vscode/issues/3220 might help
Yeah, I don’t remember what my input to the thread was, but I probably tried to bump it. 😃
I have since been thinking that a way to do something like that would be to use vscode custom tree views. Together with nav
that could become pretty powerful.
Think something like “Watch Expressions” in a debugger. Whenever you evaluate something it would be added to the view, and would stay there for as long as the evaluation was active in the editor. And in the tree view you would be able to unfold whatever data structure that resulted from the evaluations..
If we can track an evaluation as the file is being edited the tree view could offer UI for reevaluating entries.
Right now I have started with a thing that might be a bit too hard for me to solve. I am fed up with how I currently need to open and close sockets for every nrepl msg. But to fix that I need a much less naive way of handling bencode decoding. And neither bencode, nore sockets is really part of my skill set. I’m not really a programmer, just a product manager who caught interest in Clojure. Haha.