profile
viewpoint

startedkonnov/apalache

started time in 5 days

starteddanistefanovic/build-your-own-x

started time in a month

startedbreandan/kotlingrad

started time in a month

startedsquare/javapoet

started time in a month

Pull request review commentrobbyrussell/oh-my-zsh

Fix vi-mode: (control cursor shape, restore visual mode, use visual mode, speed up mode changes)

 VI_KEYMAP=main +function _vi-mode-set-cursor-shape-for-keymap() {+  # https://vt100.net/docs/vt510-rm/DECSCUSR+  local _shape=0+  case "${1:-${VI_KEYMAP:-main}}" in+    main)    _shape=6 ;; # vi insert: line+    viins)   _shape=6 ;; # vi insert: line+    isearch) _shape=6 ;; # inc search: line+    command) _shape=6 ;; # read a command name+    vicmd)   _shape=2 ;; # vi cmd: block+    visual)  _shape=2 ;; # vi visual mode: block+    viopp)   _shape=0 ;; # vi operation pending: blinking block

You're right. It wasn't apparent because it to enter visual mode, you have to first enter vicmd (which works and sets the cursor to a block; but it should have been blinking).

Do you know if there's a reliable way to detect the local modes? Should vi-cmd-mode, visual-mode, visual-line-mode also be wrapped?

erydo

comment created time in a month

starteduptech/alt

started time in a month

starteddandavison/delta

started time in a month

startedantifuchs/chars

started time in a month

startedKindedJ/KindedJ

started time in 2 months

startedarrow-kt/arrow

started time in 2 months

startedcmf/psiviewer

started time in 2 months

startedftomassetti/LangSandbox

started time in 2 months

startedmicrosoft/cascadia-code

started time in 2 months

startedAllenDowney/ModSimPy

started time in 2 months

startedhuggingface/transformers

started time in 2 months

issue commentbanacorn/agda-mode

Unicode input issue

Additional info: This does not appear to be a font issue (at least, not strictly). The text shows up visibly in Vim and my console and they're the same font as in Atom, and changing Atom's font between several common ones like Menlo, Consolas, etc. does not fix the issue.

I've confirmed that Atom is set to UTF-8. I'm beginning to think this might be a purely Atom/Chrome issue (wrt to correctly displaying the combining right arrow). For example, I see squares on this page in Chrome: https://tex.stackexchange.com/questions/171356/using-unicode-combining-right-arrow-above-to-generate-vector-command

So perhaps the "bug" here is just that agda-mode attempts to use that character, which it should reasonably be allowed to do. And the secondary cause is that it prefers that character to the intended superscript r.

buggymcbugfix

comment created time in 2 months

issue commentbanacorn/agda-mode

Unicode input issue

Ok, I have not tracked this issue down but I can provide some additional information and repro steps. I noticed something interesting: clicking the symbol in the input method correctly inserts the character.

Key Sequence UI State
<kbd>\</kbd> text-0 <br> im-0
<kbd>\</kbd><kbd>^</kbd> text-1 <br> im-1
<kbd>\</kbd><kbd>^</kbd><kbd>r</kbd> text-2 <br> im-2
<kbd>\</kbd><kbd>^</kbd><kbd>r</kbd> (Hover) text-3 <br> im-3
<kbd>\</kbd><kbd>^</kbd><kbd>r</kbd> (After click) text-5 <br> im-5

If I select those squares (which select as a single character), copy the value, and paste into xxd:

pbpaste | xxd -

The result is:

00000000: 79e2 8397                                y...

Which is 79 (y) plus a [combining character e2 8397 (COMBINING RIGHT ARROW ABOVE)] (https://www.fileformat.info/info/unicode/char/20d7/index.htm).

The result of the entire editor text is:

00000000: 6964 656e 7469 7479 e283 97ca b3         identity.....

Note that the cab3 is the Unicode of the intended ʳ character.

Interestingly, when I just copied from Atom and pasted into vim, it looks like so:

Screen Shot 2019-09-24 at 9 07 58 PM

Which shows the arrow combining character more clearly.

buggymcbugfix

comment created time in 2 months

pull request commentbanacorn/agda-mode

Add keymap.el to generate keyap asset from Agda emacs-mode

Yep, I saw that repo! For some reason couldn't find the link when I put up this PR, sorry…

The main reason I didn't use that was that its version of the files like agda-input.el are not actually the same as the "real" upstream ones. They require being hand-edited to extract portions of the key mapping code. And e.g. its version of latin-ltx.el in particular would require heavy editing, since the upstream definition uses several computed bindings. Also all of the extensions had already been incorporated into the main agda-input.el, which has gone through a lot of additions over the past few years.

This script loads the actual shipped ELisp modules and dumps the mappings as interpreted by Emacs/Quail, so that the definitions are faithful to the upstream sources of truth. It would definitely be pretty easy to add a hook for further customization by users.

erydo

comment created time in 2 months

pull request commentbanacorn/agda-mode

Add keymap.el to generate keyap asset from Agda emacs-mode

By the way @banacorn — if this isn't an approach you like, that's fine! Just figured I'd submit the PR since I was hacking at this just out of interest related to agda/agda#4104. I was curious how to pull the "actual" mappings out, rather than copying them and re-generating them. It would be nice to package/consolidate these somehow so they could be used with e.g derekelkins/agda-vim#45

erydo

comment created time in 2 months

PR opened banacorn/agda-mode

Add keymap.el to generate keyap asset from Agda emacs-mode

The script loads agda-mode.el and generates both a JSON and JavaScript keymap/query file.

This removes the need for a hand-edited/extracted copy of Emacs agda-mode source, which makes it easier to keep up-to-date with the original mappings. Additionally this includes the inherited mappings from latin-ltx without need for copying them.

The script can be run with npm run keymap-gen, or run with custom arguments like so:

./keymap.el generate --agda-emacs-mode-dir ~/Code/agda/src/data/emacs-mode
+249 -2

0 comment

6 changed files

pr created time in 2 months

create barncherydo/agda-mode

branch : keymap-from-emacs

created branch time in 2 months

delete branch erydo/agda

delete branch : agda-input

delete time in 2 months

push eventagda/agda

Robert Estelle

commit sha 035510f1e41522e31bd75d60c30abf04020590c8

agda-input.el: Add some missing characters Some characters were missing because their numeric Unicode value is out of sequence of the others in that set, because the character might be doing double-duty. This also adds comments for some characters that are just plain missing from Unicode, as of the current standard (12.1), so that nobody else goes on a wild goose chase looking for them.

view details

Robert Estelle

commit sha 29836b03cfd7779b22b6cb186b0a8a0147bc3487

agda-input.el: Add some missing characters (#4104) agda-input.el: Add some missing characters

view details

push time in 2 months

PR merged agda/agda

agda-input.el: Add some missing characters agda-mode emacs unicode

Some characters were missing because their numeric Unicode value (code point) is out of sequence of the others in that set. However for those characters, the reason is that those characters are doing double-duty, rather than being actually omitted from the sequence.

This also adds comments for some characters that are actually just plain missing from Unicode, as of the current standard (12.1), so that nobody else goes on a wild goose chase looking for them when they notice that some letters are skipped.

+31 -0

0 comment

1 changed file

erydo

pr closed time in 2 months

PR opened agda/agda

agda-input.el: Add some missing characters

Some characters were missing because their numeric Unicode value is out of sequence of the others in that set, because the character might be doing double-duty.

This also adds comments for some characters that are just plain missing from Unicode, as of the current standard (12.1), so that nobody else goes on a wild goose chase looking for them.

+31 -0

0 comment

1 changed file

pr created time in 3 months

create barncherydo/agda

branch : agda-input

created branch time in 3 months

starteddylanaraps/pure-bash-bible

started time in 3 months

issue commentagda/agda

Feature request: reflecting abstract syntax

Just for reference/discussion to a previous related (or duplicate) issue about this:

  • Issue #3849: Syntax macros / delay type-checking of macros
jespercockx

comment created time in 3 months

starteddfm/gp

started time in 3 months

startedjohn-h-k/MathSharp

started time in 3 months

PR closed agda/agda

Reviewers
[travis] Cache additional directories status: work-in-progress travis

The path list was taken from Stack's suggested set here: https://github.com/commercialhaskell/stack/blob/bbfefa49e0960f6ac368a6e4dfc4dbbc192a3944/doc/travis-complex.yml#L17-L23

Travis documentation on caching here: https://docs.travis-ci.com/user/caching/

The caches are specific to each branch/PR and to each job within it, so the blast radius of caching issues should be very small.

It is possible that aggressive caching could cause problems, if, for example, a dependency builds badly at some point, or if something goes wrong with GHC/stack's/cabal's dirtiness detection. The fact that Stack's repo includes these as their example gives me some confidence, though, and if it does cause problems the cache can be easily cleared. (Go here: https://travis-ci.org/agda/agda/caches)

It's possible it would be a good idea to clean them up more or tar them up, as they do here: https://github.com/haskell-suite/haskell-src-exts/blob/e0f2aa86d68b993f0a81633af467dc550b3e7270/.travis.yml But I haven't looked into that. It would depend on how big those caches turn out to be.

+30 -12

4 comments

1 changed file

erydo

pr closed time in 3 months

pull request commentagda/agda

[travis] Cache additional directories

Closing this because so much work has been done on the travis build in the meantime, and I haven't had time to pay attention to this recently.

erydo

comment created time in 3 months

PR closed agda/agda

[travis/make/cabal] Use correct BUILD_DIR in initial install status: work-in-progress travis
  • The first install with Cabal (make … install-bin) did not have BUILD_DIR set. But I think it should have, and may have been duplicating work because of this. (NOTE: View only the first commit to see this line, because subsequent change allowed that variable to come from environment anyway, making the line technically unchanged).
  • Every (other) invocation of make explicitly passed BUILD_DIR in, despite having that exported as an env var. They needed to do this because the Makefile would override the environment variable.
  • Now, the Makefile respects the env var if it's exported and non-empty.
+24 -21

1 comment

2 changed files

erydo

pr closed time in 3 months

startedminimaxir/gpt-2-simple

started time in 3 months

startedprzemoc/metastore

started time in 3 months

issue commentmoby/buildkit

invalid not-modified ETag with local network ADD in docker

I believe this can be closed now that #1159 is merged in. Not sure why GitHub didn't close this one when that was merged.

NateBu

comment created time in 3 months

startednuno-faria/tiler

started time in 3 months

startedEmbarkStudios/texture-synthesis

started time in 3 months

startedcuelang/cue

started time in 3 months

startedbenedekrozemberczki/graph2vec

started time in 3 months

more