several issues + wishes

[Oswald Buddenhagen]

moin!

i'm using a debian-packaged mc 4.6.0.

mc forgets to reset the x window title when it exits.

a cmdline switch to replace the "mc" prefix in the window title would be
very helpful. i usually have dozens of xterms with mc open, some of them
are root consoles and some on remote hosts. it's impossible to manage
them if they are all titled "mc - ...".

a single esc keypress should be translated to esc esc after some
timeout. the timeout could be made depandant on the "slow terminal"
setting and/or could be automatically adopted based on measurements of
previous key sequences. dunno if this is simply doable with curses ...

the text viewer should support syntax highlighting.

the type/ keyword in mc.etx should use "file -z", not "plain" "file".
for now i simply created wrapper script for "file" and put it in the
path in front of the regular "file", but i think this will potentially
cause trouble. using "file -z" allows things like:
type/^(ASCII )?troff.*gzip compressed
Open=gzip -dc %f | nroff  -Tlatin1 -mandoc | sensible-pager
View=%view{ascii,nroff} gzip -dc %f | nroff  -Tlatin1 -mandoc
which is obviously by far more reliable than some magic based on file
extensions (don't you hate having your rotated+compressed log files
formatted like man pages?).

cooledit issues:

under some weird circumstances cooledit eats files (makes them
zero-length). i think this happens if the directory containing the file
is renamed below cooledit's feet.
similar, but by far not so fatal is that cd-ing below cooledit makes it
save the file to the wrong (new) directory.

c is treated like c++. that's somewhat annoying.

c++ style comments are not recognized after preprocessor directives.

vim marks #if 0 -ed code as comment. this would be a nice feature to
steal. :)

complex sh syntax highlithing, in particular bash syntax is totally
screwed. see these examples:
  cont=$((${delay2[i]}+$now-$(date '+%s')))
  "${mailclasses:1:$((${#mailclasses}-2))}"
  fil=$(egrep -i "/([0-9]{2,3} - )?${i% $dsh *}( $dsh |( $dsh 
[^/]+)?(/.+)?/([0-9]{2,3} - )?)${i##* $dsh }\$" /tmp/xm-$$ | tr '\n' '\\')
  dfil="$ddir/$i - ${sartist:+$(escape "${artist[cntr]}") $dsh }$(escape 
"${title[cntr]}").$ext"

a "backspace unindents" option (as known from the borland IDEs for
example) would be very nice.

the type of white-space used by auto-indent should not be based on the
"fill tabs with spaces" setting. instead, the leading whitespace from
the above line should be copied. otherwise it's impossible to use a
tabbing style like
if (...)
if (cond1 && function(par1,
  par2))
statement;
(which is _the_ tabbing style).

"intelligent home" which alternates between column 1 and the first
column with non-whitespace on it would not hurt.

some basic file locking would be nice. i often end up editing the same
file in two windows.

dunno if this is simply an issue of terminfo: a lot of advanced key
combinations (in particular [shift-]ctrl-) are not recognized in
xterm, even though they produce keycodes.
as a consequence of this, it is impossible to insert selection into the
x-clipboard -> entries should be added to the menu.


otherwise mc rules - i admit to be an addict. :)

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: several issues + wishes

[Oswald Buddenhagen]

On Wed, Feb 12, 2003 at 03:00:14PM +0100, Oswald Buddenhagen wrote:
> dunno if this is simply an issue of terminfo: a lot of advanced key
> combinations (in particular [shift-]ctrl-) are not recognized in
> xterm, even though they produce keycodes.

> as a consequence of this, it is impossible to insert selection into the
> x-clipboard -> entries should be added to the menu.
> 
hmm, i just noticed, that the shift-insert pasting of x's PRIMARY
selection (not the clipboard) is xterm's feature. consequently i have a
new wish: mc should directly support the x clipboard.

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: several issues + wishes

[Oswald Buddenhagen]

moin,

thx for the reply.

> > mc forgets to reset the x window title when it exits.
> 
> It was never meant to "reset" the title.  There was a discussion how
> to restore the original title, but no good solution was suggested.
> 
too bad. is the problem that xterm does not provide a title query
sequence?

> > a cmdline switch to replace the "mc" prefix in the window title would be
> > very helpful. i usually have dozens of xterms with mc open, some of them
> > are root consoles and some on remote hosts. it's impossible to manage
> > them if they are all titled "mc - ...".
> 
> I think an environment variable would be better.  Something like PS1, but
> specific to mc.  Then you would set it in .profile on the remote host.
>
no. a) it complicates things like "xterm -e su -c 'mc --title root'", as
i need to set up the variable first somehow (note that sh does not
source any files in non-interactive mode by default) and b) i don't want
a "remotehost" title when i'm working locally on the other host.
i'm not saying that an env var is bad, but a cmdline switch is still
required and should take precedence.

> > a single esc keypress should be translated to esc esc after some
> > timeout. the timeout could be made dependent on the "slow terminal"
> > setting and/or could be automatically adopted based on measurements of
> > previous key sequences. dunno if this is simply doable with curses ...
> 
> Sometimes it's useful when Escape doesn't time out.  Users don't have to
> use three fingers to run the "Find File" dialog.  Also, Escape+number is
> the last resort if the functional keys don't work.
> 
indeed, i forgot that case. this smells like a good candidate for an
option.

> > the text viewer should support syntax highlighting.
> 
> I have no idea how to do it.  The syntax highlighting used in the
> internal editor is tied to a memory model used in the editor. 
>
"there is no problem in IT that cannot be solved by adding another layer
of indirection" ... :)

> The viewer uses mmap() on files, so it can read huge files without
> loading them into memory.  I think this feature is more important than
> syntax highlighting.
> 
[disclaimer: these observations apply to mc 4.55]
this "huge file support" is rather theoretical. open /dev/hda and see it
explode. switching to line break mode (and, beware, start scrolling
backwards), switching to hex mode, etc. - all trigger(ed) incredible
memory/cpu consumption.

fwiw, it would also be possible to let the editor keep unmodified chunks
of text as references to a mmaped file. that would make appending to a
gigant file actually doable (especially if some options like "don't
compute line numbers if file is > ... mb" would be added). keeping the
file writeout consistent would be a bit tricky, though (don't overwrite
fragments that are still needed).

> How portable is "file -z"?
>
i don't know. sound like a ./configure candidate. falling back to
calling zip manually shouldn't be that hard.

> > c is treated like c++. that's somewhat annoying.
> 
> It's annoying for a reason.  Calling a variable "new" or "class" is not a
> good idea.
> 
that's nonsense. it's a bad idea to do so in interfaces that can be
included in c++ sources, but not in plain .c files. i think treating .h
always as c++ is acceptable, especially given that there is hardly a way
to find out if it is. that does not apply to .c, though.
fwiw, i sometimes miss a menu entry to explicitly set the highlight
style.

now for something esotheric: nested language syntax highlighting, for
example perl embedded into a shell script. the plain text yielded from
"de-quoting" the "outer" language would be passed into the next
highlighter. no, this is not very urgent; i just wished it existed when
i was editing one of my highly unreadable bash scripts the other day. :)

> > complex sh syntax highlighting, in particular bash syntax is totally
> > screwed. see these examples:
> >   cont=$((${delay2[i]}+$now-$(date '+%s')))
> >   "${mailclasses:1:$((${#mailclasses}-2))}"
> >   fil=$(egrep -i "/([0-9]{2,3} - )?${i% $dsh *}( $dsh |( $dsh 
>[^/]+)?(/.+)?/([0-9]{2,3} - )?)${i##* $dsh }\$" /tmp/xm-$$ | tr '\n' '\\')
> >   dfil="$ddir/$i - ${sartist:+$(escape "${artist[cntr]}") $dsh
> }$(escape "${title[cntr]}").$ext"
> 
> The current syntax highlighting code cannot deal with such complex
> expressions.
>
too bad. :-(  any ETA?

oh, and perl syntax highlight, esp. wrt. the various uses of the $ char
is majorly broken. yes, to highlight it correcty, one needs to keep
incredible amounts of context information ...
btw, is it intentional, that %hashes are not highlightet (as oposed to
@arrays)?

> > the type of white-space used by auto-indent should not be based on the
> > "fill tabs with spaces" setting. instead, the leading whitespace from
> > the above line should be copied. otherwise it's impossible to use a
> > tabbing style like
> > if (...)
> > if (cond1 && function(par1,
> >   par2))
> > statement;
[to say it in 

resetting the xterm title (once more) (Re: several issues + wishes)

[Oswald Buddenhagen]

On Tue, Feb 18, 2003 at 11:53:32AM +0100, Oswald Buddenhagen wrote:
> > > mc forgets to reset the x window title when it exits.
> > 
> > It was never meant to "reset" the title.  There was a discussion how
> > to restore the original title, but no good solution was suggested.
> > 
> too bad. is the problem that xterm does not provide a title query
> sequence?
> 
ok, i read the threads about it.
the direct x connection variant is doomed to failure on remote machines 
if no (x forwarding)/(env var setup) is done. i strongly dislike it.
so back to xterm's reporting sequence. it _is_ doable - your approach was
just incorrect: you've tried to force an asynchronous function into a
synchronous execution scheme. not only that it obviously does not work
very well, it's not even necessary: at startup the query command should
be sent and things should continue as usual. the reply should be handled
asynchronously as part of the normal input stream. that effectively
means, that at the time the old title is received, a new one has been set 
already long ago - who cares? on the xterm side the processing is done
in-order, so we'll always get the correct title. one remaining case is
mc exiting before the report arrives, but anybody quitting mc after no
more than 5 seconds should be shot anyway. :)
does this make sense?

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: several issues + wishes

[Oswald Buddenhagen]

i had one more thought ...

On Tue, Feb 18, 2003 at 11:53:32AM +0100, Oswald Buddenhagen wrote:
> > > a cmdline switch to replace the "mc" prefix in the window title would be
> > > very helpful. i usually have dozens of xterms with mc open, some of them
> > > are root consoles and some on remote hosts. it's impossible to manage
> > > them if they are all titled "mc - ...".
> > 
> > I think an environment variable would be better.  Something like PS1, but
> > specific to mc.  Then you would set it in .profile on the remote host.
> >
> no. a) it complicates things like "xterm -e su -c 'mc --title root'", as
> i need to set up the variable first somehow (note that sh does not
> source any files in non-interactive mode by default)
>
valid

> and b) i don't want a "remotehost" title when i'm working locally on
> the other host.
>
nonsense. the "xterm -e ssh remotehost mc --title remote" case is already
covered by a), and the "log in interactively, start mc" case is the same
with both a var and a switch (i'd set up a shell function to do the
right thing based on login origin).

but i found, that appending to the already existing title would be very
helpful (i hope you can get the title query working):
 xterm -T konsole1
 xterm -T konsole2
 xterm -T root -e su
 xterm -T ktown -e ssh ktown
 xterm -e mc
 xterm -e mc --title mc2
in the interactive shells mc is aliased to 'mc --append-title'. think 
"konsole1: mc - ~". the benefit is obvious, i think.
--title "" would remove the "mc -" part entirely to save some space in
the task bar.

to carry things to excess: --title could interpret macros like these:
 %o - old title
 %f - currently open dir/file
 %a - current status ("" (=view), "edit")
 %F - currently processes dir/file
 %A - precise current status (as %a + the usual file operations)
 %{[var]?[text1]:[text2]} - if var (see above) is non-empty, text1,
  otherwise text2 (both subject to further expansion).
one could create things like this:
 "%{o?%o (mc):mc}: %{a?%a :}%f"
or the normal variant, but optimized for prefix size (for narrow task
bar entries) (btw, most apps use "%f - title" order):
 "%{o?%o\: :}%f - mc"
or for the pedantic:
 "mc%{o? (%o):} - %{A?%A:view} %F"


greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: several issues + wishes

[Oswald Buddenhagen]

moin!

> cooledit issues:
> 
i just stumbled over another thing that drives me crazy: starting a
selection after having moved clears the previous selection. i think the
previous selection should be extended if the cursor is exactly at the
beginning/end of the old selection.

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Retain orig. filename as suffix for tmp. filename

[Oswald Buddenhagen]

On Mon, Feb 24, 2003 at 01:39:44AM +0100, Adam Byrtek / alpha wrote:
> +basename = strrchr (filename, PATH_SEP);

> +if (basename && *basename==PATH_SEP)
> + basename++;
this is totally bogus.

if (basename)
  basename++;
else
  basename = filename;

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Retain orig. filename as suffix for tmp. filename

[Oswald Buddenhagen]

