This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
In Sweden Christmas Eve is the big thing with Christmas. Traditions vary some between families of course, but it’s common with some morning presents in the christmas sock so that the kids can make it through the long wait of opening the presents under the tree, which happens after Christmas dinner.
Merry Christmas all friends of Calva! (If you celebrate some other holiday this season I hope you have a merry time too, of course.)
In the spirit of Christmas I hope you’ll consider giving the Calva extensions some thumbs up and good words on the Visual Studio Marketplace: https://marketplace.visualstudio.com/search?term=Calva&target=VSCode&category=All%20categories&sortBy=Relevance ❤️
I'm actually going through the horrific account recovery process for my microsoft account just to give you a rating
of course, you provide me with a home away from emacs when doom-emacs' develop branch breaks
I also think it's really important for the clojure experience in a popular editor like VSCode to be great, to help attract people to the language
proto-repl in Atom is nice, but, it seems abandoned, doesn't work well with anything but leiningen, and Atom seems to be losing mindshare to VSCode
and I'm not going back to the mines of vim anytime soon, my love for vim emulations non-withstanding
proto-repl has a neat tree-like explorer for data structures which I found useful while developing a query engine for an analytics platform
ProtoREPL shows the way feature-wise. I hope we will be able to bring some of that goodness to vscode.
I've been playing around with other languages recently as well, Rust and Reason in particular, and I feel VSCode offers a better experience there, so it's nice having a single environment to keep things in
@pez I’m secretly developing a web-based REBL-esque thingy. we should pow-wow at some point when I have more done and you have time to see if we can make something real cool
@lilactown 😄 that sounds brilliant. There is a lot of scope to do something very cool there, especially if it's easy to extend views somehow as an end user.
calva: lint on save option, when disabled, disable linting altogether or does it lint on change?
if github is telling the truth, those are the only places where that configuration option (and linting) are called, but @pez would be the definitive answer, naturally 🙂
calva.lintFile action should not be affected, from what I can see, so you should still be able to invoke it manually with Ctrl+Alt+V, or "Lint current file", but it seems that it should never happen without your explicit request.
I have the "Clojure Linter (Joker)" plugin installed as well, and wondering how they interact
Calva has no knowledge of that extension, so unless it knows about calva (and if it's possible for vscode extensions to look at eachother's config) I guess they just do their own thing 🙂
eh, I was working up a big function and auto-save had saved halfway through because I was distracted by my environment, and the error stuck around until I manually saved
there may be an isomorphic command in Clojure Linter (Joker), but I'm unfamiliar with it
heh, well, it's just different behavior from what I'm used to with my currently-broken emacs setup
yeah, so I've looked at the source of that plugin here: https://github.com/martinklepsch/vscode-joker-clojure-linter/blob/master/src/extension.ts
I need to create a radar plot with all the various editors and the things I look for in them
i mean, eshell is nice, ansi-term is nice, but since they're so tied to the GPL you're not going to get libuvterm or whatever neovim is using in there
although I do like that it tries to emulate a posix
sh under windows, which makes it nicer for me
yeah, dammit stallman. ironically the GPL exists because Symbolics stole all his code from the MIT lisp machine project. 😉
my biggest gripe about both VSCode and Atom is how difficult it is to keep your full config in git
yeah, it makes a mess, and as a (very newbie) extension developer, I find it's api... lacking.
I have problems with random source paths getting set absolute in my .vscode configs, do you have similar issues?
as I'm not going to sign into my personal github account from my tightly-locked-down-and-probably-rooted work machine
I have some silly shell script that moves up my
.emacs/init.el attached as an emacs interactive defun here
there's no canonical list of extensions I can sync between machines and then tell it to "make it like that"
ah, wait- it's not just CONFIG, the problem for you is you don't know what extensions to install, right?
huh, that is an interesting and yet surely easy problem, you need to PM me and remind me of this in a few days after I sober up 😉
I use a roaming profile so this one didn't bite me, but there should definitely be a decent way of doing this
for the most part it's fine, I do different things on my work and personal machines and don't need f.e. the reasonML stuff or the Hugo CMS stuff on my work machine, nor the cucumber step definition stuff on my personal machine
I use the same emacs config on both machines and it's fine, and VSCode is at least sane about extension loading times unlike Atom
but, i just futz about until the errors go away. That said, since I'm a contractor I tend to bring my own device, unless I have some silly air-gap policy, in which case it becomes exciting form filling in time anyway.
I abandoned atom and went back to emacs because it just randomly would tank performance horribly, which is a shame 😕
it's a wise decision. contractors are the last to come in, and the first to get kicked off a project.
so okay, you're looking for a vscode plugin that can work out the extensions you need installed, and install them, right?
or.. some anonymous thing like pastebin so you can post new configs but at least get the setup you need.
I have to say though, I'm pretty happy so far with my experience of vscode extension dev. I wish I could just open a scratch buffer and start evaluating typescript in the main process and be allowed to destroy things if i'm an idiot
but sadly that's basically, places where my code doesn't have to talk to anyone else's code
I spend more time than I would like in some typescript/react native code that I'm not super familiar with and the team that works on that code all uses VSCode and I haven't figured out how to make emacs play nicely with either JSX or lsp
when I get frustrated with emacs from time to time for my clojure work I come over to VSCode and kick the tires
but I think it's doable to raise the bar on vscode, and I don't think it's THAT much work
I don't think it's the millenials you have to worry about there, it's the tide pod generation
I like tig on the cli for git, use it from within the VSCode terminal, but it's no magit
I've thought about building out a cli magit clone in rust, but I have so little time outside of work for code anymore, and I'm spending that on an app I'm working on that I want to sell
also, I don't really mean to sleight millennials, just the problem with emacs is the conventions are so arcane as to be unnecessarily cryptic these days
like, "we know everyone else settled on these terms for window & clipboard management like 30 years ago, but our terms predate those, damnit! USE THEM!"
there was a lot of misty eyes over the lispm's in the early 2000's, although as a former user you can totally toast your environment and its security is a joke 🙂
I think nav/datify and a perusal of https://dspace.mit.edu/handle/1721.1/6946 would extract it though
and looking at vscode, I've had to re-implement a lot of things for my upcoming
calva-fmt patch to make it usable, which really should have been exposed by vscode
(it is not cool that I have to implement my own re-startable lexer that syncs with the edits in order to figure out if the line above is inside a multi-line string...)
I could rely on their lexical info, but they.. uh.. went a bit weird. vscode internally stores the 'colour', not the 'type' of a token. whoops.
it's fine, I have a fast robust system for that now, but it's silly that I had to spend a week on it so I could get to the part where I got to start doing what I needed.
emacs uses a slightly silly lisp-specific facility for a lot of it's lisp work, too, so it's not immune to this either.
I've noticed some slightly variant behavior with another extension I use for C stuff that varies based on my current theme
it's weird and I just sort of wrote it off as the usual jank associated with cobbling together one's environment piecemeal from bits and bobs
but if they're looking at the color of a token and not its type, that would explain the behavior
I'd been looking at LL(1) parsers that could do this in the 80's, but it seems they made it pretty generic. It's what Atom uses internally now.
hopefully now that Microsoft owns Github we'll see a bit more collaboration from them on their editor efforts
it would be neat. handling breadcrumbs in some random language would be far less work imo
vscode was an easier proposition to me after suffering atom performance tanks, so I can see why they have architected it the way they have