Re: .syntax file syntax changed since 4.5.4x?

2003-01-26 Thread Arpi
Hi,

 I'm porting my .syntax hilite files from AMC (uses syntax code from 4.5.4x)
 and found that the /nn number codes has gone. I've never understood their
 purpose but all my syntax files contains them after each color code.
 
 -keyword $(*) yellow
 -keyword ${*} brightgreen
 +keyword $(*) yellow/24
 +keyword ${*} brightgreen/16
 
 Should I remove them, or it doesn't matter?

After some more RTFM i've found opposite things written.
In the Syntax file, the comment says:

# syntax rules version 62
# (after the slash is a Cooledit color, 0-26 or any of the X colors in rgb.txt)

While the english manpage has examples, for example:

 keyword  whole  static   24
 keyword  whole  extern   24
 keyword {14
 keyword }14
 keyword '*'  6

followed by:

   The  possible  colors  are:  black,  gray, red, brightred,
   green,  brightgreen,  brown,  yellow,  blue,   brightblue,
   magenta,  brightmagenta,  cyan,  brightcyan, lightgray and
   white.

Imho this thing should be cleaned up for 4.6.0, either remove numbers or
color names or at least fix the manpage to explain what are them, instead
of having examples using numbers and description using color names.


A'rpi / Astral  ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel



Re: .syntax file syntax changed since 4.5.4x?

2003-01-26 Thread Adam Byrtek / alpha
On Sun, Jan 26, 2003 at 01:47:09PM +0100, Arpi wrote:
 Imho this thing should be cleaned up for 4.6.0, either remove numbers or
 color names or at least fix the manpage to explain what are them, instead
 of having examples using numbers and description using color names.

Don't get me wrong, I'm not against fixing all you have mentioned (in
this mail and others) - but we REALLY HAVE to release 4.6.0 as fast as
we can - many people (like you before) still belive that 4.55 is the
last oficial release, that the whole gmc-thing is still there and that
mc is unmaintained and sucks.

So we should have stable 4.6.0, and then merge your patches from amc
(some of them are quite useful) or fix color handling.

Pavel, now that you resolved the Italian .po problem, are there any
problems that could slow down the 4.6.0 release?

Regards

-- 

  _.|._ |_  _.: Adam Byrtek, alpha@(irc.pl|debian.org)
 (_|||_)| |(_|: gg 1802819, pgp 0xB25952C0
 |: jid alpha.pl(at)jabber.org
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel



Re: Find file dialog in mc-4.6.0-pre3

2003-01-26 Thread Arpi
Hi,

 I've scanned a TODO list and found the item -
 Make find dialog more responsive - inside
 After 4.6.1 on 4.6.x branch section.
 
 But I think the responsiveness of the dialog is unacceptable for the
 4.6.0 release. I missed the moment when it became so bad, (may be 1-3

I agree.

So i went and hunted down the bug :)
It's a nice 100l one, said in MPlayer terminology...

In src/key.c, the is_idle() function is broken.
It's called by the dialog loop (used by Find File too) to decide if
call the callback fv (search for files) or handle the key/mouse events.

The original code ends this way:

timeout.tv_sec = 0;
timeout.tv_usec = 0;
select (maxfdp, select_set, 0, 0, timeout);
return !FD_ISSET (0, select_set);

which is, according to 'man select' broken at 2 points:

   int  select(int  n,  fd_set  *readfds,  fd_set  *writefds,
   fd_set *exceptfds, struct timeval *timeout);

   n is the highest-numbered descriptor in any of  the  three
   sets, plus 1.
 ^^
so it should be:

select (maxfdp+1, select_set, 0, 0, timeout);

this may work on some select() implementations, i've heard that some ignores
the first parameter and calculates it from the fd sets. but it's better fixed.

and:

   FD_ISSET(int fd, fd_set *set);

   FD_ISSET  tests  to  see  if  a
   descriptor is part of the set; this is useful after select
   returns.

so it should be:

return !FD_ISSET (input_fd, select_set);

(the original code works only if input_fd==0)

after changing these, find is responsive again!

btw, NOTE: i didn't handled the gpm events, they need extra code,
so the current is_idle() should be changed deep. I've just summarized
the idea about the bug. If you want, i can prepare a commitable patch.


A'rpi / Astral  ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel