1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
.. _ctags-lang-elm(7):
==============================================================
ctags-lang-elm
==============================================================
Random notes about tagging Elm source code with Universal Ctags
:Version: 6.2.1
:Manual group: Universal Ctags
:Manual section: 7
SYNOPSIS
--------
| **ctags** ... --languages=+Elm ...
| **ctags** ... --language-force=Elm ...
| **ctags** ... --map-Elm=+.elm ...
DESCRIPTION
-----------
The Elm parser is a PEG parser using PackCC, which is part of the
ctags infrastructure. It should correctly process all top level
statements, however there is a limitation with functions embedded
in let/in blocks. They will mostly be fine, but sometimes a
function in a let/in block will be omitted.
EXAMPLES
--------
Imports
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Imported modules are tagged, and their role is "imported", not "def".
Types, functions, etc which are exposed via imported module have their
role as "exposed".
Exposed items are marked as being in the scope of their own module,
not the module that's doing the importing.
"input.elm"
.. code-block:: Elm
module SomeMod exposing (..)
import MyMod exposing
( map
, Maybe
, Result(..)
, MyList(Empty)
)
"output.tags"
with "--options=NONE -o - --sort=no --extras=+r --fields=+r input.elm"
.. code-block:: tags
SomeMod input.elm /^module SomeMod exposing (..)$/;" m roles:def
MyMod input.elm /^import MyMod exposing$/;" m roles:imported
map input.elm /^ ( map$/;" f module:MyMod roles:exposed
Maybe input.elm /^ , Maybe$/;" t module:MyMod roles:exposed
Result input.elm /^ , Result(..)$/;" t module:MyMod roles:exposed
MyList input.elm /^ , MyList(Empty)$/;" t module:MyMod roles:exposed
Empty input.elm /^ , MyList(Empty)$/;" c type:MyMod.MyList roles:exposed
Namespaces
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespaces are tagged and their role is "def".
"input.elm"
.. code-block:: Elm
module AMod exposing (..)
import MyImport as NSpace exposing (impFunc)
"output.tags"
with "--options=NONE -o - --sort=no --extras=+r --fields=+r input.elm"
.. code-block:: tags
AMod input.elm /^module AMod exposing (..)$/;" m roles:def
NSpace input.elm /^import MyImport as NSpace exposing (impFunc)$/;" n module:AMod roles:def moduleName:MyImport
MyImport input.elm /^import MyImport as NSpace exposing (impFunc)$/;" m roles:imported
impFunc input.elm /^import MyImport as NSpace exposing (impFunc)$/;" f module:MyImport roles:exposed
Type names
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Constructors top level functions will have type names.
"input.elm"
.. code-block:: Elm
funcA : Int -> Int
funcA a = a + 1
type B
= B1Cons
{ x : Float
, y : Float
}
| B2Cons String Integer
| B3Cons
"output.tags"
with "--options=NONE -o - --sort=no --extras=+r --fields=+r input.elm"
.. code-block:: tags
funcA input.elm /^funcA a = a + 1$/;" f typeref:typename:Int -> Int roles:def
B input.elm /^type B$/;" t roles:def
B1Cons input.elm /^ = B1Cons$/;" c type:B typeref:typename:{ x : Float , y : Float } -> B roles:def
B2Cons input.elm /^ | B2Cons String Integer$/;" c type:B typeref:typename:String -> Integer -> B roles:def
B3Cons input.elm /^ | B3Cons$/;" c type:B typeref:typename:B roles:def
Function parameter lists
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Function parameter lists can be extracted into the tags file
signature field. They are not really function signatures, but
it's the closest concept available in ctags.
Use "--fields=+S".
.. code-block:: Elm
funcA a1 a2 =
a1 + a2
"output.tags"
with "--sort=no --extras=+r --fields=+rS"
.. code-block:: tags
funcA input.elm /^funcA a1 a2 =$/;" f signature:a1 a2 roles:def
KNOWN LIMITATIONS
-----------------
The ctags signature field is used for function parameter lists, even
though it's not an idea field. See above.
Elm requires all statements at the same logical level to have the
same indentation. If there is additional indentation that line is part
of the previous one. Therefore without over-complicating the
PEG parser we have the following limitations...
Sometimes functions in let/in blocks will be omitted.
Functions in let/in blocks will be marked as being in the scope of their
outer function, regardless of how deeply nested the let/in block is.
Functions in let/in blocks won't have type names.
SEE ALSO
--------
:ref:`ctags(1) <ctags(1)>`, :ref:`ctags-client-tools(7) <ctags-client-tools(7)>`
|
