Commits

Peter Szilagyi committed 8925c11

filled some long lines, marked one done, and removed one of my dumbest

Comments (0)

Files changed (1)

 Right now for projects that aren't watched we don't have this data. Is
 it OK to just include the data for watched projects?
 *** sweeks:
-I'll take what I can get. If we include the data only for watched projects, the UI should make clear that the data for unwatched project is unknown, not zero.
+I'll take what I can get. If we include the data only for watched
+projects, the UI should make clear that the data for unwatched project
+is unknown, not zero.
 
 I'd like to leave open something to get all the data someday.
 
 
 ** Improve user feedback when querying ocamlspotter fails
 *** sweeks:
-Perhaps we could improve emacs's behavior when querying ocamlspotter for a type fails. It would be nice to give the user some indication of why it failed. Right now, I think it's often silent.
+Perhaps we could improve emacs's behavior when querying ocamlspotter
+for a type fails. It would be nice to give the user some indication of
+why it failed. Right now, I think it's often silent.
+
 E.g. If ocamlspotter fails with
 
 Warning: source z.ml is newer than the spot
 addressed. The responsiveness is bad enough that I'm switching back to
 705108ac39fe.
 
-** Omake.next-error is slow on large builds
-*** sweeks
-I am doing a build of our main repo, with about 75k targets
-and 50 errors. Running next-error takes 5-10 seconds to run. I think
-the performance of this used to be OK. I haven't done a large build in
-a while, so I guess this problem was introduced in the last month.
-
-*** sweeks
-I should add that there was no obvious CPU use of emacs or
-omake_server while I was waiting. I never saw their CPU use move about
-2% during the 5-10%.
-
 ** Use elisp buttons rather than text properties
 *** seanmcl:
 I just discovered button.el, which makes things prettier that I
 
 ** Fix Js.underscore_is_* to play nicely with C-M-{f,b}
 *** dhouse:
-Perhaps this isn't possible, but I would love the following semantics: M-{f,b} move forwards and backwards between underscores, and C-M-{f,b} move forwards and backwards between "actual" word boundaries, where by "actual" I mean what you would get if you said that ?_ was not a word boundary for the duration of the call.
+Perhaps this isn't possible, but I would love the following semantics:
+M-{f,b} move forwards and backwards between underscores, and C-M-{f,b}
+move forwards and backwards between "actual" word boundaries, where by
+"actual" I mean what you would get if you said that ?_ was not a word
+boundary for the duration of the call.
+
 E.g.:
 #+BEGIN_EXAMPLE
                 F o o . f o o _ b a r _ b a z  ( )
 Compile Mode does the same thing.  I guess our m.o. is different, and
 some people keep lots of buffers unsaved on purpose, to avoid the
 compiler kicking in.
-** jane-defaults is a feature: it provides 'jane-defaults
-*** pszilagyi:
-Is that weird?  Is it weird the way we load it (with load rather than
-require)?  Seems like we should pick one way to look at it.
 ** Disable errors entering recursive edits, which isn't much use to most users.
 *** mstanojevic and ereisner (via pszilagyi):
 The default Emacs recursive edit on error behavior is more confusing
 I agree that this behavior is confusing.  Given some of the changes
 we've made recently, it should be possible to implement this again,
 saving the settings until the compilation is started.
+** Omake.next-error is slow on large builds
+*** sweeks
+I am doing a build of our main repo, with about 75k targets
+and 50 errors. Running next-error takes 5-10 seconds to run. I think
+the performance of this used to be OK. I haven't done a large build in
+a while, so I guess this problem was introduced in the last month.
+
+*** sweeks
+I should add that there was no obvious CPU use of emacs or
+omake_server while I was waiting. I never saw their CPU use move about
+2% during the 5-10%.