This allows the usage of boxes with basic ANSI SGR colors and formating.
The change was made as a quick hack for myself, so it ended up not super-clean.
The problem here is that before, boxes only had a concept of line->len that would store both the
width of the line and the number of bytes contained since they were assumed to be the same. Now,
there are visible and invisble characters - sometimes the code needs to work with the visible line
length and sometimes with the byte count.
Because of that, at this point the code could use some refactoring to make it a little more
obvious which line length (visible or bytes) is being used at a given time.
So, if anybody feels like cleaning up the mess I introduced - that would be appreciated.
Works with `lolcat -f`
Tested on:
+ debian: xterm, gnome-terminal, terminator, locally and via ssh
+ win64/cygwin: compiled and tested locally and via ssh
+ win64/putty: connected to debian server
Fixesascii-boxes/boxes#65
Currently, tags can be added to the config file, and displayed in the design information.
They are not really understood, though, so no query-by-tag or anything yet.
When boxes is fed text selected in a visual editor, this often means that
the final line of input text has no terminating newline (it's a "partial
line"). This caused an extra blank line to appear in the editor after
running boxes. #57
This commit changes the behavior of boxes so that a newline is only added
at the very end of the output, if there also was one at the very end of
the input.
The previous suggestion I made called `fortran` was for the box. However, older Fortran (i.e., FORTRAN 77) uses `c` as the comment character, not `!`. So, in case someone wants an `f77-box`, move the name to `f90-box`.
Also, a la the `ada-box` and `ada-cmt`, make a `f90-cmt` which does `!` commenting.
boxes.c:1024:31: warning: format ‘%d’ expects argument of type ‘int’,
but argument 3 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
Signed-off-by: Stephen M. Cameron <stephenmcameron@gmail.com>
