summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceToAlgorithms.lua
diff options
context:
space:
mode:
Diffstat (limited to 'Master/texmf-dist/tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceToAlgorithms.lua')
-rw-r--r--Master/texmf-dist/tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceToAlgorithms.lua312
1 files changed, 153 insertions, 159 deletions
diff --git a/Master/texmf-dist/tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceToAlgorithms.lua b/Master/texmf-dist/tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceToAlgorithms.lua
index 1187fbc3136..f1b203e550c 100644
--- a/Master/texmf-dist/tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceToAlgorithms.lua
+++ b/Master/texmf-dist/tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceToAlgorithms.lua
@@ -15,13 +15,13 @@
-- This class provides the interface between the graph drawing system
-- and algorithms. Another class, |InterfaceToDisplay|, binds the
-- display layers (like \tikzname\ or a graph drawing editor) to the
--- graph drawing system ``from the other side''.
+-- graph drawing system ``from the other side''.
--
-- The functions declared here can be used by algorithms to
-- communicate with the graph drawing system, which will usually
-- forward the ``requests'' of the algorithms to the display layers in
-- some way. For instance, when you declare a new parameter, this
--- parameter will become available on the display layer.
+-- parameter will become available on the display layer.
local InterfaceToAlgorithms = {}
@@ -58,7 +58,7 @@ local declare_handlers
-- registered handler, we call the |test| function. If it returns
-- neither |nil| nor |false|, the |handler| field of this handler is
-- called. If it returns |true|, the handler immediately
--- finishes. Otherwise, the next handler is tried.
+-- finishes. Otherwise, the next handler is tried.
function InterfaceToAlgorithms.addHandler(test, handler)
table.insert(declare_handlers, 1, { test = test, handler = handler })
@@ -76,7 +76,7 @@ local key_metatable = {}
-- for use on the display layer. There is just one function for
-- handling all declarations in order to make the declarations
-- easy-to-use since you just need to import a single function:
--- %
+--
--\begin{codeexample}[code only, tikz syntax=false]
--local declare = require "pgf.gd.interface.InterfaceToAlgorithms".declare
--\end{codeexample}
@@ -84,11 +84,11 @@ local key_metatable = {}
-- You can now use |declare| it as follows: You pass it a table
-- containing information about the to-be-declared key. The table
-- \emph{must} have a field |key| whose value is unique and must be a
--- string. If the value of |key| is, say, |"foo"|, the
--- parameter can be set on the display layer such as, say, the
+-- string. If the value of |key| is, say, |"foo"|, the
+-- parameter can be set on the display layer such as, say, the
-- \tikzname\ layer, using |/graph drawing/foo|. Here is a typical
--- example of how a declaration is done:
--- %
+-- example of how a declaration is done:
+--
--\begin{codeexample}[code only, tikz syntax=false]
-- ---
-- declare {
@@ -126,7 +126,7 @@ local key_metatable = {}
-- faster to read (both for humans and for computers). Second, for C
-- code, it is quite inconvenient to have long strings inside a C
-- file. In such cases, you can use the |documentation_in| field:
--- %
+--
--\begin{codeexample}[code only, tikz syntax=false]
-- ---
-- declare {
@@ -138,7 +138,7 @@ local key_metatable = {}
--\end{codeexample}
--
-- The |some_filename| must be the name of a Lua file that will be
--- read ``on demand'', that is, whenever someone tries to access the
+-- read ``on demand,'' that is, whenever someone tries to access the
-- documentation, summary, or examples field of the key, this file
-- will be loaded using |require|. The file should then use
-- |pgf.gd.doc| to install the missing information in the keys.
@@ -146,15 +146,14 @@ local key_metatable = {}
-- \medskip\noindent\textbf{The Use Field.}
-- When you declare a key, you can provide a |use| field. If present,
-- you must set it to an array of small tables which have two fields:
--- %
-- \begin{itemize}
--- \item |key| This is the name of another key or a function.
--- \item |value| This is either a value (like a string or a number) or
--- a function or |nil|.
+-- \item |key| This is the name of another key or a function.
+-- \item |value| This is either a value (like a string or a number) or
+-- a function or |nil|.
-- \end{itemize}
--
-- Here is an example:
--- %
+--
--\begin{codeexample}[code only, tikz syntax=false]
-- ---
-- declare {
@@ -177,8 +176,8 @@ local key_metatable = {}
-- the array had been set explicitly to the value given by the |value|
-- field. If the |value| is a function, we pass a different value to
-- the key, namely the result of applying the function to the value
--- originally passed to the original key. Here is a typical example:
--- %
+-- originally passed to the original key. Here is a typical example:
+--
--\begin{codeexample}[code only, tikz syntax=false]
-- ---
-- declare {
@@ -194,7 +193,7 @@ local key_metatable = {}
--
-- Just like the value, the key itself can also be a function. In this
-- case, the to-be-used key is also computed by applying the function
--- to the value passed to the original key.
+-- to the value passed to the original key.
--
-- As mentioned at the beginning, |declare| is a work-horse that will call
-- different internal functions depending on whether you declare a
@@ -210,7 +209,7 @@ local key_metatable = {}
function InterfaceToAlgorithms.declare (t)
local keys = InterfaceCore.keys
-
+
-- Sanity check:
assert (type(t.key) == "string" and t.key ~= "", "parameter key may not be the empty string")
if keys[t.key] or t.keys == "algorithm_phases" then
@@ -220,14 +219,14 @@ function InterfaceToAlgorithms.declare (t)
for _,h in ipairs (declare_handlers) do
if h.test(t) then
if h.handler(t) then
- break
+ break
end
end
end
-- Attach metatable:
setmetatable (t, key_metatable)
-
+
-- Set!
keys[t.key] = t
keys[#keys + 1] = t
@@ -247,10 +246,10 @@ end
---
--- This function is called by |declare| for ``normal parameter keys'',
+-- This function is called by |declare| for ``normal parameter keys,''
-- which are all keys for which no special field like |algorithm| or
-- |layer| is declared. You write
--- %
+--
--\begin{codeexample}[code only, tikz syntax=false]
-- ---
-- declare {
@@ -267,7 +266,6 @@ end
-- When an author writes |my node[electrical charge=5-3]| in the
-- description of her graph, the object |vertex| corresponding to the
-- node |my node| will have a field |options| attached to it with
--- %
--\begin{codeexample}[code only, tikz syntax=false]
--vertex.options["electrical charge"] == 2
--\end{codeexample}
@@ -275,40 +273,40 @@ end
-- The |type| field does not refer to Lua types. Rather, these types are
-- sensible types for graph drawing and they are mapped by the higher
-- layers to Lua types. In detail, the following types are available:
--- %
+--
-- \begin{itemize}
--- \item |number| A dimensionless number. Will be mapped to a normal
--- Lua |number|. So, when the author writes |foo=5*2|, the |foo| key
--- of the |options| field of the corresponding object will be set to
--- |10.0|.
--- \item |length| A ``dimension'' in the sense of \TeX\ (a number with
--- a dimension like |cm| attached to it). It is the job of the display
--- layer to map this to a number in ``\TeX\ points'', that is, to a
--- multiple of $1/72.27$th of an inch.
--- \item |time| A ``time'' in the sense of |\pgfparsetime|. Examples
--- are |6s| or |0.1min| or |6000ms|, all of which will map to |6|.
--- \item |string| Some text. Will be mapped to a Lua |string|.
--- \item |canvas coordinate| A position on the canvas. Will be mapped
--- to a |model.Coordinate|.
--- \item |boolean| A Boolean value.
--- \item |raw| Some to-be-executed Lua text.
--- \item |direction| Normally, an angle; however,
--- the special values of |down|, |up|, |left|, |right| as well as the
--- directions |north|, |north west|, and so on are also legal on the
--- display layer. All of them will be mapped to a number. Furthermore,
--- a vertical bar (\verb!|!) will be mapped to |-90| and a minus sign
--- (|-|) will be mapped to |0|.
--- \item |hidden| A key of this type ``cannot be set'', that is,
--- users cannot set this key at all. However algorithms can still read
--- this key and, through the use of |alias|, can use the key as a
--- handle to another key.
--- \item |user value| The key stores a Lua user value (userdata). Such
--- keys can only be set from C since user values cannot be created in
--- Lua (let alone in \tikzname).
+-- \item |number| A dimensionless number. Will be mapped to a normal
+-- Lua |number|. So, when the author writes |foo=5*2|, the |foo| key
+-- of the |options| field of the corresponding object will be set to
+-- |10.0|.
+-- \item |length| A ``dimension'' in the sense of \TeX\ (a number with
+-- a dimension like |cm| attached to it). It is the job of the display
+-- layer to map this to a number in ``\TeX\ points,'' that is, to a
+-- multiple of $1/72.27$th of an inch.
+-- \item |time| A ``time'' in the sense of |\pgfparsetime|. Examples
+-- are |6s| or |0.1min| or |6000ms|, all of which will map to |6|.
+-- \item |string| Some text. Will be mapped to a Lua |string|.
+-- \item |canvas coordinate| A position on the canvas. Will be mapped
+-- to a |model.Coordinate|.
+-- \item |boolean| A Boolean value.
+-- \item |raw| Some to-be-executed Lua text.
+-- \item |direction| Normally, an angle; however,
+-- the special values of |down|, |up|, |left|, |right| as well as the
+-- directions |north|, |north west|, and so on are also legal on the
+-- display layer. All of them will be mapped to a number. Furthermore,
+-- a vertical bar (\verb!|!) will be mapped to |-90| and a minus sign
+-- (|-|) will be mapped to |0|.
+-- \item |hidden| A key of this type ``cannot be set,'' that is,
+-- users cannot set this key at all. However algorithms can still read
+-- this key and, through the use of |alias|, can use the key as a
+-- handle to another key.
+-- \item |user value| The key stores a Lua user value (userdata). Such
+-- keys can only be set from C since user values cannot be created in
+-- Lua (let alone in \tikzname).
-- \end{itemize}
--
-- If the |type| field is missing, it is automatically set to
--- |"string"|.
+-- |"string"|.
--
-- A parameter can have an |initial| value. This value will be used
-- whenever the parameter has not been set explicitly for an object.
@@ -318,7 +316,7 @@ end
-- no value is provided. For a key of type |"boolean"|, if no
-- |default| is provided, |"true"| will be used automatically.
--
--- A parameter can have an |alias| field. This field must be set to
+-- A parameter can habe an |alias| field. This field must be set to
-- the name of another key or to a function. Whenever you access the
-- current key and this key is not set, the |alias| key is tried
-- instead. If it is set, its value will be returned (if the |alias|
@@ -326,7 +324,7 @@ end
-- alias is not set either and neither does it have an initial value,
-- the |initial| value is used. Note that in case the alias has its
-- |initial| field set, the |initial| value of the current key will
--- never be used.
+-- never be used.
--
-- The main purpose of the current key is to allow algorithms to
-- introduce their own terminology for keys while still having access
@@ -334,7 +332,7 @@ end
-- class uses the name |layerDistance| for what would be called
-- |level distance| in the rest of the graph drawing system. In this
-- case, we can declare the |layerDistance| key as follows:
--- %
+--
--\begin{codeexample}[code only, tikz syntax=false]
-- declare {
-- key = "layerDistance",
@@ -351,7 +349,7 @@ end
--
-- Note that there is a difference between |alias| and the |use|
-- field: Suppose we write
--- %
+--
--\begin{codeexample}[code only, tikz syntax=false]
-- declare {
-- key = "layerDistance",
@@ -368,7 +366,7 @@ end
--
-- If the alias is a function, it will be called with the option table
-- as its parameter. You can thus say things like
--- %
+--
--\begin{codeexample}[code only, tikz syntax=false]
-- declare {
-- key = "layerDistance",
@@ -379,9 +377,9 @@ end
-- }
--\end{codeexample}
--
--- As a special courtesy to C code, you can also set the key
+-- As a special curtesy to C code, you can also set the key
-- |alias_function_string|, which allows you to put the function into
--- a string that is read using |loadstring|.
+-- a string that is read using |loadstring|.
--
-- (You cannot call this function directly, it is included for
-- documentation purposes only.)
@@ -391,36 +389,36 @@ end
local function declare_parameter (t)
t.type = t.type or "string"
-
+
if t.type == "boolean" and t.default == nil then
t.default = true
end
-
+
-- Normal key
assert (type(t.type) == "string", "key type must be a string")
-
+
-- Declare via the hub:
- if t.type ~= "hidden" then
+ if t.type ~= "hidden" then
InterfaceCore.binding:declareCallback(t)
-
+
-- Handle initials:
if t.initial then
InterfaceCore.option_initial[t.key] = InterfaceCore.convert(t.initial, t.type)
end
end
-
+
if t.alias_function_string and not t.alias then
local count = 0
t.alias = load (
function ()
- count = count + 1
- if count == 1 then
- return "return "
- elseif count == 2 then
- return t.alias_function_string
- else
- return nil
- end
+ count = count + 1
+ if count == 1 then
+ return "return "
+ elseif count == 2 then
+ return t.alias_function_string
+ else
+ return nil
+ end
end)()
end
@@ -437,17 +435,16 @@ end
---
-- This function is called by |declare| for ``algorithm
--- keys''. These keys are normally used without a value as in just
+-- keys.'' These keys are normally used without a value as in just
-- |\graph[tree layout]|, but you can optionally pass a value to
-- them. In this case, this value must be the name of a \emph{phase}
-- and the algorithm of this phase will be set (and not the
-- default phase of the key), see the description of phases below for
--- details.
+-- details.
--
-- Algorithm keys are detected by the presence of the field |algorithm|
-- in the table |t| passed to |declare|. Here is an example of how it
-- is used:
--- %
--\begin{codeexample}[code only, tikz syntax=false]
-- local ReingoldTilford1981 = {}
--
@@ -500,7 +497,7 @@ end
-- drawing engine which ``phase'' of the graph drawing process your
-- option applies to. Each time you select an algorithm later on
-- through use of the algorithm's key, the algorithm for this phase
--- will be set; algorithms of other phases will not be changed.
+-- will be set; algorithms of other phases will not be changed.
-- For instance, when an algorithm is part of the spanning tree
-- computation, its phase will be |"spanning tree computation"| and
-- using its key does not change the main algorithm, but only the
@@ -508,7 +505,7 @@ end
-- current graph (in case this is needed by the main algorithm). In
-- case the |phase| field is missing, the phase |main| is used. Thus,
-- when no phase field is given, the key will change the main
--- algorithm used to draw the graph.
+-- algorithm used to draw the graph.
--
-- Later on, the algorithm set for the current phase can be accessed
-- through the special |algorithm_phases| field of |options|
@@ -522,12 +519,12 @@ end
--
-- The following example shows the declaration of an algorithm that is
-- the default for the phase |"spanning tree computation"|:
--- %
+--
--\begin{codeexample}[code only, tikz syntax=false]
-- ---
-- declare {
-- key = "breadth first spanning tree",
--- algorithm = {
+-- algorithm = {
-- run =
-- function (self)
-- return SpanningTreeComputation.computeSpanningTree(self.ugraph, false, self.events)
@@ -541,7 +538,7 @@ end
--
-- The algorithm is called as follows during a run of the main
-- algorithms:
--- %
+--
--\begin{codeexample}[code only, tikz syntax=false]
-- local graph = ... -- the graph object
-- local spanning_algorithm_class = graph.options.algorithm_phases["spanning tree computation"]
@@ -570,7 +567,7 @@ end
local function declare_algorithm (t)
-- Algorithm declaration!
assert(type(t.algorithm) == "table" or type(t.algorithm) == "string")
-
+
t.phase = t.phase or "main"
local function make_class ()
@@ -581,7 +578,7 @@ local function declare_algorithm (t)
else
class = lib.class(require(t.algorithm))
end
-
+
-- Now, save pre- and postconditions
class.preconditions = t.preconditions or {}
class.postconditions = t.postconditions or {}
@@ -605,26 +602,26 @@ local function declare_algorithm (t)
-- Save in the algorithm_classes table:
InterfaceCore.algorithm_classes[t.key] = store_me
-
+
assert(t.type == nil, "type may not be set for an algorithm key")
t.type = "string"
-
+
-- Install!
InterfaceCore.binding:declareCallback(t)
-
+
if t.phase_default then
assert (not InterfaceCore.option_initial.algorithm_phases[t.phase],
- "default algorithm for phase already set")
+ "default algorithm for phase already set")
assert (type(store_me) == "table",
- "default algorithms must be loaded immediately")
+ "default algorithms must be loaded immediately")
InterfaceCore.option_initial.algorithm_phases[t.phase] = store_me
InterfaceCore.option_initial.algorithm_phases[t.phase .. " stack"] = { store_me }
else
InterfaceCore.option_initial.algorithm_phases[t.phase .. " stack"] = {
dummy = true -- Remove once Lua Link Bug is fixed
- }
- end
-
+ }
+ end
+
return true
end
@@ -632,44 +629,42 @@ end
---
--- This function is called by |declare| for ``collection kinds''. They
--- are detected by the presence of the field |layer|
+-- This function is called by |declare| for ``collection kinds.'' They
+-- are detected by the presence of the field |layer|
-- in the table |t| passed to |declare|. See the class |Collection|
-- for details on what a collection and a collection kind is.
--
-- The |key| field of the table |t| passed to this function is both
-- the name of the to-be-declared collection kind as well as the key
-- that is used on the display layer to indicate that a node or edge
--- belongs to a collection.
+-- belongs to a collection.
--
-- \medskip
-- \noindent\textbf{The Display Layer.}
--- Let us first have a look at what happens on the display layer:
+-- Let us first have a look at what happens on the display layer:
-- A key |t.key| is setup on the display layer that, when used inside
-- a graph drawing scope, starts a new collection of the specified
-- kind. ``Starts'' means that all nodes and edges mentioned in the
-- rest of the current option scope will belong to a new collection
--- of kind |t.key|.
--- %
+-- of kind |t.key|.
+--
--\begin{codeexample}[code only, tikz syntax=false]
--declare { key = "hyper", layer = 1 }
--\end{codeexample}
--- %
-- you can say on the \tikzname\ layer
--- %
---\begin{codeexample}[code only]
+--\begin{codeexample}[code only]
-- \graph {
-- a, b, c, d;
-- { [hyper] a, b, c }
-- { [hyper] b, c, d }
-- };
--\end{codeexample}
---
+--
-- In this case, the nodes |a|, |b|, |c| will belong to a collection of
-- kind |hyper|. The nodes |b|, |c|, and |d| will (also) belong to
-- another collection of the same kind |hyper|. You can nest
-- collections; in this case, nodes will belong to several
--- collections.
+-- collections.
--
-- The effect of declaring a collection kind on the algorithm layer
-- it, first of all, that |scope.collections| will have a field named
@@ -679,37 +674,37 @@ end
-- hyperedges, each of which is a table with the following fields: The
-- |vertices| and |edges| fields each contain arrays of all objects
-- being part of the collection. The |sub| field is an array of
--- ``subcollections'', that is, all collections that were started
+-- ``subcollections,'' that is, all collections that were started
-- inside another collection. (For the collection kinds |hyper| and
-- |same layer| this makes no sense, but subgraphs could, for instance,
-- be nested.)
---
+--
-- \medskip
-- \noindent\textbf{Rendering of Collections.}
-- For some kinds of collections, it makes sense to \emph{render} them,
-- but only after the graph drawing algorithm has run. For this
-- purpose, the binding layer will use a callback for each collection
--- kind and each collection, see the |Binding| class for details.
+-- kind and each collection, see the |Binding| class for details.
-- Suppose, for instance, you would
-- like hyperedges to be rendered. In this case, a graph drawing
-- algorithm should iterate over all collections of type |hyper| and
-- compute some hints on how to render the hyperedge and store this
-- information in the |generated_options| table of the hyperedge. Then,
--- the binding layer will ask the display layer to run some some code
--- that is able to read key--value pairs passed to
+-- the binding layer will ask the dislay layer to run some some code
+-- that is able to read key--value pairs passed to
-- it (which are the key--value pairs of the |generated_options| table)
-- and use this information to nicely draw the hyperedge.
--
-- The number |t.layer| determines in which order the different
-- collection kinds are rendered.
---
+--
-- The last parameter, the layer number, is used to specify the order
-- in which the different collection kinds are rendered. The higher the
-- number, the later the collection will be rendered. Thus, if there is
-- a collection kind with layer number 10 and another with layer number
-- 20, all collections of the first kind will be rendered first,
-- followed by all collections of the second kind.
---
+--
-- Collections whose layer kinds are non-negative get rendered
-- \emph{after} the nodes and edges have already been rendered. In
-- contrast, collections with a negative layer number get shown
@@ -717,7 +712,7 @@ end
--
-- (You cannot call this function directly, it is included for
-- documentation purposes only.)
---
+--
-- @param t The table originally passed to |declare|.
local function declare_collection_kind (t)
@@ -727,11 +722,11 @@ local function declare_collection_kind (t)
local kind = t.key
local kinds = InterfaceCore.collection_kinds
local new_entry = { kind = kind, layer = layer }
-
+
-- Insert into table part:
kinds[kind] = new_entry
- -- Insert into array part:
+ -- Insert into array part:
local found
for i=1,#kinds do
if kinds[i].layer > layer or (kinds[i].layer == layer and kinds[i].kind > kind) then
@@ -741,7 +736,7 @@ local function declare_collection_kind (t)
end
kinds[#kinds+1] = new_entry
-
+
-- Bind
InterfaceCore.binding:declareCallback(t)
@@ -813,22 +808,22 @@ local unique_count = 1
--
-- For these reasons, the following happens, when a new vertex is
-- created using the function:
--- %
+--
-- \begin{enumerate}
--- \item The vertex is added to the syntactic digraph.
--- \item It is added to all layouts on the current layout stack. When
--- a graph drawing algorithm is run, it is not necessarily run on the
--- original syntactic digraph. Rather, a sequence / stack of nested
--- layouts may currently
--- be processed and the vertex is added to all of them.
--- \item The vertex is added to both the |digraph| and the |ugraph| of
--- the current algorithm.
+-- \item The vertex is added to the syntactic digraph.
+-- \item It is added to all layouts on the current layout stack. When
+-- a graph drawing algorithm is run, it is not necessarily run on the
+-- original syntactic digraph. Rather, a sequence / stack of nested
+-- layouts may currently
+-- be processed and the vertex is added to all of them.
+-- \item The vertex is added to both the |digraph| and the |ugraph| of
+-- the current algorithm.
-- \end{enumerate}
--
-- @param algorithm An algorithm for whose syntactic digraph the node
--- should be added
+-- should be added
-- @param init A table of initial values for the node that is passed
--- to |Binding:createVertex|, see that function for details.
+-- to |Binding:createVertex|, see that function for details.
--
-- @return The newly created node
--
@@ -837,7 +832,7 @@ function InterfaceToAlgorithms.createVertex(algorithm, init)
-- Setup
local scope = InterfaceCore.topScope()
local binding = InterfaceCore.binding
-
+
-- Setup node
if not init.name then
init.name = "internal@gd@node@" .. unique_count
@@ -846,29 +841,29 @@ function InterfaceToAlgorithms.createVertex(algorithm, init)
-- Does vertex already exist?
assert (not scope.node_names[name], "node already created")
-
+
if not init.shape or init.shape == "none" then
init.shape = "rectangle"
end
-
+
-- Call binding
binding:createVertex(init)
-
+
local v = assert(scope.node_names[init.name], "internal node creation failed")
-
+
-- Add vertex to the algorithm's digraph and ugraph
- algorithm.syntactic_component:add {v}
- algorithm.digraph:add {v}
+ algorithm.syntactic_component:add {v}
+ algorithm.digraph:add {v}
algorithm.ugraph:add {v}
-
- -- Compute bounding boxes:
+
+ -- Compute bounding boxes:
LayoutPipeline.prepareBoundingBoxes(algorithm.rotation_info, algorithm.adjusted_bb, algorithm.digraph, {v})
-
+
-- Add the node to the layout stack:
add_to_collections(algorithm.layout, "vertices", v)
algorithm.layout_graph:add { v }
-
+
return v
end
@@ -878,41 +873,40 @@ end
-- Generate a new edge in the syntactic digraph. This method is quite
-- similar to |createVertex| and has the same effects with respect to
-- the edge: The edge is added to the syntactic digraph and also to
--- all layouts on the layout stack. Furthermore, appropriate edges are
+-- all layouts on the layout stack. Forthermore, appropriate edges are
-- added to the |digraph| and the |ugraph| of the algorithm currently
--- running.
+-- running.
--
--- @param algorithm An algorithm for whose syntactic digraph the node should be added
+-- @param algorithm An algorithm for whose syntactic digraph the node should be added
-- @param tail A syntactic tail vertex
-- @param head A syntactic head vertex
-- @param init A table of initial values for the edge.
--
-- The following fields are useful for |init|:
--- %
-- \begin{itemize}
--- \item |init.direction| If present, a direction for the edge. Defaults to "--".
--- \item |init.options| If present, some options for the edge.
--- \item |init.generated_options| A table that is passed back to the
--- display layer as a list of key-value pairs in the syntax of
--- |declare_parameter|.
+-- \item |init.direction| If present, a direction for the edge. Defaults to "--".
+-- \item |init.options| If present, some options for the edge.
+-- \item |init.generated_options| A table that is passed back to the
+-- display layer as a list of key-value pairs in the syntax of
+-- |declare_parameter|.
-- \end{itemize}
function InterfaceToAlgorithms.createEdge(algorithm, tail, head, init)
init = init or {}
-
+
-- Setup
local scope = InterfaceCore.topScope()
local binding = InterfaceCore.binding
local syntactic_digraph = algorithm.layout_graph
local syntactic_component = algorithm.syntactic_component
-
+
assert (syntactic_digraph:contains(tail) and
- syntactic_digraph:contains(head),
- "attempting to create edge between nodes that are not in the syntactic digraph")
-
+ syntactic_digraph:contains(head),
+ "attempting to create edge between nodes that are not in the syntactic digraph")
+
local arc = syntactic_digraph:connect(tail, head)
-
+
local edge = Edge.new {
head = head,
tail = tail,
@@ -922,16 +916,16 @@ function InterfaceToAlgorithms.createEdge(algorithm, tail, head, init)
generated_options = init.generated_options
}
- -- Add to arc
+ -- Add to arc
arc.syntactic_edges[#arc.syntactic_edges+1] = edge
-
+
local s_arc = syntactic_component:connect(tail, head)
s_arc.syntactic_edges = arc.syntactic_edges
-
+
-- Create Event
local e = InterfaceToDisplay.createEvent ("edge", { arc, #arc.syntactic_edges })
edge.event = e
-
+
-- Make part of collections
for _,c in ipairs(edge.options.collections) do
LookupTable.addOne(c.edges, edge)
@@ -940,7 +934,7 @@ function InterfaceToAlgorithms.createEdge(algorithm, tail, head, init)
-- Call binding
binding.storage[edge] = {}
binding:everyEdgeCreation(edge)
-
+
-- Add edge to digraph and ugraph
local direction = edge.direction
if direction == "->" then
@@ -956,13 +950,13 @@ function InterfaceToAlgorithms.createEdge(algorithm, tail, head, init)
-- Add edge to layouts
add_to_collections(algorithm.layout, "edges", edge)
-
+
end
--- Done
+-- Done
return InterfaceToAlgorithms