JSDuck: Generated code documentation!
See CODING.md for how to run it.
Mistakes fixed:
* Warning: Unknown type function
-> Function
* Warning: Unknown type DOMElement
-> HTMLElement
* Warning: Unknown type DOM Node
-> HTMLElement
* Warning: Unknown type Integer
-> Mixed
* Warning: Unknown type Command
-> ve.Command
* Warning: Unknown type any
-> number
* Warning: Unknown type ve.Transaction
-> ve.dm.Transaction
* Warning: Unknown type ve.dm.AnnotationSet
-> ve.AnnotationSet
* Warning: Unknown type false
-> boolean
* Warning: Unknown type ve.dm.AlienNode
ve.dm doesn't have a generic AlienNode like ve.ce
-> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode
* Warning: Unknown type ve.ve.Surface
-> ve.ce.Surface
* ve.example.lookupNode:
-> Last @param should be @return
* ve.dm.Transaction.prototype.pushReplace:
-> @param {Array] should be @param {Array}
* Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member
-> (removed)
* Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member
-> (removed)
Differences fixed:
* Variadic arguments are like @param {Type...} [name]
instead of @param {Type} [name...]
* Convert all file headers from /** to /*! because JSDuck tries
to parse all /** blocks and fails to parse with all sorts of
errors for "Global property", "Unnamed property", and
"Duplicate property".
Find: \/\*\*([^@]+)(@copyright)
Replace: /*!$1$2
* Indented blocks are considered code examples.
A few methods had documentation with numbered lists that were
indented, which have now been updated to not be intended.
* The free-form text descriptions are parsed with Markdown,
which requires lists to be separated from paragraphs by an
empty line.
And we should use `backticks` instead of {braces} for inline
code in text paragraphs.
* Doc blocks for classes and their constructor have to be
in the correct order (@constructor, @param, @return must be
before @class, @abstract, @extends etc.)
* `@extends Class` must not have Class {wrapped}
* @throws must start with a {Type}
* @example means something else. It is used for an inline demo
iframe, not code block. For that simply indent with spaces.
* @member means something else.
Non-function properties are marked with @property, not @member.
* To create a link to a class or member, in most cases the name
is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux,
where a hash stands for "instance member", so Foo.bar#quux,
links to Foo.bar.prototype.quux (the is not supported, as
"prototype" is considered an implementation detail, it only
indexes class name and method name).
If the magic linker doesn't work for some case, the
verbose syntax is {@link #target label}.
* @property can't have sub-properties (nested @param and @return
values are supported, only @static @property can't be nested).
We only have one case of this, which can be worked around by
moving those in a new virtual class. The code is unaltered
(only moved down so that it isn't with the scope of the main
@class block). ve.dm.TransactionProcessor.processors.
New:
* @mixins: Classes mixed into the current class.
* @event: Events that can be emitted by a class. These are also
inherited by subclasses. (+ @param, @return and @preventable).
So ve.Node#event-attach is inherited to ve.dm.BreakNode,
just like @method is.
* @singleton: Plain objects such as ve, ve.dm, ve.ce were missing
documentation causing a tree error. Documented those as a
JSDuck singleton, which they but just weren't documented yet.
NB: Members of @singleton don't need @static (if present,
triggers a compiler warning).
* @chainable: Shorthand for "@return this". We were using
"@return {classname}" which is ambiguous (returns the same
instance or another instance?), @chainable is specifically
for "@return this". Creates proper labels in the generated
HTML pages.
Removed:
* @mixin: (not to be confused with @mixins). Not supported by
JSDuck. Every class is standalone anyway. Where needed marked
them @class + @abstract instead.
Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
|
|
|
/*!
|
2012-10-24 21:34:01 +00:00
|
|
|
* VisualEditor IndentationAction class.
|
|
|
|
*
|
2013-02-19 23:37:34 +00:00
|
|
|
* @copyright 2011-2013 VisualEditor Team and others; see AUTHORS.txt
|
2012-10-24 21:34:01 +00:00
|
|
|
* @license The MIT License (MIT); see LICENSE.txt
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Indentation action.
|
|
|
|
*
|
|
|
|
* @class
|
JSDuck: Generated code documentation!
See CODING.md for how to run it.
Mistakes fixed:
* Warning: Unknown type function
-> Function
* Warning: Unknown type DOMElement
-> HTMLElement
* Warning: Unknown type DOM Node
-> HTMLElement
* Warning: Unknown type Integer
-> Mixed
* Warning: Unknown type Command
-> ve.Command
* Warning: Unknown type any
-> number
* Warning: Unknown type ve.Transaction
-> ve.dm.Transaction
* Warning: Unknown type ve.dm.AnnotationSet
-> ve.AnnotationSet
* Warning: Unknown type false
-> boolean
* Warning: Unknown type ve.dm.AlienNode
ve.dm doesn't have a generic AlienNode like ve.ce
-> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode
* Warning: Unknown type ve.ve.Surface
-> ve.ce.Surface
* ve.example.lookupNode:
-> Last @param should be @return
* ve.dm.Transaction.prototype.pushReplace:
-> @param {Array] should be @param {Array}
* Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member
-> (removed)
* Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member
-> (removed)
Differences fixed:
* Variadic arguments are like @param {Type...} [name]
instead of @param {Type} [name...]
* Convert all file headers from /** to /*! because JSDuck tries
to parse all /** blocks and fails to parse with all sorts of
errors for "Global property", "Unnamed property", and
"Duplicate property".
Find: \/\*\*([^@]+)(@copyright)
Replace: /*!$1$2
* Indented blocks are considered code examples.
A few methods had documentation with numbered lists that were
indented, which have now been updated to not be intended.
* The free-form text descriptions are parsed with Markdown,
which requires lists to be separated from paragraphs by an
empty line.
And we should use `backticks` instead of {braces} for inline
code in text paragraphs.
* Doc blocks for classes and their constructor have to be
in the correct order (@constructor, @param, @return must be
before @class, @abstract, @extends etc.)
* `@extends Class` must not have Class {wrapped}
* @throws must start with a {Type}
* @example means something else. It is used for an inline demo
iframe, not code block. For that simply indent with spaces.
* @member means something else.
Non-function properties are marked with @property, not @member.
* To create a link to a class or member, in most cases the name
is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux,
where a hash stands for "instance member", so Foo.bar#quux,
links to Foo.bar.prototype.quux (the is not supported, as
"prototype" is considered an implementation detail, it only
indexes class name and method name).
If the magic linker doesn't work for some case, the
verbose syntax is {@link #target label}.
* @property can't have sub-properties (nested @param and @return
values are supported, only @static @property can't be nested).
We only have one case of this, which can be worked around by
moving those in a new virtual class. The code is unaltered
(only moved down so that it isn't with the scope of the main
@class block). ve.dm.TransactionProcessor.processors.
New:
* @mixins: Classes mixed into the current class.
* @event: Events that can be emitted by a class. These are also
inherited by subclasses. (+ @param, @return and @preventable).
So ve.Node#event-attach is inherited to ve.dm.BreakNode,
just like @method is.
* @singleton: Plain objects such as ve, ve.dm, ve.ce were missing
documentation causing a tree error. Documented those as a
JSDuck singleton, which they but just weren't documented yet.
NB: Members of @singleton don't need @static (if present,
triggers a compiler warning).
* @chainable: Shorthand for "@return this". We were using
"@return {classname}" which is ambiguous (returns the same
instance or another instance?), @chainable is specifically
for "@return this". Creates proper labels in the generated
HTML pages.
Removed:
* @mixin: (not to be confused with @mixins). Not supported by
JSDuck. Every class is standalone anyway. Where needed marked
them @class + @abstract instead.
Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
|
|
|
* @extends ve.Action
|
2012-10-24 21:34:01 +00:00
|
|
|
* @constructor
|
|
|
|
* @param {ve.Surface} surface Surface to act on
|
|
|
|
*/
|
|
|
|
ve.IndentationAction = function VeIndentationAction( surface ) {
|
|
|
|
// Parent constructor
|
|
|
|
ve.Action.call( this, surface );
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Inheritance */
|
|
|
|
|
|
|
|
ve.inheritClass( ve.IndentationAction, ve.Action );
|
|
|
|
|
2013-01-15 23:38:49 +00:00
|
|
|
/* Static Properties */
|
2012-10-24 21:34:01 +00:00
|
|
|
|
|
|
|
/**
|
2013-01-15 23:38:49 +00:00
|
|
|
* List of allowed methods for the action.
|
2012-10-24 21:34:01 +00:00
|
|
|
*
|
|
|
|
* @static
|
JSDuck: Generated code documentation!
See CODING.md for how to run it.
Mistakes fixed:
* Warning: Unknown type function
-> Function
* Warning: Unknown type DOMElement
-> HTMLElement
* Warning: Unknown type DOM Node
-> HTMLElement
* Warning: Unknown type Integer
-> Mixed
* Warning: Unknown type Command
-> ve.Command
* Warning: Unknown type any
-> number
* Warning: Unknown type ve.Transaction
-> ve.dm.Transaction
* Warning: Unknown type ve.dm.AnnotationSet
-> ve.AnnotationSet
* Warning: Unknown type false
-> boolean
* Warning: Unknown type ve.dm.AlienNode
ve.dm doesn't have a generic AlienNode like ve.ce
-> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode
* Warning: Unknown type ve.ve.Surface
-> ve.ce.Surface
* ve.example.lookupNode:
-> Last @param should be @return
* ve.dm.Transaction.prototype.pushReplace:
-> @param {Array] should be @param {Array}
* Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member
-> (removed)
* Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member
-> (removed)
Differences fixed:
* Variadic arguments are like @param {Type...} [name]
instead of @param {Type} [name...]
* Convert all file headers from /** to /*! because JSDuck tries
to parse all /** blocks and fails to parse with all sorts of
errors for "Global property", "Unnamed property", and
"Duplicate property".
Find: \/\*\*([^@]+)(@copyright)
Replace: /*!$1$2
* Indented blocks are considered code examples.
A few methods had documentation with numbered lists that were
indented, which have now been updated to not be intended.
* The free-form text descriptions are parsed with Markdown,
which requires lists to be separated from paragraphs by an
empty line.
And we should use `backticks` instead of {braces} for inline
code in text paragraphs.
* Doc blocks for classes and their constructor have to be
in the correct order (@constructor, @param, @return must be
before @class, @abstract, @extends etc.)
* `@extends Class` must not have Class {wrapped}
* @throws must start with a {Type}
* @example means something else. It is used for an inline demo
iframe, not code block. For that simply indent with spaces.
* @member means something else.
Non-function properties are marked with @property, not @member.
* To create a link to a class or member, in most cases the name
is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux,
where a hash stands for "instance member", so Foo.bar#quux,
links to Foo.bar.prototype.quux (the is not supported, as
"prototype" is considered an implementation detail, it only
indexes class name and method name).
If the magic linker doesn't work for some case, the
verbose syntax is {@link #target label}.
* @property can't have sub-properties (nested @param and @return
values are supported, only @static @property can't be nested).
We only have one case of this, which can be worked around by
moving those in a new virtual class. The code is unaltered
(only moved down so that it isn't with the scope of the main
@class block). ve.dm.TransactionProcessor.processors.
New:
* @mixins: Classes mixed into the current class.
* @event: Events that can be emitted by a class. These are also
inherited by subclasses. (+ @param, @return and @preventable).
So ve.Node#event-attach is inherited to ve.dm.BreakNode,
just like @method is.
* @singleton: Plain objects such as ve, ve.dm, ve.ce were missing
documentation causing a tree error. Documented those as a
JSDuck singleton, which they but just weren't documented yet.
NB: Members of @singleton don't need @static (if present,
triggers a compiler warning).
* @chainable: Shorthand for "@return this". We were using
"@return {classname}" which is ambiguous (returns the same
instance or another instance?), @chainable is specifically
for "@return this". Creates proper labels in the generated
HTML pages.
Removed:
* @mixin: (not to be confused with @mixins). Not supported by
JSDuck. Every class is standalone anyway. Where needed marked
them @class + @abstract instead.
Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
|
|
|
* @property
|
2012-10-24 21:34:01 +00:00
|
|
|
*/
|
|
|
|
ve.IndentationAction.static.methods = ['increase', 'decrease'];
|
|
|
|
|
|
|
|
/* Methods */
|
|
|
|
|
|
|
|
/**
|
2013-01-15 23:38:49 +00:00
|
|
|
* Indent content.
|
2012-10-24 21:34:01 +00:00
|
|
|
*
|
|
|
|
* TODO: Refactor functionality into {ve.dm.SurfaceFragment}.
|
|
|
|
*
|
|
|
|
* @method
|
JSDuck: Generated code documentation!
See CODING.md for how to run it.
Mistakes fixed:
* Warning: Unknown type function
-> Function
* Warning: Unknown type DOMElement
-> HTMLElement
* Warning: Unknown type DOM Node
-> HTMLElement
* Warning: Unknown type Integer
-> Mixed
* Warning: Unknown type Command
-> ve.Command
* Warning: Unknown type any
-> number
* Warning: Unknown type ve.Transaction
-> ve.dm.Transaction
* Warning: Unknown type ve.dm.AnnotationSet
-> ve.AnnotationSet
* Warning: Unknown type false
-> boolean
* Warning: Unknown type ve.dm.AlienNode
ve.dm doesn't have a generic AlienNode like ve.ce
-> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode
* Warning: Unknown type ve.ve.Surface
-> ve.ce.Surface
* ve.example.lookupNode:
-> Last @param should be @return
* ve.dm.Transaction.prototype.pushReplace:
-> @param {Array] should be @param {Array}
* Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member
-> (removed)
* Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member
-> (removed)
Differences fixed:
* Variadic arguments are like @param {Type...} [name]
instead of @param {Type} [name...]
* Convert all file headers from /** to /*! because JSDuck tries
to parse all /** blocks and fails to parse with all sorts of
errors for "Global property", "Unnamed property", and
"Duplicate property".
Find: \/\*\*([^@]+)(@copyright)
Replace: /*!$1$2
* Indented blocks are considered code examples.
A few methods had documentation with numbered lists that were
indented, which have now been updated to not be intended.
* The free-form text descriptions are parsed with Markdown,
which requires lists to be separated from paragraphs by an
empty line.
And we should use `backticks` instead of {braces} for inline
code in text paragraphs.
* Doc blocks for classes and their constructor have to be
in the correct order (@constructor, @param, @return must be
before @class, @abstract, @extends etc.)
* `@extends Class` must not have Class {wrapped}
* @throws must start with a {Type}
* @example means something else. It is used for an inline demo
iframe, not code block. For that simply indent with spaces.
* @member means something else.
Non-function properties are marked with @property, not @member.
* To create a link to a class or member, in most cases the name
is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux,
where a hash stands for "instance member", so Foo.bar#quux,
links to Foo.bar.prototype.quux (the is not supported, as
"prototype" is considered an implementation detail, it only
indexes class name and method name).
If the magic linker doesn't work for some case, the
verbose syntax is {@link #target label}.
* @property can't have sub-properties (nested @param and @return
values are supported, only @static @property can't be nested).
We only have one case of this, which can be worked around by
moving those in a new virtual class. The code is unaltered
(only moved down so that it isn't with the scope of the main
@class block). ve.dm.TransactionProcessor.processors.
New:
* @mixins: Classes mixed into the current class.
* @event: Events that can be emitted by a class. These are also
inherited by subclasses. (+ @param, @return and @preventable).
So ve.Node#event-attach is inherited to ve.dm.BreakNode,
just like @method is.
* @singleton: Plain objects such as ve, ve.dm, ve.ce were missing
documentation causing a tree error. Documented those as a
JSDuck singleton, which they but just weren't documented yet.
NB: Members of @singleton don't need @static (if present,
triggers a compiler warning).
* @chainable: Shorthand for "@return this". We were using
"@return {classname}" which is ambiguous (returns the same
instance or another instance?), @chainable is specifically
for "@return this". Creates proper labels in the generated
HTML pages.
Removed:
* @mixin: (not to be confused with @mixins). Not supported by
JSDuck. Every class is standalone anyway. Where needed marked
them @class + @abstract instead.
Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
|
|
|
* @returns {boolean} Indentation increase occured
|
2012-10-24 21:34:01 +00:00
|
|
|
*/
|
|
|
|
ve.IndentationAction.prototype.increase = function () {
|
|
|
|
var i, group,
|
2012-12-03 23:57:10 +00:00
|
|
|
fragments = [],
|
2012-11-07 23:36:03 +00:00
|
|
|
increased = false,
|
2012-10-24 21:34:01 +00:00
|
|
|
surfaceModel = this.surface.getModel(),
|
|
|
|
documentModel = surfaceModel.getDocument(),
|
2012-12-03 23:57:10 +00:00
|
|
|
selected = surfaceModel.getFragment(),
|
|
|
|
groups = documentModel.getCoveredSiblingGroups( selected.getRange() );
|
2012-10-24 21:34:01 +00:00
|
|
|
|
2012-12-03 23:57:10 +00:00
|
|
|
// Build fragments from groups (we need their ranges since the nodes will be rebuilt on change)
|
2012-10-24 21:34:01 +00:00
|
|
|
for ( i = 0; i < groups.length; i++ ) {
|
|
|
|
group = groups[i];
|
|
|
|
if ( group.grandparent && group.grandparent.getType() === 'list' ) {
|
2012-12-03 23:57:10 +00:00
|
|
|
fragments.push( surfaceModel.getFragment( group.parent.getOuterRange(), true ) );
|
2012-11-07 23:36:03 +00:00
|
|
|
increased = true;
|
2012-10-24 21:34:01 +00:00
|
|
|
}
|
|
|
|
}
|
2012-12-03 23:57:10 +00:00
|
|
|
|
|
|
|
// Process each fragment (their ranges are automatically adjusted on change)
|
|
|
|
for ( i = 0; i < fragments.length; i++ ) {
|
|
|
|
this.indentListItem(
|
|
|
|
documentModel.getNodeFromOffset( fragments[i].getRange().start + 1 )
|
|
|
|
);
|
Death and/or destruction
So. It turns out that the design of SurfaceFragment is a little -
shall we say - wonky.
One of the best things about ve.dm.SurfaceFragment is its magical
ability to retain the intention of its range, even as transactions
are being processed. This ability is granted by each fragment
listening to the surface's change event, and responding by using
translateRange for each transaction that gets processed. Surface
fragments also have these clever methods that allow you to get a
fragment based on another, which makes adjusting the range easy to do
inline without having to manually store multiple fragments or
modifying the original.
This sounded good, and we seemed to all be convinced it was well
designed. But if you add a console.log( 'hello' ); to the first line
of ve.dm.SurfaceFragment.prototype.onTransact, and then start using
the bold tool on various selections of text, you will find that there
may indeed be a flaw. What you will probably realize is that the
number of times that particular line of code is being called is
disturbingly large, and increases each time you do just about anything
in the editor. What's going on? How did we get here? Read on…
It turns out that fragments are immortal. We create them, they listen
to the surface's transact event, we are done with them, but the
surface keeps on emitting events to the now long forgotten about
fragments. They continue to build up over time, never go out of scope,
and bloat the hell out of our program.
The same ended up being true of toolbars - and each time the context
menu fired up a new one the old one was left in limbo, still
responding to events, still taking up memory, but not being visible to
the user.
All of this immortality was causing strange and difficult to track
down problems. This patch fixes this by introducing a destroy method.
This method unbinds events, allowing the object to finally fall out of
scope and die - and more importantly stop receiving notifications of
changes.
This is a hack, but Ed will no doubt get this situation sorted out
properly by making fragments lazy-evaluate their selections by only
storing an identifier of the most recent transaction they were based
on, see bug 47343.
Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
|
|
|
fragments[i].destroy();
|
2012-12-03 23:57:10 +00:00
|
|
|
}
|
|
|
|
|
Death and/or destruction
So. It turns out that the design of SurfaceFragment is a little -
shall we say - wonky.
One of the best things about ve.dm.SurfaceFragment is its magical
ability to retain the intention of its range, even as transactions
are being processed. This ability is granted by each fragment
listening to the surface's change event, and responding by using
translateRange for each transaction that gets processed. Surface
fragments also have these clever methods that allow you to get a
fragment based on another, which makes adjusting the range easy to do
inline without having to manually store multiple fragments or
modifying the original.
This sounded good, and we seemed to all be convinced it was well
designed. But if you add a console.log( 'hello' ); to the first line
of ve.dm.SurfaceFragment.prototype.onTransact, and then start using
the bold tool on various selections of text, you will find that there
may indeed be a flaw. What you will probably realize is that the
number of times that particular line of code is being called is
disturbingly large, and increases each time you do just about anything
in the editor. What's going on? How did we get here? Read on…
It turns out that fragments are immortal. We create them, they listen
to the surface's transact event, we are done with them, but the
surface keeps on emitting events to the now long forgotten about
fragments. They continue to build up over time, never go out of scope,
and bloat the hell out of our program.
The same ended up being true of toolbars - and each time the context
menu fired up a new one the old one was left in limbo, still
responding to events, still taking up memory, but not being visible to
the user.
All of this immortality was causing strange and difficult to track
down problems. This patch fixes this by introducing a destroy method.
This method unbinds events, allowing the object to finally fall out of
scope and die - and more importantly stop receiving notifications of
changes.
This is a hack, but Ed will no doubt get this situation sorted out
properly by making fragments lazy-evaluate their selections by only
storing an identifier of the most recent transaction they were based
on, see bug 47343.
Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
|
|
|
selected.select().destroy();
|
2012-12-03 23:57:10 +00:00
|
|
|
|
2012-11-07 23:36:03 +00:00
|
|
|
return increased;
|
2012-10-24 21:34:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2013-01-15 23:38:49 +00:00
|
|
|
* Unindent content.
|
2012-10-24 21:34:01 +00:00
|
|
|
*
|
|
|
|
* TODO: Refactor functionality into {ve.dm.SurfaceFragment}.
|
|
|
|
*
|
|
|
|
* @method
|
JSDuck: Generated code documentation!
See CODING.md for how to run it.
Mistakes fixed:
* Warning: Unknown type function
-> Function
* Warning: Unknown type DOMElement
-> HTMLElement
* Warning: Unknown type DOM Node
-> HTMLElement
* Warning: Unknown type Integer
-> Mixed
* Warning: Unknown type Command
-> ve.Command
* Warning: Unknown type any
-> number
* Warning: Unknown type ve.Transaction
-> ve.dm.Transaction
* Warning: Unknown type ve.dm.AnnotationSet
-> ve.AnnotationSet
* Warning: Unknown type false
-> boolean
* Warning: Unknown type ve.dm.AlienNode
ve.dm doesn't have a generic AlienNode like ve.ce
-> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode
* Warning: Unknown type ve.ve.Surface
-> ve.ce.Surface
* ve.example.lookupNode:
-> Last @param should be @return
* ve.dm.Transaction.prototype.pushReplace:
-> @param {Array] should be @param {Array}
* Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member
-> (removed)
* Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member
-> (removed)
Differences fixed:
* Variadic arguments are like @param {Type...} [name]
instead of @param {Type} [name...]
* Convert all file headers from /** to /*! because JSDuck tries
to parse all /** blocks and fails to parse with all sorts of
errors for "Global property", "Unnamed property", and
"Duplicate property".
Find: \/\*\*([^@]+)(@copyright)
Replace: /*!$1$2
* Indented blocks are considered code examples.
A few methods had documentation with numbered lists that were
indented, which have now been updated to not be intended.
* The free-form text descriptions are parsed with Markdown,
which requires lists to be separated from paragraphs by an
empty line.
And we should use `backticks` instead of {braces} for inline
code in text paragraphs.
* Doc blocks for classes and their constructor have to be
in the correct order (@constructor, @param, @return must be
before @class, @abstract, @extends etc.)
* `@extends Class` must not have Class {wrapped}
* @throws must start with a {Type}
* @example means something else. It is used for an inline demo
iframe, not code block. For that simply indent with spaces.
* @member means something else.
Non-function properties are marked with @property, not @member.
* To create a link to a class or member, in most cases the name
is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux,
where a hash stands for "instance member", so Foo.bar#quux,
links to Foo.bar.prototype.quux (the is not supported, as
"prototype" is considered an implementation detail, it only
indexes class name and method name).
If the magic linker doesn't work for some case, the
verbose syntax is {@link #target label}.
* @property can't have sub-properties (nested @param and @return
values are supported, only @static @property can't be nested).
We only have one case of this, which can be worked around by
moving those in a new virtual class. The code is unaltered
(only moved down so that it isn't with the scope of the main
@class block). ve.dm.TransactionProcessor.processors.
New:
* @mixins: Classes mixed into the current class.
* @event: Events that can be emitted by a class. These are also
inherited by subclasses. (+ @param, @return and @preventable).
So ve.Node#event-attach is inherited to ve.dm.BreakNode,
just like @method is.
* @singleton: Plain objects such as ve, ve.dm, ve.ce were missing
documentation causing a tree error. Documented those as a
JSDuck singleton, which they but just weren't documented yet.
NB: Members of @singleton don't need @static (if present,
triggers a compiler warning).
* @chainable: Shorthand for "@return this". We were using
"@return {classname}" which is ambiguous (returns the same
instance or another instance?), @chainable is specifically
for "@return this". Creates proper labels in the generated
HTML pages.
Removed:
* @mixin: (not to be confused with @mixins). Not supported by
JSDuck. Every class is standalone anyway. Where needed marked
them @class + @abstract instead.
Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
|
|
|
* @returns {boolean} Indentation decrease occured
|
2012-10-24 21:34:01 +00:00
|
|
|
*/
|
|
|
|
ve.IndentationAction.prototype.decrease = function () {
|
|
|
|
var i, group,
|
2012-12-03 23:57:10 +00:00
|
|
|
fragments = [],
|
2012-11-07 23:36:03 +00:00
|
|
|
decreased = false,
|
2012-10-24 21:34:01 +00:00
|
|
|
surfaceModel = this.surface.getModel(),
|
|
|
|
documentModel = surfaceModel.getDocument(),
|
2012-12-03 23:57:10 +00:00
|
|
|
selected = surfaceModel.getFragment(),
|
|
|
|
groups = documentModel.getCoveredSiblingGroups( selected.getRange() );
|
2012-10-24 21:34:01 +00:00
|
|
|
|
2012-12-03 23:57:10 +00:00
|
|
|
// Build fragments from groups (we need their ranges since the nodes will be rebuilt on change)
|
2012-10-24 21:34:01 +00:00
|
|
|
for ( i = 0; i < groups.length; i++ ) {
|
|
|
|
group = groups[i];
|
|
|
|
if ( group.grandparent && group.grandparent.getType() === 'list' ) {
|
2012-12-03 23:57:10 +00:00
|
|
|
fragments.push( surfaceModel.getFragment( group.parent.getOuterRange(), true ) );
|
2012-11-07 23:36:03 +00:00
|
|
|
decreased = true;
|
2012-10-24 21:34:01 +00:00
|
|
|
}
|
|
|
|
}
|
2012-12-03 23:57:10 +00:00
|
|
|
|
|
|
|
// Process each fragment (their ranges are automatically adjusted on change)
|
|
|
|
for ( i = 0; i < fragments.length; i++ ) {
|
2013-01-15 23:38:49 +00:00
|
|
|
this.unindentListItem(
|
2012-12-03 23:57:10 +00:00
|
|
|
documentModel.getNodeFromOffset( fragments[i].getRange().start + 1 )
|
|
|
|
);
|
Death and/or destruction
So. It turns out that the design of SurfaceFragment is a little -
shall we say - wonky.
One of the best things about ve.dm.SurfaceFragment is its magical
ability to retain the intention of its range, even as transactions
are being processed. This ability is granted by each fragment
listening to the surface's change event, and responding by using
translateRange for each transaction that gets processed. Surface
fragments also have these clever methods that allow you to get a
fragment based on another, which makes adjusting the range easy to do
inline without having to manually store multiple fragments or
modifying the original.
This sounded good, and we seemed to all be convinced it was well
designed. But if you add a console.log( 'hello' ); to the first line
of ve.dm.SurfaceFragment.prototype.onTransact, and then start using
the bold tool on various selections of text, you will find that there
may indeed be a flaw. What you will probably realize is that the
number of times that particular line of code is being called is
disturbingly large, and increases each time you do just about anything
in the editor. What's going on? How did we get here? Read on…
It turns out that fragments are immortal. We create them, they listen
to the surface's transact event, we are done with them, but the
surface keeps on emitting events to the now long forgotten about
fragments. They continue to build up over time, never go out of scope,
and bloat the hell out of our program.
The same ended up being true of toolbars - and each time the context
menu fired up a new one the old one was left in limbo, still
responding to events, still taking up memory, but not being visible to
the user.
All of this immortality was causing strange and difficult to track
down problems. This patch fixes this by introducing a destroy method.
This method unbinds events, allowing the object to finally fall out of
scope and die - and more importantly stop receiving notifications of
changes.
This is a hack, but Ed will no doubt get this situation sorted out
properly by making fragments lazy-evaluate their selections by only
storing an identifier of the most recent transaction they were based
on, see bug 47343.
Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
|
|
|
fragments[i].destroy();
|
2012-12-03 23:57:10 +00:00
|
|
|
}
|
|
|
|
|
Death and/or destruction
So. It turns out that the design of SurfaceFragment is a little -
shall we say - wonky.
One of the best things about ve.dm.SurfaceFragment is its magical
ability to retain the intention of its range, even as transactions
are being processed. This ability is granted by each fragment
listening to the surface's change event, and responding by using
translateRange for each transaction that gets processed. Surface
fragments also have these clever methods that allow you to get a
fragment based on another, which makes adjusting the range easy to do
inline without having to manually store multiple fragments or
modifying the original.
This sounded good, and we seemed to all be convinced it was well
designed. But if you add a console.log( 'hello' ); to the first line
of ve.dm.SurfaceFragment.prototype.onTransact, and then start using
the bold tool on various selections of text, you will find that there
may indeed be a flaw. What you will probably realize is that the
number of times that particular line of code is being called is
disturbingly large, and increases each time you do just about anything
in the editor. What's going on? How did we get here? Read on…
It turns out that fragments are immortal. We create them, they listen
to the surface's transact event, we are done with them, but the
surface keeps on emitting events to the now long forgotten about
fragments. They continue to build up over time, never go out of scope,
and bloat the hell out of our program.
The same ended up being true of toolbars - and each time the context
menu fired up a new one the old one was left in limbo, still
responding to events, still taking up memory, but not being visible to
the user.
All of this immortality was causing strange and difficult to track
down problems. This patch fixes this by introducing a destroy method.
This method unbinds events, allowing the object to finally fall out of
scope and die - and more importantly stop receiving notifications of
changes.
This is a hack, but Ed will no doubt get this situation sorted out
properly by making fragments lazy-evaluate their selections by only
storing an identifier of the most recent transaction they were based
on, see bug 47343.
Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
|
|
|
selected.select().destroy();
|
2012-12-03 23:57:10 +00:00
|
|
|
|
2012-11-07 23:36:03 +00:00
|
|
|
return decreased;
|
2012-10-24 21:34:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2013-01-15 23:38:49 +00:00
|
|
|
* Indent a list item.
|
|
|
|
*
|
2012-10-24 21:34:01 +00:00
|
|
|
* TODO: Refactor functionality into {ve.dm.SurfaceFragment}.
|
2013-01-15 23:38:49 +00:00
|
|
|
*
|
|
|
|
* @method
|
|
|
|
* @param {ve.dm.ListItemNode} listItem List item to indent
|
2012-10-24 21:34:01 +00:00
|
|
|
*/
|
|
|
|
ve.IndentationAction.prototype.indentListItem = function ( listItem ) {
|
|
|
|
/*
|
|
|
|
* Indenting a list item is done as follows:
|
|
|
|
* 1. Wrap the listItem in a list and a listItem (<li> --> <li><ul><li>)
|
|
|
|
* 2. Merge this wrapped listItem into the previous listItem if present
|
|
|
|
* (<li>Previous</li><li><ul><li>This --> <li>Previous<ul><li>This)
|
|
|
|
* 3. If this results in the wrapped list being preceded by another list,
|
|
|
|
* merge those lists.
|
|
|
|
*/
|
|
|
|
var tx,
|
|
|
|
surfaceModel = this.surface.getModel(),
|
|
|
|
documentModel = surfaceModel.getDocument(),
|
|
|
|
selection = surfaceModel.getSelection(),
|
|
|
|
listType = listItem.getParent().getAttribute( 'style' ),
|
|
|
|
listItemRange = listItem.getOuterRange(),
|
|
|
|
innerListItemRange,
|
|
|
|
outerListItemRange,
|
|
|
|
mergeStart,
|
|
|
|
mergeEnd;
|
|
|
|
|
|
|
|
// CAREFUL: after initializing the variables above, we cannot use the model tree!
|
|
|
|
// The first transaction will cause rebuilds so the nodes we have references to now
|
|
|
|
// will be detached and useless after the first transaction. Instead, inspect
|
|
|
|
// documentModel.data to find out things about the current structure.
|
|
|
|
|
|
|
|
// (1) Wrap the listItem in a list and a listItem
|
|
|
|
tx = ve.dm.Transaction.newFromWrap( documentModel,
|
|
|
|
listItemRange,
|
|
|
|
[],
|
|
|
|
[ { 'type': 'listItem' }, { 'type': 'list', 'attributes': { 'style': listType } } ],
|
|
|
|
[],
|
|
|
|
[]
|
|
|
|
);
|
|
|
|
surfaceModel.change( tx );
|
|
|
|
selection = tx.translateRange( selection );
|
|
|
|
// tx.translateRange( innerListItemRange ) doesn't do what we want
|
|
|
|
innerListItemRange = ve.Range.newFromTranslatedRange( listItemRange, 2 );
|
|
|
|
outerListItemRange = new ve.Range( listItemRange.start, listItemRange.end + 2 );
|
|
|
|
|
|
|
|
// (2) Merge the listItem into the previous listItem (if there is one)
|
|
|
|
if (
|
2013-03-20 22:35:05 +00:00
|
|
|
documentModel.data.getData( listItemRange.start ).type === 'listItem' &&
|
|
|
|
documentModel.data.getData( listItemRange.start - 1 ).type === '/listItem'
|
2012-10-24 21:34:01 +00:00
|
|
|
) {
|
|
|
|
mergeStart = listItemRange.start - 1;
|
|
|
|
mergeEnd = listItemRange.start + 1;
|
|
|
|
// (3) If this results in adjacent lists, merge those too
|
|
|
|
if (
|
2013-03-20 22:35:05 +00:00
|
|
|
documentModel.data.getData( mergeEnd ).type === 'list' &&
|
|
|
|
documentModel.data.getData( mergeStart - 1 ).type === '/list'
|
2012-10-24 21:34:01 +00:00
|
|
|
) {
|
|
|
|
mergeStart--;
|
|
|
|
mergeEnd++;
|
|
|
|
}
|
|
|
|
tx = ve.dm.Transaction.newFromRemoval( documentModel, new ve.Range( mergeStart, mergeEnd ) );
|
|
|
|
surfaceModel.change( tx );
|
|
|
|
selection = tx.translateRange( selection );
|
|
|
|
innerListItemRange = tx.translateRange( innerListItemRange );
|
|
|
|
outerListItemRange = tx.translateRange( outerListItemRange );
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO If this listItem has a child list, split&unwrap it
|
|
|
|
|
|
|
|
surfaceModel.change( null, selection );
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2013-01-15 23:38:49 +00:00
|
|
|
* Unindent a list item.
|
|
|
|
*
|
2012-10-24 21:34:01 +00:00
|
|
|
* TODO: Refactor functionality into {ve.dm.SurfaceFragment}.
|
2013-01-15 23:38:49 +00:00
|
|
|
*
|
|
|
|
* @method
|
|
|
|
* @param {ve.dm.ListItemNode} listItem List item to unindent
|
2012-10-24 21:34:01 +00:00
|
|
|
*/
|
2013-01-15 23:38:49 +00:00
|
|
|
ve.IndentationAction.prototype.unindentListItem = function ( listItem ) {
|
2012-10-24 21:34:01 +00:00
|
|
|
/*
|
|
|
|
* Outdenting a list item is done as follows:
|
|
|
|
* 1. Split the parent list to isolate the listItem in its own list
|
|
|
|
* 1a. Split the list before the listItem if it's not the first child
|
|
|
|
* 1b. Split the list after the listItem if it's not the last child
|
|
|
|
* 2. If this isolated list's parent is not a listItem, unwrap the listItem and the isolated list, and stop.
|
|
|
|
* 3. Split the parent listItem to isolate the list in its own listItem
|
|
|
|
* 3a. Split the listItem before the list if it's not the first child
|
|
|
|
* 3b. Split the listItem after the list if it's not the last child
|
|
|
|
* 4. Unwrap the now-isolated listItem and the isolated list
|
|
|
|
*/
|
|
|
|
// TODO: Child list handling, gotta figure that out.
|
2013-03-04 16:24:09 +00:00
|
|
|
var tx, i, length, children, child, splitListRange,
|
2012-10-24 21:34:01 +00:00
|
|
|
surfaceModel = this.surface.getModel(),
|
2013-03-04 16:24:09 +00:00
|
|
|
fragment = surfaceModel.getFragment( listItem.getOuterRange(), true ),
|
2012-10-24 21:34:01 +00:00
|
|
|
documentModel = surfaceModel.getDocument(),
|
|
|
|
list = listItem.getParent(),
|
|
|
|
listElement = list.getClonedElement(),
|
|
|
|
grandParentType = list.getParent().getType(),
|
2013-03-04 16:24:09 +00:00
|
|
|
listItemRange = listItem.getOuterRange();
|
2012-10-24 21:34:01 +00:00
|
|
|
|
|
|
|
// CAREFUL: after initializing the variables above, we cannot use the model tree!
|
|
|
|
// The first transaction will cause rebuilds so the nodes we have references to now
|
|
|
|
// will be detached and useless after the first transaction. Instead, inspect
|
|
|
|
// documentModel.data to find out things about the current structure.
|
|
|
|
|
|
|
|
// (1) Split the listItem into a separate list
|
2013-03-20 22:35:05 +00:00
|
|
|
if ( documentModel.data.getData( listItemRange.start - 1 ).type !== 'list' ) {
|
2012-10-24 21:34:01 +00:00
|
|
|
// (1a) listItem is not the first child, split the list before listItem
|
|
|
|
tx = ve.dm.Transaction.newFromInsertion( documentModel, listItemRange.start,
|
|
|
|
[ { 'type': '/list' }, listElement ]
|
|
|
|
);
|
|
|
|
surfaceModel.change( tx );
|
|
|
|
// tx.translateRange( listItemRange ) doesn't do what we want
|
|
|
|
listItemRange = ve.Range.newFromTranslatedRange( listItemRange, 2 );
|
|
|
|
}
|
2013-03-20 22:35:05 +00:00
|
|
|
if ( documentModel.data.getData( listItemRange.end ).type !== '/list' ) {
|
2012-10-24 21:34:01 +00:00
|
|
|
// (1b) listItem is not the last child, split the list after listItem
|
|
|
|
tx = ve.dm.Transaction.newFromInsertion( documentModel, listItemRange.end,
|
|
|
|
[ { 'type': '/list' }, listElement ]
|
|
|
|
);
|
|
|
|
surfaceModel.change( tx );
|
|
|
|
// listItemRange is not affected by this transaction
|
|
|
|
}
|
|
|
|
splitListRange = new ve.Range( listItemRange.start - 1, listItemRange.end + 1 );
|
|
|
|
|
|
|
|
if ( grandParentType !== 'listItem' ) {
|
|
|
|
// The user is trying to unindent a list item that's not nested
|
|
|
|
// (2) Unwrap both the list and the listItem, dumping the listItem's contents
|
|
|
|
// into the list's parent
|
|
|
|
tx = ve.dm.Transaction.newFromWrap( documentModel,
|
|
|
|
new ve.Range( listItemRange.start + 1, listItemRange.end - 1 ),
|
|
|
|
[ { 'type': 'list' }, { 'type': 'listItem' } ],
|
|
|
|
[],
|
|
|
|
[],
|
|
|
|
[]
|
|
|
|
);
|
|
|
|
surfaceModel.change( tx );
|
2013-03-04 16:24:09 +00:00
|
|
|
|
|
|
|
// ensure paragraphs are not wrapper paragraphs now
|
|
|
|
// that they are not in a list
|
|
|
|
children = fragment.getSiblingNodes();
|
2013-03-20 22:35:05 +00:00
|
|
|
for ( i = 0, length = children.length; i < length; i++ ) {
|
2013-03-04 16:24:09 +00:00
|
|
|
child = children[i].node;
|
2013-03-20 22:35:05 +00:00
|
|
|
if (
|
2013-03-04 16:24:09 +00:00
|
|
|
child.type === 'paragraph' &&
|
|
|
|
child.element.internal &&
|
|
|
|
child.element.internal.generated === 'wrapper'
|
|
|
|
) {
|
|
|
|
delete child.element.internal.generated;
|
2013-03-20 22:35:05 +00:00
|
|
|
if ( ve.isEmptyObject( child.element.internal ) ) {
|
2013-03-04 16:24:09 +00:00
|
|
|
delete child.element.internal;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2012-10-24 21:34:01 +00:00
|
|
|
} else {
|
|
|
|
// (3) Split the list away from parentListItem into its own listItem
|
|
|
|
// TODO factor common split logic somehow?
|
2013-03-20 22:35:05 +00:00
|
|
|
if ( documentModel.data.getData( splitListRange.start - 1 ).type !== 'listItem' ) {
|
2012-10-24 21:34:01 +00:00
|
|
|
// (3a) Split parentListItem before list
|
|
|
|
tx = ve.dm.Transaction.newFromInsertion( documentModel, splitListRange.start,
|
|
|
|
[ { 'type': '/listItem' }, { 'type': 'listItem' } ]
|
|
|
|
);
|
|
|
|
surfaceModel.change( tx );
|
|
|
|
// tx.translateRange( splitListRange ) doesn't do what we want
|
|
|
|
splitListRange = ve.Range.newFromTranslatedRange( splitListRange, 2 );
|
|
|
|
}
|
2013-03-20 22:35:05 +00:00
|
|
|
if ( documentModel.data.getData( splitListRange.end ).type !== '/listItem' ) {
|
2012-10-24 21:34:01 +00:00
|
|
|
// (3b) Split parentListItem after list
|
|
|
|
tx = ve.dm.Transaction.newFromInsertion( documentModel, splitListRange.end,
|
|
|
|
[ { 'type': '/listItem' }, { 'type': 'listItem' } ]
|
|
|
|
);
|
|
|
|
surfaceModel.change( tx );
|
|
|
|
// splitListRange is not affected by this transaction
|
|
|
|
}
|
|
|
|
|
|
|
|
// (4) Unwrap the list and its containing listItem
|
|
|
|
tx = ve.dm.Transaction.newFromWrap( documentModel,
|
|
|
|
new ve.Range( splitListRange.start + 1, splitListRange.end - 1 ),
|
|
|
|
[ { 'type': 'listItem' }, { 'type': 'list' } ],
|
|
|
|
[],
|
|
|
|
[],
|
|
|
|
[]
|
|
|
|
);
|
|
|
|
surfaceModel.change( tx );
|
|
|
|
}
|
Death and/or destruction
So. It turns out that the design of SurfaceFragment is a little -
shall we say - wonky.
One of the best things about ve.dm.SurfaceFragment is its magical
ability to retain the intention of its range, even as transactions
are being processed. This ability is granted by each fragment
listening to the surface's change event, and responding by using
translateRange for each transaction that gets processed. Surface
fragments also have these clever methods that allow you to get a
fragment based on another, which makes adjusting the range easy to do
inline without having to manually store multiple fragments or
modifying the original.
This sounded good, and we seemed to all be convinced it was well
designed. But if you add a console.log( 'hello' ); to the first line
of ve.dm.SurfaceFragment.prototype.onTransact, and then start using
the bold tool on various selections of text, you will find that there
may indeed be a flaw. What you will probably realize is that the
number of times that particular line of code is being called is
disturbingly large, and increases each time you do just about anything
in the editor. What's going on? How did we get here? Read on…
It turns out that fragments are immortal. We create them, they listen
to the surface's transact event, we are done with them, but the
surface keeps on emitting events to the now long forgotten about
fragments. They continue to build up over time, never go out of scope,
and bloat the hell out of our program.
The same ended up being true of toolbars - and each time the context
menu fired up a new one the old one was left in limbo, still
responding to events, still taking up memory, but not being visible to
the user.
All of this immortality was causing strange and difficult to track
down problems. This patch fixes this by introducing a destroy method.
This method unbinds events, allowing the object to finally fall out of
scope and die - and more importantly stop receiving notifications of
changes.
This is a hack, but Ed will no doubt get this situation sorted out
properly by making fragments lazy-evaluate their selections by only
storing an identifier of the most recent transaction they were based
on, see bug 47343.
Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
|
|
|
fragment.destroy();
|
2012-10-24 21:34:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Registration */
|
|
|
|
|
2013-03-04 16:24:09 +00:00
|
|
|
ve.actionFactory.register( 'indentation', ve.IndentationAction );
|