On Mon, Feb 24, 2003 at 11:27:53AM +0100, Adam Byrtek / alpha wrote:
> On Mon, Feb 24, 2003 at 02:26:13AM +0100, Oswald Buddenhagen wrote:
> > > +if (basename && *basename==PATH_SEP)
> > > + basename++;
> > this is totally bogus.
> 
> No, this is not 'totally bogus'. Filename var always contains at least
> one PATH_SEP:
> 
ok.

> So this 'if' is just to protect from the impossible. As all
> programmers know impossible happens about once a year to (and I want
> to be protected just in case some code changes etc.), and we surely
> dont want to increment NULL of increment beyond the string. Result is
> not so important in impossible case :)
> 
then add an assert(basename); and increment right away. it's nonsense to
handle "the impossible" in any other way than bailing out.

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: [OT] Re: rename improvement

[Oswald Buddenhagen]

On Fri, Mar 07, 2003 at 06:33:42PM +0100, Ali Akcaagac wrote:
> On Fri, 2003-03-07 at 17:30, Pavel Roskin wrote:
> > > And now friendly back to the request. I still like to see that feature
> > > in Midnight Commander and this is a serious request.
> > 
> > Which request?  If you mean Shift-F6, try Options -> Learn Keys and
> > configure F16.
> 
> hm, should it do something ? i don't see the point to learn my shift key
> since it is a common key used on 100% of all machines, no fancy things
> that need to be learned.
>
the entire problem is that the linux console maps shift-f1 to f13 and so
on - i consider this a major braindamage.
recently i remapped shift-f1 to f11, etc. up to shift-f8. shift-f9 &
shift-f10 don't produce keycodes, so i mapped f11 to f19 and f12 to f20.
whatever.

anyway, i just noticed that this mapping is now gone because of the poor
concurrency behaviour wrt. writing out config files. *grmbl*
how about a bit merging and checkpointing?

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mcedit file locking

[Oswald Buddenhagen]

On Tue, Mar 25, 2003 at 01:59:12AM -0500, Pavel Roskin wrote:
> 3) System-wide locks using fcntl() or (if not supported) flock().
>
i'd go with that one.

> Pro: No stale locks.  Works in non-writable directories.  Locking between
> users.
> 
and it's simple (except the #ifdef for fcntl vs. flock). the other
variants get hairy once you try to get around the stale lock problem.

> Con: not 100% portable, but should work on most modern systems. 
> 
and it's halfways broken over nfs - at least one of the variants. check
out the man page.

> Locks affect other software.
>
that's a) not exactly a downside, if you ask me and b) usually not true,
as the locks are only advisory, not mandatory, so "the other"
application has to use locking itself to notice what we do.

one thing to note is, that cooledit would need to keep the file open all
the time. dunno if it does currently.

> Should the lock be held for the whole time when the file is being edited
>
yes. that was my point in the initial request. i want a warning like "this
file is already being edited. still want to open it? (No/yes)".

> or just for the time when it's being saved? 
>
that helps against corrupting the file if two instances try to write out
at once, but is otherwise useless.

> Do we want the locks to affect other software? 
> Do we want locks to be shared between users?
>
it would not hurt. i don't care much, personally.

> With all that complexity I feel that we probably should postpone the issue
> or find a popular editor that used locking already and implement locking
> in a compatible way.
> 
hmm, and what if multiple popular editors use different approaches? :}

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

annoyance: undo does not reset "modified" status

[Oswald Buddenhagen]

i often accidentally do minor modifications (mostly partial escape
sequences) which i undo of course. anyway, afterwards i still don't know
if this was the only modification.

oh, fwiw, this gives me an idea: sometimes it would be useful to be able
to save the buffer to a temp file and run a diff against the original
file. super-limited version control. :)

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: annoyance: undo does not reset "modified" status

[Oswald Buddenhagen]

On Fri, Apr 04, 2003 at 03:54:19PM +0200, Adam Byrtek / alpha wrote:
> On Wed, Apr 02, 2003 at 08:01:25PM +0200, Oswald Buddenhagen wrote:
> > i often accidentally do minor modifications (mostly partial escape
> > sequences) which i undo of course. anyway, afterwards i still don't
> > know if this was the only modification.
> 
> Patch attached.
>
thanks. does this re-assert the modified state if you undo past the save
point? theoretically this would be correct. otoh, it's quite simple to
miss this point if you hold your fingers on "undo". the optimal thing
would be not undoing the stack wrap as a result of key auto-repeat - a
simple timer, e.g., 'more than 5 times the same sequence in the last
second == auto-repeat' would be sufficient, i think.

> BTW I'm not sure if it is wide to undo every cursor movement. IMO
> pop_action should apply EVERY movement action till the last action
> which actually modified something
> 
this is a quite controversial question, in fact. i'm very often annoyed
by vim because it does not treat movements (and selections, fwiw) as
undoable actions. otoh i sometimes wish mc would merge movements into
blocks. i'm just not sure what the correct rules are. maybe temporally
close "simple movements" (cursor keys) should be merged, while "big
jumps" (like search next) are not merged.  this would be less an issue
for me if cooledit supported bookmarks and "jump to start/end of
selection".

> (including this action).
>
you mean, undo means "undo last editing action plus all following
movements"? NO WAY! i absolutely HATE this behaviour in vim. while
merging moves is negotiable, pretending that they don't exist is
absolutely out of question for me.

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: annoyance: undo does not reset "modified" status

[Oswald Buddenhagen]

On Fri, Apr 04, 2003 at 05:31:59PM +0200, Adam Byrtek / alpha wrote:
> On Fri, Apr 04, 2003 at 05:21:35PM +0200, Oswald Buddenhagen wrote:
> > you mean, undo means "undo last editing action plus all following
> > movements"? NO WAY! i absolutely HATE this behaviour in vim. while
> > merging moves is negotiable, pretending that they don't exist is
> 
> And mcedit behaviour is plain stupid for me. I wan't undo to unDO, not
> unMOVE. If I change something, browse the file (eg. 100 movement
> commands) and decide to undo my last change it will be very difficult
> for me to undo the real modification. And if I want to move back - I
> can just use arrow keys.
> 
that's a pretty weak argumentation. with move merging this adds one
additional keypress, which is absolutely irrelevant given that edit
action merging is not performed (that should be added and done based on
timing, too, imho). moving to the old place otoh can be a _significant_
amount of keypresses.
for me, moving around _is_ an editing action. i have a weak short-term
memory, so being able to jump back (and forth, fwiw - where is "redo"?
:) to recatch the context after some distraction is very valuable.

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: A fix for the F3 /var/log bug...

[Oswald Buddenhagen]

On Thu, May 29, 2003 at 12:09:10AM -0400, Pavel Roskin wrote:
> On Wed, 28 May 2003, Alfie Costa wrote:
> 
> > The fix is described (with a patch for '/etc/mc/mc.ext') here:
> > 
> > Debian Bug report logs - #179350
> > mc hangs viewing a .gz file
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179350
> 
> I believe double hash used in the patch is non-portable.
> 
yep. it's a bash-ism (or a ksh-ism, fwiw).
other than that, i pretty much dislike this directory-based
special-casing. i think my suggestion with "file -z" (or equivalent) is
much cleaner.

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: A fix for the F3 /var/log bug...

[Oswald Buddenhagen]

On Thu, May 29, 2003 at 02:44:59PM -0400, Alfie Costa (backup address) wrote:
> On 29 May 2003, at 0:09, Pavel Roskin <[EMAIL PROTECTED]> wrote:
> > I believe double hash used in the patch is non-portable.
> 
> I only use Linux, so all I know for sure is that double hash works on Debian, 
> (ash, dash, bash, etc.), and judging by the 'ash/dash' man page, '##' (as 
> adopted from the Korn shell), now seems to be POSIX compliant...
> 
>   The current ver-
>  sion of sh is in the process of being changed to conform with the POSIX
>  1003.2 and 1003.2a specifications for the shell.  [...]

>  We expect POSIX conformance by the time 4.4 BSD is released.
>
according to the unix history graph
(http://www.levenez.com/unix/history.html) this sentence must be at
least ten years old. ergo i would not bet on the accuracy of the rest of
the paragraph or other standards-related claims in this page.

> Could some kind SunOS or HP-UX user please test this code?
> 
>   x=QuousqueTandemAbutere
>   echo ${x##Quousque}
> 
/bin/sh on solaris 8: bad substitution
bye bye ...

On Thu, May 29, 2003 at 04:00:56PM -0400, Alfie Costa (backup address) wrote:
> On Thu, 29 May 2003 11:31, Oswald Buddenhagen wrote:
> > yep. it's [ double hashes ] a bash-ism (or a ksh-ism, fwiw). 
> It came from from Korn, but it's POSIX shell syntax now.
> 
the point is, that it does not matter whether it is posix-compliant ...
there are simply shells in active use that are non-posix.

> > other than that, i pretty much dislike this directory-based
> > special-casing. i think my suggestion with "file -z" (or equivalent)
> > is much cleaner. 
> [...]

> A 'file -z' clause wouldn't be locationally challenged, but it'd be slower.  
>
we are talking about viewing files here ... a .2 sec delay is not
exactly a catastrophe.

> In the meantime, for those who prefer the 'file -z' way, attached is
> the same patch, changed so it does it the 'file -z | grep' way.
>
this solution is sort of ... stupid ... :]

as mc does not automatically call file -z (or uncompresses the file
itself), i created the wrapper /usr/local/bin/file:


#! /bin/sh
/usr/bin/file -z "$@"
echo "Warning: -z switch implicitly used"


in mc.ext i have these:


[here comes the .me & .ms stuff]

# Manual page - compressed
type/^(ASCII )?troff.*gzip compressed
Open=gzip -dc %f | nroff  -Tlatin1 -mandoc | sensible-pager
View=%view{ascii,nroff} gzip -dc %f | nroff  -Tlatin1 -mandoc

type/^(ASCII )?troff.*bzip compressed
Open=bzip -dc %f | nroff  -Tlatin1 -mandoc | sensible-pager
View=%view{ascii,nroff} bzip -dc %f | nroff  -Tlatin1 -mandoc

type/^(ASCII )?troff.*bzip2 compressed
Open=bzip2 -dc %f | nroff  -Tlatin1 -mandoc | sensible-pager
View=%view{ascii,nroff} bzip2 -dc %f | nroff  -Tlatin1 -mandoc

# Manual page
type/^(ASCII )?troff
Open=nroff  -Tlatin1 -mandoc %f | sensible-pager
View=%view{ascii,nroff} nroff  -Tlatin1 -mandoc %f

[... and here comes the video and image stuff. at least on my box]
--

the type/ query prolly does not even cost anything, as the info-page
pattern already calls file and i suppose mc caches the result.
of course file -z is slower than pure file, but we are talking about
uncompressing a few (hundred) bytes ...

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: A fix for the F3 /var/log bug... / POSIX and '##'

[Oswald Buddenhagen]

On Sun, Jun 01, 2003 at 02:10:53AM -0400, Alfie Costa wrote:
> but why would BSD & Debian bluff about POSIX?
> 
because nobody bothered to update it? not that this would happen very
seldom with OSS ...

> Eureka, [...]
> That shell has the '##'.  Therefore either Debian, BSD and HP are all 
> wrong about what's POSIX, or else '##' must be POSIX.
> 
that's wrong reasoning. the claim that a shell is posix-compliant does
not imply that it does not contain non-posix extensions.

> So it seems that most 'mc' platforms (AIX, Linux, HP-UX), use POSIX
> shells, except SunOS.
> 
i have doubts about this. every system today has a posix shell. but not
necessarily /bin/sh. the reasoning is to keep scripts from the stone age
(that rely on behaviour that contradicts posix) working.

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: A fix for the F3 /var/log bug...

[Oswald Buddenhagen]

On Sun, Jun 01, 2003 at 01:12:32AM -0400, Alfie Costa wrote:
> > as mc does not automatically call file -z (or uncompresses the file
> > itself), i created the wrapper /usr/local/bin/file:
> 
> This works for you,
> but how to package it?
>
not at all. it's a hack.

> How does this sound:  somewhere in the 'mc' source it calls 'file' -- 
> can't we just change that so it calls 'file -z' as needed?
>
that's exactly what i suggested.
one thing to consider is, whether all 'file's in the wild support -z or
a configure check and optionally manual on-the-fly decompression would 
have to be done instead.

> The logic would go like:
> 
> 1) let x = `file foo`
> 2) is foo compressed?  Goto 4.
what would these be good for?

> 3) let x = `file -z foo`
> 4) return x


greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: [patch] change sort order with single keyboard shortcut

[Oswald Buddenhagen]

