And then: “Don't use 'char' for number of lines” (2014: <a href="https://git.kernel.org/cgit/editors/uemacs/uemacs.git/commit/?id=8841922689769960fa074fbb053cb8507f2f3ed9" rel="nofollow">https://git.kernel.org/cgit/editors/uemacs/uemacs.git/commit...</a>)
"32,767 characters in a line should be enough for anyone."<p>I guess there's one constant with humans and infrastructure - people will always find ways to hit its limits.
This is actually an unfortunate patch... it rearranged lines for no particular reason, and scrambled the comments without updating them: they were multi-line sentences and referenced each other's positions.<p>The original code:<p><pre><code> struct line *b_dotp; /* Link to "." struct line structure */
short b_doto; /* Offset of "." in above struct line */
struct line *b_markp; /* The same as the above two, */
short b_marko; /* but for the "mark" */
struct line *b_linep; /* Link to the header struct line */
</code></pre>
The new code:<p><pre><code> struct line *b_dotp; /* Link to "." struct line structure */
struct line *b_markp; /* The same as the above two, */
struct line *b_linep; /* Link to the header struct line */
int b_doto; /* Offset of "." in above struct line */
int b_marko; /* but for the "mark" */
int b_mode; /* editor mode of this buffer */</code></pre>
> And if you have a line that is longer than 2GB, you only have yourself to blame.<p>This is why I like languages like Lisp: by default, integers are only limited by the amount of memory available (as an example: (- (expt 2 1024) (expt 3 27)) → 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356321998626652229).<p>For efficiency one can of course limit things to fixnums, and in a kernel one would want to be careful not to let reading a file eat all memory — but that's all doable in a Lisp.
For structs where there are only a dozen or so in memory at any one time, this makes sense.<p>For structs where there are thousands, or millions, in memory using the smallest type required to get the job done will improve performance because you will fit more data into the cache.
I wonder if uemacs is now that rarest of beasts, a piece of software that is actually _done_.<p>Edit: apparently it has no undo. The rules:<p>1) Linus does not make mistakes<p>2) In the event of Linus making a mistake, see rule 1<p>3) ...<p>4) git reset --hard HEAD
This reminds me of my first job (in ECAD/EDA) where microemacs was part of the design process. We had microemacs "programs" (like macros) which post-processed the output from other CAD tools. Microemacs had an internal C-like (interpreted) language, and combined with the fact that it ran on DOS and Windows 3.1 made it sort of suitable for this. However I really hope those have been replaced now.