<geri>
i just noticed @lib/tinymce.l has a readme at the end of the file; does NIL on top level make the rest of the file into a comment?
<geri>
also i only learned yesterday that vip is made of only ansi escape sequences XD
<abu[7]>
pablo_escoberg: Yes, highlighting is done only in 'addLine'. But the classification of the characters of a line is done in 'markup'
<abu[7]>
geri: Yes, reading NIL is EOF
<abu[7]>
This used in many files in the form `*Dbg
<abu[7]>
Vip war ncurses first, but I noticed that ncurses are a real mess
<geri>
i remember that :D
<geri>
are escape codes *not* a mess?
<abu[7]>
Much better :)
<geri>
are they now? :D
<geri>
i mean, i use em often, but i hadnt used cursor movement ones
<abu[7]>
Ncurses is a version mess
<geri>
ah, like that
<abu[7]>
And, more important, the code of Vip is a lot simpler without curses
<abu[7]>
Though perhaps a bit slower
<abu[7]>
but that's not the bottleneck
<geri>
its a good question whether or not its slower
<geri>
you could try comparing older to newer version for large files or something
<geri>
or maybe check latency on key press
<geri>
check like without tools, just what feels faster :D
<abu[7]>
It is not the file size (that's a bottleneck for Vip itself) but probably the screen size
<abu[7]>
Ncurses is optimized for screen output
<abu[7]>
So on a serial, slow, terminal it would be significant
<geri>
i know all refreshes are explicit
<geri>
almost all
<geri>
wrote tetris in cl w/ curses :)
<abu[7]>
ok, so you know
<geri>
that its pretty hard to manage the screen objects? yeah xd
<geri>
(or pointers in this case, you get the idea)
<abu[7]>
T
<geri>
can you print characters at particular coordinates with escape codes?
<geri>
like top left cell of the terminal, or exact middle using some math, etc?
<abu[7]>
Yes
<geri>
i think you can then do the same optimized outputs by only changing what's under the cursor/getting changed
<geri>
like if i press l, i have to rewrite current cell to be proper face, then rewrite next cell and that's p much it, rest of output shouldnt be touched
<geri>
its probably +- how its done rn
<abu[7]>
Yes, but it is not worth the effort on fast terminals
<geri>
so how does screen update rn on mouse movements?
<abu[7]>
(it used to be on 9600 baud)
<geri>
cursor**
<abu[7]>
[lib/term.l
<abu[7]>
@lib/term.l
<abu[7]>
Very simple
<abu[7]>
'cup' positions the cursor
<geri>
94 lines? woah
<geri>
there's a modal text editor in pure bash
<geri>
thats probably the same strategy as there
<abu[7]>
nice
<geri>
im kind of inspired to write my own
<geri>
:D
<abu[7]>
Good idea π
<geri>
~/.pil is hardcoded everywhere right?
<abu[7]>
Yes, several places I think
<geri>
eh
<geri>
i know its a unix tradition but i dont like cluttered $HOME
<geri>
bash and sbcl are other offenders!
<abu[7]>
Yeah, but it is very convenient
<geri>
nowadays home is a fallback location, configs go to $XDG_CONFIG_HOME or ~/.config, cache goes to $XDG_CACHE_HOME or ~/.cache
<abu[7]>
~/.config is also in HOME
<geri>
yeah, but 1 directory vs 1 per program you use
<abu[7]>
Problem is on embedded systems where home is not writable
<geri>
if that was in ~ id die
<geri>
even better
<geri>
you can add overrides using $PIL_HOME or something
<geri>
then if home isnt writable they can move it and if you dont like ~/.pil you can too
<geri>
)
<geri>
env var cause no chicken and an egg problem of "all of my dotfiles are located here, but i need ~/.pil/config to actually know where it is"
<abu[7]>
Many ways
<geri>
yeah
<geri>
i could write it myself honestly, if the idea is okay
<geri>
i think this is simpler than supporting all the XDG_*_HOME variables by default, checking if you gotta put it in home anyway and then finding out its not writable ahaha
<abu[7]>
I would change 'UsrHome' via 'struct', or just set HOME before starting pil
<geri>
won't it mess with (path "~/file")?
<geri>
and (sys "HOME") if you need it
<abu[7]>
'path' uses $UsrHome
<abu[7]>
H
<abu[7]>
H
<abu[7]>
'struct' is not usable here
<abu[7]>
We don't know the addsess
<geri>
hm
<geri>
is UsrHome available at runtime?
<abu[7]>
Not easily
<abu[7]>
I don't see any real problem
<geri>
well, you said it yourself about non-writable home problem on embedded devices
<abu[7]>
You need some writable space
<geri>
(mightve misunderstood)
<abu[7]>
s
<abu[7]>
Yes
<abu[7]>
but you have other writable space
<abu[7]>
so set HOME before start
<geri>
hmmmmmm
<geri>
i guess then youll be hardcoding paths to files in actual home if you need them
<geri>
but thats a somewhat niche issue
<geri>
or set a "home" variable which points to actual home
<geri>
nasty but it works
<geri>
do you use 'call often in prod apps?
<abu[7]>
Not sure, probably more often 'in', 'out' or 'pipe'
<geri>
i meant more about using external programs, if forgot in can call them too