On Thu, Jul 03, 2003 at 02:46:51AM +0200, David Sterba wrote:
> Hi,
> 
> > After applying my patch, following keys start
> > to work:
> >  Sort by name   Ctrl-F3
> >  Sort by extension  Ctrl-F4
> >  Sort by modification time  Ctrl-F5
> >  Sort by size   Ctrl-F6
> >  Keep unsorted  Ctrl-F7
> >  Sort by creation time  Ctrl-F8
> >  Sort by access timeCtrl-F9
> Ctrl-Fx keys are predefined in KDE to switch desktop and most users
> don't change it.
> 
screw the kde users - they have konq. those who like mc and other sweet
tools need to redefine the kde keybindings anyway. i for one freed the
shifted and controlled function keys alltogether. desktop switching is
on alt-f keys and the functions usually on alt-f are elsewhere - less
windoze-like and more logical.

greetings

-- 
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
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Restoring the functionality of Alt-o

[Oswald Buddenhagen]

On Mon, Jan 31, 2005 at 03:11:37PM +0300, buc wrote:
> Jindrich Novy wrote:
> >Let me propose some possibilities:
> >
> >1) Revert Alt-o -> annoyed users because Alt-o suddenly changes.
> >
definitely. i never used the old alt-o, but i'm sort of addicted to the
new one.

> >2) Create an alternate keyboard shortcut such as Alt-i that acts like
> >the old Alt-o.
> >
this has my vote, too.
i _guess_ meanwhile there are more new-style users ...

> >3) Keep Alt-o shortcut and switch between old/new Alt-o in
> >Options/Configuration.
> >
> May be 2) and 3) both? To avoid discrimination of old-style (or 
> new-style) users...
> 
configurability at its best ... :{

-- 
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: message formatting and i18n

[Oswald Buddenhagen]

On Sun, Feb 06, 2005 at 04:18:51PM +0100, Roland Illig wrote:
> + g_string_sprintf (errmsg, _(" Cannot open pip for reading: %s "), 
> p);
>
somehow "pip" looks wrong to me. :)

> -catstrs (_(" Not an ordinary file: "), filename,
> + _(" %s is not an ordinary file "), filename);
>  
i'm wondering why on earth "ordinary" was used, when the proper
terminology is "regular" and in no way less (i mean, even less :))
obvious to the uninitiated.

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

detach on quick-save

[Oswald Buddenhagen]

moin,

in quick-save mode the editor just overwrites the existing file. this is
all fine ... except when you cloned a source tree with "cp -al" and want
to patch one copy.
this patch adds a check whether the file has multiple hard links and
asks whether the file should be "detached" before saving.
not sure the dialog looks 100% right, but you get the idea. :)

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
Index: edit/edit-widget.h
===
RCS file: /cvsroot/mc/mc/edit/edit-widget.h,v
retrieving revision 1.24
diff -U2 -r1.24 edit-widget.h
--- edit/edit-widget.h  3 Dec 2004 17:09:27 -   1.24
+++ edit/edit-widget.h  7 Feb 2005 17:32:40 -
@@ -90,4 +90,5 @@
 
 struct stat stat1; /* Result of mc_fstat() on the file */
+int skip_ask_if_detach:1;  /* Already asked whether to detach file */
 
 /* syntax higlighting */
Index: edit/editcmd.c
===
RCS file: /cvsroot/mc/mc/edit/editcmd.c,v
retrieving revision 1.128
diff -U2 -r1.128 editcmd.c
--- edit/editcmd.c  7 Feb 2005 07:31:19 -   1.128
+++ edit/editcmd.c  7 Feb 2005 17:32:41 -
@@ -262,6 +262,23 @@
savename = g_strdup (filename);
 
