Commits

Peter Szilagyi  committed 8925c11

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

  • Participants
  • Parent commits 5c753aa
  • Tags 2013-01-11-roll-test

Comments (0)

Files changed (1)

File todo/TODO.org

 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%.