2026-06-24 02:16:19 <Stalevar    > : square does> drop dup * ; ok : sq ; ok 6 sq . 6  ok 6 square . 6  ok 6 sq . 36 ok
2026-06-24 04:28:26 <tabemann    > Stalevar, what are you doing with DOES> without CREATE (ANS) or <BUILDS (zeptoforth, Mecrisp-Stellaris)?
2026-06-24 04:29:17 <Stalevar    > tabemann, gforth
2026-06-24 04:30:06 <Stalevar    > raw does> overwrite code of last defined word
2026-06-24 04:30:11 <tabemann    > I'm surprised that doesn't cause a crash
2026-06-24 04:31:32 <tabemann    > in zeptoforth at least DOES> requires <BUILDS, as it is designed for being able to compile to flash, and you can't simply overwrite a word when compiling to flash
2026-06-24 04:31:33 <Stalevar    > I can even run does> drop dup * ; to make last compiled word square the number
2026-06-24 04:32:53 <tabemann    > then the question is, why on earth would you want to do that with anything other than CREATE (ANS) or <BUILDS
2026-06-24 04:33:43 <tabemann    > the whole point of DOES> is so you can write things like : make-adder create , does> @ + ;
2026-06-24 04:34:06 <tabemann    > or, in zeptoforth or Mecrisp-Stellaris, : make-addr <builds , does> @ + ;
2026-06-24 04:34:52 <tabemann    > *make-adder
2026-06-24 04:35:09 <tabemann    > so that you can then execute, say, cell make-adder cell+
2026-06-24 04:36:16 <Stalevar    > I was just trying to understand what DOES> does
2026-06-24 04:36:23 <tabemann    > of course, in zeptoforth you're better off writing : make-adder { x -- } : x postpone literal postpone + postpone ; ;
2026-06-24 04:36:48 <tabemann    > as that will generate faster code
2026-06-24 04:38:02 <Stalevar    > It doesn't crash zeptoforth, it said no word is being built and even colors it red (how did it know what terminal was behind ttyACM0? )
2026-06-24 04:39:53 <tabemann    > it doesn't know, it just assumes that all terminals in this day and age support ANSI
2026-06-24 04:40:31 <Stalevar    > If it was cmd in windows 8.x or earlier it wouldn't?
2026-06-24 04:40:55 <tabemann    > it assumes that people aren't actually using VT52's or Windows 8
2026-06-24 04:41:16 <Stalevar    > anyway, those probably will just print garbage instead of crashing
2026-06-24 04:41:27 <tabemann    > yeah
2026-06-24 04:41:41 <tabemann    > you'll see the ANSI color codes
2026-06-24 04:42:30 <iv4nshm4k0v > ... And that the programmer doesn't ever use script(1) to capture the interactive session in a /readable/ form...
2026-06-24 04:42:37 <Stalevar    > I don't get why some forths use create and other <builds
2026-06-24 04:43:22 <Stalevar    > tabemann, what does raw create do in mecrisp and zepto?
2026-06-24 04:44:16 <tabemann    > Stalevar, the reason why zeptoforth uses <BUILDS with DOES> is that DOES> can't overwrite a word once it's compiled to flash, so it needs a special "empty" word to be created
2026-06-24 04:44:23 <Stalevar    > In Gforth it would take next word from input buffer and put it into dictionary, while following does> fills its code section, as far as I understand
2026-06-24 04:44:28 <tabemann    > raw CREATE, though, is used for creating constant arrays
2026-06-24 04:45:00 <tabemann    > iv4nshm4k0v, you can turn off colors in zeptoforth if you want
2026-06-24 04:45:32 <Stalevar    > tabemann, by the way how does it know width of my terminal window?
2026-06-24 04:45:46 <tabemann    > if you want to allocate a block of memory as a buffer, though, the recommended approach is to use BUFFER:
2026-06-24 04:46:11 <Stalevar    > Many command line apps would break when run through ttyS / ttyUSB / ttyACM because they don't know the window size
2026-06-24 04:46:12 <tabemann    > Stalevar, it does by trying to move the cursor to an absurd coordinate, and then reading the actual cursor coordinate
2026-06-24 04:46:52 <tabemann    > however, WORDS and company assumes that the terminal is 80 characters wide unless told otherwise
2026-06-24 04:46:55 <Stalevar    > can I ask zeptoforth window size to see if it works?
2026-06-24 04:48:30 <tabemann    > Stalevar, execute ANSI-TERM::GET-TERMINAL-SIZE ( -- rows columns )
2026-06-24 04:50:44 <Stalevar    > $ stty -a
2026-06-24 04:50:44 <Stalevar    > speed 38400 baud; rows 31; columns 122; line = 0;
2026-06-24 04:52:11 <tabemann    > one thing is that it breaks if you try to use it with a "terminal" that doesn't support reading the current coordinate
2026-06-24 04:54:06 <Stalevar    > Actually, zeptoforth sends awful lot of ansi controls, it seems
2026-06-24 04:54:27 <tabemann    > if you're using ENABLE-LINE it sends them every line
2026-06-24 04:55:21 <tabemann    > if you're not using ENABLE-LINE it only sends ANSI proper when changing colors, but it also sends ACK at the end of a line and NAK if there is an error (along with a BEL)
2026-06-24 04:55:31 <tabemann    > mind you, all of these things can be turned off
2026-06-24 04:55:47 <Stalevar    > Yeah, I compiled enable-line to flash.
2026-06-24 04:56:48 <Stalevar    > Also my zeptoforth dongle doesn't light the LED up, unlike when it was micropython, but it was too bright.
2026-06-24 04:57:44 <tabemann    > what GPIO is the LED on?
2026-06-24 04:57:53 <tabemann    > and also, is it active high or active low?
2026-06-24 05:00:42 <Stalevar    > https://pastebin.com/raw/aNQC06pX
2026-06-24 05:01:01 <Stalevar    > That's main.py from when it run micropython
2026-06-24 05:02:29 <Stalevar    > can it light up a little to indicate power is on without blinding?
2026-06-24 05:04:18 <tabemann    > it's using a WS2812; for that there is extra/rp_common/neopixel.fs
2026-06-24 05:05:47 <tabemann    > Stalevar, yes, by setting the colors to something dim
2026-06-24 05:05:53 <Stalevar    > Is it already in image 16m full?
2026-06-24 05:06:40 <tabemann    > no, you have to load it yourself, as with all things in extra/ (except for things, which this is not one of, installed by the PicoCalc installers, if you're using a PicoCalc)
2026-06-24 05:12:22 <Stalevar    > OK, disable-line, paste, enable-line; it has  : init-neopixel { init-sm init-pio init-count init-pin addr -- }  ok
2026-06-24 05:12:59 <Stalevar    > I guess I need to provide some numbers and call init-neopixel
2026-06-24 05:13:18 <tabemann    > use -1 for init-sm and init-pio
2026-06-24 05:13:50 <Stalevar    > What about init-count and init-pin?
2026-06-24 05:14:01 <Stalevar    > and addr of what?
2026-06-24 05:14:22 <tabemann    > addr is the address of a BUFFER: of NEOPIXEL::NEOPIXEL-SIZE ( count -- bytes )
2026-06-24 05:14:58 <tabemann    > init-count is the number of neopixels in a string you're supporting -- for your board it will be 1
2026-06-24 05:15:23 <tabemann    > init-pin is the GPIO index for the GPIO you have your neopixel hooked up to
2026-06-24 05:16:29 <Stalevar    > Python mentions 17 and 25 GPIO
2026-06-24 05:16:39 <tabemann    > one might be power
2026-06-24 05:16:58 <Stalevar    > led_onboard2.value(1)
2026-06-24 05:17:09 <Stalevar    > So 25 is power
2026-06-24 05:17:25 <Stalevar    > And how do I get 25 on in this?
2026-06-24 05:18:22 <tabemann    > yeah
2026-06-24 05:19:18 <tabemann    > 25 PIN::OUTPUT-PIN PIN::HIGH 25 PIN::PIN!
2026-06-24 05:28:19 <tabemann    > or just import PIN and  then later 25 OUTPUT-PIN HIGH 25 PIN!
2026-06-24 05:31:01 <Stalevar    > create npxbuf 20 allot  ok
2026-06-24 05:31:15 <Stalevar    > 25 pin::output-pin pin::high 25 pin::pin!  ok
2026-06-24 05:31:15 <Stalevar    > -1 -1 1 17 npxbuf neopixel::init-neopixel  ok
2026-06-24 05:31:21 <Stalevar    > Nothing visible happens
2026-06-24 05:31:48 <tabemann    > you need to call npxbuf neopixel::update-neopixel
2026-06-24 05:32:24 <Stalevar    > Still nothing
2026-06-24 05:33:19 <tabemann    > also, the CREATE ... ALLOT idiom is deprecated in zeptoforth
2026-06-24 05:33:43 <tabemann    > the proper way to do it is: 1 NEOPIXEL::NEOPIXEL-SIZE BUFFER: NPXBUF
2026-06-24 05:34:55 <tabemann    > hmm... just realized something
2026-06-24 05:35:09 <tabemann    > I've never tried this code with an RP2350, so the clock divider is probably off
2026-06-24 05:35:47 <tabemann    > the only board I have with a WS2812 is an RP2040 board
2026-06-24 05:38:20 <Stalevar    > can I test if it works without neopixel module? Let's set it to full brightness or something
2026-06-24 05:39:09 <tabemann    > try editing the neopixel module to fix the clock divider
2026-06-24 05:39:56 <Stalevar    > \ 8000000 Hz ?
2026-06-24 05:40:00 <tabemann    > the key line is     160 15 init-sm init-pio sm-clkdiv! \ 8000000 Hz
2026-06-24 05:40:35 <Stalevar    > 8 MHz, and so?
2026-06-24 05:40:53 <Stalevar    > set it to 12MHz ?
2026-06-24 05:41:01 <tabemann    > the problem is it's dividing the system clock, and the RP2350 by default has a faster system clock than the RP2040
2026-06-24 05:41:11 <tabemann    > but this code was originally written for the RP2040
2026-06-24 05:41:58 <tabemann    > pio::sm-clkdiv! ( fractional integral state-machine pio -- )
2026-06-24 05:44:52 <Stalevar    > 25 pin::output-pin pin::high 25 pin::pin!  ok
2026-06-24 05:44:52 <Stalevar    > import neopixel stack underflow
2026-06-24 05:44:53 <Stalevar    > 100 100 100 0 npxbuf neopixel!  ok
2026-06-24 05:44:55 <Stalevar    > npxbuf update-neopixel  ok
2026-06-24 05:44:57 <Stalevar    > Still nothing
2026-06-24 05:45:18 <Stalevar    > I have replaced 8 with 12 because crystal on my board said 12.000 MHz
2026-06-24 05:45:39 <tabemann    > nah
2026-06-24 05:46:18 <tabemann    > the WS2812 PIO program expects to be clocked at 8 MHz
2026-06-24 05:46:30 <tabemann    > this has nothing to do with the crystal on your board
2026-06-24 05:46:43 <tabemann    > the problem is the system clock is faster than this code expects
2026-06-24 05:47:24 <Stalevar    > It is running PWM on the GPIO to lower the intensity, right?
2026-06-24 05:47:43 <Stalevar    > How do I just run it full on to se if I can get leds to light up at all?
2026-06-24 05:49:02 <tabemann    > the system clock of the RP2350 by default is 150 MHz, whereas for the RP2040 it is 125 MHz
2026-06-24 05:49:15 <tabemann    > don't use PWM for this, it won't work
2026-06-24 05:49:51 <tabemann    > the problem is the clock is wrong, so the WS2812 isn't working right
2026-06-24 05:50:40 <Stalevar    > So it's overly smart led, I thought it were just three leds in one package
2026-06-24 05:54:00 <tabemann    > no
2026-06-24 05:54:24 <tabemann    > you encode the color in a signal sent on a single wire to the LED
2026-06-24 05:54:39 <Stalevar    > I can see darker spot in the middle. Could I have already killed the LED thing?
2026-06-24 05:55:15 <tabemann    > nah, you wouldn't've killed it
2026-06-24 05:55:24 <Stalevar    > The led module has four legs
2026-06-24 05:55:56 <tabemann    > yes, data in, data out, power in, and ground
2026-06-24 05:56:19 <tabemann    > the reason why there's a data out is that this is used to string multiple LED's together
2026-06-24 05:56:31 <Stalevar    > It has data out? Hmm... what data can it send? It's just led block
2026-06-24 05:57:18 <Stalevar    > So data out should be unused
2026-06-24 05:58:21 <tabemann    > no
2026-06-24 05:59:01 <tabemann    > each time you send a pixel value to its data in, it sends its current pixel value to its data out
2026-06-24 05:59:56 <tabemann    > this is why you can string multiple WS2812's together
2026-06-24 06:00:13 <tabemann    > because you attach each one's data out to the next one's data in
2026-06-24 06:00:57 <Stalevar    > So you send data to last one, then pre-last one and so on and to first one, it will consequtively pushed down the line?
2026-06-24 06:01:23 <tabemann    > yes
2026-06-24 06:01:35 <tabemann    > you have to send the last LED's value first, and the first LED's value last
2026-06-24 06:11:15 <Stalevar    > Wait, 160 15 init-sm init-pio sm-clkdiv! and I edited the comment. Of course nothing changed, huh
2026-06-24 06:11:34 <Stalevar    > 125MHz/800kHz = 156.25
2026-06-24 06:12:02 <Stalevar    > 150MHz/800kHz = 187.5
2026-06-24 06:12:11 <Stalevar    > tabemann, what 15 does?
2026-06-24 06:12:26 <Stalevar    > Why is it 160 instead of 156?
2026-06-24 06:13:31 <Stalevar    >  pio::sm-clkdiv! ( fractional integral state-machine pio -- )
2026-06-24 06:13:49 <tabemann    > wait a second, the pin's 23, not 17
2026-06-24 06:14:12 <tabemann    > 15 is integral, 160 is fractional
2026-06-24 06:14:34 <Stalevar    > 15.160 ?
2026-06-24 06:14:40 <Stalevar    > or what fraction?
2026-06-24 06:15:31 <tabemann    > >>> 125_000_000 / (15 + (160 / 256))
2026-06-24 06:15:55 <tabemann    > gives 8000000
2026-06-24 06:18:03 <Stalevar    > 192 18
2026-06-24 06:18:57 <tabemann    > yes
2026-06-24 06:19:01 <tabemann    > and try GPIO 23
2026-06-24 06:21:50 <Stalevar    > but python code seems like decimal?
2026-06-24 06:23:15 <tabemann    > Python does calculations behind the scenes whereas zeptoforth just plugs in the values
2026-06-24 06:24:04 <Stalevar    > Then power is also not 25 but 37?
2026-06-24 06:24:45 <tabemann    > power may just be hard-wired
2026-06-24 06:25:12 <tabemann    > but leave the 25 in place as-is
2026-06-24 06:25:31 <Stalevar    > I have tried to turn both 37 and 25 on but nothing so far
2026-06-24 06:27:24 <tabemann    > do you have access to a schematic of the board?
2026-06-24 06:27:45 <tabemann    > try using GPIO 22 actually
2026-06-24 06:27:51 <tabemann    > there may be a typo in the comments
2026-06-24 06:28:13 <tabemann    > -1 -1 1 22 npxbuf init-neopixel
2026-06-24 06:29:55 <Stalevar    > https://ae01.alicdn.com/kf/Sc7c5f2ccf5994c2aa5fd05625099692eq.png
2026-06-24 06:32:02 <tabemann    > it's GPIO 22
2026-06-24 06:32:24 <Stalevar    > https://ae01.alicdn.com/kf/S90e241e0ce3e4833b20f1a5e8806dd4af.png
2026-06-24 06:32:32 <Stalevar    > What about power?
2026-06-24 06:33:57 <tabemann    > power may be hardwired
2026-06-24 06:34:07 <tabemann    > i.e. not to a GPIO
2026-06-24 06:34:19 <tabemann    > same thing with GND
2026-06-24 06:34:42 <tabemann    > as that image you linked didn't say anything about power or GND
2026-06-24 06:34:51 <tabemann    > for the WS2812
2026-06-24 06:35:05 <Stalevar    > Then why python code pokes 17 and 25?
2026-06-24 06:36:03 <tabemann    > 25 is the Pico's LED GPIO
2026-06-24 06:36:09 <tabemann    > 17, I don't know
2026-06-24 06:36:48 <tabemann    > oh, there may be an LED at 17 that it flashes once it's done
2026-06-24 06:37:11 <tabemann    > or it may just be toggling an output not tied to an LED
2026-06-24 06:38:02 <tabemann    > hmm I don't see anything about GPIO 17 in those images
2026-06-24 06:38:04 <Stalevar    > OK, it shines like crazy now, I have tried it again
2026-06-24 06:38:09 <Stalevar    > Maybe 25 turns it off?
2026-06-24 06:38:48 <tabemann    > 25 shouldn't turn it off
2026-06-24 06:39:31 <tabemann    > you can change its color
2026-06-24 06:40:15 <tabemann    > but yeah, WS2812's are really damn bright
2026-06-24 06:42:16 <Stalevar    > 0 1 0 0 npxbuf neopixel!  ok
2026-06-24 06:42:16 <Stalevar    > npxbuf update-neopixel  ok
2026-06-24 06:42:29 <Stalevar    > This is more like my speed, than 255 255 255
2026-06-24 06:45:58 <Stalevar    > Only question is why it didn't work the first time when did the same
2026-06-24 06:46:34 <Stalevar    > neopixel-init with same buff twice with different gpio isn't supported?
2026-06-24 06:48:03 <Stalevar    > All three are on bottom, so dark spot I noticed on the die was probably the control chip
2026-06-24 06:48:26 <Stalevar    > I mean, with 1 1 1 I can see where the actual leds are without blinding myself
2026-06-24 06:50:46 <tabemann    > I don't recommend attempting to run init-neopixel more than once on the same buffer
2026-06-24 06:52:21 <Stalevar    > Either way it was 22
2026-06-24 06:54:01 <Stalevar    > It's using SPI to bit-bang the ws 2812 fast enough?
2026-06-24 06:54:43 <tabemann    > it's using PIO to do so
2026-06-24 06:55:11 <tabemann    > PIO is designed for very tightly-controlled bit banging independent of the main CPU's
2026-06-24 06:58:26 <Stalevar    > That's pretty advanced for device which costs as much as cheapest USB flash drive
2026-06-24 06:59:42 <tabemann    > it's weird to think that a $1 USD MCU today is significantly more powerful than, say, the Mac 512K when it came out, which costed thousands of dollars *in the money of that day*
2026-06-24 07:03:14 <Stalevar    > Now, I need to know how to do a delay or something
2026-06-24 07:03:28 <Stalevar    > Then I can make LED blink in interesting patterns
2026-06-24 07:04:43 <tabemann    > MS ( ms -- )
2026-06-24 07:04:48 <tabemann    > 1000 MS waits a second
2026-06-24 07:06:23 <tabemann    > there's also TASK::DELAY, which is useful in some cases (e.g. if you want to keep a steady pace, and it also has 100 us resolution rather than 1 ms resolution, but it is more unwieldy)
2026-06-24 07:07:00 <tabemann    > ( delay start task -- )
2026-06-24 07:07:50 <tabemann    > where delay is the number of ticks after start to delay, where start is a value in ticks based on SYSTICK::SYSTICK-COUNTER, and task is the task you want to delay (TASK::CURRENT-TASK for the current task)
2026-06-24 07:13:58 <tabemann    > begin 255 0 0 0 npxbuf neopixel! npxbuf update-neopixel 333 ms 0 255 0 0 npxbuf neopixel! npxbuf update-neopixel 333 ms 0 0 255 0 npxbuf neopixel! npxbuf update-neopixel 333 ms again
2026-06-24 07:17:44 <tabemann    > just so you know, if you execute the last one, you can break out of it without rebooting by entering: control-T z
2026-06-24 07:18:12 <tabemann    > you may want to do KEY? UNTIL KEY DROP instead of AGAIN though
2026-06-24 07:20:13 <tabemann    > Stalevar, okay, I do plan on hitting the sack soon
2026-06-24 07:20:53 <Stalevar    > What happens when I hit ^C ?
2026-06-24 07:21:00 <Stalevar    > connection breaks but led keep shining
2026-06-24 07:21:39 <tabemann    > control-C reboots
2026-06-24 07:22:07 <tabemann    > but the LED is powered from USB and is unaffected by the MCU rebooting as long as power is applied
2026-06-24 07:23:10 <tabemann    > control-T z does not reboot but rather raises an exception that returns control to the REPL
2026-06-24 07:23:47 <tabemann    > however, it can fail if something catches the exception without reraising it, or if something does not properly clean up after itself when the exception is raised, breaking things
2026-06-24 07:25:07 <Stalevar    > Also Home key doesn't seem to work
2026-06-24 07:25:15 <Stalevar    > or I broke the terminal earlier
2026-06-24 07:26:11 <tabemann    > what are you trying to do with Home?
2026-06-24 07:26:32 <tabemann    > many terminal emulators catch control-A, often requiring you to enter control-A twice if you want to use it
2026-06-24 07:26:59 <tabemann    > so if you're trying to use control-A in the line editor and wondering why it's not working
2026-06-24 07:27:13 <tabemann    > I know both picocom and GNU Screen do this
2026-06-24 07:27:28 <Stalevar    > : shine ( r g b -- ) 0 npxbuf neopixel! npxbuf update-neopixel ;  ok
2026-06-24 07:27:28 <Stalevar    > : blink ( -- ) 0 5 10 begin 1 ms 2 0 do 1+ dup 10 > if drop 0 then rot loop 3dup shine key? until ;  ok
2026-06-24 07:29:09 <Stalevar    > I see, 1 ms was too fast, 50 ms more like it
2026-06-24 07:29:29 <tabemann    > 1 ms is a one millisecond delay, so yeah
2026-06-24 07:30:56 <tabemann    > okay, it's 12:30 pm here and I'm getting tired as I haven't had a lot of caffeine today
2026-06-24 07:31:07 <Stalevar    > good night
2026-06-24 07:31:17 <Stalevar    > Thanks for help getting it blinking
2026-06-24 07:31:30 <tabemann    > g'night, and have a good time playing around with your WS2812!
2026-06-24 07:33:17 <Stalevar    > : blink ( -- ) 0 5 10 begin 100 ms 2 0 do 1+ dup 10 > if drop 0 then rot loop 3dup shine key? until 2drop drop ;  ok
2026-06-24 07:37:57 <Stalevar    > It should be 3 0 do actually
2026-06-24 15:21:12 <pyzozord    > 02how is : factorial 1 [a,b] product ; computing a factorial? i have no idea how it could work
2026-06-24 16:02:42 <Stalevar    > pyzozord, what language is it? did you make sure it is computing factorial? [a,b] doesn't look like valid forth word
2026-06-24 16:02:55 <Stalevar    > if it was [ ] then it needs to be separated by space
2026-06-24 16:03:21 <Stalevar    > try see [a,b]
2026-06-24 16:03:25 <Stalevar    > see product
2026-06-24 16:04:34 <Stalevar    > : factorial 1 [a,b] product ;
2026-06-24 16:04:35 <Stalevar    > :9: Undefined word
2026-06-24 16:04:35 <Stalevar    >  : factorial 1 >>>[a,b]<<< product ;
2026-06-24 16:04:42 <Stalevar    > does not work in gforth as expected
2026-06-24 16:05:13 <lofty       > it makes me think of Factor rather than Forth.
2026-06-24 16:10:40 <pyzozord    > 02Stalevar: it was factor, i figured it out already [a,b] is a word generating a range of numbers
2026-06-24 16:17:05 <lofty       > What is the lifetime of a string created by "#>"? I know "s"" strings are basically pointers to the input field and so should be copied elsewhere immediately, but the wording of "#>" is much more vague.
2026-06-24 16:20:49 <Stalevar    > lofty, I don't even know how s" " work when not in word
2026-06-24 16:21:28 <Stalevar    > is : my-string s" my string" ; canonical way to make a string variable?
2026-06-24 16:22:30 <Stalevar    > in gforth raw s" string" spits out a pointer which seems to live long, maybe forever until interpreter is restarted
2026-06-24 16:22:34 <lofty       > the FILE word set defines interpretation semantics for "s"" as
2026-06-24 16:22:35 <lofty       > > Parse ccc delimited by " (double quote). Store the resulting string in a transient buffer c-addr u.
2026-06-24 16:22:59 <lofty       > so in practice it's a reference to the input buffer
2026-06-24 16:23:30 <Stalevar    > Is it supposed to die when you press enter? It doesn't in gforth
2026-06-24 16:24:07 <lofty       > no, but it probably dies when you interpret another "s"" string
2026-06-24 16:26:11 <Stalevar    > Nope, it doesn't, in gforth. I'm not sure if it's ever freed at all
2026-06-24 16:57:56 <Stalevar    > tabemann, edit in zeptoforth is even harder to leave than vi. I found it exits by ^V accidentally. How hard would it be to add hints like in nano?
2026-06-24 16:58:52 <Stalevar    > In vi everybody knows :q! but in this it just types :q!
2026-06-24 16:59:06 <Stalevar    > And I have no idea if it's saved anywhere in flash now or anything
2026-06-24 16:59:37 <Stalevar    > Though address suggests it edits near the dictionary area by default
2026-06-24 18:59:43 <crc         > lofty: 3.3.3.6 says the area used for #> may be transient. See https://ccreweb.org/documents/dpans94/dpans3.htm#3.3.3.6
2026-06-24 22:28:46 <tabemann    > back
2026-06-24 22:29:19 <tabemann    > Stalevar, if you're using zeptoed, you do know that there's online help, right?
2026-06-24 22:30:21 <tabemann    > unless you're using the block editor... but frankly I would avoid the block editor as if you're also using a FAT32 filesystem in flash it will corrupt it
2026-06-24 22:32:05 <tabemann    > as for the block editor, there is documentation, which is in docs/words/edit.md in the Markdown source
2026-06-24 22:33:44 <tabemann    > (just reread what you said, yeah, you're using the block editor)
2026-06-24 23:47:20 <tabemann    > Stalevar, part of why the block editor is so limited is that I'm used to editing files in filesystems, which is what zeptoed (which is much more powerful) is for
2026-06-24 23:47:50 <tabemann    > so I never really bothered to build much into EDIT