(Thanks, @mrjbq7!) Now:
+ `CHAR:` literals highlight the whole next token.
+ `0b...` binary literals don't require invalid `+=0b` or `-=0b` syntax.
+ Float literals can't start with a `,` separator.
+ Float literals can have exponents with `,` separators.
+ `foo: ...` stack effects function as intended in general.
+ Syntax clusters might be a bit cleaner with `g:factor_syn_no_error`.
+ Error match priority should be cleaned up.
(Thanks, @mrjbq7!) Now:
+ `CHAR:` literals highlight the whole next token.
+ `0b...` binary literals don't require invalid `+=0b` or `-=0b` syntax.
+ Float literals can't start with a `,` separator.
+ Float literals can have exponents with `,` separators.
+ `foo: ...` stack effects function as intended in general.
+ Syntax clusters might be a bit cleaner with `g:factor_syn_no_error`.
Also fixes comments in a lot more places than a few commits ago.
Syntax like the following is proper, and the comment highlighting fixes
from last commit make the incorrect highlighting here really stand out:
```factor
USE: ! only this line highlights
kernel
```
From Vim's |pattern.txt|, |/\v| |/\V|:
> Use of "\v" means that after it, all ASCII characters except
> '0'-'9', 'a'-'z', 'A'-'Z' and '_' have special meaning: "very magic"
This mostly makes some upcoming syntax pattern refactoring cleaner,
though most patterns still get shorter here.
This lets Factor's overly long line highlighting avoid bleeding over
into documentation source buffers, or buffers of other non-Factor file
types entirely. Also, by taking `:2match` instead of `:match`,
clobbering of most user matches (or vice versa) can be avoided.
Unfortunately, the highlighting effects all windows in a multi-buffer
split setup, but since we can't reasonably make this a `:syntax match`
group, it'll have to do. (And this behavior isn't new.)
I recently got a Model F keyboard and the arrow keys weren't mapped.
To see the keycodes on Linux:
```
IN: ui.backend.x11.keys
: code>sym ( code -- name/code/f action? )
dup . flush
dup codes at* [ nip dup t and ] when ;
```
Also try ``USE: gesture-logger``
This adds the shell function `wrapFactor`. This function is intended to wrap
the result of calling `build.sh` in the shell environment so it can be executed
outside of the nix shell.
Example:
```
$ nix-shell
[nix-shell] $ ./build.sh bootstrap
...build factor vm and image...
[nix-shell] $ wrapFactor .
exit
$ ./factor
```
`wrapFactor` takes the path to the factor root dir as argument, and expects the
binary `factor` and the image file `factor.image` there and uses Nixpkgs'
`makeWrapper` to wrap the `factor` executable in-place with the correct
`LD_LIBRARY_PATH`. Afterwards, the factor executable can be called outside of
the nix-shell environment.
This could still be improved since this current approach pauses Factor
execution when the window is being resized, and it could instead
maybe detect inLiveResize or something and be smoother.
John Benediktsson
Doug Coleman
Dusk
timor