25 Matching Annotations
  1. Apr 2024
    1. If one user marks a word as bold and another user marks the same word as non-bold, thereis no final state that preserves both users’ intentions and also ensures convergence

      Having "bold" mean some semantics, e.g., important.

      Then they merge. Alice does not consider it important, Bob does -> render both. E.g., Bob's "importance" expressed as bold, Alices "not important" as grayed text.

    2. If the context has changed

      E.g.,

      "Ny is a great city."

      Alice removes "great".

      Bob wonts to replace it with "gorgeous", by removing "reat" and adding "orgeous".

      Having merged:

      "Ny is a orgeous city."

      Begs for semantic intent preservation, such as "reword great to gorgeous".

    3. Fig. 4

      Uhh, I'd imagine "remove" would refer to "bold" annotation.

      Otherwise, there can be another "bold" with t < 20, that would be accidentally removed.

      Syntactic intent is not preserved.

    4. Conflicts occur not only with colors; even simple bold formatting operations canproduce conflicts

      Again, let them capture semantics.

      Say, "Alice considers "The fox jumped"" as important. Alice changes mind, only "The" is important. Bob considers "jumped" as important.

      Result: Alice considers "The" important. Bob considers "jumped" important.

    5. Consider assigning colored highlighting to some text

      Color is meant to convey some semantics. Like "accent", or "important". These semantics can coexist, just like italic and bold.

      So a solution may be to: 1. Let users express semantics of their annotations 2. Give user-customizable defaults of how they are to be rendered.

      Ensuring, that semantics's render is composable. I.e., it conveys originally asigned semantics.

    6. Furthermore, as with plain text CRDTs, this model only preserves low-level syntactic intent,and manual intervention will often be necessary to preserve semantic intent based on a humanunderstanding of the text

      Good remark of syntactic vs semantic intent preservation.

      Semantics are in the head of a person, that conveys them as syntactic ops. I.e., semantics get specified down to ops.

      Merging syntactically may not always preserve semantics. I.e., one wants to "make defs easier to read by converting them to CamelCase", another wants the same but via snake-case. Having merged them syntactically, we get Camel-Snake-Case-Hybrid, which does not preserve any semantic intent. The semantics intent here are not conflict-free in the first case, though.

      Make defs readable | | as CamelCase as Snake Case | | modify to CC modify to SC They diverged at this point, even before getting to syntactic changes.

      The best solution would be to solve original problem in a different way - let defs be user-specific. But that's blue sky thinking. Although done in Unison, we do have syntactic systems around.

      So staying in a syntactic land, the best we could do is to capture the original intent: "Make defs readable".

      Then we need a smart agent, human or an AI, specify it further.

  2. Jan 2024
    1. we were we were taken both by the the idea of of annotation being an important part of education and also by the approach that you've taken and the leadership you've provided

      be taken by sth 我們體會到<某事>,也很欣賞<你們的行動>

  3. Dec 2023
  4. Sep 2022
  5. Nov 2021
  6. Dec 2020
  7. Nov 2020
  8. Oct 2020
    1. Arguably what is in­ter­est­ing about Svelte’s approach to state man­age­ment is not the store itself but the auto-sub­scrip­tion that is possible because of the Svelte compiler. By simply appending a $ to a variable inside of a component, e.g. $myVariable, the compiler will know to expect an object with a subscribe method on it and generate the boil­er­plate of sub­scrib­ing and un­sub­scrib­ing for you.
  9. Sep 2020
    1. Links are just <a> elements, rather than framework-specific <Link> components. That means, for example, that this link right here, despite being inside a blob of markdown, works with the router as you'd expect
  10. Aug 2020
  11. Jul 2020
    1. But that's a lot of code to write, so Svelte gives us an equivalent shorthand — an on:message event directive without a value means 'forward all message events'.
    1. preventDefault — calls event.preventDefault() before running the handler. Useful for client-side form handling, for example. stopPropagation — calls event.stopPropagation(), preventing the event reaching the next element passive — improves scrolling performance on touch/wheel events (Svelte will add it automatically where it's safe to do so) capture — fires the handler during the capture phase instead of the bubbling phase (MDN docs) once — remove the handler after the first time it runs self — only trigger handler if event.target is the element itself
    1. Why don't you allow a range without end, like (1..)? There are two advantages. First, we can write ary[1..] instead of ary[1..-1]. The -1 is one of the most I dislike in Ruby. It is very magical, ugly, redundant, and disappointing. I envy Python's ary[1:]. I know that ary.drop(1) is slightly fast, but too long for such a common operation, IMO. Second, we can write (1..).each {|n| ... }.
    1. Shorthand attributes It's not uncommon to have an attribute where the name and value are the same, like src={src}. Svelte gives us a convenient shorthand for these cases: <img {src} alt="A man dances.">
  12. Nov 2019
  13. Feb 2014
    1. What is missing is a space between the $( and the following (, to avoid the arithmetic expression syntax. The section on command substitution in the shell command language specification actually warns for that:

      This is a very good example of why shell scripting does not scale from simple scripts to large projects. This is not the only place where changes in whitespace can lead to scripts that are very difficult to debug. A well-meaning and experienced programmer from another language, but new to bash scripting, might decide to clean up formatting to make it more consistent-- a laudable goal, but one which can lead to unintentional semantic changes to the program.

      Flat, short bash scripts are extremely useful tools that I still employ regularly, but once they begin creeping in size and complexity it's time to switch to another language to handle that-- I think that is what (rightly) has driven things likes Python, Puppet, Ansible, Chef, etc.

      Despite the syntactic horrors lurking in shell scripts there is still a beautiful simplicity that drives their use which is a testament to the core unix philosophy.