Description of problem: On tabs and trailing spaces cursor indicated current position is invisible. More info and patches available on upstream bugtracker: https://savannah.gnu.org/bugs/?13146
Still applies to mc-4.6.2-9.pre1.fc11.x86_64.
> More info and patches available on upstream bugtracker: > https://savannah.gnu.org/bugs/?13146 If not hard - please go to http://www.midnight-commander.org/trac - it's now official bugtracker for mc. For this bugreport (#13146) present ticket: http://www.midnight-commander.org/ticket/113
How I can see this bug fixed. Jindrich Novy please, can you include this fixes and update mc?
Slava Zanko, thank you for the comment.
> How I can see this bug fixed. Jindrich Novy please, can you include this fixes > and update mc? well.. current development tree is very different to mc-4.6.* - for example, we have more acceptable solution to support of UTF-8 (no have '#ifdef...#endif' stuff). Some patches from git-repository may be incompatible with used version of mc in Fedora distro. Also, current version in 'master' still buggy - too much open bugs :(. And finally, we (midnight-commander.org) don't have official approval to use the name 'Midnight Commander' (mc in savannah(CVS) official mainstream at now). But bugtracker on Savannah now closed and there is a message about official bugtracker in m-c.o IMHO, the old scheme of development (non-fast review patches in devel-maillist) is not acceptable at this time. Too much bugs accumulated in mc - need to fix (and fix as fast). But developers of official mainstream wants to review any our patch in maillist and approve them (one-by-one). This good, I don't argue - project history will stay more clean. But we have more than 800 patches in 4 months (since latest 4.6.2-pre1 from official CVS). Is someone want to wait to approve all patches? :( P.S. Sorry for the many words, just wanted to explain the situation. :)
Hm... If it fully incompatable with Fedora version and have many advantages, may be you find resonable release it say as mc-7.0 and push in Fedora new generataion like mc7?
(In reply to comment #3) > How I can see this bug fixed. Jindrich Novy please, can you include this fixes > and update mc? Hi, sure, most of them are already applied in the UTF-8 patch in Fedora already. I'll sync it with the upstream so that we don't differ too much. Maybe together with updating mc to non-prerelease 4.6.2 :)
(In reply to comment #5) > > How I can see this bug fixed. Jindrich Novy please, can you include this fixes > > and update mc? > > well.. current development tree is very different to mc-4.6.* - for example, we > have more acceptable solution to support of UTF-8 (no have '#ifdef...#endif' > stuff). Nice to see an actual work being done on mc upstream :) Are there any plans to have a release from the development tree any time soon? Do you use patches based on these by Rostislav Benes? Or do you continuously adopt the Fedora UTF-8 patch?
> If it fully incompatable with Fedora version and have many advantages, In fact, we are compatible via set of patches ;) > may be you find resonable release it say as mc-7.0 and push in Fedora new generataion like mc7? Better choise: mc+ or simple increase epoch of rpm-package. :) > I'll sync it with the upstream so that we don't differ too much. Cool. FUI: contrib/dist/redhat contain spec-file for build rpm-package. If something you don't like in this file - we are glad to see bugreport from you :) > Maybe together with updating mc to non-prerelease 4.6.2 :) Hmmm.. Actually, ms-4.6.2 was not very good release. With regard to the current 'master' branch, need to fix some opening bugs (approved and wait for vote) - and this may mean prerelease version (mc-4.7-pre1). Ops, sorry - mc+-4.7-pre1 :) > Are there any plans to have a release from the development tree any time soon? We don't have exact date of release. Because lot of bugs need to fix, we want to release out good (as possible) program. But if needed - current 'master' branch always mean 'ready to prerelease'. In future, i hope, this branch will mean 'ready to release', but now it impossible - too much bugs :(. > Do you use patches based on these by Rostislav Benes? Yes > Or do you continuously adopt the Fedora UTF-8 patch? No, sorry.
Ok, mc is nowupdated to mc-4.6.2 in rawhide :) Pavel, could you please check whether everything is fine with this release for Fedora 10? Here is a link to the new mc packages: http://koji.fedoraproject.org/koji/taskinfo?taskID=1378991 I will release an update for F10 if the feedback is positive.
(In reply to comment #9) > > I'll sync it with the upstream so that we don't differ too much. > > Cool. FUI: contrib/dist/redhat contain spec-file for build rpm-package. If > something you don't like in this file - we are glad to see bugreport from you > :) ;) Alright, I'll have a look and send you my comments. I actually spotted a .spec file among mc sources but newer happen to look inside :) > > Do you use patches based on these by Rostislav Benes? > Yes > > > Or do you continuously adopt the Fedora UTF-8 patch? > No, sorry. Good news. Rostislav's patches are better designed so it will be a happy day for me if I finally get rid of the ugly UTF-8 patch :)
> Good news. Rostislav's patches are better designed so it will be a happy day for me if I finally get rid of the ugly UTF-8 patch :) The day has come - just try to use 'master' branch :)
(In reply to comment #10) > Ok, mc is nowupdated to mc-4.6.2 in rawhide :) > > Pavel, could you please check whether everything is fine with this release for > Fedora 10? Here is a link to the new mc packages: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1378991 > > I will release an update for F10 if the feedback is positive. I was tested it. Unfortunately situation is the same - nothing happened. Cursor still invisible.
What terminal type you use? - native text-mode console - konsole (KDE) - gnome-terminal - rxvt - xterm - xfce-terminal - ... ?
Created attachment 345709 [details] screenshot ... or is it this case when the cursor is nearly invisible?
Created attachment 345716 [details] mcedit in konsole Plese note I'm not use konsole and it is default setting.
(In reply to comment #14) > What terminal type you use? I try in several now: > - native text-mode console Even in this. On text console. > - konsole (KDE) On konsole cursor visible, but it is use absolutely different scheme, as I can understand and even background of mcedit is lightblue. See screenshot. Commonly each day I use tilda, but it is based on standard vte. Also I check it in RoxTerm - Not visible in "Default" colour scheme, but viwible in colour scheme "Gtk". All by default. > - gnome-terminal In gnome-terminal not visible > - rxvt > - xterm In xterm visible. > - xfce-terminal In Terminal it is visible now.
I don't sure that this mc bug... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469251 Same trouble.
Hm... We can think what it is a some terminal-emulator bug off course, but I think opposite: If it is not worked in standard linux console (even without X) a working terminal just have workaround for that. Or not?
As I understood, some terminals show color "brightblue" as "blue". Cursor will blinking(or shown in revert colors) between "foreground" and "background" colors. Therefore on some terminals we don't see cursor and tabs&spaces highlighting. Try to change color in ~/.mc/ini file: ... [Colors] base_color=editwhitespace=black,blue xterm= color_terminals= ... And tell me, what you see. Then change color to: ... [Colors] base_color=editwhitespace=brightblue,blue xterm= color_terminals= ... Is cursor visible?
My ~/.mc/ini does not contain section [Colors] at all. I search in package mc, and it also does not contain: $ rpm -ql mc| grep -i ini /etc/mc/extfs/extfs.ini /etc/mc/extfs/sfs.ini After, I try add [Colors] base_color=editwhitespace=brightblue,blue at the and of file. But nothing happened. If I need try something, please provide full code what I should try. And, Slava Zanko, Jindrich Novy, really you can't reproduce this behaviour on yours machines??
> If I need try something, please provide full code what I should try. Ok, follow step-by-step: as root, install git package (if don't installed) # yum install git May be, you will need to install some other packages: # yum install slang-devel glib2-devel autoconf automake make gcc gettext glibc-headers I don't know, what packages you have already installed. Install all needed, plz. Then as user, run commands: $ mkdir -p ~/src $ cd ~/src $ git clone git://midnight-commander.org/git/mc.git $ cd mc $ ./autogen.sh $ ./configure --prefix=$(pwd)/INSTALL_ROOT --with-samba --with-x --enable-charset $ make && make install You will have installed mc into ~/src/mc/INSTALL_ROOT dir. Try to run: $ ~/src/mc/INSTALL_ROOT/bin/mc > And, Slava Zanko, Jindrich Novy, really you can't reproduce this behaviour on yours machines?? Behaviour reproduced on my Fedora-8 (at work) in text-mode linux console. At home I have installed Fedora-10, I'll try to check again at evening (at home). But I don't sure that change default color in sources is a good way. Some people will be happy, some - not. Relative to mc-4.6, default color may be changed by patch: diff --git a/src/color.c b/src/color.c index 1ef19d7..c81ec71 100644 --- a/src/color.c +++ b/src/color.c @@ -166,7 +166,7 @@ static const char *default_colors = "editnormal=lightgray,blue:" "editbold=yellow,blue:" "editmarked=black,cyan:" -"editwhitespace=brightblue,blue:" +"editwhitespace=black,blue:" "errdhotnormal=yellow,red:" "errdhotfocus=yellow,lightgray"; But is this better? I don't sure. In master (from git) you have several ways: 1) globally, right now: change /etc/mc/mc.lib (just add [Colors] section) 2) globally, for new users only: add into /etc/skel/.mc your changed ini-file 3) locally, right now: change ~/.mc/ini file
Pavel, I'm unable to reproduce the cursor disappearing completely, the only thing I see is displayed in comment #15. I can see the cursor in the non-X text linux console as well.
Jindrich, have you tried running mc in gnome-terminal?
(In reply to comment #24) > Jindrich, have you tried running mc in gnome-terminal? Nope, tried it just now and the cursor is indeed invisible in gnome-terminal. xterm (which I use) is fine. It looks like gnome-terminal bug to me. Let's ask someone from the gnome-terminal side.
Created attachment 345826 [details] example of highlighting In text-mode linux console (without Xorg) cursor stay invisible (Fedora-10, latest updates). In gnome-terminal cursor invisible too. :( Hm... Is better color for tabs&spaces highlight black-on-blue rather than brightblue-on-blue? See attach as example
(In reply to comment #22) > > If I need try something, please provide full code what I should try. > Ok, follow step-by-step: > > as root, install git package (if don't installed) > # yum install git [snip] Ok, tank you vary much :) I didn't mind such full explanation! I'm maintainer, and pointing what you mean compile it from git (with its URL off course) that would be quite sufficient. But, as I firstly undarstood you, I can do it only in my own config ~/.mc/ini for the current (koji build listed before) version. And I ask what I should place in it to check. If check got positive results, then we can continue thinking and diskuss about steps to resolve problem globaly.
> Ok, tank you vary much :) I didn't mind such full explanation! I'm maintainer, Ops, sorry, man, I was don't know your level of expirience. Detailed solution I did just in case... :) > But, as I firstly undarstood you, I can do it only in my own config ~/.mc/ini Well.. for testing I'm have account named 'test' on my computer... and turned off 'Autosave' checkbox in config. > for the current (koji build listed before) version. > And I ask what I should place in it to check. I don't know, is koji can direct take a project from git-repo (not from tarballs only)? If yes - this would be cool. > If check got positive results, then we can continue > thinking and diskuss about steps to resolve problem globaly. Ok, I'm awaiting. P.S, Sorry for detailed solution again. I'm really did not want to offend... :(
(In reply to comment #28) > > Ok, tank you vary much :) I didn't mind such full explanation! I'm maintainer, > Ops, sorry, man, I was don't know your level of expirience. Detailed solution I > did just in case... :) No problem! I say it only for hte information. And can you provide more info what I should ad in my ~/.mc/ini in [Colours] section to resolve this problem localy? Do that helped you?
Bug in upstream filled: http://www.midnight-commander.org/ticket/385
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
It still reproducible on my Fedora 11 and mc-4.6.99.3-0.9.52.gd40065d.i586 for example in tilda. But, related bug is not anymore.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Still happens on F13 also with other terminals using the vte.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I suppose it is fixed now.