This can be done manually by selecting a region, running shell-command-on-region, and choosing dhall. It would be a nice explicit addition to this package though if there were to be interactive functions dhall-eval-region and dhall-eval-buffer.

First of all, thanks for writing this package! I seem to be having an issue where, while I'm typing, as long as the expression is invalid (which is almost always true while typing), the error buffer pops up and also takes focus away. I have to hit Esc to close the error buffer and get back to typing.

If it helps, I'm using Emacs 26 with EVIL mode.

I get this error currently

Error running timer ‘dhall-buffer-type-compute’: (wrong-type-argument stringp nil)

with

(setq debug-on-error t)

I get to see

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("↳" nil nil)
  dhall-buffer-type()
  dhall-buffer-type-compute()
  apply(dhall-buffer-type-compute nil)
  timer-event-handler([t 23511 2211 494750 nil dhall-buffer-type-compute nil nil 157000])

any idea? - don't know if this is related to issue #18
thanks.

This would significantly improve time for typechecking.

How do I do this? dhall format uses spaces but this plugin uses tabs-- any idea why this is?

Unlike the dhall format support, a quick scan of the code makes me think that the repl support unconditionally looks for dhall-repl instead of trying to run dhall repl.

I notice that dhall-buffer-type-compute-timeris run after every change to set a variable that is used in the header line. This seems like it isn't needed when dhall-use-header-line is nil because it won't be displayed anywhere. In fact, even on moderately large files, type computing can be really expensive and make the buffer unusable. It seems to me this timer should not even be run if the type won't be used.

Also a lower priority but it seems like there could be some control over the debouncing feature you have which is currently hardcoded to 1 second right now for cases when you do want the type but you don't want to run it as frequently so it doesn't lock up the editor.

Let me know if you'd be amenable to these changes. I'm not an elisp expert but I could give it a shot.

I'm loving dhall-mode so far, thank you for it. The auto-reformatting is very convenient, but I've noticed that it's a bit over-zealous when it comes to comments. Comments at the very top of the file seem to stick around, but formatting will remove any others. This makes it hard to annotate type fields, etc.

Is there any way around this? Thank you.

When I save a dhall file and it gets reformatted, the trailing newline gets deleted, so I end up with git-diff saying

...
+}
\ No newline at end of file

The code

''
"''${FOO}"
bar
''

Isn't getting highlighted properly. The bar should still be inside the string.

Short of digging into dhall-lsp-server, the cheapest option I could find to hop between files was:

(defun jump-to-file-at-point ()
  (interactive)
  (ring-insert find-tag-marker-ring (point-marker))
  (find-file-at-point))

The type of the expression in a file can be captured with a command like

dhall --plain <<< $file 2>&1 >/dev/null

This can be used in header-line-format to always display the type at the top of the window.

It should also display a reasonable message when 1. there is an error or 2. the type is too large[†].

(I might do this myself, but wanted to open the issue as a reminder until I get to it.)

[†]: Maybe some day there will be a way to acquire a shorter type without it expanding all the aliases and imports along the way.

See dhall-lang/dhall-haskell#452

I'll try to remember to look into this, but I don't write any emacs lisp myself. Hopefully I can just find some docs sometime to figure out if I only need to pass a singleton arg list.

E.g. spago uses ascii formatting, so having them clash is annoying.

I have a massive dhall configuration that takes almost 30 seconds to "type check" in emacs, but only takes a few seconds to type check when loading into my application.

Upon further investigation, it looks like the command this mode runs is cat <buffer> | dhall resolve | dhall type. Why is resolve necessary? My understanding of this pipeline is that it will read dhall expression, replace all imports with their dhall expressions, and then get the type of this expression. dhall type appears follow imports on its own when evaluating the type, thus skipping the creation of a potentially huge expression.

I did some quick benchmarks on my own data, and (at least in my case) taking out the resolve step results in the exact same output with 11.5x speedup:

> time cat main.dhall | dhall resolve | dhall type > /tmp/both.out
cat main.dhall  0.00s user 0.00s system 82% cpu 0.003 total
dhall resolve  4.96s user 0.22s system 99% cpu 5.181 total
dhall type > /tmp/both.out  21.89s user 0.47s system 81% cpu 27.423 total

> time cat main.dhall | dhall type > /tmp/type.out
cat main.dhall  0.00s user 0.00s system 82% cpu 0.004 total
dhall type > /tmp/type.out  2.43s user 0.15s system 99% cpu 2.592 total

> diff /tmp/both.out /tmp/type.out
<nothing>

> dhall --version
1.41.2

Hi! I've been using and enjoying dhall-mode but I was wondering if it would be possible to add an option that when toggled on would suppress the dhall error buffer. It replaces one of the existing buffers if you have multiple buffers per window and it can be kind of disruptive to your workflow. In the mean time I'm planning on wrangling the buffer with popwin so that it always creates a new buffer that can be easily dismissed, e.g. ("*dhall errors*" :height 10 :noselect t :stick t :tail nil)