4coder editor is now fully open source
github.com
github.com
4coder receives significant attention via the Casey Muratori's video streams like Handmade Hero, and opening it up is sure to produce some positive growth for the development/community side of the project.
The combination of popular development livestreams and FOSS tooling utilized in those livestreams seems like it could be an important part of making FOSS development more sustainable without involving big corporate sponsors.
This is not a "opening up" of anything but the source code, with a permissive license. You're free to fork and change anything you want, but it won't be upstreamed ever as the author did the open sourcing because they are stopping maintenance of the project.
So this is more of a "closing down" with the gift of leaving us with the source code. And for that Allen Webster, I thank you!
4kdcoder?
4coder, a modern text editor based loosely on Emacs - https://news.ycombinator.com/item?id=23444912 - June 2020 (16 comments)
"What the hell is ________?"
I agree with you in general though.
Some things are aimed at a group of people, and written with that in mind. Someone closing a project/stopping maintenance of something, usually write directly to the group of users of the software.
To expect everything to contain information about everything someone could not know, means everything would have to be extremely verbose. We have search engines, typing "4coder" and finding the website took me around 2 seconds, I'm sure you'd be able to do it just as fast.
Still, the argument is the same - a person is posting an article on a news site for the sole purpose of other people seeing (consuming) it.
I consider it basic decency to create a good presentation when you're showing something in people's news feed.
>I consider it basic decency to create a good presentation when you're showing something in people's news feed.
The individual posting the article may not be the owner of the code base thus making it impossible for the poster to alter the presentation.
If the owner of the code base has not posted a link for others' "consumption," they would have conformed to your expectations.
Good point, I didn't consider that.
The point of view I'm coming from is that while it's impossible to put all possible information in a README (and such level of detail would probably make it even less readable, like Whitehead and Russel's Principia Mathematica) - there are some things that are reasonable to expect on any kind of public repository (I assume it's a public repository because of the README's public-facing style - "Welcome to the 4coder code base. [...] In this readme you will find: [...]"), such as "what is the purpose of this program".
I know nobody owes anything to nobody, and such criticism might be seen as rude - since we're basically criticizing volunteers - but consider the fact that feedback is a major part of how we figure out our mistakes. If someone is posting their work online, it would be reasonable to assume that they care about their work and want to make it better. Without (constructive) criticism, they would never receive the feedback required for improving. Praise is pleasant and should be given when it's due, but criticism is also useful information.
Edit: grammar
I love how people don't bother providing information that would be easy to provide, the URL to the website would be handy as here it isn't even included in the README on github, then people get all het up when others mention the lack of information.
You don't have to write your things FOR EVERYONE but it isn't unreasonable to suggest that folks are going to link to random projects on github and that other folks may end up on said project through unexpected means, and with no context, or with unexpected context. It probably follows that that _maybe_ spending the time to write _one sentence_ to describe WTF you're looking if you want ANYONE to consume it isn't unreasonable.
The author has a great YouTube playlist[0] as well, bringing you through some basics of their preferred methodology of programming. It's been interesting to follow along and check out how he does things.
Also, I feel like the C configuration opens the door to using other languages too, Lua comes to mind immediately. You can do that in emacs too, but it's not as straightforward.
One last thing. One of my biggest gripes with emacs is the performance (I'm using a rather low-end computer). I'm making the assumption that a moderately-sized pile of C++ will perform better than a huge pile of elisp.
I feel like a couple of posts on HN the past few months have been "X is going open source". It makes me question why projects that aren't open source when they initially release switch over to open source later. I understand keeping a repo private before having a working/stable product, but why release a product as closed source and then open it up later? Why not just keep the product off the market until it is ready to be released and make it open source before or at launch time?
I totally have space that I'm just crazy but as someone who tries to keep my stack as open source as possible I find myself not really interested in products that start closed source and eventually open up. Is it just me?
Just to reiterate: I'd rather a project go open source later vs never.
EDIT: I just realized the context for 4Coder was that it was a "we're ending this product so here's the source for anyone who wants it" -- I am super grateful for closed-source products that do this. But my question is still relevant for other projects that have done what I described above.
vscode to me is simply to bloated. They should have landed like a year and half ago.
Sounds like a handful to manage closed source solo!
Are there then commands that operate on the highlighted extent?
If you double-click a word, it that word highlighted?
Side note: it's funny how formerly closed-source projects always open up to have tons of spaghetti code and bad design planning.
I was curious after you said this, so I took a look at the 4coder source. It looks like very straightforward code. The files are clearly marked so you know exactly what they do, the APIs look simple and reasonable, and they have clearly marked folders containing all platform specific code. I'm not sure why you put this side note here, but it doesn't seem to hold water in this case. The code is definitely not spaghetti, and it looks like it was designed with quite a bit of forethought.
Edit: I would just like to add that I saw the author left several comments about the state of the code in the Readme that imply the code is very unstable. I think developers tend to be very critical of their own code, but when I took a cursory glance at the code from an outside perspective it seems much easier to follow then many other projects I've tried to take a look at. For example, for a quasi-open source project, ffmpeg is extraordinarily complex and hard to follow. So I definitely don't think OSS = super well designed code haha
To your second point: I think it's a matter of size for a project becoming spaghettified. ffmpeg is mature and massive, so it's no surprise it's jumbled at this point. For a project of 4coder's scale, I'd wager that being open source sooner would've benefitted its design.
But, it's in the past. I'm just glad the dev left the code in the community's hands before dropping it. A lot of devs don't even do that, and the project becomes history.
I dunno, I'm looking at their "4coder_base_types.h" header [0] and redefining basic types and builtin keywords for personal preference (yeah I know, static is overloaded) is a serious eyebrow raiser.
[0] https://github.com/Dion-Systems/4coder/blob/62fe17699a99f7d2...
The keywords bit isn't that common, though it could be related to some custom script (e.g. having the editor parsing the "function" keywords) or doc generator.
Finally, big libraries do this as well. Freetype is notorious for typedefing weird stuff like FTPos and all that. It's just one way to model the domain language in the code, and that's fine by me. If the big open source libraries can do it, what's wrong with a small one doing it too?
Assuming you're browsing in an IDE, and that the IDE understands your build system. Github for example doesn't detect that it's a typedef for static. There's also the fact that the keyword `internal` is overloaded, and not in a standard way. For example, does it mean that it's not exported (a la dllexport in msvc).
> In addition, i32 is not an ambiguous typedef. It's way clearer that this is a 32 bit integer than `int` is.
but that's not what the typedef is to, the typedef is to int32_t which is a standard type that is guaranteed to be 32 bits.
> If the big open source libraries can do it, what's wrong with a small one doing it too?
typedef'ing FT_POS is totally different - FT_POS is not redefining a basic type to be used all over the project, it's defining the types used to refer to coordinates. Freetype is also written in C, and is almost 30. You also better hope that when you're using these typedefs that any third party libraries (e.g. free type) also use the same aliases.
It's great that you would fail a code review in your company for that but it's not relevent.
> I DO NOT recommend learning from this codebase, especially not with an uncritical eye. It may be a useful reference for certain algorithms and architectural ideas, and it certainly contains some cautionary tails. But if you are a beginner, I encourage you to aim for more than emulating the style and structure of this codebase.
The editor seems cool regardless.
I had already skimmed the cpp (at least the `build` functions). It’s not necessary for what they’re doing. It could be easily replaced with a shell script. I know because I’ve done something very similar, supporting I think even more build variants and compilers. This is mostly copied from a real script, except I mocked up `build` somewhat, since the real one is slightly more complicated.
build() (mkdir -p "$1" && cd "$1" && shift && “$@“ ; )
...
declare -a gcc=(-std=c89 -g -D_GNU_SOURCE -fpie -pie -fno-strict-aliasing -Wall -Wextra -Wformat=2 -Wstrict-aliasing=2 -Werror)
declare -a clang=(-std=c89 -g -D_GNU_SOURCE -fpie -pie -fno-strict-aliasing -Weverything -Wno-unused-macros -Wno-used-but-marked-unused -Werror)
declare -a debug=(-O1 -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -fno-optimize-sibling-calls)
declare -a asan=("-fsanitize=address,undefined,leak")
declare -a msan=(-fsanitize=memory)
declare -a isan=(-fsanitize=integer)
...
build "$build/x86_64-linux-gnu-gcc-addrsan-debug" gcc "${gcc[@]}" "${debug[@]}" "${asan[@]}" -o example "$src/example.c"
build "$build/x86_64-linux-gnu-clang-debug" clang "${clang[@]}" "${debug[@]}" -o example "$src/example.c"
build "$build/x86_64-linux-gnu-clang-addrsan-debug" clang "${clang[@]}" "${debug[@]}" "${asan[@]}" -o example "$src/example.c"
build "$build/x86_64-linux-gnu-clang-memsan-debug" clang "${clang[@]}" "${debug[@]}" "${msan[@]}" -o example "$src/example.c"
build "$build/x86_64-linux-gnu-clang-intsan-debug" clang "${clang[@]}" "${debug[@]}" "${isan[@]}" -o example "$src/example.c"
...
If you know the compiler flags you want, nothing beats literally just writing them all down in a script, when it comes to debugging issues.
But that's the standard for how to do things on Windows. That's how it works. Sure you might not like it, but personally I don't like the implicit assumption that everything is configured and "there" that your scripts and the OPs scripts assume.
Here's the alternative in cmake though:
cmake_minimum_required(VERSION 3.10)
project(hello_world)
add_executable(app main.cpp)
Here’s part of the powershell version of a build script I have used, where I had fewer build variants, so I didn’t even bother to make a `build` function, I just copy paste the `out=... ; if { ... }` block and change the value of `$out` and which compiler and options are called. Note that you can accomplish this with far fewer variables if you don’t want quite as many build variants as this script supports — it was written as an illustration of how flexible you can make things, rather than how simple things can be, so it supports clang, clang-cl, cl, zig cc, with variants for asan, freestanding, for architectures x86, x64, aarch64:
$ml = @("-nologo","-c","-Zd","-WX","-W3")
...
$clstd = @("-volatile:iso","-permissive-")
$clangcl = @("-nologo","-diagnostics:column","-Z7","-Zo","-FC") + $clstd
$cl = $clangcl + @("-WL","-Gm-","-utf-8")
# -Wall > -W4 but includes very silly things like "function not inlined" for snprintf
$clwx = @("-WX","-W4","-wd4100","-wd4127")
...
$clfree = @("-D","EXAMPLE_FREESTANDING","-Zl","-GS-","-sdl-","-Gs9999999")
$clfreedebug = $clwx + $clodebug + $cldd + $clfree + $clnortti + $clhash + $cllink + $link + $linkfree
...
$out = "./x86_64-windows-free-cl-debug"
if ("all" -in $targets -or (split-path -path $out -leaf) -in $targets) {
new-item -itemtype directory -force $out | out-null
try {
push-location $out
$buildcount++
write-host (split-path -path $out -leaf)
ml64 @ml $src/example-x64.asm
cl "-Fm./example.map" "-Tc$src/example.c" ./example-x64.obj @cl @clfreedebug
} finally { pop-location ; }
}
What's wrong with target_link_options(foo PRIVATE -static-libgcc -static-libstdc++)
I don't understand how that particular powrshell block is more flexible than cmake from what I can see it does less (it's windows specific - mine works on Linux, Mac, windows, and also works with cross compilation toolchains out of the box). If I want to add specific warnings I can use target_compile_options to get exactly the same behaviour.
> won’t suddenly break if you install a second set of compilers for another project,
I'm genuinely curious - have you used cmake? Cmake has sensible defaults but is completely customizable. Cmake uses platform standards - if you overwrite the CC variable it will use that toolchain instead. Cmake has its warts, for sure, but lack of flexibility is definitely not one of them.
I’m always the “build system expert” on my team because of how much experience I have. If working on a team where people know the compilers, and where build times are kept reasonable (so not using lots of templates in C++), then on a practical level I recommend not using a build system at all, and just writing a super simple shell script (unity builds are easier there too). I still recommend CMake sometimes though — especially if the main requirement is just “gimme some machine code, who cares how, and who cares about using ASAN, etc.”, and the second most important requirement is to ship the code to the open source community.
BTW, I mean freestanding as in “does not link to any C library”, rather than “statically links to the C library”.
declare -a free=(-std=gnu99 -DEXAMPLE_FREESTANDING -nostartfiles -nostdlib -nodefaultlibs -ffreestanding -fno-stack-protector)But the minute you introduce someone who is familiar with windows or prefers an IDE workflow this falls apart. You are also limited to the platforms, compilers and IDEs that you write the script to support. That's not flexible, that's inflexible. Also, cmake has supported unity builds out of the box for a few years now [0] and before that cotire existed.
> I mean freestanding as in “does not link to any C library”, rather than “statically links to the C library”.
Ok, great so just use target_compile_optiond in the exact same way as you've just listed the arguments? I don't see how cmake stops you from doing that by architectural decisions at all.
As for editors and whatnot, I’ve worked on teams where people used Visual Studio, vim, CLion, VS Code, via these scripts. Most with full IDE integration, some without (some people don’t use it). The easiest pathway is to generate compile_commands.json — ironically, this is already something extremely close to the script, so it’s trivial to automatically generate from the script.
I was just saying as a postscript that I meant something different by freestanding. I agree that it’s totally orthogonal to your argument and mine.
Then write those arguments in that order with target_compile_options?
> The easiest pathway is to generate compile_commands.json — ironically, this is already something extremely close to the script, so it’s trivial to automatically generate from the script
You keep saying it's trivial to extend it to do X and to do Y, and yet it's even more trivial with cmake - it already does it. At a certain point you've just poorly reimplemented something else
I've never had to add support for a brand new c++ compiler to cmake personally, so I'll have to trust that yes it's easier to modify your she'll svript to support that, but given that 99% of my build systems work is generating IDE files and building with MSVC, GCC and clang (even across servers, mobile devices and consoles), ill continue to recommend the system that works for that rather than a hypothetical new c++ compiler that will likely require more time spent on conforming the code than modifying a cmake file.
I have ported scripts to use `zig cc` (though that uses a gcc/clang-like set of options by design, so easy in CMake also), and `tcc` (again gcc/clang-like, but only supporting a small subset of options, so with a script, I can just remove those arguments and the “port” is done — suppressing options CMake wants to give is harder).
As for poorly re-implementing something CMake already does, I disagree when CMake doesn’t do all that much (CMake’s language is not great at doing much beyond specifying basic target options). Writing compile_commands.json for a gcc toolchain is a one-liner callout to python, just `print(json.dumps({“directory”:sys.argv[1], “arguments”: argv[2:], “file”: argv[-1]}))` given the same arguments as that `build` function from earlier. This tiny extra up-front cost reaps rewards for every ship cycle where you don’t have to fight with the tool, or even learn it in the first place (think about issues like passing -D options to CMake, then reconfiguring the build in the same build dir but with different options — does this always work or do what you expect? in my experience, absolutely not). I won’t complain about the general quality of typical CMakeLists.txt files because the general quality of scripts isn’t great either! But it’s nice to limit the number of poorly taught and therefore poorly written scripting languages involved in the build, and shell is far more generally applicable, so it’s a worthwhile investment compared to CMake/meson/waf/b2/xmake/bazel/whatever else is coming down the pipe. (If you’re a massive organization, we’re talking collaboration across the globe in ways that exceed normal methods of human collaboration, and that result in monumental build times and complexity, then invest in a fancy tool like bazel, it’ll probably be worth it for you).
I’m perfectly happy for people to continue to use CMake, so I’m not saying other opinions are wrong, and I wouldn’t immediately proselytize a team to switch away if I joined it — one of the reasons I don’t tend to use it is because focusing on build tools is a huge time sink, but it’s also a time sink to start a debate about transitioning to a script. But I’m happy not having to deal with it in many situations.
It's also not a common thing for projects like that not to start as FOSS.
- Fun
- Learning new things
- No decades old quirks & constraints through backwards compatibility
- Same concept with fresh ideas & multithreading
Vim/Emacs have a huge community and ecosystem, but they aren't exactly perfect. I don't see anything weird about people writing their own editor.
I'd personally love to have a Python-programmable editor a la Emacs, and if I ever write a text editor, it's gonna be like that.
+ You don't need to learn a bespoke language to customize 4coder (vim_script in vim's case)
It's really a smaller decision compared with the point of view that text files as source code are "holding back our tools - https://dion.systems/dion_format.html
So these guys are really thinking big.
https://books.google.com/books?id=hfpwEAAAQBAJ&lpg=PA75&ots=...
> In Smalltalk there is no such thing as source files...
$ cat fact.st
Stdio stdout
nextPutAll: 100 factorial printString;
nextPut: Character lf.!
SmalltalkImage current snapshot: false andQuit: true!
$ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000"#1 it's a burden of knowledge to shift from the Unix filesystem to the Smalltalk runtime. There... are no files."
https://news.ycombinator.com/item?id=31474424
"Pharo by Example" doesn't need a wrong explanation —
"It may seem like the image file should be the key mechanism for storing and managing software projects, but in practice that is not the case at all. There are much better tools for managing code and sharing software that is developed in a team. Images are useful, but you should be very cavalier about creating and throwing away images."
"2.5 Saving, quitting and restarting a Pharo session" Pharo 9 by Example, page 14
https://books.google.com/books?id=hfpwEAAAQBAJ&lpg=PA75&dq=p...
It's actually a paradigm that works well in many programming languages besides Smalltalk such as Common Lisp, but for some reason seems to be forgotten with "modern" and "trendy" programming languages. Except for.... JavaScript!
I'd guess amongst HN users the share of emacs and vim users might be higher than for developers in general.
It's placed in README