-mc_chown (savename, edit->stat1.st_uid, edit->stat1.st_gid);
-mc_chmod (savename, edit->stat1.st_mode);
+if (this_save_mode == EDIT_QUICK_SAVE &&
+   edit->stat1.st_nlink > 1 &&
+   !edit->skip_ask_if_detach)
+{
+   switch (query_dialog (_(" File has hard-links "),
+ _("Detach before saving?"), 0,
+ 3, _("&Yes"), _("&No"), _("&Cancel")))
+   {
+   case 0:
+   mc_unlink (savename);
+   /* fallthrough */
+   case 1:
+   edit->skip_ask_if_detach = 1;
+   break;
+   default:
+   g_free (savename);
+   return 1;
+   }
+}
 
 if ((fd =
@@ -270,4 +287,7 @@
goto error_save;
 
+mc_chown (savename, edit->stat1.st_uid, edit->stat1.st_gid);
+mc_chmod (savename, edit->stat1.st_mode);
+
 /* pipe save */
 if ((p = edit_get_write_filter (savename, filename))) {
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: detach on quick-save

[Oswald Buddenhagen]

On Wed, Feb 09, 2005 at 12:45:44PM +0200, Andrew V. Samoilov wrote:
> > in quick-save mode the editor just overwrites the existing file.
> > this is all fine ... except when you cloned a source tree with "cp
> > -al" and want to patch one copy.
> > this patch adds a check whether the file has multiple hard links and
> > asks whether the file should be "detached" before saving.
> > not sure the dialog looks 100% right, but you get the idea. :)
> 
> Safe save has to be the best choise for these cases.
> 
i'm not going to switch the mode all times. i made it interactive for a
reason.
but just deleting the old file seems dangerous, indeed, so let's do the
check earlier and just switch to safe save mode if necessary.
not sure whether one should check for file_is_local or whether remote
files always have st_nlink == 1?

> Also you cannot move mc_chown()/mc_chmod() calls because they must be
> called before mc_open(). Elsewhere mc editor will hang for FTPD
> timeout on ftpfs and forever on fishfs.
> 
hmm, TooMuchBlackMagicException.

i attached a new version of the patch and a small optimization patch
which short-cuts the file existance check if it is irrelevant.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
Index: edit/edit-widget.h
===
RCS file: /cvsroot/mc/mc/edit/edit-widget.h,v
retrieving revision 1.24
diff -U2 -r1.24 edit-widget.h
--- edit/edit-widget.h  3 Dec 2004 17:09:27 -   1.24
+++ edit/edit-widget.h  9 Feb 2005 15:09:41 -
@@ -90,4 +90,5 @@
 
 struct stat stat1; /* Result of mc_fstat() on the file */
+int skip_ask_if_detach:1;  /* Already asked whether to detach file */
 
 /* syntax higlighting */
Index: edit/editcmd.c
===
RCS file: /cvsroot/mc/mc/edit/editcmd.c,v
retrieving revision 1.128
diff -U2 -r1.128 editcmd.c
--- edit/editcmd.c  7 Feb 2005 07:31:19 -   1.128
+++ edit/editcmd.c  9 Feb 2005 15:09:42 -
@@ -238,4 +239,23 @@
 }
 
+if (this_save_mode == EDIT_QUICK_SAVE &&
+   edit->stat1.st_nlink > 1 &&
+   !edit->skip_ask_if_detach)
+{
+   switch (query_dialog (_(" File has hard-links "),
+ _("Detach before saving?"), 0,
+ 3, _("&Yes"), _("&No"), _("&Cancel")))
+   {
+   case 0:
+   this_save_mode = EDIT_SAFE_SAVE;
+   /* fallthrough */
+   case 1:
+   edit->skip_ask_if_detach = 1;
+   break;
+   default:
+   return 1;
+   }
+}
+
 if (this_save_mode != EDIT_QUICK_SAVE) {
char *savedir, *saveprefix;
Index: edit/editcmd.c
===
RCS file: /cvsroot/mc/mc/edit/editcmd.c,v
retrieving revision 1.128
diff -U2 -r1.128 editcmd.c
--- edit/editcmd.c  7 Feb 2005 07:31:19 -   1.128
+++ edit/editcmd.c  9 Feb 2005 15:09:42 -
@@ -226,5 +226,6 @@
 }
 
-if (!vfs_file_is_local (filename) ||
+if (option_save_mode == EDIT_QUICK_SAVE ||
+   !vfs_file_is_local (filename) ||
(fd = mc_open (filename, O_WRONLY | O_BINARY)) == -1) {
/*
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

auto-indent

[Oswald Buddenhagen]

moin,

once upon a time, i wrote:
> proski wrote:
> > ossi wrote:
> > > the type of white-space used by auto-indent should not be based on the
> > > "fill tabs with spaces" setting. instead, the leading whitespace from
> > > the above line should be copied. otherwise it's impossible to use a
> > > tabbing style like
> > > if (...)
> > > if (cond1 && function(par1,
> > >   par2))
> > > statement;
> [to say it in words: tab for indentation, space for padding]
> > > (which is _the_ tabbing style).
> > 
> > I have no idea what you mean.
> >
> preserving the already present indentation style as much as possible.
> take the above example and imagine i want to add par3 to the function
> call. when i press enter on the first closing paren, the new line should
> be identical to the par2 line up to the point where the cursor is placed
> (below the p of par2, obviouly).

and this time i have a patch.
i implemented two variants, therefore the ifdef.
the first variant takes the nearest line with any non-whitespace as a
template, like current mcedit does. but unlike the current code, it does
not truncate the indentation to the current column (this can happen if
the line we are coming from is whitespace only and shorter than the
template line). this is also the way the old borland editors behaved,
but it's a true nightmare if you have no trailing whitespace removal.
the second variant just copies the leading whitespace of the previous
line, even if it is whitespace-only or even empty. i think this is
perfectly reasonable.


the second patch is just an optimization - the cheaper condition should
be evaluated first.

fwiw, the editor (and prolly all of mc) is full of such constructs. it
also contains things like "if (char[p] && p_in_certain_range)" where p
could actually go out of bounds unless constrained from outside.  this
should be fixed, if only for the sake of clarity.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
Index: edit.c
===
RCS file: /cvsroot/mc/mc/edit/edit.c,v
retrieving revision 1.97
diff -U2 -r1.97 edit.c
--- edit.c  7 Feb 2005 07:31:19 -   1.97
+++ edit.c  12 Feb 2005 14:11:10 -
@@ -1928,15 +1937,26 @@
 
 static void
-edit_auto_indent (WEdit * edit, int extra, int no_advance)
+edit_auto_indent (WEdit * edit)
 {
 long p;
-int indent;
+char c;
 p = edit->curs1;
-while (isspace (edit_get_byte (edit, p - 1)) && p > 0) /* move back/up 
to a line with text */
+#if 0
+/* move back/up to a line with text */
+while (p > 0 && isspace (edit_get_byte (edit, p - 1)))
p--;
-indent = edit_indent_width (edit, edit_bol (edit, p));
-if (edit->curs_col < indent && no_advance)
-   indent = edit->curs_col;
-edit_insert_indent (edit, indent + (option_fake_half_tabs ? HALF_TAB_SIZE 
: TAB_SIZE) * space_width * extra);
+#else
+/* use the previous line as a template */
+if (!--p)
+   return;
+#endif
+p = edit_bol (edit, p);
+/* copy the leading whitespace of the line */
+for (;;) { /* no range check - the line _is_ \n-terminated */
+   c = edit_get_byte (edit, p++);
+   if (c != ' ' && c != '\t')
+   break;
+   edit_insert (edit, c);
+}
 }
 
@@ -2249,10 +2269,10 @@
edit_double_newline (edit);
if (option_return_does_auto_indent)
-   edit_auto_indent (edit, 0, 1);
+   edit_auto_indent (edit);
format_paragraph (edit, 0);
} else {
edit_insert (edit, '\n');
if (option_return_does_auto_indent) {
-   edit_auto_indent (edit, 0, 1);
+   edit_auto_indent (edit);
}
}
Index: edit.c
===
RCS file: /cvsroot/mc/mc/edit/edit.c,v
retrieving revision 1.97
diff -U2 -r1.97 edit.c
--- edit.c  7 Feb 2005 07:31:19 -   1.97
+++ edit.c  12 Feb 2005 14:11:10 -
@@ -1351,5 +1351,5 @@
 edit_cursor_move (edit, edit_move_forward3 (edit, p, edit->prev_col, 0) - 
edit->curs1);
 
-if (is_in_indent (edit) && option_fake_half_tabs) {
+if (option_fake_half_tabs && is_in_indent (edit)) {
edit_update_curs_col (edit);
if (space_width)
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

visible tabs and trailing spaces

[Oswald Buddenhagen]

moin,

visible tabs help putting the tabs where you want them, particularly
when changing existing text.
making trailing whitespace visible helps avoiding it, if the editor has
no automatic trailing whitespace removal (which, in itself, is a feature
in certain situations).

i wanted the visibility to be as subtle as possible. therefore just
changing the background color (see leading tabs in Makefile highlite)
was no option. so i paint tabs as excerpts of <--> and spaces as
dots. to make it really subtle, i paint it bright blue on dark blue (the
regular background) - this is hardly visible, unless you are looking for
it. i know of no way to make it equally subtle on monochrome displays,
so the feature is disabled alltogether there.
an option to disable it is missing. volunteers sought.
the highlite color is not defined by syntax highliting, but by an
extra palette entry. i think this makes sense.
the whitespace becomes invisible when the text is selected, as there is
no possibility to merge colors. it'd be nice to fix this generally.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
Index: src/color.c
===
RCS file: /cvsroot/mc/mc/src/color.c,v
retrieving revision 1.40
diff -U2 -r1.40 color.c
--- src/color.c 24 Sep 2004 22:22:35 -  1.40
+++ src/color.c 13 Feb 2005 11:40:35 -
@@ -97,7 +97,8 @@
 { "editbold=",   0, 0 },   /* search->found */
 { "editmarked=", 0, 0 },   /* marked/selected */
+{ "editwhitespace=", 0, 0 },   /* whitespace */
 
-/* error dialog colors start at 37 */
-{ "errdhotnormal=",  0, 0 }, /* Error dialog normal/hot */ /* 37 */
+/* error dialog colors start at 38 */
+{ "errdhotnormal=",  0, 0 }, /* Error dialog normal/hot */ /* 38 */
 { "errdhotfocus=",   0, 0 }, /* Error dialog focused/hot */
 };
@@ -162,4 +163,5 @@
 "editbold=yellow,blue:"
 "editmarked=black,cyan:"
+"editwhitespace=brightblue,blue:"
 "errdhotnormal=yellow,red:"
 "errdhotfocus=yellow,lightgray";
Index: src/color.h
===
RCS file: /cvsroot/mc/mc/src/color.h,v
retrieving revision 1.21
diff -U2 -r1.21 color.h
--- src/color.h 3 Dec 2004 19:17:47 -   1.21
+++ src/color.h 13 Feb 2005 11:40:35 -
@@ -79,8 +79,9 @@
 #define EDITOR_BOLD_COLORIF_COLOR (35, A_BOLD)
 #define EDITOR_MARKED_COLOR  IF_COLOR (36, A_REVERSE)
+#define EDITOR_WHITESPACE_COLOR  IF_COLOR (37, 0 /* irrelevant */)
 
 /* Error dialog colors */
-#define ERROR_HOT_NORMAL   IF_COLOR (37, 0)
-#define ERROR_HOT_FOCUSIF_COLOR (38, 0)
+#define ERROR_HOT_NORMAL   IF_COLOR (38, 0)
+#define ERROR_HOT_FOCUSIF_COLOR (39, 0)
 
 #ifdef HAVE_SLANG
Index: edit/editdraw.c
===
RCS file: /cvsroot/mc/mc/edit/editdraw.c,v
retrieving revision 1.38
diff -U2 -r1.38 editdraw.c
--- edit/editdraw.c 7 Feb 2005 07:31:19 -   1.38
+++ edit/editdraw.c 13 Feb 2005 11:40:35 -
@@ -39,4 +39,5 @@
 #define MOD_MARKED (1 << 10)
 #define MOD_CURSOR (1 << 11)
+#define MOD_WHITESPACE (1 << 12)
 
 #define FONT_OFFSET_X 0
@@ -224,10 +225,24 @@
}
 
-   if (style & MOD_BOLD) {
-   set_color (EDITOR_BOLD_COLOR);
-   } else if (style & MOD_MARKED) {
-   set_color (EDITOR_MARKED_COLOR);
+   if (style & MOD_WHITESPACE) {
+   if (style & MOD_MARKED) {
+   textchar = ' ';
+   set_color (EDITOR_MARKED_COLOR);
+   } else {
+   if (color == EDITOR_NORMAL_COLOR)
+   set_color (EDITOR_WHITESPACE_COLOR);
+   else {
+   textchar = ' ';
+   lowlevel_set_color (color);
+   }
+   }
} else {
-   lowlevel_set_color (color);
+   if (style & MOD_BOLD) {
+   set_color (EDITOR_BOLD_COLOR);
+   } else if (style & MOD_MARKED) {
+   set_color (EDITOR_MARKED_COLOR);
+   } else {
+   lowlevel_set_color (color);
+   }
}
 
@@ -244,5 +259,5 @@
 static unsigned int line[MAX_LINE_LEN];
 unsigned int *p = line;
-long m1 = 0, m2 = 0, q, c1, c2;
+long m1 = 0, m2 = 0, q, c1, c2, tws;
 int col, start_col_real;
 unsigned int c;
@@ -267,4 +282,10 @@
 
if (row <= edit->total_lines - edit->start_line) {
+   if (use_colors) {
+   tws = edit_eol (edit, b);
+   while (tws > b && edit_get_byte (edit, tws - 1) == ' ')
+   tws--;
+   }
+
while (col <= end_col - edit->start_col) {
*p = 0;
@@ -293,5 +314,4 @@
*p |= book_mark << 16;
}
-   q++;
switch (c) {
case '\n':
@@ -301,10 +321,31 @@

Re: visible tabs and trailing spaces

[Oswald Buddenhagen]

On Sun, Feb 13, 2005 at 01:18:12PM +0100, Leonard den Ottolander wrote:
> However, could be that I've overseen this, but where is the code that
> allows the user to toggle this behaviour?

On Sun, Feb 13, 2005 at 12:56:26PM +0100, Oswald Buddenhagen wrote:
> an option to disable it is missing. volunteers sought.

;)

-- 
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: visible tabs and trailing spaces

[Oswald Buddenhagen]

On Sun, Feb 13, 2005 at 12:56:26PM +0100, Oswald Buddenhagen wrote:
> +++ edit/editdraw.c   13 Feb 2005 11:40:35 -
> + if (color == EDITOR_NORMAL_COLOR)
>
fwiw, this test sucks, because it disables visible whitespace in any
syntax-highlitet text. what we really need to find out is, whether the
physical background color matches.
so if somebody understands how the palette works and can come up with a
fast comparison ...

> + set_color (EDITOR_WHITESPACE_COLOR);
> + else {
> + textchar = ' ';
> + lowlevel_set_color (color);
> + }

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

syntax highlite stuff

[Oswald Buddenhagen]

moin,

here's two patches:

the first makes mcedit recognize certain languages when the interpreter
is invoked with /usr/bin/env. please commit.

the idea for the second patch was already suggested ... the split off
of c from c++. the difference is only the list of keywords. copy the old
c.syntax to cxx.syntax and apply the patch to get the desired effect.
unfortunately header files are always declared c++ files. not doing so
would require integration with the editor's search function and looking
for something like '^\s*class\s'.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
Index: Syntax
===
RCS file: /cvsroot/mc/mc/syntax/Syntax,v
retrieving revision 1.27
diff -U2 -r1.27 Syntax
--- Syntax  3 Nov 2004 20:16:48 -   1.27
+++ Syntax  20 Feb 2005 09:42:01 -
@@ -30,14 +30,14 @@
 include lsm.syntax
 
-file ..\*\\.sh$ Shell\sScript ^#!\s\*/.\*/([a-z]?|ba|pdk)sh
+file ..\*\\.sh$ Shell\sScript ^#!\s\*/(.\*/|usr/bin/env\s)([a-z]?|ba|pdk)sh
 include sh.syntax
 
-file ..\*\\.(pl|PL|pm|PM)$ Perl\sProgram ^#!\s\*(/.\*/perl|@PERL@)
+file ..\*\\.(pl|PL|pm|PM)$ Perl\sProgram 
^#!\s\*(/(.\*/|usr/bin/env\s)perl|@PERL@)
 include perl.syntax
 
-file ..\*\\.(py|PY)$ Python\sProgram ^#!\s\*/.\*/python
+file ..\*\\.(py|PY)$ Python\sProgram ^#!\s\*/(.\*/|usr/bin/env\s)python
 include python.syntax
 
-file ..\*\\.(rb|RB)$ Ruby\sProgram ^#!\s\*/.\*/ruby
+file ..\*\\.(rb|RB)$ Ruby\sProgram ^#!\s\*/(.\*/|usr/bin/env\s)ruby
 include ruby.syntax
 
Index: Makefile.am
===
RCS file: /cvsroot/mc/mc/syntax/Makefile.am,v
retrieving revision 1.22
diff -U2 -r1.22 Makefile.am
--- Makefile.am 6 Dec 2004 23:14:43 -   1.22
+++ Makefile.am 20 Feb 2005 09:42:01 -
@@ -4,4 +4,5 @@
aspx.syntax \
c.syntax\
+   cxx.syntax  \
cs.syntax   \
changelog.syntax\
Index: Syntax
===
RCS file: /cvsroot/mc/mc/syntax/Syntax,v
retrieving revision 1.27
diff -U2 -r1.27 Syntax
--- Syntax  3 Nov 2004 20:16:48 -   1.27
+++ Syntax  20 Feb 2005 09:42:01 -
@@ -69,7 +69,10 @@
 include texinfo.syntax
 
-file ..\*\\.([chC]|CC|cxx|cc|cpp|CPP|CXX|hxx|h\.in)$ C/C\+\+\sProgram
+file ..\*\\.c$ C\sProgram
 include c.syntax
 
+file ..\*\\.([hC]|CC|cxx|cc|cpp|CPP|CXX|hxx|h\.in)$ C/C\+\+\sProgram
+include cxx.syntax
+
 file ..\*\\.[fF]$ Fortran\sProgram
 include fortran.syntax
Index: c.syntax
===
RCS file: /cvsroot/mc/mc/syntax/c.syntax,v
retrieving revision 1.15
diff -U2 -r1.15 c.syntax
--- c.syntax15 Mar 2003 04:41:20 -  1.15
+++ c.syntax20 Feb 2005 09:42:01 -
@@ -33,32 +33,5 @@
 keyword whole while yellow
 keyword whole asm yellow
-keyword whole catch yellow
-keyword whole class yellow
-keyword whole friend yellow
-keyword whole delete yellow
 keyword whole inline yellow
-keyword whole new yellow
-keyword whole operator yellow
-keyword whole private yellow
-keyword whole protected yellow
-keyword whole public yellow
-keyword whole this yellow
-keyword whole throw yellow
-keyword whole template yellow
-keyword whole try yellow
-keyword whole virtual yellow
-keyword whole bool yellow
-keyword whole const_cast yellow
-keyword whole dynamic_cast yellow
-keyword whole explicit yellow
-keyword whole false yellow
-keyword whole mutable yellow
-keyword whole namespace yellow
-keyword whole reinterpret_cast yellow
-keyword whole static_cast yellow
-keyword whole true yellow
-keyword whole typeid yellow
-keyword whole typename yellow
-keyword whole using yellow
 keyword whole wchar_t yellow
 keyword whole ... yellow
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: [patch] Synchronization of the panels

[Oswald Buddenhagen]

On Tue, Feb 22, 2005 at 10:32:07AM +0300, Siver Andrey wrote:
> Please consider my patch to synchronize the panels with hard drives
> state.
>  
note that dnotify prevents a watched directory from being unmounted (one
of the reasons why it is being replaced). that means one has to leave
the dir in question in both panels. no problem as such, but it might
lead to surprises ...

-- 
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: New syntax highlight files, please add it to the distro

[Oswald Buddenhagen]

On Wed, Mar 16, 2005 at 07:45:45AM +0200, Mike V. Gorchak wrote:
> because assembler keywords different in the each product (WASM, MASM,
> TASM, GAS, NASM, etc) and I have tryied to add as much as possible
> keywords,
>
i'm strictly against putting all the asm syntaxes in one file. it is
annoying enough for c vs. c++; for asm (with completely different
syntax of gas compared to the rest) it would be a nightmare.

-- 
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: New syntax highlight files, please add it to the distro

[Oswald Buddenhagen]

On Thu, Mar 17, 2005 at 07:29:27AM +0200, Mike V. Gorchak wrote:
> It's works fine for me with GAS, NASM and TASM.
>
oh, sure it "works". with my variable ah in gas being highlighted, etc.
just as useful as "new" and "class", etc. all over my c sources.

> And how you planning to split NASM sources with GAS for example, both
> can contain .s and .asm extension.
> 
that's indeed a problem - the same as with c vs. c++ header files. see
my last post on this topic some days ago.

-- 
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: Issues to fix before 4.6.1?

[Oswald Buddenhagen]

On Tue, Mar 29, 2005 at 05:46:33PM +0200, Jindrich Novy wrote:
> On Tue, 2005-03-29 at 11:07 +0300, Andrew V. Samoilov wrote:
> > There is a data loss possible if file is edited with external editor over 
> > VFS.
> 
> I have similar experience even with mcedit without VFS -> data loss when
> disk quota is exceeded, the edited file is truncated to zero size. I had
> these problems with mc-4.5.51 so I'm not sure if it's still a problem
> with recent mc.
> 
i've had this just yesterday ... good luck it was no important file.
this happens with the quick save mode ... it must, given the way it
works. not sure it can be fixed properly at all without just switching
to another mode. oh, well, it could be fixed to not lose data, but the
resulting file would be a bit inconsistent.

-- 
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: [PATCH] Re: Issues to fix before 4.6.1?

[Oswald Buddenhagen]

On Wed, Mar 30, 2005 at 10:11:19AM +0200, Jindrich Novy wrote:
> if (!vfs_file_is_local (filename) ||
> (fd = mc_open (filename, O_WRONLY | O_BINARY)) == -1)
> 
> what actually truncates the filename to zero size.
>
it does not, unless mc_open has totally misleading semantics - there is
no O_TRUNCATE. the truncation comes during the actual write ... which
leaves us with a truncated/empty file, if we run out-of-space in the
middle.
the "solution" would be not to use O_TRUNCATE at all. instead, first
write the part that extends beyond the end of the old file. if that
fails to complete, truncate to the old length. if we crash now, the old
file will have garbage appended, but at least it's not clobbered
alltogether. note that we cannot just seek to the new end and write one
byte because of sparse files. after the "extension" was written,
overwrite the start of the file with the new content and possibly
truncate the file to the new length. this is all sooo ugly ...

-- 
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: [patch] const_cast to be replaced by str_unconst

[Oswald Buddenhagen]

On Tue, Apr 12, 2005 at 08:28:50PM +0200, Roland Illig wrote:
> Pavel Tsekov wrote:
> >>For those of you that are concerned about the performance loss of an
> >>extra function call: It is much more important for the code to be
> >>readable and checkable by the compiler than to be 1 millisecond faster
> >>at all.
> >
> >You can inline it.
> 
> When compiling with gcc using -Wcast-qual, this would give us a warning 
> for every file.
>
???
put
static inline unconst***() { ... }
in the header file and be fine.
of course you need a configure check that optionally #defines inline to
nothing.

-- 
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: [patch] const_cast to be replaced by str_unconst

[Oswald Buddenhagen]

On Thu, Apr 14, 2005 at 07:19:28PM +0200, Oswald Buddenhagen wrote:
> On Tue, Apr 12, 2005 at 08:28:50PM +0200, Roland Illig wrote:
> > >You can inline it.
> > 
> > When compiling with gcc using -Wcast-qual, this would give us a warning 
> > for every file.
> >
> ???
> put
> static inline unconst***() { ... }
> in the header file and be fine.
> of course you need a configure check that optionally #defines inline to
> nothing.
> 
whoops, this is exactly what you're talking about. :}
anyway, i don't think this extra warning would matter, given that it
would be in the same location in every file.
and, fwiw, isn't it possible to use a #pragma or some __attribute__ to
get rid of the warning?

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

bug: mcedit leaving stale lock files

[Oswald Buddenhagen]

moin,

if you change an existing file and save it under a new name, a lock file
for the original file is left behind.

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

[bug #13091] Open a symlink to edit when save, erase symlink and make a new file.

[Oswald Buddenhagen]

Follow-up Comment #5, bug #13091 (project mc):

F9 -> options -> save mode -> switch to "quick save"
and everything is fine ...

it might be worth consideration, though, to make the "safe save" and "do
backups" modes follow symlinks.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #7872>] Suggested changes in Python syntax bindings

[Oswald Buddenhagen]

Follow-up Comment #2, bug #7872> (project mc):

> What's the point of the "(env\s)?" change?
>
pointless, imo. env located in any other directory is entirely against the
idea of using it in the first place ...

> And isn't 'context """ """' a comment?
>
nope. read the lang spec. :-P


___

Reply to this item at:

  >

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #8735] Inconveinient editor

[Oswald Buddenhagen]

Follow-up Comment #2, bug #8735 (project mc):

... and alt-l for goto line number.

if it does not work, it may be your terminal.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #9631] Cannot "put tabs only where I want them"

[Oswald Buddenhagen]

Follow-up Comment #2, bug #9631 (project mc):

leonard didn't get the idea. :-P
this bug is _not_ fixed; nothing changed here for years.

i posted this patch some months ago, but nobody cared to notice.

___

Additional Item Attachment:

File name: mcedit-autoindent.diff Size:1 KB
patch to make autoindent sane


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #11983] Work directory problem

[Oswald Buddenhagen]

Follow-up Comment #2, bug #11983 (project mc):

this is an immediate result of bug #11982. i think it can be safely declared
a duplicate.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #12223] shift keys should change function menu descriptions

[Oswald Buddenhagen]

Follow-up Comment #1, bug #12223 (project mc):

i think this is pretty much impossible to implement in tty based apps, as the
terminal does not report modifier state changes. one could do a cross-link to
X and/or the linux console, but this would be pretty nasty.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #12737] Issues with Batch Operations

[Oswald Buddenhagen]

Follow-up Comment #5, bug #12737 (project mc):

the same happens under *nix with a vfat mount when the mount option "quiet"
(ignore perm set errors) is not set.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #12860] mc should display progress bars when copying a single directory

[Oswald Buddenhagen]

Follow-up Comment #1, bug #12860 (project mc):

this is pretty much a dupe of bug #10508, imho.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #13102] mcedit leaving stale lock files

[Oswald Buddenhagen]

URL:
  

 Summary: mcedit leaving stale lock files
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Mon 05/16/2005 at 17:31
Category: Editor
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

if you change an existing file and save it under a new name, a lock file for
the original file is left behind.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #9631] Cannot "put tabs only where I want them"

[Oswald Buddenhagen]

Follow-up Comment #5, bug #9631 (project mc):

this one is really a hard birth ... it has two years of history already ...
:)

disclaimer: i freely interpret the original report as being the same as my
wish, because the request makes little sense when implemented literally. :)

ok, here is the mail i sent along with the patch:

once upon a time, i wrote:
> proski wrote:
> > ossi wrote:
> > > the type of white-space used by auto-indent should not be based on the
> > > "fill tabs with spaces" setting. instead, the leading whitespace from
> > > the above line should be copied. otherwise it's impossible to use a
> > > tabbing style like
> > > if (...)
> > > if (cond1 && function(par1,
> > >   par2))
> > > statement;
> [to say it in words: tab for indentation, space for padding]
> > > (which is _the_ tabbing style).
> >
> > I have no idea what you mean.
> >
> preserving the already present indentation style as much as possible.
> take the above example and imagine i want to add par3 to the function
> call. when i press enter on the first closing paren, the new line should
> be identical to the par2 line up to the point where the cursor is placed
> (below the p of par2, obviouly).

and this time i have a patch.
i implemented two variants, therefore the ifdef.
the first variant takes the nearest line with any non-whitespace as a
template, like current mcedit does. but unlike the current code, it does
not truncate the indentation to the current column (this can happen if
the line we are coming from is whitespace only and shorter than the
template line). this is also the way the old borland editors behaved,
but it's a true nightmare if you have no trailing whitespace removal.
the second variant just copies the leading whitespace of the previous
line, even if it is whitespace-only or even empty. i think this is
perfectly reasonable.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #12223] shift keys should change function menu descriptions

[Oswald Buddenhagen]

Follow-up Comment #4, bug #12223 (project mc):

> One person opines that a fix is impossible, and this is reason for an
immediate close/wontfix?
>
don't you think that the practical impossibility to fix it warrants this
step? ;)

> Curses isn't necessarily the end of console development.
>
this has nothing to do with curses. it's a fundamental problem of ttys.
the "fix" would be specific to particular environments, therefore making
behavior inconsistent (e.g., remote tty logins have absolutely no way to find
out the modifier state (unless you find a terminal that has a magic escape
sequence for it)).  therefore nobody is going to implement it - and this is
just what "won't fix" means.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #12223] shift keys should change function menu descriptions

[Oswald Buddenhagen]

Follow-up Comment #6, bug #12223 (project mc):

i think you should stop arguing about things you obviously have no idea about
...
you may, however, request an explanation, if you are uncapable of doing the
research yourself.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

link in bug status mails

[Oswald Buddenhagen]

funny thing this "savannah-zilla":

>   

but it is immediately redirected to https://

is this something the mc project holders can fix or is it up to the
gnu.org admins?

also, i find it inconvenient that the link is enclosed in <>, as i can't
just select an entire line and have klipper open it for me (actually, i
could, but that would require defining a new rule :). oh, well.

-- 
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: link in bug status mails

[Oswald Buddenhagen]

On Wed, May 18, 2005 at 12:17:14AM +0200, Thomas Zajic wrote:
> >funny thing this "savannah-zilla":
> >> 
> >but it is immediately redirected to https://
> >
> Works fine here, no redirection to https:// ...

> when you logged into Savannah, did you select "Stay in SSL mode after
> login" (IIRC this is enabled by default)?
> 
hmm, indeed, this might be it. funny effect, sorta unexpected, but it
makes sense when you think about it.

> >also, i find it inconvenient that the link is enclosed in <>,
> 
> Works fine with both mutt/urlview and Thunderbird, didn't try anything
> else. ;-)
>
never got to finding out what this urlview is, but it must be cool. :)

