Earlier quoted context omitted.
For example: https://github.com/martanne/vis/blob/master/buffer.c bool buffer_prepend0(Buffer buf, const char data) { return buffer_prepend(buf, data, strlen(data) + (buf->len == 0)); } Two function calls plus arithmetics plus step-return. Depending on the debugger interface(eclipse with gdb, vs, etc), one will have to press some form of Step 1 to 4 times to advance the line. Depending on the complier that was suppos…
How would you rewrite it? Would you use a local variable for the result from strlen(), for example?
Build Your Own Text Editor
91–100 of 164 posts
Re: Build Your Own Text Editor
#92Earlier quoted context omitted.
I made significant changes to antirez's kilo editor myself, adding in support for Lua-based scripting. I use that for composing emails, again in a lua-based mail client that I wrote myself. For coding though? I usually use emacs. It's just so damn customizable..
Why are you posting the same thing more than once?
Re: Build Your Own Text Editor
#93I'm curious if anyone here regularly codes in a text editor they wrote themselves? I've often thought of coding one for fun, with no intention to share it, just for the purpose of having a long-term project that evolves along with my skills. I've never made time for it, but I still consider it once in a while.
I do, sort of. I bought a text editor a number of years ago that was very popular. I still maintain it and use it daily and have often thought about putting out a new version. I have it running on many OS's and devices now. I have also added a lot of features specific to what I wanted. I'm not really sure if they are useful to others or not. Example: I have an iPad version where I can use an Apple Pencil and handwrit…
Re: Build Your Own Text Editor
#94marginally relevant: I was looking for a terminal text editor for git commits and other similarly simple tasks: my only requirement is that I can save&leave with ^D. Any suggestions?
$ echo 'cat > "$@"' >editor
$ chmod +x editor
$ GIT_EDITOR=./editor git commit -a
stuff
[master b2d3915] stuff
1 file changed, 1 insertion(+)
You'll need to hit enter before ^D.You can add simple Emacs-like keybindings by changing that into
$ echo 'rlwrap cat > "$@"' >editor
Or just learn ed: $ GIT_EDITOR=ed git commit --amend -a
256
1c
stuff and more stuff
.
w
271
[master c5092a6] stuff and more stuff
Date: Thu Apr 6 12:58:18 2017 +0200
1 file changed, 1 insertion(+)
(the numbers are ed telling me how much was read and written; `1c` means change the first line; `.` means I'm done inserting (go back to command mode) and `w` means write/save; exit with ^D)Re: Build Your Own Text Editor
#95Here's one from the 1980s, which I still use and keep up to date: https://github.com/DigitalMars/me and translated to D: https://github.com/DigitalMars/med
Re: Build Your Own Text Editor
#96Here's one from the 1980s, which I still use and keep up to date: https://github.com/DigitalMars/me and translated to D: https://github.com/DigitalMars/med
Re: Build Your Own Text Editor
#971000 lines of code is considered small. But check this out http://kparc.com/edit.k Under 50 lines for a text editor written in K by the language's author. Way beyond my present understanding, but the promise of very small, powerful code is incredibly attractive.
1) A standard library / set of operators that are a very good fit for the typical domains it works on.
2) Minimizing symbol length.
E.g. I translated one example I saw into Ruby, and ended up with something of similar length once I 1) implemented equivalent methods, 2) dispensed with all idioms for how to write Ruby and went for single character variable names and method names etc.
In other words, there's nothing particularly "magic" there.
K code gets to where it is largely by because its author and users are willing to violate every convention from other languages in terms of how to write and structure code in pursuit of a philosophy that is fundamentally different in terms of e.g. focusing more on code size.
That could be a good thing, but I'm not convinced that the extremely sparse code is worth the (to me at least) extreme lack in readability.
Code golf can be fun in any language, but it seems few of us have gone back to writing other code and decided it's worth aiming for code that small. In fact, I've more than once rewritten code to be longer because it made it easier to read.
That said, there are good parts in terms of language constructs etc. that'd be worth learning from. If only it wasn't so incredibly annoying to decipher the code (yes, I'm sure it gets faster when you get used to it).
Re: Build Your Own Text Editor
#98I'm curious if anyone here regularly codes in a text editor they wrote themselves? I've often thought of coding one for fun, with no intention to share it, just for the purpose of having a long-term project that evolves along with my skills. I've never made time for it, but I still consider it once in a while.
I've spent enough time tweaking, extending, and rewriting emacs lisp that I sometimes feel like I wrote my own emacs.
I have been careful to always carry a recent copy of my .emacs.d around with me on a thumb drive.
Re: Build Your Own Text Editor
#99Earlier quoted context omitted.
https://github.com/jameysharp/corrode/blob/master/src/Langua... Corrode is absolutely incredible. This file is literate Haskell, which means there's more documentation than code (I guess), and it transforms C into Rust.
> This file is literate Haskell, which means there's more documentation than code (I guess) That's the intent, but to the compiler, the meaning of literate Haskell is that comments are the default, and only lines starting with > contain code