Commits

Peter Szilagyi  committed d6a8309

todo: Reviewed priorities with Stephen and shuffled some things.
Need to get Sean's input.

  • Participants
  • Parent commits d9ace7e

Comments (0)

Files changed (1)

File todo/TODO.org

 
 Move the issue to the bottom of the `Closed' section.
 
-* Feature requests
+* High
+** Ocamlpro indentation
+*** seanmcl:
+Try to get this to work.
+* Medium
+** improve support for error messages from compiling C
+*** sweeks:
+We compile C code using OMake. Right now, errors in C lead to {{{
+Compilation was not successful, but it's stopped and there are no
+errors. Something is wrong }}}
+
+It would be good for these to produce errors that are visited in the
+ordinary way, with Omake.next-error.
+*** pszilagyi:
+When we're in the C buffer, will our cerebellums hit C-c C-l or C-x `?
+We could rebind either or both to Omake.next-error, although it may
+cause confusion (both keys have default keybindings in C Mode).
+** Opensource license
+*** seanmcl:
+We don't have a LICENSE file. Choose one, probably the same as core.
 ** Compile a table of our keybindings.  --yminsky
 *** pszilagyi:
 Inspired by the release notes, which contain nice tables of changes to
 keybindings, we should have a table of all our keybindings somewhere.
 Maybe collected via Emacs Lisp, maybe manually.  Maybe included in the
 Info doc.  Maybe it's already here somewhere.
-** Delete trailing blank lines in ocaml files.
-*** mstanojevic:
-Easy.
-** 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
-than useful to most users most of the time.  Isn't there a variable to
-flip to turn that off, and just have the error reported and state
-flushed?  Probably easy.
+** Unit test failures
+*** seanmcl
+I played around with this a bit more. It is easy to make unit tests
+fail. E.g. in core/lib_test, use a prefix argument to OMake.compile
+and run "jomake runtest" rather than the usual "jomake". You can then
+edit one of the unit tests (e.g. bigstring_test.ml) to put in an
+[assert false].
+
+Every way I've tried this, I get omake mode to report
+
+Compilation was not successful, but it's stopped and there are no
+errors. Something is wrong
+
+I don't know how to mix a type error with a unit-test error.
+
+Looking at Ron's output again, it looks to me like we might be able to
+fix this problem without reproducing it. Perhaps the parser for omake
+output could recognize a line that identifies a (phony?) target like
+
+<phony <base/core/lib_test/command-tests/check>>
+
+and end the current error message at that target?
+
+** Can't kill project if directory has gone away
+
+*** sweeks:
+I just moved a directory for a project that was building. Now I can
+not kill the project, because omake-mode complains that it cannot set
+the current directory to the now-gone directory.
+
+* Low
+** Keybindings for projects buffer
+*** sweeks:
+How about
+q for quit d for delete project
+
+(like dired)
+
+** Show error counts in projects buffer
+*** sweeks:
+Also, how about a status column? It would say one of the following:
+Building Failure Success
+*** seanmcl:
+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'd like to leave open something to get all the data someday.
+
+I'm thinking more and more that I would like the notion of "watching"
+out of the face of users as much as possible. The only user-visible
+effect I can think of that "watching" has is for the decision
+omake-server has to make about killing a project. For people like me
+who have kill_when_watched=false, even that has no effect. So I think
+that for such people watching is a completely artificial and
+unnecessary notion. I'd like to auto-watch all projects.
+*** seanmcl:
+That sounds right. I just wonder how do you unwatch them? There is a
+nonzero cost to watching a project, since emacs is constantly
+asynchronously updating the status buffer and logging. Hmm... I
+suppose if they kill the status buffer that should do the trick.  I
+agree the watching stuff in the projects buffer is mostly noise. It
+needs to be much more nicely formatted too.
+*** sweeks:
+How about maintaining the following two invariants:
+
+(there is a projects buffer) if and only if (omake-server sends to
+emacs the information for all projects needed to completely fill out
+the projects buffer)
+
+For all projects P, (there is a status buffer for P) iff (omake-server
+sends to emacs the information to fill out the status buffer for P)
+
+Then, one only pays performance for the information one wants.
+
+I think then that the notion of watching completely disappears for
+people who have kill_when_unwatched=false. I'm tempted to just take
+the semantic change of making that the behavior for everyone. Then we
+make a distinction between killing the status buffer and killing the
+project. People can either kill a project by running
+Omake.kill-project, C-c C-k, or using the projects buffer.
+
+I'm warming to the idea of inflicting that change on people, as
+perhaps the benefit of removing the notion of watching from the model
+outweighs the cost.
+
 ** the projects buffer should show the state of the build for each project --sweeks
 *** dwang (via pszilagyi):
 Same.
 *** pszilagyi:
 This should be pretty easy.
-* High
-** omake-mode degrading emacs keystroke performance
-*** sweeks
-I have two emacsen running on the same machine, with the only
-difference being that one is connected to omake-server doing a build
-and the other isn't connected to omake server. The visible response of
-keypresses (especially with hold to repeat) is much better in the
-emacs that isn't talking to omake server. If I stop the build, the
-emacs talking to omake server gets better, but it's still worse than a
-clean emacs. If I stop omake server, then the emacs reverts to good
-keypress resposiveness.  I think there's room for improvement in
-interfering less with emacs. I find that the poor responsiveness with
-a build running negatively affects my interaction with emacs.
+** After closing dedicate omake status frame, C-c C-c dies
+*** mml
+with "Wrong type argument: frame-live-p, #<dead frame Emacs: 0x1d869540>
 
