> Hi,
> I noticed, that if we store multiple lines in the history at once (as i=
t
> is possible with the current CVS version), the history line is garbeled=
if
> the text becomes very long.
>
> In my little SQL-shell, I sometimes have very long selects, that go ove=
r
> multiple lines. If I enter such a line, add it to the history and then =
go
> up with the cursor (to refetch the last line in the history), that text=
is
> garbeled. Interestingly, the first couple of lines are readable, but
> then only random characters are shown.
> Could it be, that there is some limitation
> of the number of bytes (like 1024) that can be stored per line in the
> history .. in the c-implementation of java-readline ? And if so, is the=
re
> a way to modify this limit somehow ?
Yes, there is a constant called BUF_LENGTH in=20
src/native/org_gnu_readline_Readline.c. A typical quick and dirty=20
implementation :-( of the functions utf2ucs and ucs2utf.
Solution: these functions should allocate a buffer of correct size (a max=
imum=20
of 2*strlen(line) is needed, since utf8 codes ISO-8859-x in at most 2 byt=
es).=20
The calling function should free the memory afterwards.
I could do this next weekend (provided the weatherforecast is correct). L=
et me=20
know if you want to tackle this.
Bernhard
|