-- 
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: portability of mc

[Oswald Buddenhagen]

On Wed, May 18, 2005 at 07:13:36AM +0200, Roland Illig wrote:
> Do we want mc to be able to run on platforms that have:
> 
> - 16 bit ints
> - 16 bit size_t
>
hardly any unix app will run or even compile under these conditions.
we're not in the 70s any more. :)

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

[bug #13112] Cannot copy to a directory called "*"

[Oswald Buddenhagen]

Follow-up Comment #2, bug #13112 (project mc):

i once suggested mc participating in the XDG VFS standardization process, but
proski seems to prefer taking a passive role ...


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #12223] shift keys should change function menu descriptions

[Oswald Buddenhagen]

Follow-up Comment #12, bug #12223 (project mc):

pavel wrote:
> MC already has code which queries the keyboard modifiers on these systems.
>
what does it use them for?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: [OT] Re: [bug #12223] shift keys should change function menu descriptions

[Oswald Buddenhagen]

On Tue, May 18, 1999 at 11:56:15AM +0300, Pavel Tsekov wrote:
> And no - MC is not short on developers. IMHO, MC is short on ideas
> where to go next .
> 
that's probably the best joke i heard in years. ;)
it's 100% contradicting proski's statement from some months back.
but as you seem to suffer from boredom, you'll certainly happily and
timely implement all my feature requests i'll shortly insert into
bugzilla (not that i haven't posted them before, but heck). ;)

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

[bug #12223] shift keys should change function menu descriptions

[Oswald Buddenhagen]

Follow-up Comment #16, bug #12223 (project mc):

sorry, that was me from work (i bet you guessed ;). it's unfamiliar to me
that this bugzilla allows posting without logging in.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: mc 4.6.1-pre3 not working on the linux console

[Oswald Buddenhagen]

On Thu, May 19, 2005 at 12:34:05AM +0200, Ludovic Drolez wrote:
> So I tried mc on a Debian Sid and the linux console, but it was even worse
> than reported: Any non-alphanumeric key did not work and the enter key just
> prints '..' (as if the ESC key was pressed).
> 
hihi ... as we're on the topic of cross-linking environment-specific
ways to obtain modifiers, etc.  it would not surprise me, if this was
an effect of mc thinking alt-ctrl is pressed, because of the alt-ctrl-fx
used to switch to the console.
anyway, i think the most reasonable reply is "unset DISPLAY" ...

-- 
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: [OT] Re: [bug #12223] shift keys should change function menu descriptions

[Oswald Buddenhagen]

On Wed, May 19, 1999 at 10:37:25AM +0300, Pavel Tsekov wrote:
> Do you care to explain which statement of proski do you refer to ?
>
http://mail.gnome.org/archives/mc-devel/2003-October/msg00036.html
the last sentence. imo it clearly says "we have too little time".
you otoh seemed to claim "we don't know what to do with our time",
which you now effectively refuted. i knew this before and that's why i
called your somewhat strange statement a joke.

> The best joke, IMO, is the fact that the release of MC 4.6.1 is going
> to happen real soon now for two and a half years.
>
that's indeed a sad joke ... :(

-- 
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: portability of mc

[Oswald Buddenhagen]

On Fri, May 20, 2005 at 10:41:02AM -0400, Pavel Roskin wrote:
> On Fri, 2005-05-20 at 10:09 +0200, Roland Illig wrote:
> > Pavel Roskin wrote:
> > > No.  In particular, I don't think we need to support Win64, where long
> > > cannot hold a pointer.
> > 
> > Why not? What's wrong about that?
> 
> Because it's a common assumption that long can hold any pointer.  
> 
which doesn't really change the fact, that it is wrong ... size_t isn't
exactly a new concept.

-- 
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: portability of mc

[Oswald Buddenhagen]

On Sat, May 21, 2005 at 01:11:35PM +0200, Roland Illig wrote:
> And even size_t has nothing to do with the representation of pointers. 
>
i don't think we're speaking about such stupid things as casting between
pointers and non-pointers (for other purposes than abusing a void* as a
variant type without needing to resort to a union - i think this is
safe). if we do, these bugs should be fixed anyway.
but size_t is guaranteed to be able to cover any offset within the data
address space, i think, otherwise it would be pretty much pointless in
the first place. and these are the cases where long is often used when
it shouldn't. i think it is reasoable to fix those cases independently
from the desire to run mc on winblowz (which for i couldn't care less).

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

[bug #13143] "quick save" may clobber files

[Oswald Buddenhagen]

URL:
  

 Summary: "quick save" may clobber files
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Sat 05/21/2005 at 17:24
Category: Editor
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

if we run out of disk space, some i/o error occurs, or we are just killed
while saving a file, the old contents will be lost.
that's because the old file is opened with O_TRUNC and rewritten.
the "solution" would be not to use O_TRUNC at all. instead, first write the
part that extends beyond the end of the old file (note that we cannot just
seek to the new end and write one byte because of sparse files) - if that
fails to complete, truncate to the old length (if we crash in between, the
old file will have garbage appended, but at least it's not clobbered
alltogether).  after the "extension" was written, overwrite the start of the
file with the new content (if we crash in during this, the file is clobbered,
but that's what you get for using "quick save") and possibly truncate the file
to the new length.
some VFS inherently don't support seeking, so this "slightly safer" mode is
not universally applicable.

a related note: for non-local files, "quick save" is used independently of
the configured save mode. i think the VFS should tell the editor whether it
can do remote renames, so the safe save modes we can be used in as many cases
as possible.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #6415] syntax highlighting breaks on more complicated shell regexps

[Oswald Buddenhagen]

Follow-up Comment #2, bug #6415 (project mc):

that's very unfortunate, because it makes mcedit a pretty bad editor for
sophisticated scrips.

i don't think this very hard to fix. i already did a simple parser that skips
over nested sh constructs. with recursive contexts (nested contexts need to be
color-neutral) writing a proper syntax file should be doable.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: [PATCH] space on prompt bugfix

[Oswald Buddenhagen]

On Mon, Mar 21, 2005 at 09:19:34AM +0100, Jindrich Novy wrote:
> Hi mc-devel!
> 
> There's a bug I've been annoyed with for some time so I finally decided
> to fix it.
> 
> To reproduce:
> 1. start mc
> 2. go to some directory where you see some further subdirectories
> 3. press space once or for more times -> spaces will appear in the
> command prompt
> 4. try to go to some subdirectory by pressing enter on it or press enter
> on any *.c, *.mp3 file.
> 
> Results:
> You're unable to change a directory until you delete all spaces typed on
> command prompt and mc does nothing while you're pressing Enter.
> Furthermore you're unable to launch any application by tapping enter on
> *.c, *.mp3 files, etc.
> 
[...]
> Allows an user to type leading spaces on the command prompt, but when
> enter is pressed, it tests whether the user typed at least something
> except spaces. In case it finds only spaces, it deletes them from the
> command prompt and let the enter be further processed.

On Wed, Apr 27, 2005 at 11:24:06PM +0200, Leonard den Ottolander wrote:
> Any objections against me committing this patch? The "real command line"
> argument seems bogus, as a "real command line" would accept a "command"
> existing of only spaces but mc does not.
> 
> So can I commit this? I'll verify that it works first ;) , but the patch
> seems straight forward enough.
> 
there were no objections, so i suppose you forgot it. :)

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
--- mc-4.6.1-pre3/src/main.c.jn 2005-03-19 15:55:40.0 +0100
+++ mc-4.6.1-pre3/src/main.c2005-03-19 17:04:10.0 +0100
@@ -1490,9 +1490,14 @@ midnight_callback (struct Dlg_head *h, d
if (parm == '\t')
free_completions (cmdline);
 
-   if (parm == '\n' && cmdline->buffer[0]) {
-   send_message ((Widget *) cmdline, WIDGET_KEY, parm);
-   return MSG_HANDLED;
+   if (parm == '\n') {
+   for (i = 0; cmdline->buffer[i] && cmdline->buffer[i] == ' '; i++);
+   if (cmdline->buffer[i]) {
+   send_message ((Widget *) cmdline, WIDGET_KEY, parm);
+   return MSG_HANDLED;
+   }
+   stuff (cmdline, "", 0);
+   cmdline->point = 0;
}
 
/* Ctrl-Enter and Alt-Enter */
@@ -1527,7 +1532,7 @@ midnight_callback (struct Dlg_head *h, d
reverse_selection_cmd ();
return MSG_HANDLED;
}
-   } else if (!command_prompt || !strlen (cmdline->buffer)) {
+   } else if (!command_prompt || !cmdline->buffer[0]) {
/* Special treatement '+', '-', '\', '*' only when this is 
 * first char on input line
 */
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

[bug #7872] Suggested changes in Python syntax bindings

[Oswald Buddenhagen]

Follow-up Comment #3, bug #7872 (project mc):

err, i misread it. in fact, this is very similar to what i have submitted
some time ago (and somehow i thought it was already committed ... which is
sort of like believing in santa claus ;). it's only pointless to look for env
somewhere else than in /usr/bin/.
here is my complete patch.

___

Additional Item Attachment:

File name: Syntax.diffSize:0 KB
patch making mcedit recognize scripts that invoke the interpreter via
/usr/bin/env


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #13144] c is _not_ c++

[Oswald Buddenhagen]

URL:
  

 Summary: c is _not_ c++
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Sat 05/21/2005 at 18:55
Category: Editor
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

highlighting c++ keywords like "class", "new", etc. in plain c files is
outright wrong and consequently annoying.

the only problem are .h files, as their language is not obvious from the
extension. i think the presence of class definitions is a sufficient
criterion for c++, but recognizing them reliably requires a minimal parser -
even regexps won't do ...

ps: don't tell me i shouldn't be using c++ keywords in c headers, because the
header might be included in c++ files later - this is _my_ business.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #13146] make tabs and trailing spaces visible

[Oswald Buddenhagen]

URL:
  

 Summary: make tabs and trailing spaces visible
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Sat 05/21/2005 at 19:25
Category: Editor
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

visible tabs help putting the tabs where you want them, particularly when
trying to stay consistent with the style of text written by somebody else.
making trailing whitespace visible helps avoiding it in undesired places.

here is a patch that accomplishes this. it is missing an option to disable
this feature, so i post this as a wish instead of as a patch.

i wanted the visibility to be as subtle as possible. therefore just changing
the background color (see leading tabs in Makefile highlite) was no option.
so i paint tabs as excerpts of <--> and spaces as dots. to make it really
subtle, i paint it bright blue on dark blue (the regular background) - this is
hardly visible, unless you are looking for it. i know of no way to make it
equally subtle on monochrome displays,
so the feature is disabled alltogether there.
the whitespace becomes invisible when the text is selected, as there is no
possibility to merge colors. it'd be nice to fix this generally.
the highlite color is not defined by syntax highlighting, but by an extra
palette entry. i think this makes sense.
this feature overrides other colors that might be defined for whitespace,
like the red background of tabs in Makefiles. the block in #if 0 would
preserve the color of already highlighted whitespace, but it's a too broad
criterion. i don't think ignoring this fact is a problem, as you can
recognize the tabs anyway (obviously).
note, that you can't just copy such text from the terminal, as the
pseudo-whitespace chars will show up in the copy. therefore a hotkey to
switch it off quickly would be useful. otoh, a) the problem that this feature
is disabled in selected blocks is an advantage in this context and b) by
copying, you would be destroying the original whitespace anyway.






___

File Attachments:


---
Date: Sat 05/21/2005 at 19:25  Name: mcedit-visible-ws.diff  Size: 4.38KB  
By: ossi
the not-so-ready patch


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #7872] Suggested changes in Python syntax bindings

[Oswald Buddenhagen]

Follow-up Comment #6, bug #7872 (project mc):

> [...] We could just as well start matching all possible paths to the
binaries.
>
i can't claim i'd understand that paragraph. :}

> [...] If you could comment on the usefulness [...]
>
i'm can't claim to be a python wiz, either.
http://docs.python.org/ref/strings.html
the misunderstanding wrt. comments stems from the fact, that a string right
after the def: of a function is a doc string.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: [PATCH] space on prompt bugfix

[Oswald Buddenhagen]

On Mon, May 23, 2005 at 10:44:01PM +0200, Leonard den Ottolander wrote:
> On Sat, 2005-05-21 at 20:07, Oswald Buddenhagen wrote:
> > On Wed, Apr 27, 2005 at 11:24:06PM +0200, Leonard den Ottolander wrote:
> > > So can I commit this? I'll verify that it works first ;) , but the patch
> > > seems straight forward enough.
> > > 
> > there were no objections, so i suppose you forgot it. :)
> 
> I should have asked for a verification ;-p .
>
hehe

> So you've tested this patch
>
of course not. i had a look and have not found something fundamentally
broken about it. if a "real" mc developer would do the same, it should
be totally sufficient.
this paranoid checking policy doesn't get us anywhere but to the current
state of stagnation. head is there for being broken once in a while. and
if you find yourself in the situation that you cannot break head because
people are relying on it's stability, you should seriously reconsider
your release policy ...

> and agree it should be committed?
> 
sure

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

[bug #7872] Suggested changes in Python syntax bindings

[Oswald Buddenhagen]

Follow-up Comment #8, bug #7872 (project mc):

i'd prefer to have the exact match as a simple correctness check. oh, well.

""" is just the same as ", except that you can embed physical newlines in
this type of string.
actually reading the BNF in the page i linked to would have revealed that (as
it did to me now). don't act more stupid than you are. ;)


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: [PATCH] space on prompt bugfix

[Oswald Buddenhagen]

On Mon, May 23, 2005 at 11:12:21PM +0200, Leonard den Ottolander wrote:
> On Mon, 2005-05-23 at 22:56, Oswald Buddenhagen wrote:
> > this paranoid checking policy doesn't get us anywhere but to the current
> > state of stagnation.
> 
> Bollocks. [how reviewing is good, etc.]
> 
i was talking about the testing aspect, in particular. it will be tested
after commit (apart from that i expect the author to have tested most
possible situations already), so why slow down your process by enforcing
something that nobody will do anyway?

> > head is there for being broken once in a while. [...]
> 
> I was intending to commit this to PRE as well.
> 
and you have to do this in the same second, right? ;)

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

[bug #2796] cons.saver in wrong directory

[Oswald Buddenhagen]

Follow-up Comment #4, bug #2796 (project mc):

i think it should be fixed for the sake of cleanness, not because it is
strictly necessary.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: [PATCH] space on prompt bugfix

[Oswald Buddenhagen]

On Wed, May 25, 2005 at 06:31:15PM +0300, Andy Shevchenko wrote:
> - why do you not drop tabspaces?
>
hmm, indeed, if i go into troubles to press ctrl-q tab, the same issue
comes up.

> - the beheviour of ... should be accorded to shell (no put
> the command to the history), isn't it?
> 
this was discussed already, and this patch was chosen according to this
requirement.

-- 
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: Anonymous posts in bugzilla

[Oswald Buddenhagen]

On Wed, May 25, 2005 at 07:03:29PM +0200, Roland Illig wrote:
> This needs discussion.
>
no. it's enought that i state that we want authentication. basta. :

> I do not want to restrict bug reports to Savannah developers. Bug
> reports should come from _users_, not _developers_.
> 
everyone can get an account without any review. see, even i did. :)

-- 
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: [PATCH] space on prompt bugfix

[Oswald Buddenhagen]

On Wed, Jun 01, 2005 at 11:10:16AM +0200, Jindrich Novy wrote:
> I'm attaching the new patch
>
given that the other patch was finally applied, an incremental patch
would be more helpful.
anyway, i think the change can be commited without further comment ...

-- 
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: [patch] avoiding casts of function pointers

[Oswald Buddenhagen]

On Tue, Jun 07, 2005 at 05:12:59PM +0200, Roland Illig wrote:
> This patch fixes the gcc warning about incompatible pointer types in 
> widget.c. I is much more complicated than Jindrich's patch, but in 
> return it is fully ISO C compliant. :)
> 
what an effort ...
the simplest solution is making the functions that don't need a pointer
just have a dummy parameter. that's typical for callbacks.

-- 
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: old bug in achown.c

[Oswald Buddenhagen]

On Wed, Jun 08, 2005 at 02:45:32AM +0200, Roland Illig wrote:
> - advanced_chown_callback (h, KEY_RIGHT, DLG_KEY);
> + advanced_chown_callback (h, DLG_KEY, KEY_RIGHT);
>  
heh, wow ...
another a good example of why #define is bad and enum is good - provided
you have a sufficiently strict compiler.

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

cons.saver not suid root

[Oswald Buddenhagen]

moin,

for some time now, cons.saver is not installed suid root any more,
making the whole thing sort of pointless.
the attached patch makes it useful for me.
comments?

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
--- Makefile.am.orig2005-06-08 16:30:58.0 +0200
+++ Makefile.am 2005-06-08 16:29:13.0 +0200
@@ -75,6 +75,8 @@
 if USE_EDIT
$(MAKE) install_mcedit
 endif
+   chown root:root $(pkglibdir)/cons.saver
+   chmod u+s $(pkglibdir)/cons.saver
 
 #
 # Make relative symlinks, but do the right thing if LN_S is `ln' or `cp'.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: cons.saver not suid root

[Oswald Buddenhagen]

On Wed, Jun 08, 2005 at 04:40:14PM +0200, Jakub Jelinek wrote:
> On Wed, Jun 08, 2005 at 04:35:16PM +0200, Oswald Buddenhagen wrote:
> > for some time now, cons.saver is not installed suid root any more,
> > making the whole thing sort of pointless.
> > the attached patch makes it useful for me.
> > comments?
> 
> cons.saver should not be setuid root, it should be setuid to whatever
> user owns /dev/vcsa* devices.  Ideally there is a vcsa user that
> just owns these devices and cons.saver.
> 
yes, i'm aware of this. anyway, we have no portable (even across
linuxes) way to create a vcsa user, so there is no other option than
root. actually, this is what many other programs do. and if packagers
can do better, i won't complain. i just want something that works out of
the box.

-- 
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: cons.saver not suid root

[Oswald Buddenhagen]

On Wed, Jun 08, 2005 at 04:54:36PM +0200, Leonard den Ottolander wrote:
> On Wed, 2005-06-08 at 16:49, Oswald Buddenhagen wrote:
> > yes, i'm aware of this. anyway, we have no portable (even across
> > linuxes) way to create a vcsa user, so there is no other option than
> > root.
> 
> I'd rather have the downstream packagers fixing the device permissions
> and the accompanying user than suid-ing cons.saver root.
>
and "punish" the upstream users, including ourselves? interesting.

> That's just ugly.
> 
ugly is this paranoia wrt just making it suid root. how many LOC is it?
i mean, if none of the five halfways qualified developers here is able
to audit this thing and declare it secure, mc can pack it's bags anyway
...

-- 
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: cons.saver not suid root

[Oswald Buddenhagen]

On Wed, Jun 08, 2005 at 05:13:00PM +0200, Leonard den Ottolander wrote:
> On Wed, 2005-06-08 at 17:03, Oswald Buddenhagen wrote:
> > and "punish" the upstream users, including ourselves? interesting.
> 
> This issue can be easily fixed with package builds.
>
suppose i prefer configure && make && stow ...

> I'd assume people that don't use a form packaging on their systems
> should be knowledgeable enough to read the docs and fix this issue by
> hand. How much effort is it to suid root the binary anyway if you
> really don't want to figure out how to setup the device access?
> 
are you kidding?
do you really expect every new user to do a bughunt as the first thing?

also, don't underestimate the "usage rate" of the upstream build system.
it is the de-facto standard of installing 3rd-party unix software.

> > ugly is this paranoia wrt just making it suid root.
> 
> What about the concept of "least necessary access"?
> 
what about the concept of "user friendliness"?
yes, there is a tradeoff. well, everywhere is.

> You ignore the possibility of eventualities in the future.
>
what type of eventualities do you talk about?

-- 
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: cons.saver not suid root

[Oswald Buddenhagen]

On Wed, Jun 08, 2005 at 05:23:42PM +0200, Egmont Koblinger wrote:
> On Wed, Jun 08, 2005 at 04:35:16PM +0200, Oswald Buddenhagen wrote:
> 
> > --- Makefile.am.orig2005-06-08 16:30:58.0 +0200
> > +++ Makefile.am 2005-06-08 16:29:13.0 +0200
> > @@ -75,6 +75,8 @@
> >  if USE_EDIT
> > $(MAKE) install_mcedit
> >  endif
> > +   chown root:root $(pkglibdir)/cons.saver
> > +   chmod u+s $(pkglibdir)/cons.saver
> 
> Seems to lack destdir support...
> 
indeed.
well, i didn't propose the patch for commit, only for comments for now.
i'm not sure about the correct location for the commands.

-- 
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: cons.saver not suid root

[Oswald Buddenhagen]

On Wed, Jun 08, 2005 at 05:42:07PM +0200, Koblinger Egmont wrote:
> On Wed, Jun 08, 2005 at 04:49:11PM +0200, Oswald Buddenhagen wrote:
> > we have no portable (even across
> > linuxes) way to create a vcsa user, so there is no other option than
> > root.
> 
> How about not creating a user or group, but observing the installed system?

> IMHO if all the vcsa devices are owned by the same user or same group whose
> uid/gid is below 100, then we could assume that that one is a vcsa-like user
> or group, and install mc setgid or setuid to that particular gid or uid.
> 
the number 100 is 100% arbitrary when looking at the linux landscape.
also, i loathe putting anything more intelligent than
stat("/dev/vcsa0").group == "vcsa"
in the detection logic - _this_ might become a real security hole.

-- 
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: cons.saver not suid root

[Oswald Buddenhagen]

On Wed, Jun 08, 2005 at 05:43:05PM +0200, Leonard den Ottolander wrote:
> On Wed, 2005-06-08 at 17:23, Oswald Buddenhagen wrote:
> > suppose i prefer configure && make && stow ...
> 
> Patch is your friend. Or just chown and chmod afterwards.
> 
you needn't to educate _me_. now that i identified the problem and
patched my checkout i could not care less.

> > do you really expect every new user to do a bughunt as the first thing?
> 
> I'd expect most new users to use a distro that sets this up properly for
> them.
>
you shouldn't. particularly, you should not force them to do so by
making either way of installation harder in unexpected ways.

> IMO this is more of a documentation issue than a build issue. Maybe
> we should add a note to the README.
> 
readmes are only read when the installation is non-obvious in the first
place or when a problem suggesting a user fault occurs. personally, i'd
assume it's a bug or the feature is missing alltogether.

> > also, don't underestimate the "usage rate" of the upstream build
> > system.  it is the de-facto standard of installing 3rd-party unix
> > software.
> 
> Any statistics on this?
>
i don't think percentages matter in this case. there is a non-trivial
amount of users that use this method, even if it is only 1% of the total
number. but the other 99% are outright irrelevant to that matter.

> By the way, afaik cons.saver is only used on Linux.
> 
i think freebsd was discussed some time ago. anyway, what's the point?

> > what type of eventualities do you talk about?
> 
> Possible introduction of bugs when somebody should start touching this
> code.
> 
oh, c'mon, the idiot that touches a suid/sgid program without thoroughly
considering the consequences should be stoned anyway. maybe the blob at
the top of the file should be made more explicit to protect against
roland^Wpeople that tend to commit faster than they think. ;)

-- 
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: C-\ hotlist key in 4.6.1 won't work under tty

[Oswald Buddenhagen]

On Thu, Jun 09, 2005 at 02:10:15PM +0200, Werner Opriel wrote:
> The Directory hotlist can't be displayed using the hotkey C-\ (Strg-Altgr-\) 
> when working on a console (tty).
> C-\ does work correctly in an xterm or konsole under X.
> 
> With the old "Woody" Version 4.5.55 we have no problems with the hotlist 
> shortcut.
> 
i reported this some months ago already but seemingly nobody had an
idea. i will put it in the bts as soon as i have the leisure and feel
like it.
note that the effect is bound to the german keyboard layout; i was
speculating it might have something to do with altgr being down.

-- 
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: C-\ hotlist key in 4.6.1 won't work under tty

[Oswald Buddenhagen]

On Thu, Jun 09, 2005 at 11:23:29PM +0200, Leonard den Ottolander wrote:
> On Thu, 2005-06-09 at 14:10, Werner Opriel wrote:
> > The Directory hotlist can't be displayed using the hotkey C-\
> > (Strg-Altgr-\) when working on a console (tty).
> 
> Why do you press "Altgr"? Why not just Strg-\?
> 
because, in fact, it is strg-altgr-? (altgr-? is \, obviously) - one'd
expect you to have enough intelligence to make sense out of this despite
the little inaccuracy. ;)

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

[bug #13102] mcedit leaving stale lock files

[Oswald Buddenhagen]

Follow-up Comment #2, bug #13102 (project mc):

bah, damn, it's one of my local patches.
sorry for the noise.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #13711] extend instead of removing selection

[Oswald Buddenhagen]

URL:
  

 Summary: extend instead of removing selection
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Sun 07/10/2005 at 12:08
Category: Editor
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

starting a selection after having moved clears the previous selection. i think
the previous selection should be extended if the cursor is exactly at the
beginning/end of the old selection.
of course this is arguable. maybe a (hidden) option should be added.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: "Display bits"

[Oswald Buddenhagen]

On Mon, Jul 11, 2005 at 09:34:37AM +0200, Egmont Koblinger wrote:
> On Sun, Jul 10, 2005 at 11:52:56PM +0200, Leonard den Ottolander wrote:
> > Any objection against me changing the string "Display bits" in the
> > options menu to "Character coding"?
> 
> What's the real purpose of that option at all? 
> 
it *might* be for setting 7-bit serial terminal links. but in this case
one could use tcgetattr to find out about it. so i dunno ...

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

[bug #13726] subshell type ahead discarded

[Oswald Buddenhagen]

URL:
  

 Summary: subshell type ahead discarded
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Mon 07/11/2005 at 14:47
Category: Subshell
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

unlike in a real shell, in mc's subshell any input entered while the previous
command was still running is discarded. this is highly annoying. this
behaviour is new in mc 4.6.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #13727] recursive "are same file"

[Oswald Buddenhagen]

URL:
  

 Summary: recursive "are same file"
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Mon 07/11/2005 at 15:34
Category: Core
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

recently i accidentally entered "." instead of ".." in the file copy dialog on
a relatively big tree ... for every f***ing file in the tree i got the "
and  are the same file" message box, without any way to escape except
killing mc from the outside.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #13728] superflous copying instead of moving

[Oswald Buddenhagen]

URL:
  

 Summary: superflous copying instead of moving
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Mon 07/11/2005 at 15:44
Category: Core
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

situation:
foo/name/file exists.
bar/name/ exists.
both on the same partition.
you're in "foo/", cursor over "name".
press , enter "../bar", confirm.
effect: file is moved by copying. this is because mc incorrectly diagnoses a
cross-device move.
the code in question is file.c, move_file_file() & move_dir_dir().
when fixing, please consider the case of moving a tree where only a subtree is
on another device. but maybe it was already considered. :)







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: [bug #6415] syntax highlighting breaks on more complicated shell regexps

[Oswald Buddenhagen]

On Sat, May 21, 2005 at 06:03:01PM +, Oswald Buddenhagen wrote:
> that's very unfortunate, because it makes mcedit a pretty bad editor
> for sophisticated scrips.
> 
fwiw, roland, please reopen the bug.

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

[bug #13729] ctrl- hotlist key won't work under tty

[Oswald Buddenhagen]

URL:
  

 Summary: ctrl-\  hotlist key won't work under tty
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Mon 07/11/2005 at 16:00
Category: Keyboard input
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: GNU/Linux

___

Details:

in the linux console with a german keyboard layout, one is unable to get to
the directory hotlist via ctrl-\.
in this layout, \ is altgr-ß (equivalent to ralt-= on an american keyboard). i
suspect that mc refuses to activate the hotkey, because it finds ralt to be
pressed.
this behavior is new in mc 4.6.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: [bug #13729] ctrl- hotlist key won't work under tty

[Oswald Buddenhagen]

On Mon, Jul 11, 2005 at 04:00:03PM +, Oswald Buddenhagen wrote:
> [bug #13729] ctrl-  hotlist key won't work under tty
>  Summary: ctrl-\  hotlist key won't work under tty
> 
heh, didn't i say that savannah is a funny thing? two "cool" effects in
one page for one backslash. :)))

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

[bug #13730] cons.saver lacking privileges

[Oswald Buddenhagen]

URL:
  

 Summary: cons.saver lacking privileges
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Mon 07/11/2005 at 16:35
Category: Subshell
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: GNU/Linux

___

Details:

this has been discussed to death already, but i've seen no viable solution so
far, only hack suggestions and general paranoia.
the problem is, that "classical" 'configure && make && su -c make install'
installations from upstream source have a non-working cons.saver, because it
lacks access to /dev/vcsa?.
the preferred solution is having a vcsa group which /dev/vcsa? belong to and
to which cons.saver is set-gid. however, there is no portable way across linux
distros to accomplish this.
the pragmatic solution is just having cons.saver set-uid root and leaving
potentially safer variants to distro-specific packages, like many other
applications in the same situation do. after a security audit of the really
small cons.saver source this variant should be perfectly applicable.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #13731] confirm deleting from directory hotlist

[Oswald Buddenhagen]

URL:
  

 Summary: confirm deleting from directory hotlist
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Mon 07/11/2005 at 16:51
Category: None
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

i once posted this:

it happens quite often that i accidentally delete items from the hotlist -
take the wrong angle when blindly moving up from the cursor block, and you hit
del instead of enter.
i think it would make sense if the hotlist obeyed the "confirm delete" option
as well.
alternatively, don't make del the delete action (and use f8 instead), but i
think this sucks more.

as a followup jindrich novy posted a completely overengineered patch with a
"don't ask again" checkbox.

my reply was:

i don't think it makes too much sense. and, as far as i see, it is not
persistant. mc does not have a track record of "don't ask again" checkboxes
anyway, afair.
you can make it consistent with non-empty directory deletion by making it
possible to select multiple entries and have an "all" button in the
confirmation dialog. but that seems to be major overkill to me.
so if you really feel that the confirmation is so annoying (ermm, how often do
you delete bookmarks?), add a separate option to the confirmations dialog
(name it generically, like "confirm low-value delete" or something, to avoid
adding more options of this type).







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #13728] superflous copying instead of moving

[Oswald Buddenhagen]

Follow-up Comment #2, bug #13728 (project mc):

yes, indeed. i even started developing an algorithm to post here, but stopped
because the existance checks and file/dir discrimination started turning the
few lines into real work. :)=
anyway, the basic idea is: when a move fails, if the source is a file, move
via copy, otherwise create the target dir (if missing) and recursively call
the move function for all files in the source dir. or something like that.
:)


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: change of syntax files

[Oswald Buddenhagen]

On Sun, Jul 03, 2005 at 10:13:16PM +0200, Roland Illig wrote:
> I would like to simplify some of the syntax files in the way the 
> attached Perl example shows.
> 
 [x] Do it
 [ ] Don't do it
 [ ] I don't care
 
anyway, i think it would be nicer to extend the highlighter with a
textstart keyword or something. after all, it applies to pretty much all
script highlight definitions.

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

[bug #13733] escape key timeout stuff

[Oswald Buddenhagen]

URL:
  

 Summary: escape key timeout stuff
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Mon 07/11/2005 at 17:27
Category: Keyboard input
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

so there is this old_esc_mode option ...
it really needs some more exposure. in fact, it should be enabled by default,
and the timeout should be lowered from one second to at most 100 ms (that is,
virtually instantaneous).
high-latency network links should not cause problems, as the chars of one
keypress should still be in one packet, keeping the sequence intact. if there
really is some problem with this, the patch posted by denis vlasenko on
2004-10-25 to make the timeout configurable via an environment variable can be
used.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #13734] viewer should save position & mode per file

[Oswald Buddenhagen]

URL:
  

 Summary: viewer should save position & mode per file
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Mon 07/11/2005 at 17:30
Category: Viewer
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

the file viewer should save the position (along with other options, like hex,
raw, etc.) per file, just like the editor does.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #13735] session management wanted

[Oswald Buddenhagen]

URL:
  

 Summary: session management wanted
 Project: GNU Midnight Commander
Submitted by: ossi
Submitted on: Mon 07/11/2005 at 19:23
Category: None
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: current (CVS or snapshot)
Platform Version: All

___

Details:

this one is from the more exotic department ... :)

in a "heavily x-windowed environment" you want session management. basically
this means two things:
(1) saving application state across session exit and restoration per-instance
(per-window). for mc this includes panel locations, mode (normal, view, edit),
cursor positions in panels, viewer, editor, most/all options.
(2) prevention of data loss at session exit. for mc this is essentially
unsaved files in mcedit.

under x the standard protocol is xsmp (google for it, the first hit is right
:).
the session manager is a server that runs on the x client; there is no
connection to the x protocol itself.
basically it works this way: on session exit, there is a first broadcast "is
it ok to end the session?". the clients with unsaved data can pop up asking
what to do (save/discard/cancel [shutdown]). if the first round is successfull
(no app objects the shutdown), a second round of broadcasts is send around,
this time "safe yourself requests". every app is required to save its state in
whatever way it wants, as long as this state information is kept away from the
other instances of the same app. additionally, the app must tell the session
manager what should be started upon session restoration to bring back the app
into the state it left off. usually this is the command name of this app with
some instance identifier.

as mc is no "native" x client, we have to go through some hoops to get what we
want.
(2) requires that the app somehow gets the user's attention. there is no way
around x in this case. fortunately, about any x terminal emulator exports the
own window id in the WINDOWID env variable. thus we can simply do something
like that:
  XRaiseWindow(mydpy, getenv("WINDOWID"));
  XSetInputFocus(mydpy, getenv("WINDOWID"), RevertToParent, CurrentTime);
(1) is a bit more tricky. as mc runs nested into a terminal emulator,
communicating the correct restart command to the session manager is a problem.
what we really want is a command line like "xterm -geometry ... -e mc
--session foo". i seriously doubt that xsmp provides any means to do "command
line merging", so mc cannot just extend xterm's restart command. however, i
think the following would work: create a wrapper script xmc:

---
#! /bin/bash
# usage: xmc [--mc-option] ... terminal-emulator [options ...]

# this is a trivial version; it only works with --parm=arg options
# (i.e., single-element options). a full version needs to know each
# option's argument requirements.
while $# != 0; do
  case $1 in
--*) opts=("[EMAIL PROTECTED]" "$1"); shift;;
*) break;;
  esac
done

# uuidgen is currently part of libuuid1 on debian
exec "$@" -e mc --session ~/.mc/sessions/$(uuidgen) "[EMAIL PROTECTED]"
---

that way xterm (or whatever) sees a command line that already contains the
identifier of a session, which mc can use for its purposes. as xterm saves the
complete client command line across sessions, we don't have to tell the
session manager anything, things just work ...


note that somebody simply clicking away the xterm window is not relevant to
the matter of session management. well, one could still do some crash
recovery, but that would be A Goog Thing (TM) independently of session
management.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: mc-4.6.1-versionsort.patch

[Oswald Buddenhagen]

On Sun, Jul 04, 2004 at 12:08:28PM +0200, Roland Illig wrote:
> wwp wrote:
> >IMO it would worth trying to complete the patch to cover all the
> >GUI/storage issues, maybe asking to Pavel or anyone who know mc
> >mechanisms to have a look at the patch?
> 
> So here's the patch. Do with it what you want.
> 
please update the patch (if necessary) and commit (or put it in the
patch tracker (which nobody seems to review anyway :{)).

> diff -uN mc-4.6.1-pre1/src/dir.c mc-4.6.0-4.6.1-pre1.new/src/dir.c
> --- mc-4.6.1-pre1/src/dir.c   2003-10-24 19:55:36.0 +0200
> +++ mc-4.6.0-4.6.1-pre1.new/src/dir.c 2004-02-07 13:41:44.0 +0100
> @@ -27,6 +27,7 @@
>  #include "dir.h"
>  #include "wtools.h"
>  #include "treestore.h"
> +#include "mc-strverscmp.h"
>  
>  /* If true show files starting with a dot */
>  int show_dot_files = 1;
> @@ -48,6 +49,7 @@
>  sort_orders_t sort_orders [SORT_TYPES_TOTAL] = {
>  { N_("&Unsorted"),unsorted },
>  { N_("&Name"),sort_name },
> +{ N_("Name (&Version)"), sort_vers },
>  { N_("&Extension"),   sort_ext },
>  { N_("&Modify time"), sort_time },
>  { N_("&Access time"), sort_atime },
> @@ -124,6 +126,19 @@
>  }
>  
>  int
> +sort_vers (const file_entry *a, const file_entry *b)
> +{
> +int ad = MY_ISDIR (a);
> +int bd = MY_ISDIR (b);
> +
> +if (ad == bd || mix_all_files) {
> +return mc_strverscmp (a->fname, b->fname) * reverse;
> +} else {
> +return bd - ad;
> +}
> +}
> +
> +int
>  sort_ext (const file_entry *a, const file_entry *b)
>  {
>  char *exta, *extb;
> diff -uN mc-4.6.1-pre1/src/dir.h mc-4.6.0-4.6.1-pre1.new/src/dir.h
> --- mc-4.6.1-pre1/src/dir.h   2003-10-24 19:55:36.0 +0200
> +++ mc-4.6.0-4.6.1-pre1.new/src/dir.h 2004-02-07 13:41:14.0 +0100
> @@ -43,6 +43,7 @@
>  /* Sorting functions */
>  int unsorted   (const file_entry *a, const file_entry *b);
>  int sort_name  (const file_entry *a, const file_entry *b);
> +int sort_vers  (const file_entry *a, const file_entry *b);
>  int sort_ext   (const file_entry *a, const file_entry *b);
>  int sort_time  (const file_entry *a, const file_entry *b);
>  int sort_atime (const file_entry *a, const file_entry *b);
> @@ -57,7 +58,7 @@
>  int sort_group (const file_entry *a, const file_entry *b);
>  
>  /* SORT_TYPES is used to build the nice dialog box entries */
> -#define SORT_TYPES 8
> +#define SORT_TYPES 9
>  
>  /* This is the number of sort types not available in that dialog box */
>  #define SORT_TYPES_EXTRA 6
> diff -uN mc-4.6.1-pre1/src/Makefile.am mc-4.6.0-4.6.1-pre1.new/src/Makefile.am
> --- mc-4.6.1-pre1/src/Makefile.am 2003-11-27 19:06:57.0 +0100
> +++ mc-4.6.0-4.6.1-pre1.new/src/Makefile.am   2004-02-07 13:30:04.0 
> +0100
> @@ -52,7 +52,8 @@
>   glibcompat.c glibcompat.h global.h help.c help.h hotlist.c  \
>   hotlist.h info.c info.h key.c key.h keyxdef.c layout.c  \
>   layout.h learn.c learn.h listmode.c listmode.h main.c main.h\
> - menu.c menu.h mountlist.c mountlist.h mouse.c mouse.h myslang.h \
> + menu.c mc-strverscmp.c menu.h mountlist.c mountlist.h mouse.c   \
> + mouse.h myslang.h   \
>   option.c option.h panel.h panelize.c panelize.h poptalloca.h\
>   popt.c poptconfig.c popt.h popthelp.c poptint.h poptparse.c \
>   profile.c profile.h regex.c rxvt.c screen.c setup.c setup.h \
> diff -uN mc-4.6.1-pre1/src/mc-strverscmp.c 
> mc-4.6.0-4.6.1-pre1.new/src/mc-strverscmp.c
> --- mc-4.6.1-pre1/src/mc-strverscmp.c 1970-01-01 01:00:00.0 +0100
> +++ mc-4.6.0-4.6.1-pre1.new/src/mc-strverscmp.c   2004-02-07 
> 13:29:49.0 +0100
> @@ -0,0 +1,109 @@
> +/* Compare strings while treating digits characters numerically.
> +   Copyright (C) 1997, 2002 Free Software Foundation, Inc.
> +   This file is part of the GNU C Library.
> +   Contributed by Jean-François Bignolles <[EMAIL PROTECTED]>, 1997.
> +
> +   The GNU C Library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   The GNU C Library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with the GNU C Library; if not, write to the Free
> +   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> +   02111-1307 USA.  */
> +
> +#include 
> +
> +/* states: S_N: normal, S_I: comparing integral part, S_F: comparing
> +   fractionnal parts, S_Z: idem but with leading Zeroes only */
> +#define  S_N0x0
> +#define