[PATCH] eliminate buffer in screen.c

2005-08-26 Thread Bart Oldeman

Hi,

this patch was inspired by the UTF8 patch used by various distributions.
This is just a clean up: I realized that buffer[] in repaint_file is 
unnecessary. Instead of formatting into this buffer and then using addstr() one 
can just addstr and printw directly.


Just for the record: I (but then I'm an outsider, so this opinion can be 
completely worthless, take it with a big grain of salt ;) don't think using 
arrays of wchar_t (like in ecs.c) is the right approach for mc, at least 
outside the editor. Rather strings can just be kept UTF8 (or a few other mb 
encodings such as EUC-JP perhaps, but Slang only supports UTF8, that would be 
ncurses only then).


What is needed (IMHO) are a few support functions that calculate the width of a 
(partial) multibyte string, and the byte length of a substring that matches a 
certain width. It's the width that matters namely, not the number of characters 
in the corresponding wchar_t string: think of double-width and combining 
characters.


Bart

2005-08-27  Bart Oldeman  <[EMAIL PROTECTED]>

* screen.c (add_permission_string): Use const for dest.
* screen.c (to_buffer): Rename to add_string. Output directly to
  the screen instead of storing the output into a buffer.
* screen.c (format_file): Rename to display_file. Eliminate dest
  buffer.
* screen.c (repaint_file): Eliminate buffer.

--- screen.c.~1.216.~   2005-08-27 15:51:38.0 +1200
+++ screen.c2005-08-27 18:48:23.0 +1200
@@ -137,7 +137,7 @@

 /* This code relies on the default justification!!! */
 static void
-add_permission_string (char *dest, int width, file_entry *fe, int attr, int 
color, int is_octal)
+add_permission_string (const char *dest, int width, file_entry *fe, int attr, 
int color, int is_octal)
 {
 int i, r, l;

@@ -450,15 +450,12 @@
 { "dot",   1,  0, J_RIGHT,   " ",  0, string_dot, NULL },
 };

-static char *
-to_buffer (char *dest, int just_mode, int len, const char *txt)
+static void
+add_string (int just_mode, int len, const char *txt)
 {
 int txtlen = strlen (txt);
 int still, over;

-/* Fill buffer with spaces */
-memset (dest, ' ', len);
-
 still = (over=(txtlen > len)) ? (txtlen - len) : (len - txtlen);

 switch (HIDE_FIT(just_mode)){
@@ -475,15 +472,11 @@

 if (over){
if (IS_FIT(just_mode))
-   strcpy (dest, name_trunc(txt, len));
+   addstr (name_trunc(txt, len));
else
-   strncpy (dest, txt+still, len);
+   printw ("%*s", len, txt+still);
 } else
-   strncpy (dest+still, txt, txtlen);
-
-dest[len] = '\0';
-
-return (dest + len);
+   printw ("%*s%-*s", still, "", len-still, txt);
 }

 static int
@@ -537,14 +530,12 @@
 return (NORMAL_COLOR);
 }

-/* Formats the file number file_index of panel in the buffer dest */
+/* Displays the file number file_index of panel */
 static void
