cool! how does this work? e.g. how do you know which UI element matches which text element, do you track it while rendering? How do you propagate changes in the UI? do you update the text and then re-render the whole UI?
I use the the code lenses of code action feature of the LSP so that the user can start a preview. The LSP server will then open a native window on desktop.
Every time the users do some change in the code, the editor sends the document and we re-render the preview.
I use the textDocument/documentHighlight request to know when elements are being selected from the code so I can highlight them in the preview.
When selecting an element in the preview UI, my LSP server sends a window/showDocument to position the cursor at the right location. And if the user changes property or do change in the file, we do a workspace/applyEdit command with the changes.
Got excited about the function keys but unfortunately the Glove80 isn't a replacement for my Kinesis Advantage. I really dislike a battery powered keyboard, plugging in a cable into my laptop in the morning is something that never bothered me. However, having a failing keyboard/mouse in the middle of some work really annoys me.
Maybe I am wrong but aren't two movable parts a bit annoying as well? My keyboard gets moved on my desk quite a bit and repositioning two moving parts sounds quite tedious...
However, having a failing keyboard/mouse in the middle of some work really annoys me.
Do you mean failing because the battery is empty? Why not hook it up then and power it through USB? There are handy split cables with which you can hook up both halves in one go. Some people even disconnect the batteries.
Maybe I am wrong but aren't two movable parts a bit annoying as well? My keyboard gets moved on my desk quite a bit and repositioning two moving parts sounds quite tedious...
Hasn't been an issue for me. But you could always fix the distance in some way (3D printed tool, measure the distance and cut out some plastic/papes, etc.). Personally I just put my arms how I find them comfortable and then position the halves to align with that. Takes maybe five seconds.
Compared to the Advantage2, I use a slightly wider separation distance, so it's more comfortable (though the KA2 distance was still ok-ish for me).
I type a lot but not that much typing that pads per finger would be an issue for me. I use f keys for changing desktops (ctrl + Fx) and I use the media keys to change volume. The later I use infrequently and not having a symbol on a key wouldn't work for me, I wouldn't remember where it is...
You can still use layers even though there is an extra row of keys so not sure why to remove keys other people rely on.
> … so not sure why to remove keys other people rely on.
It’s nice for some people, including me, too have fewer rows of keys because then I have greater confidence in my peripheral vision. Extra rows introduce uncertainty.
Agree! main points I don't like about the 360 are the missing F-keys and wireless, i.e. the need to charge it constantly. In this line, a use hub would be nice to connect a mouse like it is possible for the old Advantage..
Other frameworks like express (nodejs) or actix (Rust) also don't crash if you "throw" in an request handler so this doesn't sounds very exciting to me. The interesting question for me is how retries are handled after an error occurred? For example, if the error happens in an http request handler, does the request still fails with 500 or is it magically retried by Erlang while keeping the request hanging? For internal service calls how are retries working? i.e. how can I configure that a request is retried after a failure? I guess Erlang does this and this is the power behind it?
The example of a missing file seems not very good since its a problem that is probably not solved by waiting. A better example is probably a busy DB that is temporary not reachable?
The Erlang VM is built around message passing, so in the case of a dropped database connection your application code would pass a message to the database API asking for the results of a SQL query. The database API is currently trying to reconnect, so it’s not processing that queue of messages, but once it gets there it’ll pick up the message, run the query, and then send one back to the process that asked. This is all largely transparent to your application code, beyond being able to set some preferences in your return message handler around things like how long you’re willing to wait.
The whole “let it crash” thing comes from Erlang’s process supervision - in practice the DB API isn’t actually retrying. It’s continually failing to connect and if it can’t the process just crashes. The supervisor then notices and starts a new process in its place, this continues until either a process successfully starts or the configured retry count is hit. If the retry count is exceeded then the supervisor crashes, either taking the entire application with it, or more commonly being restarted itself by the next supervisor up the tree.
The point is that Erlang (the BEAM VM) follows this pattern everywhere, not just for web requests. It’s baked into the language and runtime, and that’s infinitely more powerful and customizable than not crashing in a request handler.
What happens if you borrow a more complex mutable object to a thread and this thread is killed somehow leaving the borrowed object in a corrupt state, e.g because the thread was killed while doing an unsafe operation on the borrowed object. Can't I catch_unwind the scope call and then access the corrupted object?
Unwind safety is an underdeveloped aspect of rust. Unwinding is not meant to be used for control flow. catch_unwind should be used to protect FFI callbacks and restart unwinding on the other side. I would consider its use in thread pools to be an abuse of the feature.
That said, given that unwinding does exist, it is the responsibility of unsafe code blocks to account for it. They must not allow safe code to create UB. That they mostly don't account for it is a culture issue.
It ultimately depends on how they're written. println! is a macro, and doesn't "break the tooling". on the other end of the spectrum, using a crate like demonstrate (unit testing) produces hard to understand errors and slows down the IDE.
I don't remember experiencing Rust Analyzer crashes for a long time, though (I do remember some in the past).
println! is only a declarative macro, whereas Maud is a proc macro.
The declarative macros aren't too head-twisting for tools, they just expand as declared, this can sometimes have a few surprising effects but generally it is very manageable. Procedural macros have essentially unlimited power and thus are sometimes entirely impossible to analyse.
Given all the drawbacks of passwords there isn't really an alternative to passwords for me. For example, what do you do if you only have 2-factor auth and you lose access to all your devices/docs? e.g. when you are on holidays?
PAKE supports in the browser would be awesome. Some applications for it:
