Re: gtk_text_buffer errors & two questions

  • From: Serge <omoikane@xxxxx>
  • To: emelfm2@xxxxxxxxxxxxx
  • Date: Wed, 23 Oct 2013 20:04:05 +0400

On Wed, 23 Oct 2013 12:38:55 +1100
<tpgww@xxxxxxxxxxx> wrote:


> 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.

> 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


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: