Source

js-elisp / todo / TODO.org

   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
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
# -*- mode: org -*-
#+STARTUP: indent

* Notes

Things to think on:

  - How do I submit an issue?
  - How do I comment on an issue?
  - How do I close an issue?
  - How are the maintainers notified when I do any of the above?

** Opening issues

*** Structure

Please use the following structure for issues:

\** SUMMARY
\*** USER:
comment
\*** USER:
comment
...

*** Preformatted blocks

Be careful of * on the front of lines, especially
in omake output.  If there are stars org-mode will think they are
headers.  Either escape the first star on any line of output,
or use an EXAMPLE block that protect stars.

To insert an example block, use

#+BEGIN_EXAMPLE
    block
      with
         structure
      I want
    to keep
    *** omake:
#+END_EXAMPLE

*** Including files

To include a file, say a patch or output, copy the file to this
directory and save the link with double square brackets, e.g.

[[file:todo-files/FILE]]

which makes a link.  Follow the link using C-c C-o `org-open-at-point'.

*** Adding comments

Include your comment at the bottom of the issue/conversation, so they
are in chronological order from top to bottom.

** Closing issues

Hit C-c C-x C-s (org-advertized-archive-subtree) to move the issue to
TODO.org_archive.

* High
** Omake.next-error malfunctions from status buffer
*** pszilagyi:
sweeks discovered that now, in some circumstances, when he hits C-c
C-l in the omake status buffer, it switches to "omake stopped but
there is no error" mode.

This is happening a lot.  We've managed to get it reproduced for me
as well.  What happens, among other things, is that some errors
aren't recognized by omake-server, and if a recognized error is
followed by an unrecognized error, the recognized error persists and
omake-mode thinks it's the current error.  The raw buffer is stalled
until a recognized error comes through, and seems not to relay the
unrecognized error.

Specifically, consider these:

open Core.Std
let () = 13
let f s = Set.remove s (Set.choose s)

Running Omake.compile with the whole thing, then commenting out the 13
line and letting omake recompile, causes an unrecognized error, which
leaves omake-mode using the stale error from the 13 line.
** Ocamlpro indentation
*** seanmcl:
Try to get this to work.
** 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).
** make "k" in projects buffer stay on the current line
*** sweeks:
Pressing "k" to kill a project causes the cursor to go back to the
first line of the buffer.  It should stay on the current line.
* Tests to add
** Fatal errors
*** Missing programs
If one of the following programs are not installed on your path,
we show a fatal error page when you do any interface action.
- omake
- ocamlfind
- omake_server.exe

*** check permissions on files in omake-file.el
;; (defun Omake.File.check-perms (f &optional socket)
;;   ;; Don't worry about readability.  The socket can't be read, so
;;   ;; just consider writability (for uniformity).
;;   (unless (file-writable-p f)
;;     (signal 'Omake.Errors.file-perms (list f))))
;; (mapc 'Omake.File.check-perms
;;       (list
;;        Omake.File.root
;;        Omake.File.top
;;        Omake.File.socket
;;        Omake.File.mode-log-dir
;;        Omake.File.mode-log
;;        Omake.File.server-log))

** Project errors
*** No OMakeroot above default directory

** Automate the release procedure testing
[[file:todo-files/omake-release-procedure.org]]
** After Omake.Connection.open, Omake.Connection.open-p is true.
** After Omake.Server.ensure-running, Omake.Server.running-p is true.

* Medium
** Set a default mail-host-address.
*** pszilagyi:
I had to set my mail-host-address to "janestreet.com" for
add-change-log-entry to work well.  We should probably set this by
default so Emacs mail and log functions work.  We don't use them
much, but this is easy.
** Make interactive tests runnable from the command line
They need a proper exit code.
** Revisit earlier discussion
[[file:todo-files/watcher-discussion]]
** Agda2 inspiration
- Use pipes rather than PTYs?  I found this in agda2-mode.el
  (let ((process-connection-type nil)) ; pipes are faster than PTYs
- (setq process-adaptive-read-buffering t)
- (set-process-query-on-exit-flag agda2-process nil)
- (set-process-filter agda2-process 'agda2-output-filter)

** 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.
** 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 project 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.
** Can't kill project in projects buffer if current directory has gone away
*** pszilagyi:
On a related note, the projects buffer inherits default-directory,
and, if that is deleted, it gives a similar error when you try to kill
any project.  For this, you can kill the projects buffer and recreate
it, and it will inherit your (presumably now existing)
default-directory again.
** save commented-out defaults in ~/.omake-server/config
*** pszilagyi:
Nuffer points out that it was nice having defaults saved, so you could
tell that they were, and what to change.  We have good reasons to not
save the actual default values in the configuration, but we can always
save comments at the top to cover the discoverability.  This is
especially important for ~/.omake-server/config, which can't be
modified by the user through Emacs, only by editing.
** Don't lowercase omake-server configuration values.
*** pszilagyi:
For example, you want to be able to set (omake_command "jomake -j 8
.DEFAULT runtest") in ~/.omake-server/config.
** Back up (and maybe auto-save) files in /tmp, at least.
*** pszilagyi:
Brett had an accident with "cr todo" (editing a temp file), which
makes it pretty clear to sweeks and me that it would be better to back
up (and maybe auto-save) files in /tmp, at least.
backup-enable-predicate is probably the way.
* Low
** Move old readme into texi docs
[[file:todo-files/old-readme]]
*** pszilagyi:
Better not do this until the code structure has stabilized.  Otherwise
the details will still be changing and doc will get stale.
** remove (setq auto-revert-verbose nil) in omake-file.el
;; CR seanmcl: We may be able to fix this by using a custom
;; `revert-buffer-function'.  See autorevert.el
** 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.
** After closing dedicate omake status frame, C-c C-c dies
*** mml
with "Wrong type argument: frame-live-p, #<dead frame Emacs: 0x1d869540>

*** 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 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 could use fuzzy matching via ido-completing-read or sim.
*** mstanojevic via pszilagyi:
So you don't have to know the exact filename.
*** pszilagyi:
Would be nice for core_<module>.ml files.
** 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.

** 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:todo-files/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.

** correctly handling errors in the presence of INCLUDE
*** pszilagyi:
On Thu, Feb 7, 2013 at 10:02 AM, Dan Nuffer <dnuffer@janestreet.com> wrote:
> So I'm using pa_macro to include one file in another (.ml) file.
> Cleverly, pa_macro seems to generate locations for errors correctly
> regarding the source, which the omake server is correctly
> understanding (e.g. if A includes B, and there's an error in the
> included text, Omake.next-error will properly bring me there).  One
> thing that is not working correctly is clearing the errors: it seems
> that if I have an error in the included file, the omake server will
> not stop reporting this error until, I think at least the including
> file compiles (or maybe the whole library or whole project, I'm not
> really sure), whereas I think it should probably clear that error
> out on changes to the included file.
>
> So two questions.  First: did my explanation above actually make
> sense?  Second would this be hard to fix*? (* I am definitely not
> requesting a feature right now, just trying to get a handle on
> this...)

Ah, yes, I think I see what you mean.

I think this is possible, however, it might be be described as hard to
fix.  Basically, it would require to report certain kinds of
dependence information, more than currently reported, through the
chain up to Emacs, so it can know more about which errors to flush as
it sees files successfully compiled.

It may be possible to handle this case specially in omake-server, with
only like 60% of the total work for the general case, or something.

Anyway, this is a good idea.
** 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:todo-files/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
using 110% CPU. There was one other omake_server_test.exe process
running, with arguments "server running", and it was hung not using
CPU, I believe since the time the server started spinning.  The
mode-log for the relevant emacs was last updated at the time the
server started spinning. Here's the tail of the log.

Async   : server ping -counter 511 -pid 29122 -version 13
Read    : (progn (Omake.Server.logf "Server  : (Omake.Ping.ack 511)") (Omake.Ping.ack 511))\n
Eval    : (progn (Omake.Server.logf "Server  : (Omake.Ping.ack 511)") (Omake.Ping.ack 511))
Server  : (Omake.Ping.ack 511)
Read    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))\n
Eval    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
Server  : (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t)
Read    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))\n
Eval    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
Server  : (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t)
Here's the tail of the server log.

