Update of bug #14155 (project mc):
Status: Need Info = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #27:
Not sure why you didn't
Follow-up Comment #28, bug #14155 (project mc):
This is getting annoying. I didn't close it because of comment #24.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155
Follow-up Comment #29, bug #14155 (project mc):
Sorry. I took comment #26 as a we can close this report, and thought you
still weren't aware you could close bugs. Well, you can reopen it yourself if
you want.
___
Reply to this item at:
Follow-up Comment #25, bug #14155 (project mc):
Ping.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155
___
Message sent via/by Savannah
Follow-up Comment #26, bug #14155 (project mc):
I guess we can safely close that one . If anyone has any kind of objections
she/he could request that we reopen the bug report.
___
Reply to this item at:
Follow-up Comment #24, bug #14155 (project mc):
I've applied a slightly modified version of mc-xterm-mouse-tweak.patch. The
difference is that the applied patch doesn't try to dereference a NULL
pointer if the COLORTERM environment variable is not set. So, Roland, if you
are reading, please,
Update of bug #14155 (project mc):
Assigned to: leonardjo = ptsekov
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155
Follow-up Comment #22, bug #14155 (project mc):
Another, smaller issue, is that the scrolling happens a screenful at a
time. It would be more intuitive if it scrolled a few lines at a time.
Maybe if other people like the current behaviour it could be made into some
kind of user preference or
Follow-up Comment #23, bug #14155 (project mc):
Pavel Tsekov wrote:
Hi John,
Yeah, sure. You can disable it from the GNOME preferences
I don't see where/how MC is configured in gnome. I run MC on the console or
in xterms, without gnome running. Any more details on how to fix the btn4
btn5
Follow-up Comment #21, bug #14155 (project mc):
Hi John,
Yeah, sure. You can disable it from the GNOME preferences.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155
Follow-up Comment #17, bug #14155 (project mc):
Under rxvt and aterm we should use the ESC[?1000h sequence since they do not
know better. Both can be detected by searching the environment for COLORTERM.
___
Reply to this item at:
Follow-up Comment #18, bug #14155 (project mc):
Eterm understands ESC[?1002h but it behaves as if it was given ESC[?1000h so
I suggest that we use ESC[?1000h.
A patch is on the way.
___
Reply to this item at:
Follow-up Comment #19, bug #14155 (project mc):
See attached patch. Mouse should work fine with rxvt, aterm, Eterm, xterm,
gnome-terminal, konsole... At least that's what I've tested.
___
Additional Item Attachment:
File name:
Follow-up Comment #20, bug #14155 (project mc):
Hi there,
BTW, are you aware that the 'F10' keyboard shortcut in gnome-terminal doesn't
work: F10 seems to be reserved for accessibility purposes for activating the
GUI menu bar in GNOME programs.
Update of bug #14155 (project mc):
Status: Fixed = Need Info
Open/Closed: Closed = Open
___
Follow-up Comment #15:
The second patch broke
anonymous wrote:
Follow-up Comment #7, bug #14155 (project mc):
hey everyone. ok so this problem had been bugging me too. and i see the patch
fixed it and for that I am very grateful.
but now it appears something else has broke, the situation is this;
i use Eterm for my terminal. I noticed
Update of bug #14155 (project mc):
Status: Ready For Test = Fixed
Assigned to:None = leonardjo
Open/Closed:Open = Closed
Follow-up Comment #9, bug #14155 (project mc):
Well, I suppose Eterm is not properly emulating xterm mouse reporting. I'll
try to find an Eterm binary or source and see what's wrong. Btw when you run
Eterm without doing symlink magic and setting TERM manually what is the value
of TERM ?
Follow-up Comment #10, bug #14155 (project mc):
Hello,
It is not very clear from your comments which combination patch/terminal
emulator/TERM work or doesn't work. Anyway, I tried
to run MC (CVS) under Eterm 0.9.3 and it works fine - I have mouse wheel and
I have function keys . I don't have
Follow-up Comment #11, bug #14155 (project mc):
If it is not clear - you have to enable X11 mouse reporting in Eterm. This is
done from the Eterm menu - Terminal - Toggles - X11 Mouse Reporting.
___
Reply to this item at:
Follow-up Comment #12, bug #14155 (project mc):
If it's of any assistance, I've checked the behaviour of PuTTY with the first
attached patch and it works perfectly -- function keys, mouse, etc fine.
Regarding the second patch, I haven't tested that one yet. My Microsoft
Optical Intellimouse
Follow-up Comment #13, bug #14155 (project mc):
The second patch does enable dragging - which is you press a button down and
move up or down the mouse. By doing this what you want can be accomplished .
___
Reply to this item at:
Follow-up Comment #8, bug #14155 (project mc):
just noticed something else,
i applied the patch to 4.6.1 at first, and I didnt have function keys or
mouse in Eterm, but all was fine in xterm.
I decided to download and apply the patch to 4.6.0, and now I have function
keys in Eterm, but no
Update of bug #14155 (project mc):
Status: Fixed = Ready For Test
Open/Closed: Closed = Open
___
Follow-up Comment #6:
Committed the mouse
Hello,
On Sat, 27 Aug 2005, Leonard den Ottolander wrote:
Committed the mouse wheel no click patch, fixed the ChangeLog entry and CVS
log entries.
The other patch should still be reviewed.
No problem, but by whom ? I hardly see anyone interested in reviewing
patches. And of course the main
Hello,
On Thu, 25 Aug 2005, Leonard den Ottolander wrote:
Must be my problem as well. Sorry for the mix up. I'll fix it once you
mail the change log entry. Plus I'll have a closer look to find the
second patch ;) .
The two patches can be found in the section 'Attached files' at the bottom
of
Follow-up Comment #4, bug #14155 (project mc):
As about slow-scrolling mouse wheel you can try dragging the mouse up/down
with a pressed button. This scrolls up/down one line at at time.
___
Reply to this item at:
Follow-up Comment #5, bug #14155 (project mc):
... using the attached patch ( mc-xterm-mouse-enable-drag.patch ) :)
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155
Additional Item Attachment, bug #14155 (project mc):
File name: mc-xterm-mouse-enable-drag.patch Size:1 KB
Support for GPM_DRAG when using xterm mouse reporting
http://savannah.gnu.org/bugs/download.php?item_id=14155item_file_id=2860
___
Update of bug #14155 (project mc):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
Platform Version:GNU/Hurd = All
Hello,
Update of bug #14155 (project mc):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
Platform Version:GNU/Hurd = All
Leonard you got it
Update of bug #14155 (project mc):
Release: 4.6.0 = All versions
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155
Follow-up Comment #3, bug #14155 (project mc):
I tested this patch and it worked fine (I applied the patch to the
4.6.1-1.FC3 src rpm). Thanks very much!
JP
___
Reply to this item at:
URL:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14155
Summary: 4.6.1: mouse wheel strangeness
Project: GNU Midnight Commander
Submitted by: johnpye
Submitted on: Wed 08/17/05 at 07:47
Category: Core
Follow-up Comment #1, bug #14155 (project mc):
I should add that I'm using PuTTY on Win 2K to access an FC3 box remotely.
But everything works find with Vim and any other mouse-happy Curses apps.
JP
___
Reply to this item at:
35 matches
Mail list logo
