As draw_textarea_utf8 loops over each character of the textarea content, it
checks whether the character is on the screen; draws it if so; increments
the screen co-ordinate; and updates the position in the textarea text.
The last step was being skipped when the character was not on the line,
so a line would be drawn from the beginning, even if the left edge of the
textarea is off the screen.
Closes: Bug 835 - Text in textarea is unaffected by horizontal scrolling of
document in UTF-8 mode
If utf8_char2cells isn't told where the string that contains
the given UTF-8 character ends, it computes that itself. Two users
of utf8_char2cells, format_textutf8 and split_line, were calling
utf8_char2cells in a loop without providing the end of the string,
resulting in numerous calls by utf8_char2cells to strlen.
With this patch, format_textutf8 and split_line each find the end
of the string once and provide it to utf8_char2cells.
This particularly improves performance with textareas, since
format_textutf8 is called multiple times each time the user interacts
with the textarea and when it must be redrawn.
Closes: Bug 823 - Big textarea is too slow with CONFIG_UTF8
To use it to test whether that CGI works put the following in your
elinks.conf:
set protocol.file.cgi.policy = 1
set protocol.file.cgi.path = "/path/to/elinks/test/cgi"
Then point ELinks to the print-vars.sh script inside the CGI test directory
in the ELinks source directory.
The quote_level was decremented unconditionally and could become negative
resulting in a negative index after applying "modulus 2". Reproducable
with an HTML file contianing "</q>".
Reported by paakku.
CPPFLAGS was dropped[1] back on 2004-04-24. Then a workaround was
introduced by commit 6d7e9bfe5b to fix
compilation on FreeBSD that used CPPFLAGS to store iconv related flags.
The use of CPPFLAGS with respect to the COMPILE "macro" reappeared in
40e257bedd on 2006-08-05.
This commit makes configure.in print CPPFLAGS and LDFLAGS. Before,
CPPFLAGS and CFLAGS was mixed together in the feature summary. It also
restores the use of CPPFLAGS storing iconv related flags but keeps the
use of the SAVE/RESTORE_FLAGS in the iconv macro.
Reported by Daniel E. Macks <dmacks@netspace.org> on 2005-11-22 in a mail
to elinks-users with the ID: <slrnem7tjs.lvk.dmacks@happy.netspace.org>.
[1] http://pasky.or.cz/gitweb.cgi?p=elinks-history.git;a=commit;h=ebad0e71572b41dac5376e148fe4b1b5cb9ccc33
src/protocol/smb/smb.c: Added #error directives so that this
vulnerable code cannot be accidentally compiled in.
features.conf: Disable CONFIG_SMB by default and explain why.
configure.in: If CONFIG_SMB is enabled, disable it and warn the user.
This is for people who have customized features.conf.
The version checking was recently reworked in commit
14d5ff3b17, however use of 'puts' is wrong
because it returns nil and thus always causes the check to exit with code
1.
The issue was brought up by dalias. Acked on IRC by Thomas Adam.
doc/remote.txt says there must be a nonempty sequence of ASCII
alphabetic characters before the opening parenthesis. Check that
they really are ASCII characters and that the sequence is nonempty.
Thus, elinks -remote '(foo)' now treats the string as an address,
rather than as a command.
UCS_ORPHAN_CELL is currently defined as U+0020 SPACE, which was
already used before this macro, so the behaviour does not change,
but the code seems clearer now.
I searched for ' ' and 32 and 0x20 and \x20, and replaced with
UCS_ORPHAN_CELL wherever UCS_NO_CHAR was involved. However,
some BFU widgets first draw spaces and then overwrite with text;
those will require a more complex fix if UCS_ORPHAN_CELL is ever
changed to some other character.
Be more strict about the format accepted by the ELinks specific extension
to the -remote URL syntax. That is, commands must begin with a nonempty
sequence of ASCII alphabetic characters followed by optional whitespace and
an opening parenthesis. Also, document the syntax.
Fixes bug 830.
When I first read the warning about "NO NATIONAL CHARS SUPPORT!"
I was amazed: XML is based on Unicode, so why would the authors of the
XBEL specification have botched support for those characters? The bug
is actually in the ELinks implementation of XBEL, and it has already
been entered in the ELinks bugzilla. Make the documentation string
refer to that.
Recognize all of 
 
 with any number of leading
zeroes. (Previously only and 
 were supported.) All of
these are case insensitive.
Treat each CR+LF combination ( ) as a single newline.
