ottypes / rich-text Goto Github PK

I hope it's a right place to ask such a questions. I've starter porting rich-text library to Python 2.7 and it's already quite usable (although with no test coverage yet). Now I'm not sure whether you'd find it fine if I published it under MIT licence. I'd also want to know, what kind of credits would you like me to provide for you and whether rich-text-py is a fair name for my repo and package. May I publish it to PyPI once it's polished enough?

I need to work this without require dependencies
How to export a standalone client js version?

Could explain shortly how this implementation relates to ot-text and ot-text-tp2?

What's better, what's worse, what's different? Is this implementation more stable? Why to use it?

Thanks :)

Hey,
I experience the issue with Quill on bookmarklet script. After running it on http://www.dwr.com/ initialisation of quill fails with Uncaught Error: diff() called on non-document. I found, that it happens, because clone method of the op returns string instead of object.
After replacing original clone method from https://github.com/ottypes/rich-text/blob/master/lib/op.js#L6,
with

clone: function (attributes, keepNull) {
      if (!is.object(attributes)) return {};
      var memo = {};
      Object.keys(attributes).forEach(function(key) {
        if (attributes[key] !== undefined && (attributes[key] !== null || keepNull)) {
          memo[key] = attributes[key];
        }
      });
      return memo;
    },

everything goes normal. I think it could happen, because original website using some polyfil script. Any thoughts, how to fix or avoid this would be appreciate.

https://github.com/ottypes/rich-text/blob/master/lib/type.js#L2

There is no need for importing package.json anymore. It was used for pulling version number here: 7d2c20b but that line has since been hardcoded.

Ran into a webpack issue where in order to use this package, I had to add .json type in webpack.

Ohai! Needed to use this OT document type to register it as a valid ShareJS type on the browser/client side and found that there wasn't a Bower package for it.

Is it possible to add support for Bower?

I was reviewing your reference implementation as I'm porting the rich-text ottype to Python and wanted to check-in on something.

The implementation of clone() in op.js is the following:

clone: function (op) {
    var newOp = this.attributes.clone(op);
    if (typeof newOp.attributes === 'object') {
      newOp.attributes = this.attributes.clone(newOp.attributes, true);
    }
    return newOp;
  },

I think your intention is to effectively perform a deep copy of the op. It seems to accomplish this by doing a shallow copy and then special-casing attributes since it knows it is an object and does a separate shallow-copy on it's contents.

While this mostly works, seems like you could run into issues when copying an op that represents a new Quill 1.0-style insert embed operation. Since in this case the value of the insert key is itself an object, like the attributes case, you currently would end up just copying the reference but not deep-copying the individual object keys. Am I correct?

Currently potentially hides a bug in compose

I'm using Quill.js together with socket.io/nodejs on backend. Quill has events for deltas, so I can send the deltas to all clients and create Collaborative editor.

I'm using https://github.com/ottypes/rich-text plugin for backend and my question is how I can apply deltas to backend document.
I can do this in Quill by doing editor.updateContents(deltas_array) and current content will be updated with the incoming deltas.

I've searched through whole rich-text plugin documentation, but I couldn't find a feature to apply deltas to a document.

Here's the issue.

If there are two deltas:

var oldDelta = new Delta().insert('ab', {bold: true}).insert('cd');
var newDelta = new Delta().insert('abz', {bold: true}).insert('cd');

And the diff function is applied like so:

var diffedDelta = oldDelta.diff(newDelta);

Than diffedDelta's operations will look like:

{
  ops: [
    {
      retain: 2
    },
    {
      attributes: {
        bold: true
      },
      insert: 'z'
    }
  ]
}

But, if newDelta is changed to:

var newDelta = new Delta().insert('abc', {bold: true}).insert('cd');

Notice that instead of inserting abz we insert abc.

Than diffedDelta's operations will look like:

{
  ops: [
    {
      retain: 2
    },
    {
      retain: 1,
      attributes: {
        bold: true
      }
    },
    {
      insert: 'c'
    }
  ]
}

