<veltas>
emacs takes too long to start, that's the real issue, and no text editors shouldn't be daemons
clog has quit [Ping timeout: 260 seconds]
<lispmacs[work]>
I use emacs a lot, but I've felt for a long time that Emacs should be designed so as to allow one to compile a much more minimal core
<lispmacs[work]>
down to core editing/display functionality, and a core lisp engine
<lispmacs[work]>
there are lots of very minimalistic emacs clone text editors available, but none of them have any kind of lisp engine included, so far as I know
<crc>
I don't want to use a 15mb+ text editor
<crc>
Also, the key combinations it likes are painful; I'd need to devise new key maps to accommodate them in a better manner
<crc>
(The only modifier on my main keyboard layout is control, which isn't conducive to using emacs)
<veltas>
I like emacs shortcuts, but there is evil plugin for vim-style emacs if people want it. The bloat and performance are the big issues
<veltas>
I am not surprised if some forthers use emacs given the crossover we seem to have with lispers
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 240 seconds]
<crc>
I used vi for a while, but stopped due to difficulty with using with dvorak
X-Scale` is now known as X-Scale
* crc
will eventually be using an editor written in forth as his primary editor...
<veltas>
That's the dream
<crc>
I'll achieve it this year I think
<crc>
I have a mostly complete line editor (e.g., ed) now, and aam starting to consider how to add a visual mode to it
<veltas>
This is where my head programming is right now, my design is to try and make an ed-style editor have a bare basic visual mode
<veltas>
Just as simple as writing it all down! /s
<veltas>
Good luck with that and I'll definitely try it when it's working
<crc>
I'll let you know
PDogJr has left #forth ["Leaving"]
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
zolk3ri has joined #forth
* Zarutian_HTC
uses pico if he has to use an text terminal, otherwise TextMate, BareBonesEdit, notepad++, or notepadqq (nodepad++ but compiled with minimal wine into it)
<Zarutian_HTC>
and that is for plain text
<Zarutian_HTC>
otherwise I use more specialized editors such as vscode or other such near Squeak/Smaltalk80 IDE tools
<Zarutian_HTC>
qemu + gui like debugger interface with back stepping is something I covet
* Zarutian_HTC
really likes how vscode can discover doctype info from @ prefixed comments using tscode techniques
<crc>
Other than my editor-in-procress, I mostly use pico or nano, except on iOS, where I use Textastic.
Zarutian_HTC1 has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
<remexre>
Zarutian_HTC1: do you know if qemu -s works with rr?
<Zarutian_HTC1>
dont know what rr is in this context
<Zarutian_HTC>
I have mainly used qemu for emulation of mips and other mid size MCUs
<Zarutian_HTC>
and often code that does not use the c calling conventions nor ever was output from a c or c++ compiler
<remexre>
I've been using it for AArch64, and after hooking it up conveniently to gdb + writing a bunch of gdb commands as an extension to dump forth state, it works like a charm
<remexre>
very much not following C ABI in my project either
<Zarutian_HTC>
many c/c++ debuggers I had come across choke if the stack pointer register isnt being used for framed stacks
<Zarutian_HTC>
gdb usually just works
<Zarutian_HTC>
but man, ghidra is such a nice thing to use on multi arch flash dumps
<remexre>
huh, I didn't find it super-helpful the one time I tried it, though it was on a stripped version
<remexre>
might give it another shot though (probably will need something stronger than gdb once I write an optimizer, anyway)
<Zarutian_HTC>
well, having reverse engineered the electronic circuits in the device and adding hints that ghidra can read, it is better than most
<remexre>
ah yep, that's something I definitely haven't even thought about doing
<Zarutian_HTC>
gleaning which mcus and such were being used, what was connected to which ports etc
<Zarutian_HTC>
and subroutine structures often reveal what purpose they have even if I never knew their original names
<Zarutian_HTC>
but do you know what is underhanded? executables that have been stripped and then fake section info added
<remexre>
oof
<Zarutian_HTC>
stuff like symbol tables that nearly make sense, but only isolation
<Zarutian_HTC>
only in*
<remexre>
do you think that's that like, intentional anti-reverse-engineering, or something closer to "30-year old perl script that generates linker scripts"
<Zarutian_HTC>
I can never be sure. Might be the latter used for the former
<Zarutian_HTC>
pretty sure that who ever made the executable just wanted to fuck with people
<Zarutian_HTC>
found stuff like clueless software agent basic construction in it
<remexre>
uh like basic the lang? that sentence doesn't totally parse to me :P
<Zarutian_HTC>
nope like a thing that takes data from the environment, sha256 hashes it, uses that result as an aes decryption key on an included ciphertext, sha256 hashes the resulting plaintext and if that matches a given constant, jumps into the plaintext
<remexre>
uhhhhhhhhhh
<Zarutian_HTC>
basically an encrypted section of the program that can only be decrypted in the right environment
<remexre>
I'd sorta imagine it'd be less of a pain to just load the decryption key from a tamper-resistant rom
<remexre>
but ig idk how expensive those are
<Zarutian_HTC>
nono, that wasnt it purpose
<Zarutian_HTC>
let say the executable was for a worm.
<Zarutian_HTC>
the encrypted section could only be decrypted and run on the target machine
<remexre>
sure, but if it's vendor-provided code, they could just stick a rom on the board, right?
<remexre>
instead of having to collect all sorts of environment info
<Zarutian_HTC>
naah this was from a malware found in one of the backup servers used at electronics repair shop