-format_file (char *dest, int limit, WPanel *panel, int file_index, int width, 
int attr, int isstatus)
+display_file (WPanel *panel, int file_index, int width, int attr, int isstatus)
 {
 int  color, length, empty_line;
 const char *txt;
-char *old_pos;
-char *cdest = dest;
 format_e *format, *home;
 file_entry *fe;

@@ -571,26 +562,21 @@
else
txt = (*format->string_fn)(fe, format->field_len);

-   old_pos = cdest;
-
len = format->field_len;
if (len + length > width)
len = width - length;
-   if (len + (cdest - dest) > limit)
-   len = limit - (cdest - dest);
if (len <= 0)
break;
-   cdest = to_buffer (cdest, format->just_mode, len, txt);
length += len;

 attrset (color);

 if (permission_mode && !strcmp(format->id, "perm"))
-add_permission_string (old_pos, format->field_len, fe, attr, 
color, 0);
+add_permission_string (txt, format->field_len, fe, attr, 
color, 0);
 else if (permission_mode && !strcmp(format->id, "mode"))
-add_permission_string (old_pos, format->field_len, fe, attr, 
color, 1);
+add_permission_string (txt, format->field_len, fe, attr, 
color, 1);
 else
-   addstr (old_pos);
+   add_string (format->just_mode, len, txt);

} else {
 if (attr == SELECTED || attr == MARKED_SELECTED)
@@ -614,7 +600,6 @@
 {
 intsecond_column = 0;
 int   width, offset;
-char   buffer [BUF_MEDIUM];

 offset = 0;
 if (!isstatus && panel->split){
@@ -643,7 +628,7 @@
widget_move (&panel->widget, file_index - panel->top_file + 2, 1);
 }

-format_file (buffer, sizeof(buffer), panel, file_index, width, attr, 
isstatus);
+display_file (panel, file_index, width, attr, isstatus);

 if (!isstatus && panel->split){
if (second_column)
__

Re: accels busted

2005-08-26 Thread Pavel Tsekov
Hello,

On Fri, 26 Aug 2005, Oswald Buddenhagen wrote:

> On Fri, Aug 26, 2005 at 02:29:48PM +0300, Pavel Tsekov wrote:
> > I told you the `use_8th_bit_as_meta' does the trick for me -
> >
> and i told you pretty much explicitly that it does not change a freakin'
> shit. you're seeing a different problem.

http://savannah.gnu.org/cgi-bin/viewcvs/mc/mc/edit/editwidget.c.diff?sortby=date&r2=1.62&r1=1.61&diff_format=u

edit_drop_hotkey_menu() is tried if edit_translate_key() fails. Of course
it doesn't fail because M + something is supposed to be predefined macro.
Different ways to fix this exist and I cannot tell which one is the best
right away. Checking whether a macro bound to M + something exists is one
to go. I don't like it very much I'd rather prefer to have the the menu
hotkeys to invoke the menu always i.e. calling edit_drop_hotkey_menu()
before edit_translate_key(). Opinions ?
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: accels busted

2005-08-26 Thread Oswald Buddenhagen
On Fri, Aug 26, 2005 at 02:29:48PM +0300, Pavel Tsekov wrote:
> I told you the `use_8th_bit_as_meta' does the trick for me - 
> 
and i told you pretty much explicitly that it does not change a freakin'
shit. you're seeing a different problem.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: accels busted

2005-08-26 Thread Oswald Buddenhagen
On Fri, Aug 26, 2005 at 02:43:46PM +0300, Pavel Tsekov wrote:
> And it works fine. Alt + l works in mcedit.
> 
you really seem to be slightly dislectic. ;)))
i was talking about _letters from the *main* menu_ - like Alt-f ...

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: accels busted

2005-08-26 Thread Pavel Tsekov
Hello,

On Fri, 26 Aug 2005, Pavel Tsekov wrote:

> Hello,
>
> On Sat, 20 Aug 2005, Oswald Buddenhagen wrote:
>
> > one of the recent commits broke the alt-
> > accelerators in mcedit.
>
> Oh boy, now reading it again I see that I've missed the `mcedit' part. Ok,
> let me try .

Same thing. Display bits


(*) ISO 8859-1

[ ] Full 8 bits input

And it works fine. Alt + l works in mcedit.

GNU Midnight Commander 4.6.1a
Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish
With builtin Editor
Using the ncurses library
With optional subshell support
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
Data types: char 8 int 32 long 32 void * 32 off_t 64 ecs_char 8

xterm-192-1

LANG=C

___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: accels busted

2005-08-26 Thread Pavel Tsekov
Hello,

On Sat, 20 Aug 2005, Oswald Buddenhagen wrote:

> one of the recent commits broke the alt-
> accelerators in mcedit.

Oh boy, now reading it again I see that I've missed the `mcedit' part. Ok,
let me try .
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: accels busted

2005-08-26 Thread Pavel Tsekov
Hello,

On Fri, 26 Aug 2005, Oswald Buddenhagen wrote:

