-
Notifications
You must be signed in to change notification settings - Fork 63
/
js-comment.ml
182 lines (129 loc) · 3.28 KB
/
js-comment.ml
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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
(* ocp-indent is not going to be confused by comment-embedded tokens. *)
type t = {
(* This is a comment *)
a: int;
}
type t = {
(* This is a comment : with a colon. *)
a: int;
}
type t = {
a: int;
(* with the : second field *)
b: int;
}
type t = {
a: int;
b: int;
(* and : the third... *)
c: int;
}
(* colon in CR comment messes Tuareg up *)
type cfg = {
foo : int; (* ignore-CR someone: float? *)
bar : string;
}
(* To be more precise about the Tuareg bug, it is the fact that the colon in the comment
is the first or second colon after the start of the record definition. If the comment
occurs after the first 2 fields in the record everything is fine.
For example, this is OK: *)
type t= {
foo : int;
bar : string; (* ignore-CR someone: float? *)
baz : string;
}
(* but Tuareg messes this up *)
type t= {
foo : int;
(* ignore-CR someone: float? *)
bar : string;
}
(* Now that we have support for {v v} and {[ ]}, reindent inside comments,
unless they are explicitly delimited as code or pre-formatted text. These
three all end up flattened to the same level. *)
(*
type t = {
(* This is a comment *)
a: int;
}
*)
(*
type t = {
(* This is a comment *)
a: int;
}
*)
(*
type t = {
(* This is a comment *)
a: int;
}
*)
(* Possible to-do warning: Star-prefixed lines are allowed and indented a little
less, to line up with the star in the opening comment parenthesis. Maybe we
don't care enough about them to worry about it, though. *)
(** Doc comment text should be aligned with the first line, so indented more
than otherwise. *)
(* We're now using some ocamldoc block syntax to control indentation, and sweeks
and the rest of us have been relying on it, in and out of doc comments.
{[
let code =
should be reindented like code
so as to work also with vim
]}
{v g
This is totally verbatim text and shouldn't be reindented. It
probably doesn't matter what the indentation of the first line of a
verbatim block is. But how will this be done in vim?
xx
yy
zz
c v}
Does this even confront ocp-indent? I think, when reindenting whole files,
source code blocks do confront ocp-indent.
*)
(* {v
(* comments embedded in verbatim sections *)
(* want to be able to verbatim-out big chunks of code *)
v} *)
(* {v
non-comments in verbatim sections
duh
v} *)
module M = struct
let x = 0
(* reference *)
end
module M = struct
let () =
()
(* If there's a blank line before this, at least, shouldn't it revert to the
block-level indentation, even if it doesn't precede a declaration? As
long as the prior declaration is complete, I mean. If there isn't a
blank line, I can see associating the comment with the line before. *)
end
module M = struct
let () = ()
(* sim. *)
end
module M = struct
let () =
()
(* no problem *)
let () =
()
end
val f : foo : int ->
-> bar_snoo : a b
(* this comment is in the wrong place *)
-> unit
val f : foo : int ->
-> bar_snoo : a
(* this comment is in the right place [under discussion] *)
-> unit
(* The only difference is the type "a b" instead of "a" for the labeled value
bar_snoo. *)
module M : sig
val v : 'a t -> s -> 'a t
(* ... *)
end