Which is not the same as before when we inserted abz. There is an extra operation.

In the first case the text is abzcd and in the second case it's abccd, so the issue is if the newly inserted character between ab and cd is the same as the first character from cd than it behaves differently.

After digging through the code, I found that the issue is in the function diff_commonPrefix inside the fast-diff library, mainly in the binary search code.

x = new Delta([{insert: "x"}]);
retain_0_delete_1 = new Delta([{retain: 0}, {delete: 1}]);
result = x.compose(retain_0_delete_1);

The result is [{insert: "x"}, {delete: 1}]. It should be just [], right?

{ retain: 0 } can happen with programmatically generated deltas.

Jason,

Under the Insert Operation section of the README, you mention the following syntax for embeds:

// Insert an embed
{
  insert: { image: 'https://octodex.github.com/images/labtocat.png' },
  attributes: { alt: "Lab Octocat" }
}

However based on what I've read on Deltas - Quill Documentation it looks like what QuillJS generates for embeds is this:

// Insert an image
{
  insert: 1,
  attributes: {
    image: 'https://octodex.github.com/images/labtocat.png'
  }
}

It looks like your rich-text ottype implementation supports both. Is it correct that we need to support the insert key value being a string (for text) and both a number or a dict for an embed? Are you planning on using both in Quill?

Given a.compose(b) == c, a.diff(c) == b

We'd also like to take an optional index argument to indicate a suggested index for change. This is useful for example when diffing two documents with all newlines, it is useful to know where the insertion/deletion occurred besides assuming it was the first or last character.

Useful for transforming cursor positions

Would an implementation of presence be welcome in this repo?

Here are two implementations that already exist in forks:

• https://github.com/houshuang/rich-text/pull/1/files
• master...dantedallag:master

Noticed that the other type NPM package names follow ot-* (eg. ot-text), and rich-text seems like a very generic name given that it's mostly related to OT, no?

Should a package rename to ot-rich-text be considered?

I haven't been able to find any info on whether the rich-text type supports or not the Transformation Property 2. I'd be great to add this to the README.

Hi, the rich-text ot type doesn't seem available in sharejs and I can't for the life of me work out how the the files in webclient are built.

Any hints on how the build process should work?

As I understand, when the side param to transform is "left", the first operation should "happen" first. However, the logic here seems to be reversed.

> require('rich-text').type.transform([ { insert: 'a' } ], [ {insert: 'b'} ], 'left')
Delta { ops: [ { retain: 1 }, { insert: 'a' } ] } // I'd expect Delta { ops: [ { insert: 'a' } ] }

For comparison:

> require('ot-text').type.transform([ 'a' ], [ 'b' ], 'left')
[ 'a' ] // as expected

I think this line should be changed to return delta2.transform(delta1, side === 'right');

Thought I'd point out a small documentation nit that might confuse some folks.

The Quick Example section shows the following:

delta.compose(death);
// delta is now:
// {
//   ops: [
//     { insert: 'Gandalf ', attributes: { bold: true } },
//     { insert: 'the ' },
//     { insert: 'White', attributes: { color: '#fff' } }
//   ]
// }

It suggests that the existing delta object has changed. But in fact the semantics of compose don't edit the delta itself, but simply return a new composed delta. A more accurate documentation to reflect this might be the following:

var composed = delta.compose(death);
// composed is:
// {
//   ops: [
//     { insert: 'Gandalf ', attributes: { bold: true } },
//     { insert: 'the ' },
//     { insert: 'White', attributes: { color: '#fff' } }
//   ]
// }

I can't seem to find an invert method on the operations. If this is not available, I wonder how and if Quill.js supports proper "collaborative" undo?

rich-text might drop retain if it's the last op.
In that case, delta.length() might return the wrong value.
https://github.com/ottypes/rich-text/blob/master/lib/delta.js#L88

Previously we had baseLength and targetLength but now with implied retains there is no way to know if two deltas are composable.