> On Thu, Aug 25, 2005 at 11:27:35PM +0200, Leonard den Ottolander wrote:
> > So what I'm saying is I do not understand how you came to the
> > conclusion that these two issues (8-bit vs. menu hotkeys) are related.
> >
> i have to agree. i'm pretty convinced that the breakage stems from one
> of roland's "cleanup" patches.

Still, not providing any information ? Should I go through all of his
"cleanup" patches to find out the reason ? I told you the
`use_8th_bit_as_meta' does the trick for me - provide further information
so I can debug and see what would help you. Is it so hard.

___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: accels busted

2005-08-26 Thread Oswald Buddenhagen
On Thu, Aug 25, 2005 at 11:27:35PM +0200, Leonard den Ottolander wrote:
> So what I'm saying is I do not understand how you came to the
> conclusion that these two issues (8-bit vs. menu hotkeys) are related.
> 
i have to agree. i'm pretty convinced that the breakage stems from one
of roland's "cleanup" patches.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: accels busted

2005-08-26 Thread Pavel Tsekov
Hello,

On Thu, 25 Aug 2005, Leonard den Ottolander wrote:

> Hi Pavel,
>
> On Thu, 2005-08-25 at 22:58 +0200, Pavel Tsekov wrote:
> > > Odd.
> > > $ rpm -q mc
> > > mc-4.6.1a-0.11.FC4
> > >
> > > No difference...
> >
> > "Me too" is not as effective as providing actual details. I've requested
> > some information which would be useful to track down the problem:
>
> On FC4 I cannot reproduce the fix you propose ("no difference" setting
> or unsetting that option). Build options for mc on FC4 will _most_
> likely not differ from FC3, and same is true for the used tarball (at
> least with respect to this 8-bit option).
>
> So what I'm saying is I do not understand how you came to the conclusion
> that these two issues (8-bit vs. menu hotkeys) are related.

How do you think ? By looking at the source code and when it is not
enough - by debugging. If you've read the link I've posted you should have
understood that I was looking at the code which reads input events
delivered from the terminal. This code is found in get_key_code(). To
enlighten yourself a bit about my reasons search for the following text
'use_8th_bit_as_meta' in the body of get_key_code(). Of course this might
not be the only reason for M + key failing but is for sure a good start.
It is event more interesting what is read from the keyboard when M +
something is pressed but nobody cared to provide information.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [bug #14155] 4.6.1: mouse wheel strangeness

2005-08-26 Thread Pavel Tsekov
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 the bugreport page. Attaching to this mail for your convinience.

Now to the details ...

mc-xterm-mouse-wheel-fix.patch - This patch fixes the problem reported by
John Pye here:

  https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=14155

When the mouse wheel is scrolled events could be delivered too fast to
MC so that it would think that double click occured. This is why John
complains about MC changing directories. The patch fixes the problem by
resetting the `clicks' variable each time a mouse wheel event is
delivered. The `clicks' variable is used to track the number of button
press events which occured in a row and the time interval between too
adjacent events is less than `double_click_speed'. It is obviously wrong
to fire double click event on fast mouse wheel scrolling. So I think this
patch is good.


mc-xterm-mouse-enable-drag.patch - This patch enables xterm's
'Button-event tracking' mouse reporting and adds support for
generating GPM_DRAG events to xmouse_get_event()


[...]
Button-event tracking is essentially the same as normal tracking, but
xterm also reports button-motion events.  Motion events are reported only
if the mouse pointer has moved to a different character cell.  It is
enabled by specifying parameter 1002 to DECSET. On button press or
release, xterm sends the same codes used by normal tracking mode.  On
button-motion events, xterm adds 32 to the event code ...
[...]

As a consequence we get some fine features under xterm terminals which
were missing before:

  Dragging the mouse in the editor to select a block of text now
  highlights the block immediatley and not after the mouse button
  is released.

  Dragging the mouse in a panel containing file listing highlights the
  entry under the mouse cursor.

  ...

Changelog entries for the patches ...

mc-xterm-mouse-wheel-fix.patch:

2005-08-25  Pavel Tsekov  <[EMAIL PROTECTED]>

