Discussion:
gtk_text_buffer errors & two questions
Serge
2013-10-22 17:23:02 UTC
Permalink
Hello.

gtk_text_buffer errors were due to WITH_OUTPUTSTYLES 1.

I have two questions:
1. Is it possible to change color of commands in output pane?
2. How to get rid of squares and wrong symbols in output pane?
Please see attached screenshots.
Have a nice day.
--
Claws Mail version 3.8.1
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
t***@onepost.net
2013-10-23 01:38:55 UTC
Permalink
On Tue, 22 Oct 2013 21:23:02 +0400
Post by Serge
gtk_text_buffer errors were due to WITH_OUTPUTSTYLES 1.
Then we should try to figure out what was going wrong with that. The style-parsing mechanism was developed and tested using english-language, and there may be some problem with UTF-8 text. And even more so with non-UTF-8 text.
Post by Serge
1. Is it possible to change color of commands in output pane?
Do you mean just the echo/repeat of the running command ? If so, no. That's about the only colour that's hard-coded. Not sure why.
Post by Serge
2. How to get rid of squares and wrong symbols in output pane?
Some (the squares) are control characters, normally for terminal control. Enabling WITH_OUTPUTSTYLES is intended to deal with some of those (it's not a fully-fledged terminal, so the parser's coverage is not comprehensive).

Some may be completely unrecognised text - probably using an encoding different from the one set for your operating environment. Output listings are processed as whole-lines, and converted to UTF-8 according to the user's system settings. Nothing reasonable can be done about mixed encodings. Trying to check and correct the encoding of each character as it's being printed is very slow.

Regards
Tom
Serge
2013-10-23 16:04:05 UTC
Permalink
On Wed, 23 Oct 2013 12:38:55 +1100
Post by t***@onepost.net
Do you mean just the echo/repeat of the running command ? If so, no.
That's about the only colour that's hard-coded. Not sure why.
I think this is bad) because these blue lines are slightly visible on
some screens with black background themes.
Maybe system text color will be much better.
Post by t***@onepost.net
Some may be completely unrecognised text - probably using an encoding
different from the one set for your operating environment. Output
listings are processed as whole-lines, and converted to UTF-8
according to the user's system settings. Nothing reasonable can be
done about mixed encodings. Trying to check and correct the encoding
of each character as it's being printed is very slow.
But as you can see on the 1.jpg screenshot, instead of garbled text
there is must be the same text as in the above and below lines.

And i have another problem - with checked "Use external encoding
converter" option, emelfm2 hangs completely with 100% one core CPU load.
Output:
"...
[DEBUG ] e2_command_run_at (command:file.view,range:2)
[DEBUG ] find an alias for file.view
[DEBUG ] disable refresh, expand macros
[DEBUG ] enable refresh, expand macros 1
[DEBUG ] ret: "hu.txt"
[DEBUG ] e2_action_run (from:, art:file.view)
[DEBUG ] attempted BGL re-lock
[DEBUG ] e2_task_set_data (pid:0,mode:2,command:(null))
[DEBUG ] e2_action_run () ends
[DEBUG ] bad attempt to open BGL
[DEBUG ] immediate-action-thread (ID=140418726659840) started
[DEBUG ] repoint encoding conversion funcs if necessary, before action
starts [DEBUG ] signal handler (signal num:17)
[WARN ] received signal from unrecorded child process (6263)
Killed"

Hangs both 0.9.0 and svn builds.

"enca -L russian -x UTF-8 </path/file" is working properly in terminal.

Have a nice day.
--
Claws Mail version 3.8.1
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
Loading...