-*** sweeks
-I just compared the keystroke responsiveness of tip to that of
-the most recent roll to test here, 705108ac39fe. Things have gotten
-much worse in the last month. I think this issue needs to be
-addressed. The responsiveness is bad enough that I'm switching back to
-705108ac39fe.
+*** seanmcl
+I run into this sometimes in other packages. Emacs gets
+confused somehow by referring to a dead frame. In emergencies you can
+do: run this if you can't kill a buffer due to a dead-frame error
+(setq menu-updating-frame nil) but I'll work on finding why it's
+happening to omake-mode.
 
-** 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.
+** Remove 'watching' a project from user consideration.
 
-*** 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%.
+*** seanmcl
+Now the only way to kill a project will be from the projects window or
+command line. It will significantly simplify the user interface.
 
+** omake-mode just hangs when omake runs out of memory
+*** seanmcl
+I'm running on a low-memory virtual OS, and while building core I ran
+out of memory. Omake-mode just hung, even though there was a readable
+message in the raw output:
+
+#+BEGIN_EXAMPLE
+ * omake: blocked (25 min 04.50 sec, 10/777 scans, 1387/2133 rules, 1907/7179 digests)
+[===========================================================   ] 03857 / 03954
+
+ * omake: targets were not rebuilt because of errors:
+core_extended-108.07.00/lib/patience_diff.cmx
+depends on: core_extended-108.07.00/lib/patience_diff.ml
+      - build core_extended-108.07.00/lib patience_diff.cmx
+      + <compute 1 value dependencies>
+      - build core_extended-108.07.00/lib patience_diff.cmx
+      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo [[../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/patience_diff.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c patience_diff.ml
+Fatal error: exception Out_of_memory
+Called from file "arg.ml", line 216, characters 4-32
+      - exit core_extended-108.07.00/lib patience_diff.cmx, 55.11 sec, code 2
+core_extended-108.07.00/lib/patience_diff.o
+depends on: core_extended-108.07.00/lib/patience_diff.ml
+core_extended-108.07.00/lib/procfs.cmx
+depends on: core_extended-108.07.00/lib/procfs.ml
+      - build core_extended-108.07.00/lib procfs.cmx
+      + <compute 1 value dependencies>
+      - build core_extended-108.07.00/lib procfs.cmx
+      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo ../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/procfs.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c procfs.ml
+      - exit core_extended-108.07.00/lib procfs.cmx, 2 min 16.04 sec, code 127
+core_extended-108.07.00/lib/procfs.o
+depends on: core_extended-108.07.00/lib/procfs.ml
+core_extended-108.07.00/lib/readline.cmx
+depends on: core_extended-108.07.00/lib/readline.ml
+core_extended-108.07.00/lib/readline.o
+depends on: core_extended-108.07.00/lib/readline.ml
+      - build core_extended-108.07.00/lib readline.o
+      + <compute 1 value dependencies>
+      - build core_extended-108.07.00/lib readline.o
+      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -for-pack Core_extended -c readline.ml
+      - exit core_extended-108.07.00/lib readline.o, 39.92 sec, code 127
+ * omake: polling for filesystem changes
+#+END_EXAMPLE
+
+** 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.
+E.g. If ocamlspotter fails with
+
+Warning: source z.ml is newer than the spot
+then I think this doesn't make it back to the user.
+** Jane.find-file-in-project should commit to unique matches
+*** mml:
+say there is one file in my repo named comment.ml. If I do
+Jane.fine-file-in-project and type comment.ml and hit enter, I get
+Possible completions are: comment.ml in dev/code-review/cr-server/
+comment.mli in dev/code-review/cr-server/
+
+I'd the function just went ahead and picked comment.ml since that is
+the only file of that (base)name.
+*** mstanojevic:
+I've noticed this as well. Workaround is to type space after the
+filename and then enter and it will choose the file you want.
+
+** Scan server log for errors
+*** seanmcl:
+Now when the server encounters an error, it dutifully logs it, but the
+log is only inspected haphazardly. We should scan the logs
+periodically and alert the user somehow that an error has
+occurred. Perhaps the command line tool will warn about it when
+running any command, an/or it could be sent to all Emacs processes.
+
+** Bitbucket docs
+*** seanmcl:
+Make a wiki and readme for external users.
+** Push our tuareg changes
+*** seanmcl:
+Our copy of Tuareg has changes Christophe's doesn't. Push them upstream.
+
+** Improve feedback when an invalid command is supplied to Omake.compile
+*** sweeks:
+When one uses a prefix arg to supply a command to Omake.compile, and
+then supplies an invalid command, the feedback to the user could be
+improved. Currently, the status buffer says: Progress : No files
+processed yet [ | ]
+
+FATAL ERROR: The omake process is dead.
+
+and there is an "exec failed" message in the raw buffer. It would be
+good to get the "exec failed" message into the status buffer. It seems
+like omake server should have a pretty good idea what's going on, and
+should be able to communicate it to emacs.
+
+We also briefly confused ourselves by not distinguishing "omake
+process" from the error message, and "omake server", thinking that the
+error message meant the omake server was dead, when it wasn't. We were
+misremembering the other error message.
+
+ERROR: The server is not responding.
+
+wonder whether the use of "FATAL ERROR" and the red coloring is too
+much in this case. IMO, the server being down is much more serious
+(typically indicating a bug) than omake exiting, which may just
+indicate user error. Perhaps we should use purple for server down. Or
+stop using red for "The omake process is dead." Also, maybe the text
+could be improved, perhaps eliminating the word "process". How about:
+
+ERROR: omake is not running
+
+BTW, this came up when a user tried to set an environment variable
+using bash syntax in a custom command line (rather than
+Omake.toggle-env). Perhaps we could do something to make clear what
+language is allowed when a command is specified (i.e. not bash), and
+to preempt even trying to run omake when the command syntax is
+invalid.
+
+** Discovery of jomake/omake in server config file
+*** seanmcl:
+Now it defaults to jomake, and home users must edit the config by
+hand. This is annoying. Search in the path for jomake, and otherwise
+omake.
+
+** Jane.auto-modes not working
+At least Haskell, SML and dot-mode are not working with the same
+error: "(void-function <mode-name>)" For haskell the fix is to say
+(load-library "haskell-site-file") instead of (require
+'haskell-site-file). I haven't looked into others
+[[%0A./Jane.haskell.patch][
+
+[[file:Jane.haskell.patch]]
+
+** Add an elisp command to "ignore" errors from a file
+*** sweeks:
+Sometimes I fix errors in file A by changing file B. Omake mode only
+sees B change, and doesn't remove the error until it sees A change. In
+big compiles, this ccould be a long time. I'd like a way to manually
+force omake mode to act as if it had seen a file change:
+Omake.clear-errors-for-file
+
+I currently simulate this by add whitespace to file A, waiting until
+omake-mode clears A's errors, and then deleting the whitespace.
+
+Of course, if the change to B didn't actually fix the errors,
+omake-mode should re-display them when it compiles A again (or when it
+starts polling again without having had to compile A).
+
+*** seanmcl:
+We decided to have a new class of errors, Ignored. Ignored errors show
+up below Current, Unvisited, and Visited. Ignored errors are never
+cycled-through if there exists a Visited or Unvisited error. If both
+of those categories are empty, then we cycle through Ignored
+errors. Errors can be manually moved to and from Ignored by running
+Omake.toggle-ignored-errors in a file. Errors are automatically
+promoted from Ignored to Unvisited when an ignored file is recompiled.
+
+*** sweeks:
+A possible slightly different way of handling things.
+
+Ignored errors are never cycled through.  If the user runs next-error
+and there are ignored errors but no visited or unvisited errors, then
+omake-mode selects a file from the unvisited errors (perhaps the file
+that was ignored longest ago) and toggles it, so that the errors
+become visited or unvisited, at which point next-error does its normal
+thing.  The user can manually run toggle-ignored-errors for a file by
+pressing enter on an ignored error from that file in the status
+buffer.
+
+** Info files should have an index
+*** seanmcl: Add one to both info files.
+
+** Update info docs
+*** seanmcl: Lots has changed
+** Restarting a build should reuse the existing build's error window
+*** sweeks:
+This is better than the current behavior, which is to kill the
+existing error buffer, and then use the window selection algorithm to
+pick a new one.
+*** seanmcl:
+This appears to have been resolved some time ago. I can't
+reproduce. Please reopen if you notice the problem again.
+*** sweeks:
+This problem is still around. I just reproduced it. I use a dedicated
+error frame. I started building two projects, and had each of their
+status buffers displayed in a window in my dedicated error frame. I
+then restarted a project, and it deleted the buffer in one window, and
+then replaced the status buffer in the other window when it restarted.
+
+** omake status buffer alternates windows on C-c C-c  --ereisner
+*** pszilagyi:
+You can call Omake.set-dedicated-status-window, but that is brittle,
+because windows go away completely when you close them.  It looks like
+Omake.choose-frame-and-maybe-window is trying to keep the
+configuration stable even without a dedicated status window, but
+failing.  It was not obvious to me what went wrong, but I can easily
+imagine something subtle, it's pretty complex.  One suspect is the
+minibuffer being the selected window or something at some point
+during C-c C-c, when it prompts if you really want to kill the
+existing omake.
+** Stale writer exception
+*** seanmcl: I got this some time ago [[file:stale-writer-exn.txt]]
+
+** Remove spin lock in Omake.Server.start
+*** seanmcl:
+When I tried (sleep-for N) in the function Omake.Server.start, an
+asyncronous process sometimes interrupted it and it broke some
+invariants. The spin lock works, but is a wart. Try to come up with
+something better.
+
+** Module types in ocamlspot
+*** pszilagyi:
+Sometimes, I get "no type" for a module type, sometimes "stack
+overflow in regexp matcher", depending on the case.  Sometimes, I do
+get a module type.
 ** omake-server spinning at 100%+ CPU
 *** sweeks
 Ron hit a case today in which his omake_server_test.exe was spinning
 but it terminated quickly. There must have been some property of Sam's
 particular lines.
 
-** Stopping omake server leaves around omake processes
+** omake-mode degrading emacs keystroke performance
 *** sweeks
-If I run "controller stop" from the command line, omake server leaves
-around the omake processes that it was managing.
-
-*** seanmcl
-Ug. Right. Maybe service_command could have an argument that runs some
-cleanup code before stopping the daemon. I'll have to dig into the
-commands themselves to get the behavior I want.
-
-*** seanmcl
-Now we use service_command's start, but the old stop which kills the
-children processes. On hold whether we should fix service_command to
-install a signal handler for sigint.
+I have two emacsen running on the same machine, with the only
+difference being that one is connected to omake-server doing a build
+and the other isn't connected to omake server. The visible response of
+keypresses (especially with hold to repeat) is much better in the
+emacs that isn't talking to omake server. If I stop the build, the
+emacs talking to omake server gets better, but it's still worse than a
+clean emacs. If I stop omake server, then the emacs reverts to good
+keypress resposiveness.  I think there's room for improvement in
+interfering less with emacs. I find that the poor responsiveness with
+a build running negatively affects my interaction with emacs.
 
 *** sweeks
-I chatted with Nathan about this. He agrees that [Service_command]
-should handle SIGTERM and call [exit] so that [at_exit] handlers can
-run.  He also pointed out that [Service_command] may be going away
-from [Core_extended], being replaced by something that subsumes it,
-but is also more tied to being inside Jane Street.
+I just compared the keystroke responsiveness of tip to that of
+the most recent roll to test here, 705108ac39fe. Things have gotten
+much worse in the last month. I think this issue needs to be
+addressed. The responsiveness is bad enough that I'm switching back to
+705108ac39fe.
 
-To make progress now, how about you fix [Service_command] in your
-clone of Core to do this?
+** 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.
 
-** After closing dedicate omake status frame, C-c C-c dies
-*** mml
-with "Wrong type argument: frame-live-p, #<dead frame Emacs: 0x1d869540>
+*** 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%.
 
-*** seanmcl
-I run into this sometimes in other packages. Emacs gets
-confused somehow by referring to a dead frame. In emergencies you can
-do: run this if you can't kill a buffer due to a dead-frame error
-(setq menu-updating-frame nil) but I'll work on finding why it's
-happening to omake-mode.
-
-** Remove 'watching' a project from user consideration.
-
-*** seanmcl
-Now the only way to kill a project will be from the projects window or
-command line. It will significantly simplify the user interface.
-
-** omake-mode just hangs when omake runs out of memory
-*** seanmcl
-I'm running on a low-memory virtual OS, and while building core I ran
-out of memory. Omake-mode just hung, even though there was a readable
-message in the raw output:
-
-#+BEGIN_EXAMPLE
- * omake: blocked (25 min 04.50 sec, 10/777 scans, 1387/2133 rules, 1907/7179 digests)
-[===========================================================   ] 03857 / 03954
-
- * omake: targets were not rebuilt because of errors:
-core_extended-108.07.00/lib/patience_diff.cmx
-depends on: core_extended-108.07.00/lib/patience_diff.ml
-      - build core_extended-108.07.00/lib patience_diff.cmx
-      + <compute 1 value dependencies>
-      - build core_extended-108.07.00/lib patience_diff.cmx
-      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo [[../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/patience_diff.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c patience_diff.ml
-Fatal error: exception Out_of_memory
-Called from file "arg.ml", line 216, characters 4-32
-      - exit core_extended-108.07.00/lib patience_diff.cmx, 55.11 sec, code 2
-core_extended-108.07.00/lib/patience_diff.o
-depends on: core_extended-108.07.00/lib/patience_diff.ml
-core_extended-108.07.00/lib/procfs.cmx
-depends on: core_extended-108.07.00/lib/procfs.ml
-      - build core_extended-108.07.00/lib procfs.cmx
-      + <compute 1 value dependencies>
-      - build core_extended-108.07.00/lib procfs.cmx
-      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo ../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/procfs.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c procfs.ml
-      - exit core_extended-108.07.00/lib procfs.cmx, 2 min 16.04 sec, code 127
-core_extended-108.07.00/lib/procfs.o
-depends on: core_extended-108.07.00/lib/procfs.ml
-core_extended-108.07.00/lib/readline.cmx
-depends on: core_extended-108.07.00/lib/readline.ml
-core_extended-108.07.00/lib/readline.o
-depends on: core_extended-108.07.00/lib/readline.ml
-      - build core_extended-108.07.00/lib readline.o
-      + <compute 1 value dependencies>
-      - build core_extended-108.07.00/lib readline.o
-      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -for-pack Core_extended -c readline.ml
-      - exit core_extended-108.07.00/lib readline.o, 39.92 sec, code 127
- * omake: polling for filesystem changes
-#+END_EXAMPLE
-
-** improve support for error messages from compiling C
-*** sweeks:
-We compile C code using OMake. Right now, errors in C lead to {{{
-Compilation was not successful, but it's stopped and there are no
-errors. Something is wrong }}}
-
-It would be good for these to produce errors that are visited in the
-ordinary way, with Omake.next-error.
-*** pszilagyi:
-When we're in the C buffer, will our cerebellums hit C-c C-l or C-x `?
-We could rebind either or both to Omake.next-error, although it may
-cause confusion (both keys have default keybindings in C Mode).
-** 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.
-E.g. If ocamlspotter fails with
-
-Warning: source z.ml is newer than the spot
-then I think this doesn't make it back to the user.
-** Jane.find-file-in-project should commit to unique matches
-*** mml:
-say there is one file in my repo named comment.ml. If I do
-Jane.fine-file-in-project and type comment.ml and hit enter, I get
-Possible completions are: comment.ml in dev/code-review/cr-server/
-comment.mli in dev/code-review/cr-server/
-
-I'd the function just went ahead and picked comment.ml since that is
-the only file of that (base)name.
-*** mstanojevic:
-I've noticed this as well. Workaround is to type space after the
-filename and then enter and it will choose the file you want.
-
-** Opensource license
-*** seanmcl:
-We don't have a LICENSE file. Choose one, probably the same as core.
-** Scan server log for errors
-*** seanmcl:
-Now when the server encounters an error, it dutifully logs it, but the
-log is only inspected haphazardly. We should scan the logs
-periodically and alert the user somehow that an error has
-occurred. Perhaps the command line tool will warn about it when
-running any command, an/or it could be sent to all Emacs processes.
-
-** Keybindings for projects buffer
-*** sweeks:
-How about
-q for quit d for delete project
-
-(like dired)
-
-** Unit test failures
-*** seanmcl
-I played around with this a bit more. It is easy to make unit tests
-fail. E.g. in core/lib_test, use a prefix argument to OMake.compile
-and run "jomake runtest" rather than the usual "jomake". You can then
-edit one of the unit tests (e.g. bigstring_test.ml) to put in an
-[assert false].
-
-Every way I've tried this, I get omake mode to report
-
-Compilation was not successful, but it's stopped and there are no
-errors. Something is wrong
-
-I don't know how to mix a type error with a unit-test error.
-
-Looking at Ron's output again, it looks to me like we might be able to
-fix this problem without reproducing it. Perhaps the parser for omake
-output could recognize a line that identifies a (phony?) target like
-
-<phony <base/core/lib_test/command-tests/check>>
-
-and end the current error message at that target?
-
-** Bitbucket docs
-*** seanmcl:
-Make a wiki and readme for external users.
-** Omake mode just hangs when low on memory
-*** seanmcl:
-I'm running on a low-memory virtual OS, and while building core I ran out of memory. Omake-mode just hung, even though there was a readable message in the raw output:
-\*** omake: blocked (25 min 04.50 sec, 10/777 scans, 1387/2133 rules, 1907/7179 digests)
-[===========================================================   ] 03857 / 03954
-
-\*** omake: targets were not rebuilt because of errors:
-core_extended-108.07.00/lib/patience_diff.cmx
-depends on: core_extended-108.07.00/lib/patience_diff.ml
-      - build core_extended-108.07.00/lib patience_diff.cmx
-      + <compute 1 value dependencies>
-      - build core_extended-108.07.00/lib patience_diff.cmx
-      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo [[../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/patience_diff.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c patience_diff.ml
-Fatal error: exception Out_of_memory
-Called from file "arg.ml", line 216, characters 4-32
-      - exit core_extended-108.07.00/lib patience_diff.cmx, 55.11 sec, code 2
-core_extended-108.07.00/lib/patience_diff.o
-depends on: core_extended-108.07.00/lib/patience_diff.ml
-core_extended-108.07.00/lib/procfs.cmx
-depends on: core_extended-108.07.00/lib/procfs.ml
-      - build core_extended-108.07.00/lib procfs.cmx
-      + <compute 1 value dependencies>
-      - build core_extended-108.07.00/lib procfs.cmx
-      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo ../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/procfs.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c procfs.ml
-      - exit core_extended-108.07.00/lib procfs.cmx, 2 min 16.04 sec, code 127
-core_extended-108.07.00/lib/procfs.o
-depends on: core_extended-108.07.00/lib/procfs.ml
-core_extended-108.07.00/lib/readline.cmx
-depends on: core_extended-108.07.00/lib/readline.ml
-core_extended-108.07.00/lib/readline.o
-depends on: core_extended-108.07.00/lib/readline.ml
-      - build core_extended-108.07.00/lib readline.o
-      + <compute 1 value dependencies>
-      - build core_extended-108.07.00/lib readline.o
-      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -for-pack Core_extended -c readline.ml
-      - exit core_extended-108.07.00/lib readline.o, 39.92 sec, code 127
-\*** omake: polling for filesystem changes
-
-** Push our tuareg changes
-*** seanmcl:
-Our copy of Tuareg has changes Christophe's doesn't. Push them upstream.
-
-** Improve feedback when an invalid command is supplied to Omake.compile
-*** sweeks:
-When one uses a prefix arg to supply a command to Omake.compile, and
-then supplies an invalid command, the feedback to the user could be
-improved. Currently, the status buffer says: Progress : No files
-processed yet [ | ]
-
-FATAL ERROR: The omake process is dead.
-
-and there is an "exec failed" message in the raw buffer. It would be
-good to get the "exec failed" message into the status buffer. It seems
-like omake server should have a pretty good idea what's going on, and
-should be able to communicate it to emacs.
-
-We also briefly confused ourselves by not distinguishing "omake
-process" from the error message, and "omake server", thinking that the
-error message meant the omake server was dead, when it wasn't. We were
-misremembering the other error message.
-
-ERROR: The server is not responding.
-
-wonder whether the use of "FATAL ERROR" and the red coloring is too
-much in this case. IMO, the server being down is much more serious
-(typically indicating a bug) than omake exiting, which may just
-indicate user error. Perhaps we should use purple for server down. Or
-stop using red for "The omake process is dead." Also, maybe the text
-could be improved, perhaps eliminating the word "process". How about:
-
-ERROR: omake is not running
-
-BTW, this came up when a user tried to set an environment variable
-using bash syntax in a custom command line (rather than
-Omake.toggle-env). Perhaps we could do something to make clear what
-language is allowed when a command is specified (i.e. not bash), and
-to preempt even trying to run omake when the command syntax is
-invalid.
-
-** Discovery of jomake/omake in server config file
-*** seanmcl:
-Now it defaults to jomake, and home users must edit the config by
-hand. This is annoying. Search in the path for jomake, and otherwise
-omake.
-
-** Jane.auto-modes not working
-At least Haskell, SML and dot-mode are not working with the same
-error: "(void-function <mode-name>)" For haskell the fix is to say
-(load-library "haskell-site-file") instead of (require
-'haskell-site-file). I haven't looked into others
-[[%0A./Jane.haskell.patch][
-
-[[file:Jane.haskell.patch]]
-
-** Add an elisp command to "ignore" errors from a file
-*** sweeks:
-Sometimes I fix errors in file A by changing file B. Omake mode only
-sees B change, and doesn't remove the error until it sees A change. In
-big compiles, this ccould be a long time. I'd like a way to manually
-force omake mode to act as if it had seen a file change:
-Omake.clear-errors-for-file
-
-I currently simulate this by add whitespace to file A, waiting until
-omake-mode clears A's errors, and then deleting the whitespace.
-
-Of course, if the change to B didn't actually fix the errors,
-omake-mode should re-display them when it compiles A again (or when it
-starts polling again without having had to compile A).
-
-*** seanmcl:
-We decided to have a new class of errors, Ignored. Ignored errors show
-up below Current, Unvisited, and Visited. Ignored errors are never
-cycled-through if there exists a Visited or Unvisited error. If both
-of those categories are empty, then we cycle through Ignored
-errors. Errors can be manually moved to and from Ignored by running
-Omake.toggle-ignored-errors in a file. Errors are automatically
-promoted from Ignored to Unvisited when an ignored file is recompiled.
-
-*** sweeks:
-A possible slightly different way of handling things.
-
-Ignored errors are never cycled through.  If the user runs next-error
-and there are ignored errors but no visited or unvisited errors, then
-omake-mode selects a file from the unvisited errors (perhaps the file
-that was ignored longest ago) and toggles it, so that the errors
-become visited or unvisited, at which point next-error does its normal
-thing.  The user can manually run toggle-ignored-errors for a file by
-pressing enter on an ignored error from that file in the status
-buffer.
-
-** Info files should have an index
-*** seanmcl: Add one to both info files.
-
-** Update info docs
-*** seanmcl: Lots has changed
-** Status buffer coopts minibuffer and interferes with Omake.shutdown
-*** sweeks:
-Files: ldn-qws-010.delacy.com:/tmp/omake-server/dastapov/bug-report/1
-
-User report:
-
-Over the last week I've twice found myself in a situation where
-Omake-mode status buffer decides that it has to occupy the minibufer
-and stay there.
-
-Minibuffer still acts as minibuffer, except that now it is 10 lines
-high and refuses to be shrinked.
-
-If you create new frame, only one of them would have a \"corrupt\"
-minibuffer.
-
-I know that this has happened to nchapman as well.
-
-Omake.shutdown does not solve this - new compilations come up in
-minibuffer.
-
-Omake.shutdown-and-remove-hooks does, though - minibuffer gets back to
-normal.
-
-Sadly, I am writing this bugreport _after_ I figured out that
-shutdown-and-remove-hooks is the solution :(
-
-I don't know how to recreate this :(
-
-If this happens to me again I'll try to do a better investigation
-
-** Show error counts in projects buffer
-*** sweeks:
-Also, how about a status column? It would say one of the following:
-Building Failure Success
-*** seanmcl:
-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'd like to leave open something to get all the data someday.
-
-I'm thinking more and more that I would like the notion of "watching"
-out of the face of users as much as possible. The only user-visible
-effect I can think of that "watching" has is for the decision
-omake-server has to make about killing a project. For people like me
-who have kill_when_watched=false, even that has no effect. So I think
-that for such people watching is a completely artificial and
-unnecessary notion. I'd like to auto-watch all projects.
-*** seanmcl:
-That sounds right. I just wonder how do you unwatch them? There is a
-nonzero cost to watching a project, since emacs is constantly
-asynchronously updating the status buffer and logging. Hmm... I
-suppose if they kill the status buffer that should do the trick.  I
-agree the watching stuff in the projects buffer is mostly noise. It
-needs to be much more nicely formatted too.
-*** sweeks:
-How about maintaining the following two invariants:
-
-(there is a projects buffer) if and only if (omake-server sends to
-emacs the information for all projects needed to completely fill out
-the projects buffer)
-
-For all projects P, (there is a status buffer for P) iff (omake-server
-sends to emacs the information to fill out the status buffer for P)
-
-Then, one only pays performance for the information one wants.
-
-I think then that the notion of watching completely disappears for
-people who have kill_when_unwatched=false. I'm tempted to just take
-the semantic change of making that the behavior for everyone. Then we
-make a distinction between killing the status buffer and killing the
-project. People can either kill a project by running
-Omake.kill-project, C-c C-k, or using the projects buffer.
-
-I'm warming to the idea of inflicting that change on people, as
-perhaps the benefit of removing the notion of watching from the model
-outweighs the cost.
-
-** Ocamlpro indentation
-*** seanmcl:
-Try to get this to work.
-** Restarting a build should reuse the existing build's error window
-*** sweeks:
-This is better than the current behavior, which is to kill the
-existing error buffer, and then use the window selection algorithm to
-pick a new one.
-*** seanmcl:
-This appears to have been resolved some time ago. I can't
-reproduce. Please reopen if you notice the problem again.
-*** sweeks:
-This problem is still around. I just reproduced it. I use a dedicated
-error frame. I started building two projects, and had each of their
-status buffers displayed in a window in my dedicated error frame. I
-then restarted a project, and it deleted the buffer in one window, and
-then replaced the status buffer in the other window when it restarted.
-
-** Stale writer exception
-*** seanmcl: I got this some time ago [[file:stale-writer-exn.txt]]
-
-* Medium
-** omake status buffer alternates windows on C-c C-c  --ereisner
-*** pszilagyi:
-You can call Omake.set-dedicated-status-window, but that is brittle,
-because windows go away completely when you close them.  It looks like
-Omake.choose-frame-and-maybe-window is trying to keep the
-configuration stable even without a dedicated status window, but
-failing.  It was not obvious to me what went wrong, but I can easily
-imagine something subtle, it's pretty complex.  One suspect is the
-minibuffer being the selected window or something at some point
-during C-c C-c, when it prompts if you really want to kill the
-existing omake.
-** Module types in ocamlspot
-*** pszilagyi:
-Sometimes, I get "no type" for a module type, sometimes "stack
-overflow in regexp matcher", depending on the case.  Sometimes, I do
-get a module type.
-* Low
 ** Use elisp buttons rather than text properties
 *** seanmcl:
 I just discovered button.el, which makes things prettier that I
 was doing with text-properties and lexical-let. In particular, the
 errors and project buffers have such buttons.
 
-** Remove spin lock in Omake.Server.start
-*** seanmcl:
-When I tried (sleep-for N) in the function Omake.Server.start, an
-asyncronous process sometimes interrupted it and it broke some
-invariants. The spin lock works, but is a wart. Try to come up with
-something better.
-
 ** 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.
     (ocamlspot-message-add path-range)))
 #+END_EXAMPLE
 
+** Use markers instead of file/line/char triples
+*** seanmcl:
+markers have the nice property that they are updated as the file is
+edited, so Omake.next-error can find an error even if code above the
+error changed.
+
+** omake-mode support for refactoring
+*** sweeks:
+Nathan mentioned to me the excellent idea that we could scrape OMake output to automatically assist with refactoring. For example, suppose one renames module "Foo" to "Bar". Well, then whenever OMake spits out an error "Unbound module Foo", we likely want to replace "Foo" with "Bar" at the point of that error.
+I was thinking that since omake-mode already parses OMake output and understands the structure of OCaml error messages, we could add some emacs functionality to assist with refactoring.
+
+I imagine a function Omake.rename-module that would prompt for the old
+and new module names, and would instruct omake-mode to, when it
+encounters an unbound-module error, rather than display the error in
+the [Errors] buffer, automatically replace the old name with the new
+name in the code. Similarly for Omake.rename-variable.
+
+** pdiff type errors
+*** sweeks:
+For type error messages that we can parse well enough to detect [t1 !=
+t2], it would be cool to display in emacs the pdiff of [t1] and [t2],
+as a way of making it easier for the user to find the source of the
+type error.
+
+** Lift the 50 error limit
+*** seanmcl:
+Improve performance/streaming so that the 50 error limit is no longer
+necessary.
+
+** Show command that caused an error
+*** seanmcl:
+It would be cool to have a keybinding that would let me toggle display
+of the build command that led to the current error message. Maybe the
+keybinding should just be the existing C-c C-h, but that would add a
+new field to the displayed error, "Build command: ..."
+
+** Flymake highlighting of errors
+*** seanmcl:
+It would be cool if the tuareg buffer would highlight errors from
+omake. Maybe in the style of fly-make, or maybe with something like
+this:
+
+#+BEGIN_EXAMPLE
+;; Some code that will make it so the background color of the lines that gcc ;; found errors on, should be in another color.
+
+(defvar all-overlays ())
+
+(defun delete-this-overlay (overlay is-after begin end &optional len) (delete-overlay overlay))
+
+(defun highlight-current-line () (interactive) (setq current-point (point)) (beginning-of-line) (setq beg (point)) (forward-line 1) (setq end (point)) ;; Create and place the overlay (setq error-line-overlay (make-overlay 1 1))
+
+;; Append to list of all overlays (setq all-overlays (cons error-line-overlay all-overlays))
+
+(overlay-put error-line-overlay 'face '(background-color . "pink")) (overlay-put error-line-overlay 'modification-hooks (list 'delete-this-overlay)) (move-overlay error-line-overlay beg end) (goto-char current-point))
+
+(defun delete-all-overlays () (while all-overlays (delete-overlay (car all-overlays)) (setq all-overlays (cdr all-overlays))))
+
+(defun highlight-error-lines (compilation-buffer, process-result) (interactive) (delete-all-overlays) (condition-case nil (while t (next-error) (highlight-current-line)) (error nil)))
+
+(setq compilation-finish-function 'highlight-error-lines)
+#+END_EXAMPLE
+*** pszilagyi:
+You did this, right?  We have overlays now, I noticed.
+** Visual flickering in [Errors] buffer
+*** sweeks:
+With a large error message expanded as the current error, the error
+noticeably flickers between blue and orange, remaining primarily
+blue. The frequency of the flicker is not regular and the interval is
+often less than a second. Also, if I Alt-tab, the error freezes in the
+orange color.
+*** seanmcl:
+Does it happen only when the mouse is over the text, or even when it's not?
+*** sweeks:
+I missed an important fact in my report -- the flickering was
+occurring on the error that I had the mouse over. So, it being
+(darkish) blue made sense -- the problem was the flicker.  I also
+noticed that the size of the error does not matter. I can hover over a
+small error, whether current or not, and see the flicker.
+
+So, in summary, any error that is hovered over has a flicker, and is
+mostly right color, but ocassionally flickers to the wrong color (the
+non-hover color), except with Alt-Tab, in which case the hover color
+is lost. Perhaps the alt-tab behavior is unavoidable, since perhaps
+the window system tells emacs that the mouse is no longer
+hovering. But I hope the flicker is avoidable.
+
+Clearly very small, since I can just move my mouse to cut off the
+flicker.
+*** moconnor (via pszilagyi):
+Mike noticed this with a single error, latest prod release
+(2012-12-03), and Emacs 24.
+** Only ask to save files under omakeroot
+*** seanmcl:
+Now when compiling it asks about all files
+*** pszilagyi:
+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
+than useful to most users most of the time.  Isn't there a variable to
+flip to turn that off, and just have the error reported and state
+flushed?  Probably easy.
+** Delete trailing blank lines in ocaml files.
+*** mstanojevic:
+Easy.
+* Hold
+* Closed
 ** Make M-q inside a comment leave following code alone
 *** dhouse:
 I have a feeling this has an easy answer but I can't think of it.
       poorly_indented arguments
 Then the "foo" bit can be filled without affecting the following code (presumably because it is now in a new paragraph).
 #+END_EXAMPLE
-
-** Use markers instead of file/line/char triples
-*** seanmcl:
-markers have the nice property that they are updated as the file is
-edited, so Omake.next-error can find an error even if code above the
-error changed.
-
-** omake-mode support for refactoring
-*** sweeks:
-Nathan mentioned to me the excellent idea that we could scrape OMake output to automatically assist with refactoring. For example, suppose one renames module "Foo" to "Bar". Well, then whenever OMake spits out an error "Unbound module Foo", we likely want to replace "Foo" with "Bar" at the point of that error.
-I was thinking that since omake-mode already parses OMake output and understands the structure of OCaml error messages, we could add some emacs functionality to assist with refactoring.
-
-I imagine a function Omake.rename-module that would prompt for the old
-and new module names, and would instruct omake-mode to, when it
-encounters an unbound-module error, rather than display the error in
-the [Errors] buffer, automatically replace the old name with the new
-name in the code. Similarly for Omake.rename-variable.
-
-** pdiff type errors
-*** sweeks:
-For type error messages that we can parse well enough to detect [t1 !=
-t2], it would be cool to display in emacs the pdiff of [t1] and [t2],
-as a way of making it easier for the user to find the source of the
-type error.
-
-** Lift the 50 error limit
-*** seanmcl:
-Improve performance/streaming so that the 50 error limit is no longer
-necessary.
-
-** Show command that caused an error
-*** seanmcl:
-It would be cool to have a keybinding that would let me toggle display
-of the build command that led to the current error message. Maybe the
-keybinding should just be the existing C-c C-h, but that would add a
-new field to the displayed error, "Build command: ..."
-
-** Can't kill project if directory has gone away
-
-*** sweeks:
-I just moved a directory for a project that was building. Now I can
-not kill the project, because omake-mode complains that it cannot set
-the current directory to the now-gone directory.
-
-** Flymake highlighting of errors
-*** seanmcl:
-It would be cool if the tuareg buffer would highlight errors from
-omake. Maybe in the style of fly-make, or maybe with something like
-this:
-
-#+BEGIN_EXAMPLE
-;; Some code that will make it so the background color of the lines that gcc ;; found errors on, should be in another color.
-
-(defvar all-overlays ())
-
-(defun delete-this-overlay (overlay is-after begin end &optional len) (delete-overlay overlay))
-
-(defun highlight-current-line () (interactive) (setq current-point (point)) (beginning-of-line) (setq beg (point)) (forward-line 1) (setq end (point)) ;; Create and place the overlay (setq error-line-overlay (make-overlay 1 1))
-
-;; Append to list of all overlays (setq all-overlays (cons error-line-overlay all-overlays))
-
-(overlay-put error-line-overlay 'face '(background-color . "pink")) (overlay-put error-line-overlay 'modification-hooks (list 'delete-this-overlay)) (move-overlay error-line-overlay beg end) (goto-char current-point))
-
-(defun delete-all-overlays () (while all-overlays (delete-overlay (car all-overlays)) (setq all-overlays (cdr all-overlays))))
-
-(defun highlight-error-lines (compilation-buffer, process-result) (interactive) (delete-all-overlays) (condition-case nil (while t (next-error) (highlight-current-line)) (error nil)))
-
-(setq compilation-finish-function 'highlight-error-lines)
-#+END_EXAMPLE
-** Visual flickering in [Errors] buffer
-*** sweeks:
-With a large error message expanded as the current error, the error
-noticeably flickers between blue and orange, remaining primarily
-blue. The frequency of the flicker is not regular and the interval is
-often less than a second. Also, if I Alt-tab, the error freezes in the
-orange color.
-*** seanmcl:
-Does it happen only when the mouse is over the text, or even when it's not?
-*** sweeks:
-I missed an important fact in my report -- the flickering was
-occurring on the error that I had the mouse over. So, it being
-(darkish) blue made sense -- the problem was the flicker.  I also
-noticed that the size of the error does not matter. I can hover over a
-small error, whether current or not, and see the flicker.
-
-So, in summary, any error that is hovered over has a flicker, and is
-mostly right color, but ocassionally flickers to the wrong color (the
-non-hover color), except with Alt-Tab, in which case the hover color
-is lost. Perhaps the alt-tab behavior is unavoidable, since perhaps
-the window system tells emacs that the mouse is no longer
-hovering. But I hope the flicker is avoidable.
-
-Clearly very small, since I can just move my mouse to cut off the
-flicker.
-*** moconnor (via pszilagyi):
-Mike noticed this with a single error, latest prod release
-(2012-12-03), and Emacs 24.
-** Only ask to save files under omakeroot
-*** seanmcl:
-Now when compiling it asks about all files
-*** pszilagyi:
-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.
-* Hold
-* Closed