Does Org have a mechanism for escaping its own syntax? Last time I searched, to type *this* (keeping the asterisks) you had to insert a zero-width space (U+200B). In markdown you just escape them with \*this\*.
I've used the following, in addition to the "escape character" method (which is officially documented as the other commenter noted):
For in-line escaping, I use tilde-blocks ~ ~ ... as in ~~ . This type-sets in monospace (code format) in exports, which usually* is what one wants anyway, viz. to demarcate the symbol as being symbolised.
This summary is definitely useful as I'm myself a user of Org. I still think backslash escaping doesn't get to be annoying, and is a simple algorithm, which is important when you want to paste text into your org documents from other sources.
You can keep these tricks in mind while writing, but sometimes it's not you doing the writing. It could be pasted text, it could be a machine writing.
I think org-mode was never primarily about its rendered output. Most users probably, like me, spend a lot of time (hours every day) in various org-mode documents, staring at what is essentially the raw mark-up. Org-mode in Emacs makes only a few minor changes to how the text is displayed, like hiding link targets, so you rarely look at the output. I export less than 1% of my org documents, so usually I don't care at all about what formatting renders like, as long as I get the mark-up correct enough that org-mode itself is functional (links can be followed, sections collapsed etc). The few documents I do want to export I can imagine using workarounds like the zero-width spaces, but it is not like there is often a need to have things looking like org-mode mark-up in the output.
For me at least, worrying about escaping mark-up would be too distracting and just add noise, as the raw mark-up is what I will read anyway. But I think some good way to escape things would not be a bad thing to have.
BTW there are verbatim blocks that can be used when you have entire lines of non-org content. And of course src-blocks. But that obviously does not handle every case escapes could be useful.
That was some bad luck. I made an edit seconds after the post came rendered to get the formatting right. (On HN I expected to have to type \\\* to render \* but you just have to type \\*)
I understand your use case, I just think it makes it not worthy of comparisons to markdown.
So you can type *word* without it becoming bold? So an article can contain: "The logs come to about ~300 lines once you start the server with ~systemctl start fnord~"
The `code` equivalent in Org is ~code~. How do you type that without the Org highlighting removing the ~ from "~300 lines", thinking that the code snippet begins there? This is an example I got from grepping my org files for U+200B.
I see. Just gave it a try and backslash works as escape. Though also I'm probably unlikely to experience such issues myself as my Emacs theme shows formatting characters even after applying the formatting.
Still exports as <p>\~300 lines</p> (in case of an HTML export). In fact you could "escape it" with any character, the backslash isn't doing anything special, the formatting just doesn't trigger if there's no white space on one side. When I use Org I also do not have auto-formatting, as you do, but the highlighting would still be wrong. And it'd be masochistic to put up with that unless you've invested a lot into Org for other reasons.
Sounds to me like it's a shortcoming of the exporter then, to not remove the escape characters as appropriate. Though one would think others would've run into this issue and fixed it. Or perhaps you're missing some other prevalent alternative?
The highlighting corrects for me once I "escape" the "~300".
Isn't the aim to have the highlighting only apply to `~systemctl start fnord~`, and not have whatever you used to escape the "~300" appear in an export? Highlighting and exporting are 2 pretty distinct functions.
I use org a lot, in fact, it's my daily driver. I also have to deal with MySQL, and, if using the vertical output (what you get if you finish a query with '\G' instead of ';' it makes pasting into an org file a pain.
Sure, not a big pain, I just wrapped it in a function paste-from-mysql that appends the whitespace, but then I need to take out the whitespace of I want to paste that somewhere else. It would be nice to have org support some sort of 'do not interpret what comes next' block markers. I guess someone with enough time and skills could make this change but, alas, that's not me.
Thanks! I had actually seen that, but didn't realize that org does remove the leading comma when you extract a block to paste it somewhere else, which is great, because it means I need one less function.
Now I just need to keep my paste function, but have it add a leading comma instead of a space, and I need to use example instead of src (not a problem for this use case since, even though I normally paste them into sql src blocks, the syntax highlighting isn't that useful.
You gave me a nice little task for a rainy day, thanks :)
In an Org document that contains Org examples (e.g. if this article had been written in Org), even Emacs gets confused about rendering it. So you might find that sections in example text are evaluated as being part of top-level sections and collapsing is wonky, etc.
I run into this a lot with gptel. I use a main Org file for all my daily notes, and since gptel streams LLM output as Org (which is good), it conflicts with my main file. I have a post-processing function that converts headings into `#` to avoid this, but it's a hack I'd rather not do.
Hmm I'm still not seeing the issue. Why aren't the examples just lists under say an examples header? Or the LLM output? Maybe gptel is expecting output to be in a fresh file or at the top level? It should be a trivial fix to intent a level before inserting.
Here's people installing Tailscale binaries and gracefully working around a missing kernel module and the missing iptables binary on the Kobo Sage / Kobo Libra 2:
Markov models with more than 3 words as "context window" produce very unoriginal text in my experience (corpus used had almost 200k sentences, almost 3 million words), matching the OP's experience. These are by no means large corpuses, but I know it isn't going away with a larger corpus.[1] The Markov chain will wander into "valleys" of reproducing paragraphs of its corpus one for one because it will stumble upon 4-word sequences that it has only seen once. This is because 4 words form a token, not a context window. Markov chains don't have what LLMs have.
If you use a syllable-level token in Markov models the model can't form real words much beyond the second syllable, and you have no way of making it make more sense other than increasing the token size, which exponentially decreases originality. This is the simplest way I can explain it, though I had to address why scaling doesn't work.
[1] There are 4^400000 possible 4-word sequences in English (barring grammar) meaning only a corpus with 8 times that amount of words and with no repetition could offer two ways to chain each possible 4 word sequence.
I think that the ingame terminal window inherited from Quake that continued onto the original Half life, onto recent games like CS2, rather than a place for entering debug/cheat commands that other game developers seem to only imagine it as, is a QoL feature that me and many other people have missed before. Any game setting (graphics options, FPS cap, FOV) can be changed by tab-completing commands from the ingame terminal. Actions like shooting, jumping, cycling weapon-in-hand are also available as text commands.
Text commands might seem like a impractical, though quaint interface to the game, but that terminal also lets you bind any command to any key (this includes settings-changing commands). Not just a command, you can run more than one command at once like "cl_command1 ; cl_command2; ...". The terminal has some more scripting-like features that are readily available to the player, but just with that, you could have, for example, a key bound to a bunch of commands that turn up graphics settings to make the game as beautiful as possible for a screenshot, and another that undoes those commands for situations where you need higher performance.
You can also bind the key "K" to write in chat "My people need me" and instantly respawn:
bind K 'say "My people need me" ; kill'
Almost total input freedom as it will turn out.
It is basically a keyboard macroing system but offered to you on a platter by the game, making ever-crufty external macroing or bringing out something like AutoHotKey unnecessary. Though not as deep, it has just the right amount of depth. Binding keys to commands is not done through a special GUI, it is being done through a text command as well (just 'bind'), and that implies that you can nest bind commands:
> Scripting in Team Fortress 2 involves using configuration files to change keybinds, create aliases, adjust advanced graphical settings, automate complex actions, and execute sequences of console commands. Unlike hacking, scripting is an official feature built into the game and will not trigger a Valve Anti-Cheat ban. The complexity of scripts can range from simple keybindings to intricate loops and nested aliases that change themselves dynamically.[1]
Yes, but... even if you know that it is APL inspired, that does not change the fact that this is not how you want to write C.
The C pre-processor is probably one of the most abused pieces of the C toolchain and I've had to clean up more than once after a 'clever' programmer left the premises and their colleagues had no idea of what they were looking at. Just don't. Keep it simple, and comment your intent, not what the code does. Use descriptive names. Avoid globally scoped data and functions with side effects.
That doesn't look smart and it won't make you look smart, but it is smart because the stuff you build will be reliable, predictable and maintainable.
Layman question: say you have a C codebase with a bunch of preprocessor macros and you want to get rid of a particular one that's too clever, and assume no other macros depend on it.
Is it possible to command the preprocessor to take the source files as input and print them out with that one particular macro expanded and no other changes?
Intuitively, it sounds like it should be possible, and then you'd end up with a code base with a bunch of repetition but one fewer too-clever abstraction - and refactoring to deal with repetition (if necessary!) is a far more approachable and well-understood problem.
(Kind of like how some fancy compiles-to-javascript languages have a literal 'mytool --escape' command that will turn the entire code base into a plain, non-minified javascript in case you ever want to stop using them.)
It was a theoretical question. It's not the first time I hear the complaint '$previous_dev left a bunch of unmaintainable macro tricks in a C codebase' and I thought, since those macros get expanded as part of the compilation process, surely it should be possible to intercept and capture the expanded version?
Even if a whitelist is not available (the SO question involves a particular C++ preprocessor and may not apply to others), a hacky approach might be to comment out all the #defines in the codebase, uncomment the ones you want to get rid of, and then run the full preprocessor task on it. Ugly but probably doable for a one-time refactoring.
The beginning of the article talks about not learning APL--specifically mentions that he's not here to talk about APL--and proceeds into a wide-eyed dissection of the C without mentioning APL syntax again. It also doesn't, literally, say that the C is like APL; it says Arthur is an APL guy who writes weird C code. Another comment disagrees that this is APL style at all--which is it?? I think you could have given me more credit than this. I read the article and participated as best I could. I'm always happy to bump APL related articles so they get more visibility.
It's irrelevant that someone doesn't think the code is APL-inspired. Their disagreement is as much with the article as your comment. I felt like what is written in the article already implied what I then read in your comment. Credit where due, the disagreement with the article probably would've not been posted if the implications in that part hadn't been re-stated plainly. Comments like these can be useful as pointers to specific aspects of an article, where conversations can be organized under, now that I think about it.
Dunno why electroly is dragging me into this but I believe you've misread the article. When it says "His languages take significantly after APL" it means the languages themselves and not their implementations.
I think the article expresses no position. Most source code for array languages is not, in fact, inspired by APL. I encourage you to check a few random entries at [0]; Kap and April are some particularly wordy implementations, and even A+ mostly consists of code by programmers other than Whitney, with a variety of styles.
I do agree that Whitney was inspired to some extent by APL conventions (not exclusively; he was quite a Lisp fan and that's the source of his indentation style when he writes multi-line functions, e.g. in [1]). The original comment was not just a summary of this claim but more like an elaboration, and began with the much stronger statement "The way to understand Arthur Whitney's C code is to first learn APL", which I moderately disagree with.
I unfortunately glossed over the part of the original comment that gives it substance: "The most obvious of the typographic stylings--the lack of spaces, single-character names, and functions on a single line--are how he writes APL too."
That's backing for a claim.
Also, I haven't once written APL. I think this might've been borderline trolling, just because of how little investment I have in the topic in reality. Sorry.
It's definitely unpleasant when opinions you hear seem like they might be parroted, but at least it's in good faith. I find it frustrating to hear argumentation that shames, rather than attempt to correct or add anything.
reply