2026-06-12 00:52:27 <lofty       > any name suggestions for "( x1 x2 x3 -- x1 x1 x2 x3 )"? I seem to need this quite a bit.
2026-06-12 01:00:38 <f87         > : dup3rd 2>r dup 2r> ;
2026-06-12 01:17:23 <Stalevar    > L␋⎽├  ␋┼°⎺⎼└▒├␋⎺┼  ▒␉⎺┤├  ├␤␊ FILE⎽ (├␤␊ ␌┤⎼⎼␊┼├ ␍␋⎼␊␌├⎺⎼≤ ␉≤ ␍␊°▒┤┌├).  S⎺⎼├ ␊┼├⎼␋␊⎽ ▒┌⎻␤▒␉␊├␋␌▒┌┌≤ ␋° ┼⎺┼␊ ⎺°-␌°├┤┴SUX ┼⎺⎼ --⎽⎺⎼├ ␋⎽ ⎽⎻␊␌␋°␋␊␍.
2026-06-12 01:21:53 <xentrac     > that looks slightly like a VT100 that has accidentally gone into graphics mode
2026-06-12 01:22:16 <xentrac     > lofty: possibly you should move x2 and x3 into variables or values or onto the return stack
2026-06-12 01:24:29 <xentrac     > or just x3
2026-06-12 01:27:51 <Stalevar    > xentrac, you can start cat, then type ^V^[)^V^N and press Enter ^D and switch your terminal into the mode
2026-06-12 01:27:53 <xentrac     > because maybe you're much smarter than I am but I tend to lose track of the things on the stack when I have that many of them
2026-06-12 01:28:38 <Stalevar    > ^V allows typing control characters directly
2026-06-12 01:28:56 <xentrac     > Stalevar: well, not *my* terminal emulator: https://gitlab.com/kragen/bubbleos/blob/master/yeso/admu.c
2026-06-12 01:29:49 <xentrac     > also generally I don't have either ^[ or ^N assigned to anything in the Unix tty key settings so I don't need the ^Vs
2026-06-12 01:30:53 <Stalevar    > Yeah, I probably can type it with just ^[)0^N in cat
2026-06-12 01:31:04 <Stalevar    > But in echo it will be interpreted as bash controls
2026-06-12 01:31:08 <xentrac     > 0 is a discrepancy
2026-06-12 01:31:16 <xentrac     > well, if you're running bash, yes
2026-06-12 01:31:16 <Stalevar    > Yeah, I forgot it first time
2026-06-12 01:31:33 <Stalevar    > And to exit it's ^O
2026-06-12 01:31:41 <xentrac     > lofty: I've linked my standard advice about stack manipulation here before: https://news.ycombinator.com/item?id=33264506
2026-06-12 01:34:11 <Stalevar    > xentrac, hmmm. I thought CoC is like what you can and cannot write in official community resources, like LKML?
2026-06-12 01:34:32 <Stalevar    > It isn't supposed to restrict users in any way, if they don't interact with developers?
2026-06-12 01:34:53 <xentrac     > Stalevar: ?
2026-06-12 01:35:15 <Stalevar    > Your terminal emulator included CODE_OF_CONDUCT which says it doesn't have one?
2026-06-12 01:35:43 <Stalevar    > I'm arguing that CoC isn't supposed to put restrictions beyond the license?
2026-06-12 01:36:00 <Stalevar    > Or it's not CoC but rather second license
2026-06-12 01:36:31 <Stalevar    > But if it does, that's sick
2026-06-12 01:37:18 <xentrac     > I think you're talking about the BubbleOS Code of Conduct? https://gitlab.com/kragen/bubbleos/-/blob/master/CODE_OF_CONDUCT.md
2026-06-12 01:41:16 <Stalevar    > yes
2026-06-12 01:41:39 <Stalevar    > Security. Information security, unlike the security of a safety deposit box or a military position, is binary — either you have it or you don’t, with respect to a particular threat model and security objective.
2026-06-12 01:42:25 <Stalevar    > Hm... but for example can I run arbitrary code on your computer which you are connected to IRC right now? Theoretcally? I guess it might be possible
2026-06-12 01:42:41 <Stalevar    > Practically I have little idea how to start
2026-06-12 01:42:42 <xentrac     > it's probably possible
2026-06-12 01:43:52 <xentrac     > I think you're saying "aren't CoCs concerned with your item #1?" to which I answered in that document, "Purpose #1 does not make
2026-06-12 01:43:55 <xentrac     > sense for a single author, or indeed for most small groups of people,
2026-06-12 01:43:56 <Stalevar    > Hm, I wonder if I can make it display mojibake by sending raw control bytes
2026-06-12 01:43:58 <xentrac     > and purposes #2 and #3 are contemptible,
2026-06-12 01:44:00 <xentrac     > so BubbleOS does not have a code of conduct."
2026-06-12 01:44:34 <xentrac     > possibly; IRC clients try to display those as reverse-video capital letters like 
2026-06-12 01:44:50 <xentrac     > or other reverse-video characters like
2026-06-12 01:45:34 <xentrac     > it's possible that there's a distinction between what you're asking and what I was saying there that I don't understand
2026-06-12 01:45:48 <Stalevar    > $ ␊␌␤⎺ ^O
2026-06-12 01:47:22 <Stalevar    > xentrac, I mean will it break terminal if I send this )0
2026-06-12 01:49:18 <Stalevar    > Interesting, it seems to only break lowercase latin
2026-06-12 01:50:08 <Stalevar    > 6.≠  ◆  ▒  ␉  ␌  ␍  ␊  °  ±  ␤  ␋  ┘  ┐  ┌  └  ┼  ⎺
2026-06-12 01:50:08 <Stalevar    > 7.≠  ⎻  ─  ⎼  ⎽  ├  ┤  ┴  ┬  │  ≤  ≥  π  ≠  £  · ^?
2026-06-12 01:50:13 <xentrac     > your ESC didn't make it through I think
2026-06-12 01:50:43 <xentrac     > but yeah, the VT52 (and I guess VT100) only had pseudographic alternatives for the lowercase character sub-block
2026-06-12 01:51:06 <Stalevar    > I'll look through RAW LOG feature: )0
2026-06-12 01:51:28 <Stalevar    > Maybe server stripped it, but it's sent as it is
2026-06-12 01:51:37 <xentrac     > or maybe my client did
2026-06-12 01:51:57 <xentrac     > do you see the  highlighted right bracket?
2026-06-12 01:52:02 <xentrac     > it vanishes for me
2026-06-12 01:52:20 <Stalevar    > I see cursive font
2026-06-12 01:52:44 <xentrac     > I don't know if the lowercase-only-thing (also {|}~ I think) was to save money on the ROM or an intentional feature so that you could caption your pseudographics with capital letters and numbers without having to waste bandwidth on switching character sets all the time
2026-06-12 01:54:05 <xentrac     > yeah, also `, which is your diamond ◆
2026-06-12 01:55:17 <Stalevar    > Normal IRC control codes are ^B bold, ^O normal, 0x1F underline and 0x1D Italic
2026-06-12 01:56:05 <Stalevar    > Probably for tables
2026-06-12 01:56:27 <xentrac     > 0x1F is ^_ of course :)
2026-06-12 01:57:00 <xentrac     > and my client evidently doesn't support italics (but does strip out the ^] 0x1D)
2026-06-12 01:59:53 <Stalevar    > More: 0x1F Strikethrough, 04 Set color ^C\d\d where \d means a digit, 0-padded number up to 15?
2026-06-12 02:00:44 <Stalevar    > 16 Color 16 which my client doesn't list. And normal text
2026-06-12 02:00:52 <Stalevar    > 16 Color 17 which my client doesn't list. And normal text
2026-06-12 02:01:01 <Stalevar    > 16 Color 20 which my client doesn't list. And normal text
2026-06-12 02:01:04 <xentrac     > yeah, I don't see colors there either
2026-06-12 02:01:19 <xentrac     > you said 0x1F was underline
2026-06-12 02:01:22 <Stalevar    > My clients renders 16, 17 and 20 as gray
2026-06-12 02:01:32 <Stalevar    > 0x1E
2026-06-12 02:01:34 <xentrac     > also there are two contradictory interpretations for set color
2026-06-12 02:01:47 <xentrac     > 03color 03, 3color 3
2026-06-12 02:02:01 <Stalevar    > I can see color in your message, light green
2026-06-12 02:02:03 <xentrac     > 04color 04, 4color 4
2026-06-12 02:02:06 <Stalevar    > red
2026-06-12 02:02:10 <xentrac     > yeah, for me too
2026-06-12 02:02:32 <xentrac     > but look at the contents
2026-06-12 02:02:39 <Stalevar    > 5 Color 5 without 0 And normal text
2026-06-12 02:02:56 <Stalevar    > Yeah, 0 padding isn't mandatory
2026-06-12 02:03:28 <Stalevar    > 0004 Color 0004 with extra 000 And normal text
2026-06-12 02:03:49 <Stalevar    > Ah, it interpreted 00
2026-06-12 02:04:31 <xentrac     > also 0,12you can set the background color apparently
2026-06-12 02:04:33 <xentrac     > https://modern.ircdocs.horse/formatting#color
2026-06-12 02:05:30 <Stalevar    > Good thing it's out of fashion.
2026-06-12 02:05:59 <Stalevar    > Some would try to post "art" in IRC with this
2026-06-12 02:06:08 <xentrac     > a lot of channels I'm on have a special mode to strip out color codes
2026-06-12 02:06:27 <Stalevar    > Yeah, it was so annoying that IRC servers included protection
2026-06-12 02:08:12 <Stalevar    > 0x11 must be real useful, too bad hexchat doesn't list it in right-click menu
2026-06-12 02:09:45 <xentrac     > only a minority of IRC clients display text with proportional fonts
2026-06-12 02:14:25 <Stalevar    > ┼── │    │  │││
2026-06-12 02:14:25 <Stalevar    > │   │    │  │││
2026-06-12 02:14:38 <Stalevar    > Nope, my client doesn't support 0x11 sadly
2026-06-12 02:14:47 <Stalevar    > And it's proportional font
2026-06-12 02:18:37 <Stalevar    > Do foxes write in Forth?
2026-06-12 02:19:23 <xentrac     > does Forth write on a fox?
2026-06-12 03:13:08 <Stalevar    > xentrac, I was referring to vulpine
2026-06-12 07:39:07 <veltas      > I've found the best way to do 'rules' for any project is to not write them down, and then talk to people who break the unwritten rules first, and then ignore / block them (or immediately if it's clearly in bad faith).  When you have process etc it just creates abuse of the process.
2026-06-12 07:41:19 <veltas      > I don't fault people (or larger projects) for having said rules, etc, as they're often a requirement for funding, but really the least overhead and most informal approach that can be tolerated is always best.  You get a lot of mileage from just being civil and the golden rule.
2026-06-12 07:41:44 <veltas      > And if people in charge don't respect that then no rules or codes of conduct will help you.
2026-06-12 07:53:33 <xentrac     > yeah
2026-06-12 07:53:39 <xentrac     > those can all be true too
2026-06-12 12:56:04 <cleobuline  > forthBot:  : R RECURSE ;  R
2026-06-12 12:56:05 <forthBot    > Error: Call depth exceeded (recursion trop profonde ?)
2026-06-12 12:59:33 <veltas      > xentrac: Did you see this? https://www.reddit.com/r/linux/comments/1u1gj4s/sonny_piers_elaborates_on_his_ban_from_the_gnome/
2026-06-12 13:00:16 <veltas      > Ex GNOME person alleges that CoC was used to silence him exposing serious leadership issues
2026-06-12 13:14:20 <Stalevar    > veltas, gnome is dead
2026-06-12 13:14:33 <Stalevar    > They propose excluding X11 support from GTK4
2026-06-12 13:15:08 <Stalevar    > Though their habit to break working software started long before that
2026-06-12 13:15:24 <Stalevar    > For example Gnome2 was OKeish, but 3 terrible.
2026-06-12 13:15:52 <Stalevar    > KDE4 was also worse than KDE3, but not by much
2026-06-12 13:22:56 <veltas      > KDE and GNOME are retiring X11
2026-06-12 13:23:06 <veltas      > Don't know about XFCE but if not then XFCE are a good project
2026-06-12 13:23:42 <veltas      > And I've basically been forced to use XFCE for years anyway because the performance of KDE/GNOME has been so bad
2026-06-12 13:25:04 <veltas      > I mean I don't even use XFCE but I mean on my wife's laptop that's what she's got because everything else is unusable
2026-06-12 13:25:28 <veltas      > I use dwm because I've obviously got nothing better to do
2026-06-12 13:26:03 <veltas      > She likes the "mouse logo", although I'm not 100% sure what rodent it's meant to be
2026-06-12 13:26:52 <veltas      > Apparently it is indeed a mouse
2026-06-12 13:30:07 <veltas      > https://www.nhbs.com/blog/uk-small-mammal-identification
2026-06-12 14:08:04 <lofty       > Attempting to write a syntax highlighter for forth is fun. "2dup" could be a word, or it could be a base-36 integer.
2026-06-12 14:08:54 <Stalevar    > veltas, I'm wondering what would happen if you bring a hacker's solution to a CS school test? For example the problem expected something like  n=int(input());\ns=0\nk=0\nfor i in range(n):\n\ta=int(input())\n\tif a%7==0:\n\t\ts+=a\n\t\tk+=1\nprint(s/k)
2026-06-12 14:09:35 <Stalevar    > But you bring in a brainfuck interpreter with embedded brainfuck code solving the problem?
2026-06-12 14:09:49 <veltas      > lofty: Yeah it's a nightmare
2026-06-12 14:10:36 <lofty       > I can't say I write many base-36 literals though.
2026-06-12 14:10:51 <iv4nshm4k0v > Tcl has some similarities to that.  While the convention is to write if { 42 = [ foo ] } { puts bar }, it's equally possible to write it like it like if " 42 = \[ foo ] " " puts bar ".  One of the reasons I've stopped using syntax highlighting altogether.
2026-06-12 14:11:28 <Stalevar    > iv4nshm4k0v, nope, you need a space after if
2026-06-12 14:11:48 <veltas      > In Forth I'd say that a Forth environment is best suited to highlight as it is the only thing with the context needed to say whether something was e.g. a literal or an immediate etc
2026-06-12 14:12:25 <iv4nshm4k0v > Stalevar: Huh?  I do have a space after if, in either case.
2026-06-12 14:12:26 <iv4nshm4k0v > (It's known as "everything is a string," or EiaS, among Tclers.)
2026-06-12 14:12:37 <veltas      > But having to run the code to get highlighting is already quite bad
2026-06-12 14:13:03 <veltas      > I also don't use highlighting to write Forth, if I do I just highlight comments
2026-06-12 14:13:13 <veltas      > And that's not perfect but less error prone
2026-06-12 14:13:55 <Stalevar    > iv4nshm4k0v, In your sample there is " immediately after if, then entire 'if 42 = [ foo ] ' will be interpreted as command which doesn't exist
2026-06-12 14:14:14 <lofty       > I think Forth is probably a language where you can reasonably forgo syntax highlighting because otherwise everything is a keyword :p
2026-06-12 14:14:26 <Stalevar    > But otherwise yes, { } and " " are almost equivalent in Tcl
2026-06-12 14:14:54 <lofty       > But I think I'd probably highlight some control-flow words
2026-06-12 14:15:32 <iv4nshm4k0v > No there isn't; my example - the way I've sent it from my IRC client - in hex starts with 69 66 20 22 20 34 32 20 3d 20 5c 5b 20 66 6f 6f 20 5d 20 22; as you can see, there's 20 (blank) after 69 66 (if).
2026-06-12 14:15:54 <veltas      > That's how I saw it too
2026-06-12 14:16:06 <veltas      > Think it's on your end Stalevar
2026-06-12 14:16:12 <iv4nshm4k0v > Was there a proportional font involved somewhere, perchance?
2026-06-12 14:17:55 <iv4nshm4k0v > To those who speak Bourne shell, Tcl's "" are like shell's "", while { } are like '' with balancing, so { { } } is the same " { } ", but { $foo } is /not/ the same as " $foo ".
2026-06-12 14:20:14 <veltas      > Tcl is definitely one of the bonkers langs like Forth, Lisp, etc
2026-06-12 14:20:45 <veltas      > Tcl/Tk has been super influential and I see Tcl around sometimes in random places
2026-06-12 14:20:56 <Stalevar    > I apologize, there is indeed a space. But why is it so short
2026-06-12 14:21:38 <veltas      > Font/client issue maybe
2026-06-12 14:26:00 <Stalevar    > Still, first space looks shorter than second here:  if " 42
2026-06-12 14:26:10 <Stalevar    > I have changed font to Liberation Sans 16
2026-06-12 14:26:23 <Stalevar    > Can you suggest a good font for IRC?
2026-06-12 14:26:42 <Stalevar    > It was Noto Sans Extra Condensed 14 before
2026-06-12 14:27:25 <Stalevar    > DejaVu doesn't have Regular for some reason, only book, ultra light and so on
2026-06-12 14:35:32 <veltas      > book is regular
2026-06-12 14:42:49 <iv4nshm4k0v > I kinda prefer my IRC client to run in a Screen (or Tmux) window, so I've been using Terminus as my "IRC font" for a while now.
2026-06-12 14:42:50 <iv4nshm4k0v > ... As to DEs, on the installs that warrant having Big GUIs around, I tend to use Openbox.  Elsewhere, I'm fond of JWM (which can be built with very few dependencies) and VTWM (which sadly doesn't seem to interoperate well with some Big GUI software - such as Chromium; hence Openbox.)  I've toyed with Gnome and KDE back in 2001 or so, but never figured how either can help me in any way.
2026-06-12 14:56:05 <forthBot    > Environment for cleobuline inactive, freeing...
2026-06-12 14:58:50 <veltas      > I'm finding firefox runs way faster than chromium, not sure if chrome is faster though, but chromium especially seems to be a mess
2026-06-12 14:58:57 <veltas      > Might be my bad graphics
2026-06-12 14:59:20 <veltas      > And/or ability to use a proper adblock
2026-06-12 14:59:30 <veltas      > I need to try Scribus
2026-06-12 15:10:43 <iv4nshm4k0v > I typically use Chromium over VNC over an SSH tunnel to an LXC container.  I haven't tried, but I guess that the bottleneck such a setup creates would make Firefox no faster than Chromium.
2026-06-12 15:10:44 <iv4nshm4k0v > I've used Firefox before Quantum, and I've used Classic Theme Restorer once Firefox adopted Australis.  Quantum has made CTR (and a bunch of other plugins; say, Certificate Patrol) impossible, so I saw no reason to stick to it.  I intend to try Pale Moon at some point, at least for some tasks, though I don't actually expect it to be compatible with lots of proprietary webapps out there.
2026-06-12 15:12:10 <veltas      > Yeah web browsers are a mess
2026-06-12 15:56:11 <KipIngram   > I'm currently fairly content with Brave.
2026-06-12 19:14:07 <lofty       > When learning Rust there's a phase of "fighting the borrow checker" where one's mental model does not fit the language's rules, until eventually you start to think the same way the language does. I think I'm beginning to understand how Forth wants me to structure solutions to problems, though I'm still quite far from "factoring".
2026-06-12 19:37:28 <veltas      > You may be closer than you think
2026-06-12 19:41:58 <lofty       > https://gist.github.com/Ravenslofty/92c4908a7d6e8eff6a62a71e04a74913 <-- I'm reasonably proud of "position:make" despite it being a bit incomplete.
2026-06-12 20:18:15 <oak         > lofty: that's pretty code!
2026-06-12 20:19:47 <lofty       > ^^;;
2026-06-12 20:20:26 <oak         > Something I noticed early on with Forth is that it's the most I've enjoyed reading other people's code.
2026-06-12 20:20:45 <oak         > I don't know why yet.
2026-06-12 20:20:59 <lofty       > I am surprised it's considered pretty; I'm just trying to write what feels natural, despite my inexperience with forth
2026-06-12 20:28:42 <vdupras     > With a slight reworking of your piece constants (let's say, have the color flag on bit 4 instead of bit 8), it would become easy to change your big "if ... emit then" list into an array of characters combined with a vectorized emitter
2026-06-12 20:28:47 <vdupras     > that would be prettier
2026-06-12 20:29:18 <vdupras     > (hum, bit 7)
2026-06-12 20:30:20 <lofty       > I will be honest I am unsure how to do initialised arrays in Forth in a way that isn't just doing a bunch of "value array N + !"
2026-06-12 20:32:57 <vdupras     > I don't know either, I suppose it depends on the Forth implementation. In the Forth I know, it would be: create piecechars ,".pnbrqk?.PNBRQK?"
2026-06-12 20:34:29 <lofty       > I guess "c," is a thing
2026-06-12 20:34:44 <vdupras     > yeah, but doing it 16 times is a bit ugly
2026-06-12 20:35:00 <oak         > When I type in "KEY 5" and hit enter, I notice it reads the next key I type, rather than " 5" from the input buffer. Does Forth distinguish stdin from the input buffer?
2026-06-12 20:35:44 <lofty       > oak: yes, that's my reading of the standard.
2026-06-12 20:36:36 <lofty       > to put it another way, if they were not the same, how would a forth program receive different input?
2026-06-12 20:37:02 <lofty       > *if they were the same
2026-06-12 20:37:11 <lofty       > (I am tired, sorry)
2026-06-12 20:37:43 <oak         > I didn't realize one would need to.
2026-06-12 20:37:59 <oak         > Huh. Going to have to think about that one more.
2026-06-12 20:38:24 <lofty       > if "key 5" always yielded "5", then you could just replace "key" with "char" :p
2026-06-12 20:39:20 <oak         > Aah, so CHAR is the input buffer equivalent of KEY.
2026-06-12 20:39:25 <lofty       > ...no
2026-06-12 20:39:28 <vdupras     > it's possible to imagine both approaches working because it's rather rare that "key" is called during the interpretation of a code block (it would block that interpretation). It's generally going to be compiled into a word and that word is going to be called interactively. In this context, the input buffer is not source code but the keyboard
2026-06-12 20:40:17 <oak         > vdupras: Ah, okay, so is KEY reading from stdin or from the keyboard directly?
2026-06-12 20:40:19 <lofty       > if you have to read from the input buffer, then perhaps investigate "SOURCE"
2026-06-12 20:40:40 <vdupras     > I guess it depends from the implementation. I don't know what the Forth standard says
2026-06-12 20:40:43 <lofty       > Ah, okay, so is KEY reading from stdin or from the keyboard directly? <-- this is not defined by the standard. the standard does not even have a concept of "stdin".
2026-06-12 20:40:54 <vdupras     > Personally, I prefer the idea of having a separate input for "key"
2026-06-12 20:41:02 <oak         > I noticed that when I run "echo 'KEY .' | gforth" that I get "4" (EOT).
2026-06-12 20:41:03 <lofty       > key input events arrive from somewhere and that's all the standard cares about.
2026-06-12 20:41:42 <lofty       > https://forth-standard.org/standard/core/KEY#
2026-06-12 20:41:44 <lofty       > * https://forth-standard.org/standard/core/KEY
2026-06-12 20:41:47 <lofty       > https://forth-standard.org/standard/core/KEY
2026-06-12 20:41:54 <lofty       > I really am tired. sorry.
2026-06-12 20:42:25 <oak         > lofty: No worries ;)
2026-06-12 20:42:40 <oak         > Thanks for the link. I didn't know about this reference -- I'd been using GForth's.
2026-06-12 20:43:23 <vdupras     > as lofty wrote above, the standard really sounds like it means something else than the input buffer. but still, it's possible to imagine a Forth that doesn't distinguish that input and still is usable
2026-06-12 20:44:12 <lofty       > When it means the input buffer it will say so; e.g. https://forth-standard.org/standard/core/SOURCE
2026-06-12 20:45:50 <oak         > Thank you for the notes, lofty vdupras. This gives me some good reading & thinking to do.
2026-06-12 20:46:05 <lofty       > oak: what happens with "gforth -e "key . bye""?
2026-06-12 20:46:53 <oak         > lofty: It reads from the keyboard, for me.
2026-06-12 20:46:59 <oak         > That's interesting.
2026-06-12 20:47:34 <xentrac     > oak: interesting!
2026-06-12 20:47:57 <xentrac     > veltas: no, I didn't
2026-06-12 20:48:57 <oak         > So when there is data on stdin, KEY always returns EOT, but otherwise it reads from the keyboard directly.
2026-06-12 20:49:21 <oak         > 
ACTION has her brain break

2026-06-12 20:51:28 <xentrac     > I've been using Xfce a little but mostly MATE
2026-06-12 20:51:37 <xentrac     > My wife is also a fan of the mouse logo
2026-06-12 20:52:14 <xentrac     > lofty: maybe you could have the Forth compiler output syntax-highlighting information to a separate stream
2026-06-12 20:53:48 <lofty       > xentrac: I have the "Hal replaces a lightbulb" video bookmarked for suggestions like these :p
2026-06-12 20:54:06 <lofty       > (https://youtu.be/5W4NFcamRhM :p)
2026-06-12 20:54:18 <xentrac     > in ColorForth the author of the code syntax-highlights it by using color-change tokens which tell the interpreter which words are integers or comments or etc.
2026-06-12 20:54:38 <oak         > Ha ha. Just realized that CR emits a LF.
2026-06-12 20:55:05 <xentrac     > I hadn't heard of Merkaartor before
2026-06-12 20:57:53 <xentrac     > I think it's reasonable to say that char is the input-buffer equivalent of key.  Or [char] (or, in old standards, ascii).
2026-06-12 20:59:54 <xentrac     > well, I guess char discards characters after the first; PForth implements it as bl parse drop c@
2026-06-12 21:04:45 <xentrac     > but https://forth-standard.org/standard/core/PARSE says that it returns an address within the input buffer
2026-06-12 21:06:32 <xentrac     > lofty: that's a humorous video about yak-shaving.  but I don't think "maybe you could have the Forth compiler output syntax-highlighting information to a separate stream" is a yak-shaving suggestion.  You're confronting the fact that an extensible compiler can do some arbitrary user-defined computation to figure out how to parse or indeed even tokenize its input, which adds difficulty to the problem of
2026-06-12 21:06:38 <xentrac     > syntax highlighting.  The way to solve that problem is to get the syntax-highlighting information out of the compiler instead of trying to approximate it with a pile of regular expressions; this is currently the mainstream approach in languages like Rust, where everybody uses the Language Server Protocol these days
2026-06-12 21:11:30 <lofty       > xentrac: it is perhaps a _little bit_ yak-shaving when my goal is to write a small chess program for a demo...
2026-06-12 21:13:32 <lofty       > To be clear I do agree with what you're saying, which is why language servers exist; I would say that Rust is significantly easier to write with rust-analyzer
2026-06-12 21:14:17 <lofty       > But I would also say that writing an LSP for my forth kernel would be joining the war on scope creep on the side of scope creep.
2026-06-12 21:14:22 <xentrac     > yes, but I would argue that that is a result of "maybe I should write a syntax highlighter for Forth in order to write a small chess program" rather than "maybe I should modify my Forth compiler in order to get a syntax highlighter"
2026-06-12 21:20:55 <lofty       > (If anything I think this experiment in syntax highlighting has made me want to use # prefixes for decimals so I don't have to bother with implementing BASE and such.)
2026-06-12 21:23:51 <lofty       > xentrac: anyway, even if I was to output such information, I don't think it would be feasible to then ingest that information into the editor. so, regex highlighting and admitting incompleteness will have to do for the time being.
2026-06-12 21:51:27 <xentrac     > I guess it depends on the editor?
2026-06-12 22:00:58 <xentrac     > in Emacs you can just (put-text-property (point) (mark) 'font-lock-face 'info-title-2)
2026-06-12 22:01:13 <xentrac     > and then the region between point and mark changes its font to the info-title-2 font
2026-06-12 22:02:18 <xentrac     > both (point) and (mark) just evaluate to integers, the character offsets of point and mark from the start of the buffer
2026-06-12 22:05:20 <xentrac     > it would be pretty easy to walk through a file each line of which said things like "353 372 font-lock-function-name-face" and applied the requested face to each span of text.  Maybe in chunks during idle time rather than blocking the entire editor