* key.c (xmouse_get_event): Disable double-click tracking for
mouse wheel events.

mc-xterm-mouse-enable-drag.patch

2005-08-24  Pavel Tsekov  <[EMAIL PROTECTED]>

* mouse.c (enable_mouse): Use xterm's 'Button-event mouse
tracking' instead of 'Normal tracking'.
* key.c (xmouse_get_event): Add support for generating GPM_DRAG
events.Index: src/key.c
===
RCS file: /cvsroot/mc/mc/src/key.c,v
retrieving revision 1.83
diff -u -p -r1.83 key.c
--- src/key.c   20 Jul 2005 20:29:08 -  1.83
+++ src/key.c   24 Aug 2005 14:07:02 -
@@ -532,9 +532,11 @@ xmouse_get_event (Gpm_Event *ev)
 break;
case 64:
 ev->buttons = GPM_B_UP;
+clicks = 0;
 break;
case 65:
 ev->buttons = GPM_B_DOWN;
+clicks = 0;
 break;
default:
 /* Nothing */
Index: src/key.c
===
RCS file: /cvsroot/mc/mc/src/key.c,v
retrieving revision 1.83
diff -u -p -r1.83 key.c
--- src/key.c   20 Jul 2005 20:29:08 -  1.83
+++ src/key.c   25 Aug 2005 12:12:27 -
@@ -512,7 +512,12 @@ xmouse_get_event (Gpm_Event *ev)
ev->type = 0;
}
 } else {
-ev->type = GPM_DOWN;
+   if (btn >= 32 && btn <= 34) {
+   btn -= 32;
+   ev->type = GPM_DRAG;
+   } else
+   ev->type = GPM_DOWN;
+
GET_TIME (tv2);
if (tv1.tv_sec && (DIF_TIME (tv1,tv2) < double_click_speed)){
clicks++;
Index: src/mouse.c
===
RCS file: /cvsroot/mc/mc/src/mouse.c,v
retrieving revision 1.15
diff -u -p -r1.15 mouse.c
--- src/mouse.c 27 May 2005 03:35:15 -  1.15
+++ src/mouse.c 25 Aug 2005 12:12:27 -
@@ -91,7 +91,7 @@ void enable_mouse (void)
printf(ESC_STR "[?1001s");
 
/* enable mouse tracking */
-   printf(ESC_STR "[?1000h");
+   printf(ESC_STR "[?1002h");
 
fflush (stdout);
mouse_enabled = 1; 
@@ -117,7 +117,7 @@ void disable_mouse (void)
 #endif
 case MOUSE_XTERM:
/* disable mouse tracking */
-   printf(ESC_STR "[?1000l");
+   printf(ESC_STR "[?1002l");
 
/* restore old highlight mouse tracking */
printf(ESC_STR "[?1001r");
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


[patch] fix cursor display in hex viewer

2005-08-26 Thread Jindrich Makovicka
Hi,

after opening a file in the viewer, the cursor does not appear when the
viewer was left in the hex mode previously. The atached patch fixes this
issue.

Steps to reproduce:

press F3 on a file
press F4 to switch to hex
press F10 to exit the viewer
press F3 again - the cursor stays in the top right corner

-- 
Jindrich Makovicka
Index: view.c
===
RCS file: /cvsroot/mc/mc/src/view.c,v
retrieving revision 1.339
diff -u -r1.339 view.c
--- view.c  22 Aug 2005 19:19:51 -  1.339
+++ view.c  26 Aug 2005 07:07:35 -
@@ -3376,7 +3376,6 @@
 init_widget (&view->widget, y, x, lines, cols,
 view_callback,
 real_view_event);
-widget_want_cursor (view->widget, 0);
 
 view->filename  = NULL;
 view->command   = NULL;
@@ -3387,6 +3386,7 @@
 /* leave the other growbuf fields uninitialized */
 
 view->hex_mode  = default_hex_mode;
+widget_want_cursor (view->widget, view->hex_mode);
 view->hexedit_mode  = default_hexedit_mode;
 view->hexview_in_text   = FALSE;
 view->text_nroff_mode   = default_nroff_flag;
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel