h  k sz cs  p st  v 
     1  2  3  4  5  6 
  7  8  9 10 11 12 13 
 14 15 16 17 18 19 20 
 21 22 23 24 25 26 27 
 28 29 30 31

This page documents the patches made in SzSzI to JOE 3.5 (http://joe-editor.sourceforge.net/). The patches were made by Péter Szabó.

Download i386 binary package for Debian Sarge starting from http://www.szszi.hu/~pts/joe/

How to apply the patches and recompile joe

$ wget http://www.szszi.hu/~pts/joe/joe-3.5.tar.gz
$ wget http://www.szszi.hu/~pts/joe/pts-joe-3.5-01-misc.patch
$ wget http://www.szszi.hu/~pts/joe/pts-joe-3.5-02-preprocessor.patch
$ tar xzvf joe-3.5.tar.gz
$ (cd joe-3.5 && patch -p1 <../pts-joe-3.5-01-misc.patch)
$ (cd joe-3.5 && patch -p1 <../pts-joe-3.5-02-preprocessor.patch)
$ (cd joe-3.5 && ./configure)
$ (cd joe-3.5 && make)
$ su -c 'cd joe-3.5 && make install'

misc.patch

Download from http://www.szszi.hu/~pts/joe/pts-joe-3.5-01-misc.patch

This patch fixes a few bugs and quirks, and also adds a few small features. If necessary, we can split this patch to several smaller patches.

Bugfixes:

• pfcol() is updated so it now doesn't move the cursor to the nearest character boundary while computing p->col.
  • The fix fixes the issue when the column field (%c) in status line gets updated (pfcol() called from stagen() called from disptw() called from edupd() called from ttgetc() called from edloop() called from main()), and the cursor is not standing on a proper UTF-8 charcacter boundary (possibly in hex mode).
  • The original implementation had a side effect: it changed b->byte etc., moving the cursor forward to the next boundary (which was a side effect of `while (p->byte < pos) pgetc(p);'). This was certainly incorrect, because it caused the cursor to move actually rightwards with `ltarw' command (which is supposed to move it leftwards), when that command was executed along with a status line refresh.
  • The fix here changes only p->col and p->valcol, other attributes (especially p->byte) are left unaffected. The behaviour of the fix is identical to the original when p is standing on UTF-8 character boundary. On the other hand, if p is in the middle of an UTF-8 character, p->col is set to the column at the beginning of that character.
• Fixed a segfault in docmd() and exmacro() when an empty (whitespace) macro is specified.
• Fixed a typo (> 255) in macro.c.
• Fixes in utypeb_raw() for proper insertion of bytes in hex and nonhex mode.
• time_rc was not initialized in main(). Bug found using valgrind(1).
• Fixes in main() to support .joerc file and folder names containing spaces.
• Small fixes to procrc() for handling long configuration lines.

New or improved features:

• ustat() (the stat command) now displays the number of bytes the current UTF-8 character occupies.
• If the environment variable NO_JOERC is present, system configuration files (such es /etc/joe/joerc) are not parsed. (Many functions affected.) The reason for this improvement is that on some systems JOE configuration files are completely bogus, so the user should be able to tell JOE to ignore those files and read configuration from the user's home directory instead.
• Ditto for the JOE syntax highlighting configuration files.
• The configuration file line maximum line length is increased from 1024 to 4096 in procrc().
• If a configuration file line is too long, an error message is displayed, the line is processed truncated, and line numbering continues working. Modified procrc().
• New built-on commands fwrdhist (ufwrdhist()) and bkwdhist (ubkwdhist()) are provided. These commands are useful in history buffers. They jump to the next or previous line, respectively, which starts with the same string as the current line up to the cursor. This is equivalent to bash's history-search-backward and history-search-forward commands, which are bound to the PageUp and PageDown keys in /etc/inputrc on modern Linux distributions. Keyboard bindings added to builtins.c.
• docmd() now reports more detailed errors if a command missing or not found.
• Configuration lines are now also read from $HOME/.joe/rc (in main.c). This is so all relevant configuration files can be put by the user into $HOME/.joe and added to a personal CVS.
• Added functionality to uquote() (the quote command) so that now it can insert bytes (not only characters). Byte insertion is activated by pressing y first. Byte insertion works in hex and non-hex mode, too.
• Added support for the OVERRIDE_JOE_P35RC environment variable, which, when specified, sets the file name of the .joerc file to use. This is a convenience feature for experimenting with alternative .joerc files.

Implementation improvements:

• prgetc() is made faster for UTF-8 buffers.
• p_goto_eol() is made faster with o.crlf and UTF-8 buffers.
• head comments added to brzs(), pfwrd() and pbkwd() to b.h.
• The .joe folder name is not hard-wired into the .c files anymore. Now it is specified in Makefile.in, and passed to the C code as #define DOTJOEDIR ".joe" .
• Some math functions (in umath.c) such as m_cbrt() are skipped when compiling with uClibc, because these functions are not available.
• my_getcap() now doesn't reopen the same termcap file multiple times (for tc=)
• Added documentation fixes to utf8.c.
• Added preprocessor support (preprocess_rc_line()) to procrc(). Currently preprocessing does nothing.

preprocessor.patch

Download from http://www.szszi.hu/~pts/joe/pts-joe-3.5-02-preprocessor.patch

This patch adds a preprocessor to the .joerc configuration files. Preprocessing is done separately on one each line read from configuration files. Only lines starting with $ are affected (others are left unchanged). The affected lines are replaced by the string returned by the preprocessor, and the replaced line is parsed by JOE as a regular configuration file line.

The rationale for a preprocessor is to allow JOE's configuration depend on the environment variables. For example, the following configuration lines turns off syntax highlighting for the terminal types xterm and rxvt, and turn it on for all other terminals:

-highlight
$()$(if(iseq(getenv("TERM"),"rxvt"),"--highlight"))
$()$(if(iseq(getenv("TERM"),"xterm"),"--highlight"))

The first line (-highlight) turns on syntax highlighting, and the other two lines conditionally turn it off (with --highlight) if the value of the TERM environment variable is rxvt or xterm, respectively.

Here is a more compact solution:

$(if(or(iseq(getenv("TERM"),"xterm"),iseq(getenv("TERM"),"rxvt")),"-"))-highlight

Both solutions demonstrate that the preprocessor syntax is quite ugly. A nicer syntax would be:

joe.options.highlight=
  ((t=joe.getenv("TERM"))=="xterm" || t=="rxvt") ? false : true

Adding scripting support (e.g. lua) for both the configuration file and runtime macros would be a proper solution to avoid this ugliness. This patch focuses on easy-to-implement and yet powerful-enough configuration file preprocessing.

Definition of the preprocessor syntax:

• Lines not starting with $ are not preprocessed.
• Preprocessor substitutions have the form $(INSTR), where INSTR is the preprocessor instruction. All other parts of the line are kept intact.
• If INST is empty, the replacement is empty.
• If INST is a single character (except for the close paren), the return value is that character.
• If INST is an environment variable name of at least 2 characters (matches regexp [_A-Za-z0-9]{2,}), the replacement is the value of the environment variable.
• Otherwise, INST is evaluated as a list of preprocessor expressions (see below) separated by ,s, and the replacement is the concatenation of the evaluated values of the expressions.
• It is not possible to return multiple lines in a preprocessor substitution using newline characters.

Definition of the preprocessor expression syntax:

• Whitespace is significant. The safest way is to avoid whitespaces everywhere except inside strings.
• Temporary values and the final result are stored in a 4096-byte long buffer. If it overflows, an error message is issued (Preprocessed line too long, truncated), and possibly other errors will also be reported.
• A proper string constant starts with ", ends with ", and all \ and " inside it must be escaped by preceding it with a \.
• A preprocessor expression is a string with parens (characters ( and )) properly nested. Parens preceded by an odd number of \s are not considered. Proper strings constants inside the expression are also not considered.

Evaluation of expressions:

• All values are 8-bit strings.
• Expression evaluation is binary-safe, i.e. strings can contain the character 0.
• String constants evaluate to their value (except for delimiting "s and escaping \<code>s). There is no magic, i.e. <code>\t doesn't get converted to a tabulator.
• An expression preceded by a ! is evaluated and then negated. The negation of the empty string is the string 1. The negation of any other string is the empty string.
• qq(STRING) is evaluated as the string constant "STRING" (but the parens of the former must be nested properly).
• (EXPR1,...) evaluates to the concatenation of the evaluation of its arguments.
• All other expressions are function calls. The general function call syntax is: FUNCTIONNAME(ARGUMENT1,ARGUMENT2,...) . Whitespace is significant.
• answer() evaluates to 42.
• getenv(VARNAME) evaluates its argument, and evaluates to the value of the environment variable named VARNAME, or an empty string, if the variable is not defined.
• concat(STRING1,...) evaluates its aguments, and evaluates to the concatenation of the restults.
• iseq(STRING1,STRING2) evaluates its arguments, and evaluates to 1 if the results are equal strings. Otherwise it evaluates to the empty string.
• isglob(STRING,GLOB) evaluates its arguments, and evaluates to 1 if the string matches the glob. Otherwise it evaluates to the empty string. All characters in glob match only themselves, except for ?, which matches any single character; and *, which matches any string (empty or not).
• if(CONDITION) evaluates its CONDITION argument, ignores the result, and evaluates to the empty string.
• if(CONDITION,TRUEBRANCH) evaluates its CONDITION argument, and if the results nonempty, it evaluates to the evaluation of its TRUEBRANCH argument. Otherwise, it evaluates to the empty string.
• if(CONDITION,TRUEBRANCH,FALSEBRANCH) evaluates its CONDITION argument, and if the results nonempty, it evaluates to the evaluation of its TRUEBRANCH argument. Otherwise, it evaluates to the evaluation of its FALSEBRANCH argument.
• or(EXPR1,...) evaluates its arguments left-to-right up to the first non-empty result, and evaluates to that result. If all results are empty, it evaluates to the empty string. Because of the up to above, this is called lazy evaluation.
• and(EXPR1,...) evaluates its arguments left-to-right up to the first empty result, and evaluates to that result (empty string). If all results are non-empty, it evaluates to the last result. Because of the up to above, this is called lazy evaluation.
• An error is displayed if any other function is attempted to be called.