[2012-07-25 09:48:20.597985] omake server received: (Ping 29122((version 13)(uid 511)))
[2012-07-25 09:48:20.598030] Writing: (progn (Omake.Server.logf "Server  : (Omake.Ping.ack 511)") (Omake.Ping.ack 511))
[2012-07-25 09:48:20.714021] Writing: (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
[2012-07-25 09:48:21.717247] Writing: (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
I did an strace on the spinning omake server, and didn't see much. I did notice that there weren't any calls to select, other than from the OCaml ticker thread. So async cycles weren't running. That seems to point to an infinite loop within an async job as opposed to an infinite loop continually running new jobs.

*** sweeks
Ron adds that his entire emacs was hung when the problem happened.

*** seanmcl
It would be cool if there were a way to send the server a
message saying 'print a stack trace on stdout'.  Where can I learn
more about the ocaml ticker thread? For example, I don't know how you
inferred your comment about the select calls.

*** seanmcl
Interestingly, there are only two 'let rec' calls in the
entire program. One 'Error.dedup' is obviously terminating by
induction on the input. The second 'Files.omakeroot_dir' walks up the
file name for omakeroot_dir. It is less obvious that it terminates
since it's dealing with a string, and while the string usually gets
smaller, Filename.dirname "/" == "/". But I check for that case, so I
don't see any obvious looping.

*** seanmcl
I'm putting this on hold, since I haven't heard anything in over a month.

*** sweeks
Sam E caused omake-server to spin using 100% CPU several times today. Interestingly, on the last one, while we were looking into it, omake-server stopped spinning, and appeared to continue functioning normally. It now seems likely to me there is a quadratic (or worse) performance issue in omake server's processing of omake output. Regexps are always a good candidate.
Here is the tail of the project-log.

[2012-09-06 11:11:44.481373] New output
[2012-09-06 11:11:44.534868] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
[2012-09-06 11:11:45.034537] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
[2012-09-06 11:11:45.481933] New output
[2012-09-06 11:11:46.536472] New output
[2012-09-06 11:11:51.713523] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 6.1s
[2012-09-06 11:11:55.892051] New output
[2012-09-06 11:11:55.901067] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
[2012-09-06 11:12:14.752257] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 7.3s
[2012-09-06 11:12:32.609426] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 25s
[2012-09-06 11:12:43.124088] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 35s
[2012-09-06 11:12:43.126133] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
[2012-09-06 11:13:07.277727] New output
[2012-09-06 11:13:08.288586] New output
The "omake did not reach EOF for" warnings fit with omake server spinning on something computational, preventing the async file-tail job from getting a chance to run.

The raw buffer is small, 137,361 bytes. However, it has some very long lines (10k characters), further pointing at something superlinear in line length like regexp handling. Here are the line lengths:

41
89
92
89
29
77
16
43
26
48
28
28
28
31
36
25
56
89
24
38
41
7594
115
114
110
188
115
114
110
109
115
114
110
123
32
43
47
43
9714
17
61
89
60
215
32
56
47
56
10048
17
61
89
73
202
32
43
47
43
9996
17
61
89
60
208
32
49
47
49
10020
17
61
89
66
210
32
51
47
51
10028
17
61
89
68
210
32
51
47
51
10028
17
61
89
68
268
45
82
213
46
57
38
57
53
57
10034
23
67
95
74
44
55
38
55
53
55
10026
23
67
95
72
46
57
38
57
53
57
10034
23
67
95
74
38
49
38
49
53
49
10002
23
67
95
66
51
62
38
62
53
62
10054
23
67
95
79
38
49
38
49
53
49
9720
23
67
95
66
41
All the long lines were of the form:

      + ../../../bin/link-quietly ocamlopt.opt ...
where the "..." is lots of -I switches and libraries.

I don't see that omake-server even needs to understand such lines, so
perhaps we could put a simple hack in to just not process them.

*** seanmcl
Yeah, any line may go through 13 regexp calls, some of which
have a number of alternations. I'd rather not tinker with Pcre or the
regular expressions themselves. I like your idea of filtering
problematic lines. I ran the server on a file with very long lines,
but it terminated quickly. There must have been some property of Sam's
particular lines.

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

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

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

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

E.g.:
#+BEGIN_EXAMPLE
                F o o . f o o _ b a r _ b a z  ( )
With M-{f,b }  |   ->  | ->  |  ->   |  ->   | -> |
With C-M-{f,b} |   ->  |        ->           | -> |
#+END_EXAMPLE
*** sweeks:
My understanding is that this is now working, and all that is left to
do here is rename Js.* as Jane.*.
*** seanmcl:
No, house wants something slightly more complex. He wants to have
`forward-sexp' treat _ like a word char and `forward-word' treat _
like punctuation.

** Make ocamlspot work with tramp
*** anon:
Right now, ocamlspot.el is not usable on remote repositories with
tramp, which is very annoying.  Simply applying
s/call-process/process-file/ on the definition of ocamlspot-run-query
made it work for me.
*** valantin:
Actually, it is not quite enough yet. With the previous proposal,
displaying type at point works, but not going to the definition of the
element at point (it tries to open the file on the local machine
instead of the remote one).  If ocamlspot returned relative paths in
its output, I think it would have worked. In any case, I added the
following thing in my .emacs to make it work (I am sure it can be done
in a better way, I never program in elisp):

#+BEGIN_EXAMPLE
;; returns the part of the path that contains the machine name (or "" for a local path)
(defun tramp-prefix-of-path (path)
  (let* ((prev-dir (directory-file-name path))
        (dir (directory-file-name (file-name-directory prev-dir))))
    (while (and dir (not (equal dir prev-dir)))
      (setq prev-dir dir)
      (setq dir (directory-file-name (file-name-directory prev-dir))))
    (substring (if dir dir prev-dir) 0 -1)))

;; the value of filename is the only thing that changed compared to ocamlspot.el
(defun ocamlspot-jump-to-path-range (path-range)
  (if (string-match "^<?\\(.*\\):\\(l[\-0-9]+c[\-0-9]+b[\-0-9]+:l[\-0-9]+c[\-0-9]+b[\-0-9]+\\|[0-9]+:[0-9]+\\|all\\|-1:-1\\)>?$" path-range)
      (let ((filename (concat (tramp-prefix-of-path default-directory) (match-string 1 path-range)))
            (position (match-string 2 path-range)))
        ;; display the result
        (ocamlspot-jump-to-spot filename position)
        (let ((type (ocamlspot-find-val-or-type)))
          ;; (if type (ocamlspot-message-add (format "Type: %s" type)))
          ))
    ;; failed to get the normal result
    ;; CR jfuruse: this is an error message. Should be decolated?
    (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.
** 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.
** OMake Server protocol version mismatch handled confusingly
*** pszilagyi:
sweeks had a strange failure at the last roll.  Part of this was the
combination of moving omake_server.exe (so the old jane-elisp couldn't
even find the new omake_server.exe binary to ping the server or shut
it down), but after restarting Emacs, the new OMake Server binary
seemed to be trying to communicate more than expected with the old
server.  Maybe it could fail more clearly when the version doesn't
match.

One aspect of this is how the Emacs Lisp code handles version
mismatch.  Another is how it finds omake_server.exe.  If the initial
localization code (based on (file-name-directory load-file-name)) took
an absolute pathname, it would resolve the
/j/office/app/emacs/dev/jane-elisp symlink to a particular version,
which would have some good effects, including really allowing a
running Emacs to continue finding binaries and things in the old
release.  This can be dangerous in combination with automount, though.
** global default keybindings
*** pszilagyi:
It would be nice if C-c C-c, etc., worked in other types of buffers,
like Fundamental Mode, etc.  If we add the bindings to the global
keymap, they can show through in the various modes.
** store omake environment variable settings in the repo?
*** pszilagyi:
sweeks was confronted by a change to physical name of his repo clones
losing his existing env variable settings, which live in
~/.omake-server/ID, where ID is the physical name of the hg clone.
In this case, /mnt/local/janevg-data was moved to /mnt/local/sda1 and
symlinks swapped, so the old name still worked as a directory, but
the project ID changed out from under him.

Anyway, this makes you think about the identity of the project and
where project settings should live, and one option is to store them
in a file right in the clone itself, so they are found and stored
independent of the physical name of the project.
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.