Re: [r...@rover.dkm.cz: [repo.or.cz] midnight-commander clone completed]

[Pavel Roskin]

On Sun, 2009-01-04 at 17:01 +0100, Enrico Weigelt wrote:
> * Pavel Roskin  schrieb:
> 
> Hi,
> 
> > >I really don't see the problem.
> > 
> > The problem is that the mirror already existed on that site.  Now we  
> > have two mirrors.  It's confusing to the users.  Some may be tracking  
> > my mirror now.  Instead of giving you control over the existing  
> > mirror, I'll need to ask the site administration to remove my mirror.   
> > The users will have to switch to your repository.
> 
> Why do you have to close your mirror ? I dont see any reason.
> 
> Thousands of OSS projects get mirrored all around the world, even
> without explicit knowledge of the devs, and - as far as I know - 
> nobody feels pissed about that. What's the problem ?

I don't want to be responsible for an obsolete repository.

> > I believe it's important that the project developers act as a team 
> > and coordinate their actions.  
> 
> What is there to coordinate on just some dumb unofficial mirror ?

Its name and who is responsible for mirroring.

> > I realize I'm not a team member anymore, but I've been maintaining 
> > the mirror for along time.  
> 
> Wait, you really feel kicked-away, just because your mirror isn't 
> the only one anyomore ? Quite strange, IMHO.

There is no need for two mirrors on one site.  The only problem with the
existing mirror was that you didn't control it.  Otherwise, it was
perfectly usable.

> > I spent quite a lot of time mapping CVS authors to the real names, 
> > and that mapping is used in your repository.
> 
> Right, and you did a great job. You volunteered to do an dirty,
> but important job, nobody else was willing to do. And I don't 
> think anyone here won't appreciate that. 
> 
> So you *are* a valueable member of the team, and I don't see how 
> some additional, uninteresting git mirror can change that fact.

Thanks.  I'm unsubscribing from the lists now and I'm not going to
continue this discussion.

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

Re: [r...@rover.dkm.cz: [repo.or.cz] midnight-commander clone completed]

[Pavel Roskin]

Quoting Enrico Weigelt :


* Pavel Roskin  schrieb:

Hi,


What's the point?  I could have given you full access to the "mc"
repository on the same site.  After all, it's just a mirror.  You
could have rewritten the whole repository.  Now we have two competing
mirrors for the same project.  I'm not going to keep it this way.


Hey, it's just dumb *readonly* mirror. nobody can commit there
(not even me) - it just syncs itself from the master periodically.
the idea behind is nothing more to have yet another publically
available copy to keep some unncessary traffic from the weak
mc.o server. and in case something bad happens to the server,
we've got an backup.

It's not a fork or anything like that.


I understand that it's a mirror and not a fork.


I really don't see the problem.


The problem is that the mirror already existed on that site.  Now we  
have two mirrors.  It's confusing to the users.  Some may be tracking  
my mirror now.  Instead of giving you control over the existing  
mirror, I'll need to ask the site administration to remove my mirror.   
The users will have to switch to your repository.


I believe it's important that the project developers act as a team and  
coordinate their actions.  I realize I'm not a team member anymore,  
but I've been maintaining the mirror for along time.  I spent quite a  
lot of time mapping CVS authors to the real names, and that mapping is  
used in your repository.  It's just not nice to set up an alternate  
mirror without bothering to ask me.


It's not like I'm going to spend much time on the project anyway, but  
such treatment will discourage me from dealing with the new team.


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

Re: [r...@rover.dkm.cz: [repo.or.cz] midnight-commander clone completed]

[Pavel Roskin]

Quoting Enrico Weigelt :



JFYI:

just created a git mirror ...

...

http://repo.or.cz/m/editproj.cgi?name=midnight-commander


What's the point?  I could have given you full access to the "mc"  
repository on the same site.  After all, it's just a mirror.  You  
could have rewritten the whole repository.  Now we have two competing  
mirrors for the same project.  I'm not going to keep it this way.   
I'll ask the admins to get "mc" offline.


I can tell from my experience that failure to cooperate is destructive  
for any project.  Creating a mirror without asking others is an  
example of such failure.  Sure, you saved a day or two by not asking  
me and not waiting for my reply.  But by not asking, you made a little  
step towards excluding others from the development.  If people see  
that their opinion doesn't matter, they stop participating.  This  
leads to a one-person project, which stops when that person gets tired.


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

Re: Disable cvs/savannah

[Pavel Roskin]

On Tue, 2008-12-30 at 16:01 +0100, Patrick Winnertz wrote:
> Hey,
> In order to get everything into shape it would be cool if someone could leave 
> a big fat note in cvs that the new repro can be found at www.midnight-
> commander.org.
> The same applies to the savannah bugtracker.. could please someone who has 
> the 
> power disable it (or prevent it from spamming this list? ;))

According to https://savannah.gnu.org/projects/mc, the admins are Miguel
de Icaza and Pavel Tsekov.

> The last point: Is someone captable to give www.ibiblio.org/mc a new shape? 
> It 
> would be cool if someone could add a redirect to www.midnight-commander.org. 

I have access to that site, so I can upload anything.  However,
www.midnight-commander.org doesn't have any download link, so perhaps a
redirect would be premature.  However, I can write a short page
referring users to www.midnight-commander.org for development and to the
file archives on ibiblio for download.

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

Re: Further Midnight Commander development

[Pavel Roskin]

Hello, Miguel!

Quoting Miguel de Icaza :


I would personally like to see mc move to git, there are nice hosting
services like github, it is easy to fork and it is easy to review
patches from third parties.


I'm maintaining a git mirror of the mc repository:
http://repo.or.cz/w/mc.git

It's updated automatically.  It can be just cloned for further  
development.  I took care to provide full names of all committers ever  
committing anything to the mc repository.


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

Re: Removing myself from the project

[Pavel Roskin]

On Wed, 2008-12-17 at 20:07 +0100, Patrick Winnertz wrote:
> Hey Pavel,
> 
> Could you please be so kind and add me to the list of people who are allowed 
> to commit into the cvs? I would like to work further on mc and integrate 
> patches from the mc clone into mc. It would be very sad if mc will die out.

I don't have such permission.

The usual approach is that somebody wishing to contribute code posts
patches to the mailing list.  Other developers review the patches and
commit them.  Once the contributor posts many consistently good patches,
he or she is granted commit access by the project administrator.

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

Removing myself from the project

[Pavel Roskin]

Hello!

Most messages posted to the mailing lists are spam.  Most comments added
to the bug tracker are spam.  I simply don't have to deal with it every
day.  Neither do I have time to deal with site administrators to fix the
spam problem upstream.  Therefore, I'm removing myself from the list of
mailing list moderators and from the list of project members on
Savannah.

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

Re: Updated Czech translation

[Pavel Roskin]

On Wed, 2008-06-04 at 15:54 +0200, Jindrich Novy wrote:
> Hi mc-devel,
> 
> Anna Katerina Talianova sent me updated Czech mc translation. I'm not
> sure whether the strings are complete for the current head mc, but
> fixes some typos in previous translations. Anna claims the
> translations are based on 4.6.1.
> 
> po file attached.

I've merged the result of merging the current and the new translations,
giving preference to the new translation:

msgmerge --update --compendium=cs.po.old --no-location cs.po mc.pot
msgfmt -c --statistics -o cs.gmo cs.po
978 translated messages, 5 fuzzy translations, 4 untranslated messages.

Please considering crediting the translators in the header next time.

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

Re: unable to updated translation file

[Pavel Roskin]

On Sun, 2008-04-06 at 10:47 +0200, Marco Ciampa wrote:
> I've done
> 
>  cvs up
> 
> then 
> 
>  ./configure --prefix=/usr
> 
> []
> config.status: WARNING:  intl/Makefile.in seems to ignore the --datarootdir
> setting
> config.status: error: cannot find input file: po/Makefile.in.in
> 
> any hint?

There is no configure in CVS.  Please read HACKING.

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

[bug #16908] Missing manpage for the binary cons.saver

[Pavel Roskin]

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

I'm afraid your description it too confusing for users.  Users who read that
manual page will have a wrong impression that they have to run cons.saver
manually by pressing Ctrl-O, and also that they will need to perform some
administrative tasks for security.

___

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: Hello mc Maintainers! :)

[Pavel Roskin]

On Fri, 2008-03-07 at 21:50 +0100, Patrick Winnertz wrote:
> On Friday 07 March 2008 19:55:10 Pavel Roskin wrote:
> > On Fri, 2008-03-07 at 17:23 +0100, Patrick Winnertz wrote:
> > > > > This is basically the same as your wiki idea only using a VCS
> > > > > instead. git would do the job quite good, but cvs will work, too,
> > > > > I guess.
> > > >
> > > > I am most familiar with cvs and svn, but maybe git would fit better.
> > >
> > > I am most familiar with svn and cvs, too but there are some things I
> > > really miss in svn ... I dislike the idea of branching there.  git is
> > > quite new for me, too, but as I heard from different people it should
> > > be exactly what is needed here.
> >
> > I can set up a git mirror on http://repo.or.cz/ and keep it updated from
> > the cron script.  I'm doing it for another project already.
> This would rock.. Please do. 

It took me some time to make a list of all committers.  I never expected
it to be so long - 105 committers!  I could not recover names of
"davidsa", "gertd" and "martin" because they never committed any
ChangeLog entries.

The final (hopefully) import is in progress.  I hope it will complete
overnight.  The project patch is http://repo.or.cz/w/mc.git

If something is wrong, please let me know.

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

Re: Hello mc Maintainers! :)

[Pavel Roskin]

On Fri, 2008-03-07 at 17:23 +0100, Patrick Winnertz wrote:
> > > This is basically the same as your wiki idea only using a VCS instead.
> > > git would do the job quite good, but cvs will work, too, I guess.
> >
> > I am most familiar with cvs and svn, but maybe git would fit better.
> I am most familiar with svn and cvs, too but there are some things I really 
> miss in svn ... I dislike the idea of branching there.  git is quite new 
> for me, too, but as I heard from different people it should be exactly 
> what is needed here.

I can set up a git mirror on http://repo.or.cz/ and keep it updated from
the cron script.  I'm doing it for another project already.

The greatest thing about git (especially when used with StGIT frontend)
is that is allows working on several patches at once.

Complete switching to git would be great, but it would need getting rid
of changelogs and relying on the commit messages for the history.
That's something only the maintainers can decide.

But just having a git mirror would help those who cannot stand working
in CVS after trying git or another modern version control system.

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

Re: Missing M-H key binding entry in hungarian man page

[Pavel Roskin]

On Mon, 2008-02-18 at 11:32 +0100, Bozo Lajos wrote:
> Hallo Dear Developers,
> 
> In MC among other things my favorite feature is the "directory history" (M-H) 
> and I searched
> info about key bindings for this feature in the hungarian man page.
> Unfortunately I found only the description of the feature but key binding is 
> not
> mentioned. The description is appended tightly to the description of 'M-u' 
> feature.
> Inserting new lines and the 'M-H' string before the description would correct 
> this little bug.
> This bug can be found at the last entry of the 'Directory Panels' section of 
> the hungarian man page.

Fixed in CVS.  Thanks!

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

Re: New virtual file systems

[Pavel Roskin]

On Sat, 2008-01-12 at 09:50 -0500, Jacques Pelletier wrote:
> but after doing ./autogen.sh, it won't consider my new scripts: they won't be 
> renamed without the '.in' extention.

I think you forgot to add them to AC_CONFIG_FILES in configure.ac.

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

Re: Moving the MC homepage to www.gnu.org

[Pavel Roskin]

On Wed, 2007-09-05 at 19:09 +0200, Alexander Kriegisch wrote:
> OT: Damn, this happens *every time* I do not explicitly remember not to
> answer e-mails from this list directly: They are sent to the person
> whose message I answer instead of to the list, so I have to create
> another copy with the right address. Can this be fixed?

That's what the "reply all" option is for, and it's present in all
decent mail clients.  This way, you have a choice whether to reply
personally or to the list.

What you probably expect from your experience with some other list is
that the "reply" would default to the list address.  This is implemented
using the "reply-to" line in the message header.  The problem with this
approach is that it gives you less flexibility.  If you want to reply
privately, you have to instruct your mail client to ignore "reply-to",
which is rarely supported.

More discussion here:
http://marc.merlins.org/netrants/reply-to-harmful.html

-- 
Regards,
Pavel Roskin

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

Re: Bugs should be reported to [EMAIL PROTECTED]

[Pavel Roskin]

On Tue, 2007-04-10 at 09:10 +1000, Jeremy Dawson wrote:

> Bugs should be reported to mc-devel@gnome.org
> 
> If an email to this address is to be replied to in this fashion, it 
> would be preferable if the address was not publicised.

I disagree.  There is no guarantee that you get an acceptable reply or
any reply at all from a mailing list.  It's determined by many factors,
such as the quality of the original post and the availability of the
subscribers who want to reply.

I think a public mailing list is still a better than other alternatives.
It's archived, so all replied are visible to others.  It encourages good
replies.  It also discourages rude and stupid replies, since they will
stay online for everybody to see.  It's not to say that it doesn't
happen, but other subscribers can take corrective actions, and do it in
public view.

Mailing lists split the load between participants, so nobody is under
pressure to respond.  Every subscriber makes a choice whether to
subscribe, so they are in control.  Getting support requests by private
e-mail may be an annoyance for somebody who chose to stop working on the
project or who cannot comment on a specific issue.

Bug tracking may be also adequate for some more specialized tasks, but
they are less visited by anyone but core developers.  In any case,
mailing lists are superior to personal e-mail.

I believe the mailing lists should stay and should continue to be
publicized as the place to report bugs.

-- 
Regards,
Pavel Roskin

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

Re: Request for discussion - how to make MC unicode capable

[Pavel Roskin]

On Sat, 2007-02-24 at 14:57 +0200, Pavel Tsekov wrote:
> Hello,
> 
> I'd like to initiate a discussion on how to make MC
> unicode deal with multibyte character sets. I'd like
> to hear from the developers of the UTF-8 patch and
> from the ncurses maintaner. Anyone else who can help
> with their expertise is also welcome. This has been
> a major drawback for quite some time and it needs to
> be addressed ASAP.

Yes, thank you for addressing this issue!  I just want to give you some
general advice based on my experience.

Don't try to keep backward compatibility from the beginning, no matter
how important it is.  Code for the most advanced API first, and then
backport the changes to older APIs if needed.

The main reason is that the new API introduces new concepts.  The
concepts are based on better understanding if the issue.  Retaining the
code that is not based on those conceptions next to the new code would
create a maintenance nightmare.  In some cases, the new API enforces the
new rules.  Don't let the offenders to hide behind conditional
statements.

In case of Unicode, the new concept is distinction between bytes and
characters.  Many functions need to be checked that they don't mix them.
It's totally impractical to write a preprocessor conditional every time
something is changed.  It's better to change to code for Unicode support
and then think how to provide backward compatibility for the whole
source tree with minimal changes throughout the code.

Another reason is that the programmer's time is very expensive and
should be used properly.  A programmer should be testing how his code is
working rather than whether it compiles for an old libc.  Very few
actual bugs (i.e. incorrect runtime behavior, as opposed to often
trivial compile issues) are discovered as a result of portability
problems.  Much more bugs are discovered on the primary development
system by the main developer.

People opposing the changes are often more vocal that those who need the
changes.  The later category may not be using mc at all.  Perhaps they
tried mc and didn't like how it looked on the Unicode capable terminal.
Or maybe they were affected by bugs caused by distribution patches.

Those who don't want the changes can be usually satisfied by later
changes that restore the old behavior or the resource consumption.
Again, existing users could be asked to contribute portability fixes and
optimization.  It's an easier job than converting the code to the new
concepts and untangling the mess of function interdependencies.

And those who threaten to switch to different software or to fork the
project are usually not very good contributors to begin with.  The won't
be missed.

In more practical terms, I suggest that mc uses only ncurses or S-Lang
for Unicode.  Doing two ports would exhaust already limited resources.
I think the preference should be given to ncurses because it's not
trying to be an interpreted language or anything else other than a
screen library.

-- 
Regards,
Pavel Roskin

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

Re: No MC snapshot since 2006-12-28

[Pavel Roskin]

Hello!

On Mon, 2007-01-08 at 10:01 +1100, Zdzislaw Sliwinski wrote:
> On the surface, it looks like you guys could use "cvs watch".

I don't see how it could be useful.  The goal is to find out if there
were any updates since a certain time in the past.  How would you use
"cvs watch" for that?

It's also implied that the implementation show be completely transparent
to the developers.  For instance, they shouldn't have to use "cvs edit"
just because somebody somewhere is making the snapshots.

-- 
Regards,
Pavel Roskin


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

Re: No MC snapshot since 2006-12-28

[Pavel Roskin]

Quoting Pavel Tsekov <[EMAIL PROTECTED]>:

> Isn't it possible to use the CVS output to see if there were updated
> files ?

Yes, but only if it's a dedicated working directory where "cvs up" is only run
by the snapshot script.

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

Re: No MC snapshot since 2006-12-28

[Pavel Roskin]

On Thu, 2007-01-04 at 23:07 +0200, Pavel Tsekov wrote:
> On Thu, 2007-01-04 at 21:07, Pavel Roskin wrote:
> > On Thu, 2007-01-04 at 17:51 +0200, Pavel Tsekov wrote:
> > > Would you check why the snapshot is not being generated ?
> > 
> > No problems this time.  I run the snapshot generator manually from time
> > to time.  The new snapshot is available now.
> 
> I see. I thought the snapshot was generated manually. At
> least it seemed to me that new versions appear after changes
> were commited :) Perhaps the process can be automated ?

The script will need to find out if there are any updates in CVS.  We
don't want to post a snapshot without actual changes in CVS.
Unfortunately, there is no single commit ID in CVS, so I'll need to
implement an algorithm to calculate it (I think it could be SHA1 of the
sorted list of all files with revisions).

I'm placing the issue on my TODO list.

-- 
Regards,
Pavel Roskin


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

Re: No MC snapshot since 2006-12-28

[Pavel Roskin]

On Thu, 2007-01-04 at 17:51 +0200, Pavel Tsekov wrote:
> Would you check why the snapshot is not being generated ?

No problems this time.  I run the snapshot generator manually from time
to time.  The new snapshot is available now.

-- 
Regards,
Pavel Roskin


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

Re: Removing rxvt.c ?

[Pavel Roskin]

Hello!

On Tue, 2006-10-17 at 15:42 +0300, Pavel Tsekov wrote:
> Hello,
> 
> What do you think about removing rxvt.c ? It seems that
> the patch required to support this feature never was
> accepted in rxvt... And it also seems to be unnecessary
> with the current version of MC (which is 5 years old).

It's not unnecessary.  You cannot have "output lines" in Options->Layout
on unpatched rxvt.

That said, I've never used the "output lines" options, so I'm ambivalent
on that.  I think the best approach would be to have a terminal emulator
in mc rather than rely on the parent terminal for the subshell output.

-- 
Regards,
Pavel Roskin

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

Re: file coloring

[Pavel Roskin]

Hello!

On Sun, 2006-08-13 at 19:01 +0300, Pavel Tsekov wrote:
> On Sun, 13 Aug 2006, Kisel Jan wrote:
> 
> > Good day!
> >
> > I suggest you mc patch to apply file-coloring scheme based on file name
> > pattern.
> 
> So far none of the file highlighting patches submitted to the list was 
> accepted (considered). The reasons differ - incomplete patches, the author 
> doesn't want to change his/her patch and finally the MC maintainer thinks 
> that this feature is not worth adding. I think we should decide whether 
> this is indeed an useful feature or whether patches addressing file
> highlighting should be rejected.

I'm not against file highlighting.  In fact, mc is already highlighting
"core" files by their name.  It would be better for this facility to be
configurable rather than hardcoded.  It's also important that the
configuration file is not limited to DOS-style extensions.  I think
shell globs would be fine, so that one could define a color for core.*
or *.tar.* or something like that.

It would be nice to highlight directories as well.  Perhaps "CVS",
".svn", ".git" and similar special directories should have a distinctive
color.

> You might want to read the thread below:
> 
>http://mail.gnome.org/archives/mc/2002-October/msg00110.html

I'm a bit overreacted here about mp3's.  I think the best approach would
be not to try to highlight non-technical stuff by default, at least not
until mc supports 256 colors.

-- 
Regards,
Pavel Roskin


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

[bug #17268] Shift+Enter weirdness

[Pavel Roskin]

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

You are right, Pavel, I forgot it.  Accidental pasting of multiline text can
be harmful.  Let's leave the code as is.

___

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: Conflicting new line symbol in folder name

[Pavel Roskin]

On Thu, 2006-08-10 at 03:32 +0400, Dima K. wrote:
> There is a bug when you open folder with name like "\nx" ( where \n is new 
> line symbol and x any symbol )

I cannot reproduce it.  You didn't describe the bug, so I don't know
what to look for.  You forgot to specify the version and the OS.

-- 
Regards,
Pavel Roskin


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

Re: mc 4.6.1 : colon bug in file names

[Pavel Roskin]

On Mon, 2006-08-07 at 16:42 +, Ludovic wrote:
> Hi !
> 
> Some Debian users have found an annoying bug on files which have a colon in 
> their name:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380075
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381353
> 
> Is it Debian specific or not ?

What is actually run?  Can you check the command line by "ps x"?  It may
be a bug in the pdf viewer.  I see that evince 0.5.4 has this problem
(Fedora Core 6 Test 2).

-- 
Regards,
Pavel Roskin


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

[bug #17268] Shift+Enter weirdness

[Pavel Roskin]

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

I think the patch is wrong.  Shift-Enter needs to be distinguished from Enter
in the editor to allow correct paste from X clipboard by Shift-Ins when
auto-indent is enabled.  Enter does auto-indent, but Shift-Enter doesn't.  If
Shift-Enter is treated like Enter, the pasted text will look like a stair.
The fix belongs to the single-line entry widget, not to key.c.

___

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-2006-07-12-22 bug report

[Pavel Roskin]

On Sat, 2006-07-15 at 09:14 +0200, enrico wrote:
> 0x080be9e0 in vfs_s_generate_entry (me=0x81043c0, name=0x81b69f0 "WA",
> parent=0x0, mode=493) at direntry.c:179   ││
> 179 inode = vfs_s_new_inode (me, parent->super, st); 

See "FIXME: check if vfs_s_find_inode returns NULL" in direntry.c.
Apparently, what's happening is exactly that.  Of course, it's not hard
to check the result and return, but it would be nice to actually make mc
work rather than bail out.

I cannot reproduce this error, so I guess you are doing something
unusual with the FTP server.  More details about that could be helpful.

-- 
Regards,
Pavel Roskin

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

Re: non ascii file sort

[Pavel Roskin]

Hello!

On Wed, 2006-07-05 at 21:38 +0300, ForestCreature wrote:
> Hello! I've recently noticed wrong file sort order in file list pannels.
> I use ru_RU.KOI8-R locale. There is no alphabetic symbol order (what
> strcmp implies?). Attached patch works for me.

It's not so simple.  strcoll() is not guaranteed to be case sensitive in
all locales.  I think the choice in "Sort Order ..." should be between
case-sensitive, case-insensitive and locale-specific.

-- 
Regards,
Pavel Roskin

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

Re: Snapshots availability

[Pavel Roskin]

On Tue, 2006-06-27 at 15:11 +0200, Leonard den Ottolander wrote:
> Hello Pavel,
> 
> On Thu, 2006-06-22 at 14:15 -0400, Pavel Roskin wrote:
> > Snapshots are not intended for developers.  Developers should be using
> > proper version control systems.  Snapshots are for users who want to try
> > the latest features and check if some bug has been fixed, but who don't
> > intend to keep the sources up-to-date.
> 
> Which doesn't contradict the fact that in circumstances it might be
> useful for me to take a look at a snapshot somebody used to create a
> mod, like in the case of mccolorer where I did not have the correct
> snapshot available to diff against. Hence my request.

Contributors should send patches and make sure that the patches only
contains their modifications and that the modifications are intended.
They should also be able to explain the reasons for every change.  If
they cannot do it, I would not consider such changes for committing to
CVS, for the reason that either the contributor is too sloppy, has
problems with memory or is not the original author of all the changes.

-- 
Regards,
Pavel Roskin

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

Re: Snapshots availability

[Pavel Roskin]

Hello, Leonard!

On Wed, 2006-06-21 at 23:21 +0200, Leonard den Ottolander wrote:
> Hi,
> 
> Who is the creator of the two weekly snapshots found at
> http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ ?
> Pavel? Miguel?

I generate them using maint/mcsnap

> Could you please keep a couple of months worth of snapshots around? I
> couldn't find the May 30th snapshot when I wanted to compare it with
> mccolorer.

Snapshots are not intended for developers.  Developers should be using
proper version control systems.  Snapshots are for users who want to try
the latest features and check if some bug has been fixed, but who don't
intend to keep the sources up-to-date.

-- 
Regards,
Pavel Roskin

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

Re: Bugzilla submits only against >= 4.6.1

[Pavel Roskin]

On Tue, 2006-06-20 at 01:02 +0200, Leonard den Ottolander wrote:
> I didn't mean old bugs should be removed from the bug list. I just feel
> it doesn't make much sense for people to file new bugs against anything
> older than 4.6.1.
> 
> There is no added value to let people add bugs against older versions.

Anyone who takes time to file a new bug is adding some value to the
project.  It may be more or less valuable, but we shouldn't give the
impression that we don't want to hear about the problem.

> If the issue no longer exists it's just wasted time, and if it does
> still exist the reporter should make the effort to verify the issue
> indeed still exists in 4.6.1 or later.

Ideally, yes.  But not everyone can do it.  It's better to have 10
reports for already fixed bugs and one for a bug that still exists than
to have neither of them.

If you have an example where time was wasted as a result of the
availability of the older versions in the bug tracker, I may reconsider.

> > "None" is hardcoded, "All versions" is not.  I think "all version" is a
> > valid value in some cases.
> 
> Yes, but only if you keep all the other versions as valid options. If
> we'd drop anything but latest stable and CVS there's not much use
> leaving "all versions" around.

I generally assume the bug reporters to be intelligent persons who can
make there own judgment how to file a bug.

-- 
Regards,
Pavel Roskin

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

Re: Bugzilla submits only against >= 4.6.1

[Pavel Roskin]

Hello!

On Sat, 2006-06-17 at 14:52 +0200, Leonard den Ottolander wrote:
> Hello Pavel,
> 
> IMO it doesn't make much sense for people to be able to report bugs
> against mc versions older than 4.6.1. I presume most developers will
> agree with me (please protest if not).
> 
> Could you please update the Savannah bugs "Release" drop down menu to
> only contain the following elements?
> 
> older than 4.6.1 (upgrade first!)
> 4.6.1
> current (CVS or snapshot)

I think that would be solving a social problem using technical means.
If you check Red Hat's Bugzilla you'll see that it's possible to enter a
bug e.g. for Fedora Core 1.

Some bugs can be more long-lived than you may think.  I believe the
quality of the bug report should be judged not only by the version.
Bugs against old versions should be discouraged, but not outright
forbidden.

Besides, there is only one bug filed for "older than 4.5.55".

> I don't think we need the entries "All versions" and "None" but these
> might be hard coded default entries.

"None" is hardcoded, "All versions" is not.  I think "all version" is a
valid value in some cases.

-- 
Regards,
Pavel Roskin

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

Re: Symlink attack in file.c?

[Pavel Roskin]

Hello, Leonard!

On Fri, 2006-06-16 at 01:53 +0200, Leonard den Ottolander wrote:

> Something I came across a couple of times this week, just now in
> relation to an RFE regarding file permissions on copying fat files in
> RHs bugzilla
> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195614):
> http://cvs.savannah.gnu.org/viewcvs/mc/src/file.c?root=mc&r1=1.28&r2=1.29
> 
> A commit by "pavel" (Machek?) who added the remark
> "FIXME: You have security hole here, btw. Imagine copying to /tmp and
> symlink attack :-("
> 
> Is there anybody that can explain to me what he's concerned about and if
> that is still an issue? If so this is a rather long standing hole... If
> not, let's get rid of that warning.

I think it's still an issue.  Suppose the target doesn't exist.  Then mc
decides that it's OK to create the file and creates it.  In the
meantime, somebody could have created a symlink, so mc truncates the
file pointed to by the symlink.

It is a hole indeed, but it needs a good timing to be exploited.  The
attacker should know which file is about to be overwritten and the
symlink should be created after mc has checked that the target doesn't
exist, but before mc opens the file for writing.

Since mc needs to be interactive, it's hard to avoid accessing the
target file more than once.

The simplest fix would be to use O_EXCL is there was no target file
initially.  If it fails for the reason that the file exists, there
should be a huge warning that no user should be able to ignore.

-- 
Regards,
Pavel Roskin

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

Re: Problems with the mailing list ?

[Pavel Roskin]

Hello!

On Fri, 2006-06-16 at 18:57 +0300, Pavel Tsekov wrote:
> Hello,
> 
> Does anyone miss messages from the mc-devel list ? It seems like some 
> messages do not reach the mailing list at all while others don't reach
> the mailing list subcsribers. Can anyone confirm or deny this ?

I have sent an email to the GNOME mailing list administrator.

I don't see any delays or mail loss, but let's see what would happen to
this message.

-- 
Regards,
Pavel Roskin

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

Re: utf8 patch for mc, slang 2 version

[Pavel Roskin]

Hello!

On Thu, 2006-06-15 at 09:45 +1200, Bart Oldeman wrote:
> On Wed, 14 Jun 2006, Egmont Koblinger wrote:
> 
> > On Tue, Jun 13, 2006 at 07:14:41PM +0200, Tomasz K?oczko wrote:
> >
> >> BTW: anyone is working on UFT-8 support for ncurses(w) backend ?
> >
> > I don't think so, and I don't think it is worth it. Maintaining two backends
> > IMHO just causes headaches while it doesn't make mc better. I still can't
> > see why developers do not decide which one to use and drop the other one.
> 
> Maybe compatibility with older UN*Xes with curses but no slang?

It's a bogus argument.  UNIX curses was removed long ago, and it had
never worked well anyway.  I don't remember a single person complaining.
Besides, S-Lang is included with mc and it's quite portable.

-- 
Regards,
Pavel Roskin

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

Re: SO_LINGER used when not HAVE_STRUCT_LINGER_L_LINGER

[Pavel Roskin]

On Thu, 2006-05-25 at 18:35 +0200, Leonard den Ottolander wrote:
> Hello Pavel,
> 
> On Thu, 2006-05-25 at 02:15 -0400, Pavel Roskin wrote:
> > Nothing odd.  HAVE_STRUCT_LINGER_L_LINGER means that there is structure
> > linger with field l_linger.  That field (and the whole structure) is not
> > used if HAVE_STRUCT_LINGER_L_LINGER is not defined.
> 
> So you mean SO_LINGER can be defined although
> HAVE_STRUCT_LINGER_L_LINGER is not?

Yes.  Why not?  Many other socket options just use an integer as an
option.  I can imagine SO_LINGER was an on/off option in the past,
without the timeout.

> > Put #ifdef SO_LINGER ... #endif around the code you quoted.  Also do the
> > same for the declaration.
> 
> And disable the call to setsockopt() altogether?

Yes.  To be pedantic, it would be nice to research whether this option
is needed and why it's only needed for FTP but not for other VFS
implementations.

-- 
Regards,
Pavel Roskin

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

Re: SO_LINGER used when not HAVE_STRUCT_LINGER_L_LINGER

[Pavel Roskin]

Hello!

On Wed, 2006-05-24 at 14:37 +0200, Leonard den Ottolander wrote:
> Hi,
> 
> Building mc on Minix-3.1.2 last weekend I stumbled over this piece of
> code:
> 
> vfs/ftpfs.c:1346
> #ifdef HAVE_STRUCT_LINGER_L_LINGER
> li.l_onoff = 1;
> li.l_linger = 120;
> setsockopt (sock, SOL_SOCKET, SO_LINGER, (char *) &li, sizeof (li));
> #else
> setsockopt (sock, SOL_SOCKET, SO_LINGER, &flag_one, sizeof
> (flag_one));
> #endif
> 
> The build on Minix chokes on the fact that SO_LINGER is undefined. It
> seems a bit odd that constant is being used when
> HAVE_STRUCT_LINGER_L_LINGER is not defined.

Nothing odd.  HAVE_STRUCT_LINGER_L_LINGER means that there is structure
linger with field l_linger.  That field (and the whole structure) is not
used if HAVE_STRUCT_LINGER_L_LINGER is not defined.

>  Any ideas on how to fix this
> cleanly?

Put #ifdef SO_LINGER ... #endif around the code you quoted.  Also do the
same for the declaration.

-- 
Regards,
Pavel Roskin

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

Re: [RFE][PATCH] Display free space on device in panels

[Pavel Roskin]

Hello!

> I was originally inspired by the old czech m602 file manager:
> http://oldgame.legalne.net/big/images/Manazer-M602.00.120.jpg
> 
> A bit more talky design was used in the DOS Navigator:
> http://www.dev0.de/pix/dn151lfnbeta3.png

Can we avoid any highlighting?  I think Far Manager does it right:
http://red-bean.com/proski/mc/far.png

-- 
Regards,
Pavel Roskin

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

Re: midnight commander reloaded (?)

[Pavel Roskin]

On Thu, 2006-05-11 at 10:29 +0300, Pavel Tsekov wrote:
> On Wed, 10 May 2006, Pavel Roskin wrote:
> 
> > On Wed, 2006-05-10 at 14:53 +0200, Jozef Riha wrote:
> >> "Summer of Code"-like sponsorship would not probably work due to the
> >> complexity of the task, limited time and resources.
> >
> > There is one thing that may work.  We could ask to rewrite mc in another
> > programming language as proof of maturity of that language.  I hope some
> 
> For what purpose ? If someone wanted to have a file manager in language 
> XYZ he would have done so already.

Not necessarily.  There are many great things that have never been
written.

> Every now and then someone jumps in and starts complaining that he would 
> want this and that added to MC and without those very IMPORTANT features
> MC is just crap. Then they start to speculate how rewriting MC would pave
> the way and so on and so on...

That's not about me.

>  Why don't these people just start 
> contributing - either by suggesting ideas and ways to implement them or by 
> actually writing code ?!

I'm suggesting an idea how to use a "Summer of Code" like process and
get an acceptable result.  I'm not sure it will happen, but if it will,
it shouldn't be a waste of resources.

> > Maybe it should be permitted to modify an existing project (I believe
> > there is a file manager in Python) to match all significant features of
> > mc.  Although non-Python programmers would be at disadvantage in this
> > case.
> 
> I've tried ZC (Zemljanka Commander) at one point and I wasn't very 
> fascinated. It is written in Python if I remember correctly and uses
> GTK+/Gnome for the GUI. I am not sure but maybe one of the authors
> used to work on MC in the past.

As far as I can see, only plugins are in Python.  The code is in C.

The project clearly needs some work.  Some of the tarballs clearly
didn't come from "make distcheck".  config.guess in avfs is from year
1996 and doesn't know about x86_64.  The "Copyright" tag in *.spec files
is obsolete.

But the C code looks quite good.  The functions are quite short and easy
to understand.

Now I'm quite sure that modification of the existing projects should be
permitted.

-- 
Regards,
Pavel Roskin

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

Re: midnight commander reloaded (?)

[Pavel Roskin]

Hello!

On Wed, 2006-05-10 at 14:53 +0200, Jozef Riha wrote:
> "Summer of Code"-like sponsorship would not probably work due to the
> complexity of the task, limited time and resources.

There is one thing that may work.  We could ask to rewrite mc in another
programming language as proof of maturity of that language.  I hope some
e.g. Ruby programmer would take the challenge of implementing mc in a
few months.  The result would be maintainable, because otherwise it
would be a negative advertising for the language.

Maybe it should be permitted to modify an existing project (I believe
there is a file manager in Python) to match all significant features of
mc.  Although non-Python programmers would be at disadvantage in this
case.

-- 
Regards,
Pavel Roskin

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

Re: How to repress subshell path echoing?

[Pavel Roskin]

On Sun, 2006-05-07 at 18:00 +0200, László Monda wrote:
> Thanks Pavel, it works great now!
> 
> It seems that the standard Ubuntu .bashrc had "export
> HISTCONTROL=ignoredups" in it.

It's commented out in 5.10 (Breezy Badger).

> As I searched for the solution of this problem I noticed that more
> people had this issue and it made me think about what the Right Thing
> would be to do in this case.
> 
> After starting the subshell wouldn't it be better for mc to append
> ":ignorespace" to $HISTCONTROL if there's no ignorespace nor ignoreboth
> already present?

That would add complexity to mc.  HISTCONTROL is currently set in the
environment after forking but before bash is started.  Setting anything
after .bashrc requires sending a command to the shell, just like it's
done with "cd".  If you want to check the value of HISTCONTROL in the
command, it becomes quite long. (I think you would use "case" to avoid
calling external programs).

Another solution would be to have a wrapper for .bashrc that would
run .bahsrc and then change HISTCONTROL.  You can do it already - just
create a file called bashrc under ~/.mc

-- 
Regards,
Pavel Roskin

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

Re: How to repress subshell path echoing?

[Pavel Roskin]

Hello!

On Sun, 2006-05-07 at 12:23 +0200, László Monda wrote:
> As I moved from Debian to Ubuntu I noticed that my bash history
> consists 
> 
> cd "`echo -e 'PATHNAME'`"
> 
> entries which are created by mc when changing paths in the panels.

mc sets HISTCONTROL=ignorespace in bash subshell, but either it has no
effect or something is unsetting or changing this environment variable.
Try "echo $HISTCONTROL" in the mc subshell.

-- 
Regards,
Pavel Roskin

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

Re: tigetstr() usage in init_xterm_support()

[Pavel Roskin]

Hello, Pavel!

On Thu, 2006-05-04 at 16:41 +0200, Pavel Tsekov wrote:

> init_xterm_support() uses tigetstr() to retrieve the xterm mouse
> sequnce
> from the terminfo database. Unfortunately, the prototype for
> tigetstr() is
> missing which is fatal for 64-bit builds of MC as the compiler assumes
> that
> tigetstr() returns int (32 bits) instead of pointer to char (64 bits).
> Now,
> the obvious solution is to include term.h which holds the prototype
> for
> tigetstr(), but unfortunately this doesn't work very well as term.h
> defines
> a series of macros which pollute the namespace badly i.e. lines,
> buttons,
> etc...

Please consider moving init_xterm_support() outside main.c, so that the
namespace pollution doesn't affect other code.

-- 
Regards,
Pavel Roskin

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

Re: midnight commander reloaded (?)

[Pavel Roskin]

Hello!

Just a few comments.

On Tue, 2006-05-02 at 19:48 +0200, Jozef Riha wrote:
> Dear mc devs,
> 
> please let me thank you for your work at the first place. Midnight
> commander is still my number one file-manager (Linux). Except the
> utility I welcome there are however things I see in other
> file-managers (total commander) which I would be happy to see ported.
> Specifically:
> * user defined key bindings
> * better bookmarks system w/ hotkeys
> * more options for searching (Esc ?)

Potential killer feature - exclude versioning data (CVS, RCS,
SCCS, .git, .svn directories and *,v files) with one checkbox.  Although
I should probably just find a night for it and add it to mc.

> * tabs (like in firefox/opera/you name it)

I think backgrounding the viewer and the editor would be fine.  I don't
think backgrounding extra panels would be helpful.

> * plugin support
> * better archive support (zip archive inside zip archive inside rar

This is working for me already.  On the other hand, associations don't
work well on the archive files (think pdf in zip).

> and sidenote: look how tc  opens/reads huge zip files)
> * ability to send copy/move process to background and back, manager of
> background processes

Yes, that's another useful thing to background.

Another high-priority requirement - proper Unicode support.  And better
keyboard support in Linux console.

> -- Lower priority ones --
> * drag&drop support
> * option to use a GUI (--enable-gui like option)

That has the potential to make the new commander another mc.  Unless
both the text and the GUI frontends use the same library for drawing,
and the differences are transparent to the bulk of the code.

> * clock (remember volkov commander?)
> * multiplatormness (a win32 port)

Same comment applies.  If it's not transparent to most of the code, it
will damage the project very badly.

> As from what I have read about the history of mc, the current
> development is somewhat cumberome. Namely since version 4.x.x the
> patches are becoming less transparent and it is still harder for a new
> feature to make it into the sources.

To be fair, many features that were added in the "good old times"
required significant clean-ups afterward.  So it's not like that it
suddenly became harder to add features because the of the code changes.
The requirements were changed to allow only complete patches that would
not require subsequent cleanups.

>  I do not know if or how much is
> this true,  if the real problem is the active developer number or
> something else, but I somehow feel that in order to make mc going
> somewhere the sources must be rewritten from scratch.

I agree.  Lots of time was spent on figuring out why some code was
written in a certain way.  The sources are full of irrelevant
workarounds for libraries that are no longer used.

> Midnight commander is still the only widely accepted filemanager for
> console but I see it becoming too old these days. And I am not the
> only one seeing this. Therefore I was thinking of the following:
> collect a decent sum of money from the linux users who share the same
> ideas as
>  me, make a competition of tenders based on the demo of the new
> manager, set detailed specifications (GPL license mandatory) on
> software after those are met the money will be paid. Simil
> ar to SoC except for that anyone (including companies) will be able to
> take part on it.

I'm afraid the best code is written by those who are going to maintain
it in the long term, not by those who want just to meet certain
requirements before the deadline.

In the case of "summer of code", the ideas were suggested by maintainers
of actively developed projects.  The criteria for success was
integrating the changes to the codebase.

And what would happen to the mc-reloaded once the "summer of code" is
over?  Who is going to maintain it?

> What I would like to know is your opinion on the whole matter as I
> admit I may be all wrong here.

I agree that mc should be rewritten, but I don't think your approach is
workable.  You can end up with something that does what the specs say
and nothing else, and the code may be even harder to improve.

-- 
Regards,
Pavel Roskin

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

Re: Inconsistent behaviour of Options

[Pavel Roskin]

On Thu, 2006-03-09 at 23:40 +0100, Leonard den Ottolander wrote:
> Hello Pavel,
> 
> On Thu, 2006-03-09 at 17:31 -0500, Pavel Roskin wrote:
> > ... and if you exit from mc rather than e.g. close the xterm window.
> > And if you don't have another mc running that would overwrite those
> > settings if you exit from it properly.
> 
> The latter would still be a problem with direct saves.

I don't understand which scenario you have in mind.  If you mean saving
settings from two mc instances, that would be a problem, but it's a
counter-intuitive thing for users to do.

>  And that "auto
> save setup" only works on normal programme termination should be
> obvious.

Remember, users can be distracted, and they are generally assumed to
have a short attention span.  You cannot expect a user to remember to
exit from mc correctly to save settings.  There may be thousands of
things between changing the configuration and ending mc, and some of
them can kill mc, e.g. as X crash due to some other software, closing a
wrong window, reboot due to urgent security upgrade etc.

I actually find it more natural that once the dialog has been dismissed
by any button, I don't have to remember to do anything.  I'm accustomed
to software that doesn't use my memory too much.

Also, programs that save anything on exit try to protect against killing
until that data has been saved.  That's why SIGKILL is the last resort.
mc doesn't do anything like that, as it would lose the unsaved
configuration even on SIGHUP.

> > I think that "auto save setup" is something that cannot be implemented
> > reliably in mc unless you make "Ok" work exactly like "Save" and save
> > changes immediately.
> 
> But then the option auto save setup would be redundant... Unless you
> mean that the behaviour of "Ok" should be changed based on the current
> "auto save" setting.

I think "auto save setup" is redundant, but I never had time to remove
it.  Besides, it would open a huge can of worms.

Some users rely on "auto save setup" to have mc remember the last
directories.  Sure, such users have a different mental model of mc, they
try not to kill mc, and I guess they run one copy of mc at most (so it's
more a DOS/Norton Commander like model).

Another group of users likes to edit configuration files manually.  If
mc defaults not to save the configuration, the configuration files are
not created first time mc is run.  Somebody would complain.

-- 
Regards,
Pavel Roskin

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

Re: Inconsistent behaviour of Options

[Pavel Roskin]

Hello!

On Thu, 2006-03-09 at 23:14 +0100, Leonard den Ottolander wrote:
> Hi Jindrich,
> 
> On Thu, 2006-03-09 at 13:48 +0100, Jindrich Novy wrote:
> > 1. "Ok" sets the parameters only for the current session and won't touch
> > the ini file.
> 
> "Ok" is equivalent to "save" if "auto save setup" is set.

... and if you exit from mc rather than e.g. close the xterm window.
And if you don't have another mc running that would overwrite those
settings if you exit from it properly.

I think that "auto save setup" is something that cannot be implemented
reliably in mc unless you make "Ok" work exactly like "Save" and save
changes immediately.

-- 
Regards,
Pavel Roskin

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

Re: [bug #15412] gpmsupport on console doesn't work

[Pavel Roskin]

On Fri, 2006-02-03 at 16:33 +0100, Leonard den Ottolander wrote:
> Hello Pavel,
> 
> On Thu, 2006-02-02 at 16:48 +0200, Pavel Tsekov wrote:
> > Please, close.
> 
> Could Pavel get the right to close bugs please? Thanks.

Done.

-- 
Regards,
Pavel Roskin

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

Re: [PATCH] Bad permission highlighting

[Pavel Roskin]

On Fri, 2006-01-06 at 13:32 +0100, Jindrich Novy wrote:
> Hello mc-devel,
> 
> Andy Shevchenko reported a bug to me for bad permissions highlighting.
> I've written a patch for it and it's attached. It's not a big deal but
> it fixes the highlighting problem.

Actually, your patch breaks permission highlighting for CVS mc.  The
highlight is shifted to the right.  I tried both "perm" and "mode".

But mc distributed by Fedora (mc-4.6.1a-6) has this problem.  It must be
caused by Red Hat patches.  So, the patch shouldn't be applied to the
original mc sources.  In any case, it would be better to adjust values
of "l" and "r" rather than their meaning.

-- 
Regards,
Pavel Roskin

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

Re: [PATCH] Proper names

[Pavel Roskin]

Hello!

On Tue, 2005-12-20 at 20:45 +0100, Marcin Garski wrote:
> Hello,
> 
> Here is the patch that changes names to it proper version, like Red Hat, 
> GNOME, GTK+.

I think it's wrong to fix ChangeLog files in such way.  I understand
fixing spacing or obvious typos, but rewriting history of the project to
use "official" names of software - it just smells like 1984.  What if
GNOME is renamed to EMONG tomorrow?  Would we rewrite the project
history again?

> @@ -1109,7 +1109,7 @@
>  2002-10-08  Pavel Roskin  <[EMAIL PROTECTED]>
>  
>   * configure.in: Rename RH_VERSION to RPM_VERSION - not every
> - rpm-based system is Red Hat.  Replace all dashes, not just one.
> + rpm-based system is Red Hat Linux.  Replace all dashes, not just one.

This is just ridiculous.  The text doesn't become more clear, but
formatting becomes sloppy.  I don't want such changes to be applied to
the entries that bear my name.

-- 
Regards,
Pavel Roskin

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

Re: Upgrading internal samba

[Pavel Roskin]

On Sun, 2005-12-04 at 15:10 +0100, Leonard den Ottolander wrote:
> Hi,
> 
> Would it be a good idea to upgrade the internal version of samba? See
> also
> https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=5142

We'll have this problem as long as mc uses Samba configuration files.
Every time Samba changes the format of its configuration files, mc will
have to be upgraded (not just recompiled).

I see two solutions:

1) Use libsmbclient.  This way, upgrading Samba will upgrade the client
library, and mc will recognize new configuration.

2) Don't use Samba configuration files in mc.  Use a separate
configuration file or store all configuration in ~/.mc/ini

I would prefer that we at least try to use libsmbclient, and if it
doesn't work, let's report it to Samba maintainers.  This way,
libsmbclient will be ready for mc some day.

-- 
Regards,
Pavel Roskin

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

[bug #5142] mc's built-in samba library is out of date

[Pavel Roskin]

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

We'll have this problem as long as mc uses Samba configuration files.  Every
time Samba changes the format of its configuration files, mc will have to be
upgraded (not just recompiled).

I see two solutions:

1) Use libsmbclient.  This way, upgrading Samba will upgrade the client
library, and mc will recognize new configuration.

2) Don't use Samba configuration files in mc.  Use a separate configuration
file or store all configuration in ~/.mc/ini

I would prefer that we at least try to use libsmbclient, and if it doesn't
work, let's report it to Samba maintainers.  This way, libsmbclient will be
ready for mc some day.


___

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: Re[3]: mcslang library for win32

[Pavel Roskin]

On Mon, 2005-11-28 at 18:22 +0500, Pavel Shirshov (pchel) wrote:
> Hello Pavel,
> 
> Monday, November 28, 2005, 3:00:40 PM, you wrote:
> 
> >> LdO> There was some speak of reviving win32 support
> >> LdO> 
> >> (http://mail.gnome.org/archives/mc-devel/2005-September/msg00076.html).
> >> LdO> Also I don't know in what respect cygwin depends on these files.
> >>
> >>  Cygwin uses ncurses win32 port.
> 
> PT> Cygwin MC uses the Cygwin port of ncurses. Even if it used slang it would
> PT> use the Cygwin port of slang which does not need the files slvideo.c
> PT> and slw32tty.c - those files are used by the native Win32 slang port.
> 
> What is your opinion about removing mcslang PC port?

I've removed it.  Thank you for noticing.  Those files should have been
removed long ago.  If the PC port is revived, those files will be
restored as well.

-- 
Regards,
Pavel Roskin

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

Re: [PATCH] spec.syntax misses %check

[Pavel Roskin]

On Wed, 2005-11-23 at 22:05 +0100, Jindrich Novy wrote:
> Hello mc-devel,
> 
> spec.syntax ignores the %check macro. The following patch adds
> highlighting of it in spec files.

Applied.  Thank you!

-- 
Regards,
Pavel Roskin

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

Re: [PATCH] mini status bar unaligned

[Pavel Roskin]

Hello, Jindrich!

On Wed, 2005-11-23 at 20:52 +0100, Jindrich Novy wrote:
> Hi mc-devel,
> 
> the main panel in the default "Full file list" is unaligned with mini
> status bar, to reproduce:
> 
> 1) go to Left/Listing mode...
> 2) enable Full file list (likely enabled by default)
> 3) enable user Mini status
> 
> you see:
> Size and MTime field is unaligned with Size/Perm field in mini status
> bar what is just ugly.

Then don't do it.  In my opinion, time and permission are not supposed
to have the same width.  Adding space to the permission string wastes
very limited "real estate" of the text terminal.

If you want alignment, use "perm:12" instead of "perm" in the
mini-status line.

-- 
Regards,
Pavel Roskin

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

Re: Depency on ld-linux.so.2(GLIBC_PRIVATE)

[Pavel Roskin]

On Tue, 2005-11-15 at 21:05 +0100, Leonard den Ottolander wrote:

> He he. I see the same issue indeed exists with my 2005-11-10 CVS
> checkout + slang2. Any suggestions on how to fix this?

You are going the right thing :-)
Ask S-Lang developers.

-- 
Regards,
Pavel Roskin

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

Re: Depency on ld-linux.so.2(GLIBC_PRIVATE)

[Pavel Roskin]

On Tue, 2005-11-15 at 18:30 +0100, Leonard den Ottolander wrote:
> Hi Pavel,
> 
> I assume this is caused by one of the recent changes you've made. I
> haven't seen this ever before. Installing an rpm build from a
> distchecked tarball from a few days ago fails with the following error:
> 
> $ sudo rpm -Fv /usr/src/redhat/RPMS/i386/mc-4.6.1a-1.lj.i386.rpm 
> Password:
> error: Failed dependencies:
> ld-linux.so.2(GLIBC_PRIVATE) is needed by mc-4.6.1a-1.lj.i386
> 
> The same procedure with a tarball just a few days older doesn't give me
> this problem.

"nm mc" shows that the only symbol from GLIBC_PRIVATE is
__libc_enable_secure.  Search for __libc_enable_secure finds it in two
places:

intl/dcigettext.c - it's only used if that file is compiled as part of
libc, which is not the case.

slang/slcommon.c - this one uses __libc_enable_secure when glibc 2.x and
newer is used.  So, I guess it's upgrading S-Lang that introduced this
problem.

-- 
Regards,
Pavel Roskin

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

Re: Stale link to download area

[Pavel Roskin]

On Mon, 2005-11-14 at 18:29 +0100, Leonard den Ottolander wrote:
> Hi Pavel,
> 
> The "Filelist (Download area)" link on the project page
> (http://savannah.gnu.org/projects/mc/) still points to
> http://savannah.gnu.org/files/?group=mc which redirects to
> http://ftp.gnu.org/gnu/mc/ . Could you please point that to
> http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/ ? Thanks.

Fixed.

-- 
Regards,
Pavel Roskin

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

Re: Gettext version bump [was Re: make distcheck warnings]

[Pavel Roskin]

Quoting Leonard den Ottolander <[EMAIL PROTECTED]>:

> Hi Pavel,
>
> On Sat, 2005-11-12 at 19:51 -0500, Pavel Roskin wrote:
> > What kind of breakage do you see or expect to see?
>
> Being unable to build mc on such legacy systems as the build
> requirements are not met. This version bump also bumps the version
> requirements for automake and autoconf.

You are supposed to build from a tarball on such systems, not from CVS.

> > Darwin support without that ugly kludge in configure.ac.  Less warnings
> (there
> > are still plenty of them in the gettext code if you run my mctest, but
> neither
> > of them seems to indicate a real problem).
>
> I'd rather live with a few redundant warnings than without a more recent
> mc on such legacy systems.

I'm yet to see any complaints from anyone who actually tried that.

If you insist on building from CVS on legacy systems, I could write a wrapper or
replacement for autopoint to ignore the version requirements for gettext.  I
could also ask gettext maintainers to allow support for the "at least" operator
for gettext version - I think it should be safe for mc.

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

Re: make distcheck warnings

[Pavel Roskin]

Quoting Leonard den Ottolander <[EMAIL PROTECTED]>:

> Hello Pavel,
>
> On Thu, 2005-11-10 at 20:55 -0500, Pavel Roskin wrote:
> > I chose version 0.14.3 was chosen because Fedora Core 4 supplies it.  It
> > should be old enough for the core developers to have it, and new enough
> > to have most bugs fixed.
>
> I'm not so sure it's such a good idea to have the build depend on such a
> recent version of gettext. You might fix a few bugs, but you break
> compatibility with a lot of legacy systems.

What kind of breakage do you see or expect to see?  Could you please provide
more details?  I actually think newer versions of gettext should work better
with legacy systems, since the fixes are incorporated into gettext runtime over
time.

> What exactly is it we need
> version 0.14.3 for?

Darwin support without that ugly kludge in configure.ac.  Less warnings (there
are still plenty of them in the gettext code if you run my mctest, but neither
of them seems to indicate a real problem).

Actually, the CVS version of gettext supports message contexts, so it would be
nice to switch to it soon after it's released.

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

Re: make distcheck warnings

[Pavel Roskin]

Hello, Leonard!

On Thu, 2005-11-10 at 22:42 +0100, Leonard den Ottolander wrote: 
> Hi,
> 
> make distcheck reports the following warnings:
> 
> msgmerge: ta.po: warning: Charset "TSCII" is not a portable encoding
> name.
> /usr/bin/msgfmt: ta.po: warning: Charset "TSCII" is not a portable
> encoding name.

We cannot fix it in mc.  It was discussed many times.  Google for "mc
TSCII".

TSCII is not standard, but it's actually used.  Either TSCII should be
standardized, or Unicode should be used.  If I remember correctly, there
are some problems with Tamil support in Unicode.  Maybe the consoles
fonts is not so good.  I don't think we should pressure Tamil users to
follow standards if they don't have good Unicode fonts.

> configure: WARNING: Rejecting S-Lang with UTF-8 support, it's not fully
> supported yet
> ../../intl/intl-compat.c:24:1: warning: "_INTL_REDIRECT_MACROS"
> redefined
> ../config.h:644:1: warning: this is the location of the previous
> definition

The redefinition of _INTL_REDIRECT_MACROS is fixed in 0.14.3 (it might
have been fixed much earlier).

The problem with redirection was reported on Darwin, where
__USER_LABEL_PREFIX__ wasn't defined.  The problem was fixed in gettext
immediately after 0.11.5.  Since mc supported older versions of gettext,
a workaround was provided.

I also noticed that the test used in mc was incorrect - it used nested
functions instead of global functions used by gettext.  I fixed that
initially.

But then I settled for a better approach - mc is using gettext 0.14.3
now, and MC_ASM_LABELS is gone.

I chose version 0.14.3 was chosen because Fedora Core 4 supplies it.  It
should be old enough for the core developers to have it, and new enough
to have most bugs fixed.

> ../config.h:641:1: warning: "_GNU_SOURCE" redefined
> ../../intl/loadmsgcat.c:23:1: warning: this is the location of the
> previous definition

This is fixed by using AC_GNU_SOURCE.  Since it appeared in Autoconf
2.54, configure.ac requires it now.

-- 
Regards,
Pavel Roskin

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

Re: make distcheck from CVS fails (gettext)

[Pavel Roskin]

Hi Leonard,

On Wed, 2005-11-02 at 23:35 +0100, Leonard den Ottolander wrote:
> Hi Pavel,
> 
> On Wed, 2005-11-02 at 13:40 +0100, Leonard den Ottolander wrote:
> > glibcompat.o(.text+0xb): In function `Q_':
> > ../../src/glibcompat.c:120: undefined reference to `libintl_gettext'

I see.  glibcompat depends on libintl for Q_, man2hlp uses glibcompat,
so man2hlp depends on libintl (unnecessarily).

> Did you touch any files other than configure.ac, src/glibcompat.[ch] and
> src/util.[ch] in your gettext changes?

I may have touched other files, but this problem is caused by moving Q_
(formerly gettext_ui) from util.c for glibcompat.c.  I have reverted
this change.

> Hope you can fix this soon.

It's fixed.

-- 
Regards,
Pavel Roskin

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

Re: Version 4.6.1 in bugzilla

[Pavel Roskin]

On Wed, 2005-10-19 at 13:40 +0200, Leonard den Ottolander wrote:
> Hi Pavel,
> 
> Version 4.6.1 is missing in bugzilla. Could you please add it? Thanks.

Done

-- 
Regards,
Pavel Roskin

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

Re: Czech translation needs fixups

[Pavel Roskin]

On Thu, 2005-10-06 at 19:52 +0200, Egmont Koblinger wrote:
> On Thu, Oct 06, 2005 at 01:08:46PM -0400, Pavel Roskin wrote:
> 
> > You are right.  I don't like the glib implementation.  It totally
> > ignores the fact that translators are not programmers, and that they
> > will translate everything, no matter what you tell them.
> 
> I perfectly agree with you. Should we file a bugreport (enhancement
> request?) to Gnome Bugzilla?

As I said, it's already there:
http://bugzilla.gnome.org/show_bug.cgi?id=164373

But it looks like it will never be fixed.

> But even if they accept our arguments and fix it, if we want to allow
> "ButtonBar|Konec" style translations in mc, we'll have to use our own
> implementation of Q_() if glib is older than 2.X, so then a more complicated
> test will be needed, the simple #ifdef Q_ won't do it.

There is only one glib (unlike e.g. libc), so checking for glib version
would be adequate.

> H, maybe my idea of using glib's Q_() wasn't a good idea? It seems now
> that it would be easier to go our own way...

Maybe.  I still like the shorter name, and I don't want to change it
back and forward.

-- 
Regards,
Pavel Roskin

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

Re: Czech translation needs fixups

[Pavel Roskin]

On Thu, 2005-10-06 at 20:46 +0200, Jindrich Novy wrote:
> > > 2-4-> byty (the last character is ý)
> > 
> > I have fixed that.  It was plain "y" in your patch.
> I was correct in the original patch, sorry. Only plain "y" without any
> accents is suitable here.

Fixed.

> Yes, the Plural-Forms expression isn't correct for Czech inflection (the
> rule in the cs.po file looks more like a rule definition for ordinal
> numeral suffices) and the correct rule should be like this:
> 
> "Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n>=2 && n<=4 ? 1 : 2);\n"
> 
> what returns the correct result even for 0 (result=2). This should match
> perfectly messages like "You have %llu bytes free on your drive".

Fixed.

-- 
Regards,
Pavel Roskin

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

Re: Czech translation needs fixups

[Pavel Roskin]

On Thu, 2005-10-06 at 20:50 +0200, Jindrich Novy wrote:
> > I hope when glib/gi18n.h is included in glib.h, it will be mature enough
> > to avoid such stupidities.
> 
> So the preferred way is to omit everything before the pipe sign in the
> translated strings to keep compatibility with older glibs ?

Yes, except that it's for "compatibility" with new glib.

The bug is already filed:
http://bugzilla.gnome.org/show_bug.cgi?id=164373

-- 
Regards,
Pavel Roskin

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

Re: Czech translation needs fixups

[Pavel Roskin]

On Thu, 2005-10-06 at 11:03 +0200, Egmont Koblinger wrote:
> On Thu, Oct 06, 2005 at 10:09:26AM +0200, Jindrich Novy wrote:
> 
> > msgid "ButtonBar|Quit"
> > msgstr "Tla??tkov?Li?ta|Konec"
> 
> If I understand correctly how the Q_() function of glib works, the
> translated strings must not contain the prefix up to the | character, since
> glib's Q_() (perhaps due to performance issues) does not strip this prefix,
> except if gettext() returns the same pointer (i.e. the string has no
> translation available).

You are right.  I don't like the glib implementation.  It totally
ignores the fact that translators are not programmers, and that they
will translate everything, no matter what you tell them.

> So I think it should be:
> 
> msgid "ButtonBar|Quit"
> msgstr "Konec" 
> 
> but the best would be to test it with glib >= 2.4.

It's working fine with glib 2.6.6 because it doesn't include
glib/gi18n.h when glib.h is included.  If I include glib/gi18n.h, bad
things do happen.

I hope when glib/gi18n.h is included in glib.h, it will be mature enough
to avoid such stupidities.

-- 
Regards,
Pavel Roskin

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

Re: Czech translation needs fixups

[Pavel Roskin]

On Thu, 2005-10-06 at 10:09 +0200, Jindrich Novy wrote:
> On Wed, 2005-10-05 at 10:30 -0400, Pavel Roskin wrote:
> > I think your translation of "%s in %d file" is incorrect.  There are no
> > "bytes" in the message.  It's "file" that should be plural.  When
> > tested, I got "72 byty byte v 1 souborech", which doesn't look right.
> 
> Yes, the string is definitely not right. It's for the first time I see
> the plural construct in the po file, as I'm not a translator actually ;)
> 
> I assumed that:
> 
> #, fuzzy, c-format
> msgid "%s byte"
> msgid_plural "%s bytes"
> msgstr[0] "%s byt."
> msgstr[1] "%s byt."
> msgstr[2] "%s byt."
> 
> is trying to reflect different translations for inflected languages such
> as Czech.

Your assumption is correct.  However, be careful - the numbers in
brackets are values returned by the formula in the beginning of the *.po
file on the "Plural-Forms:" line.  These are not example numbers (0
bytes, 1 byte, 2 bytes etc).

It would be great to improve gettext to show the lowest number to match
the rule rather than some abstract rule number.

>  We have three suffices for describing an amount:
> 
> 1  -> byte
> 2-4-> byty (the last character is ý)

I have fixed that.  It was plain "y" in your patch.

> 5-infinity -> bytu (the last character is ů)

You may need to fix "Plural-Forms:" if that's true.  There is a
disagreement between what gettext 0.14.4 manual says about Czech
language (which is what you say) and the rules used in cs.po included
with gettext, which treat e.g. 22 like 2.  I took the rules from
gettext's cs.po.

> so because of the number of indices of msgstr[] I assumed that it's this
> case. Apparently it's not.

I don't understand what you mean.

> The attached patch translated another missing strings and fixes
> ButtonBar string to fit to 6 characters.

Applied.  I actually forgot to commit the previous patch, so I had to
apply your changes manually, but now they are in CVS.

You didn't reply about "%s in %d file".  I did some research using
Google and came with reasonable translations, but I'm not sure I got the
v/ve thing correct.

-- 
Regards,
Pavel Roskin

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

Re: Czech translation needs fixups

[Pavel Roskin]

Hi, Jindrich!

On Wed, 2005-10-05 at 13:09 +0200, Jindrich Novy wrote:
> Hi Pavel,
> 
> On Tue, 2005-10-04 at 10:47 -0400, Pavel Roskin wrote:
> > It would be great if you translate the new "plural" forms. 
> 
> The attached patch fixes some case problems in highlighted chracters
> and yet more keyboard shortcut conflicts found in dialogs what I haven't
> checked before. The "plural" forms are also translated.

Applied.  Thank you!

I think your translation of "%s in %d file" is incorrect.  There are no
"bytes" in the message.  It's "file" that should be plural.  When
tested, I got "72 byty byte v 1 souborech", which doesn't look right.

I know, it's confusing, but I couldn't think of any better way to apply
ngettext() twice to the same sentence.

-- 
Regards,
Pavel Roskin

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

Re: pr&Ompt on replace

[Pavel Roskin]

On Tue, 2005-10-04 at 22:28 +0200, Leonard den Ottolander wrote:
> Hi,
> 
> I'd like to fix the hotkey in the subject to "&Prompt on replace" as the
> "O" is a duplicate with the "O" from "&Ok". If I do not fix the strings
> in the .po files as well will this lead to untranslated strings?

Yes, it will.  When changing an English message without changing its
sense, please update the translations.

-- 
Regards,
Pavel Roskin

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

Re: Q_()

[Pavel Roskin]

Hello!

On Tue, 2005-10-04 at 15:36 +0200, Egmont Koblinger wrote:
> Hi,
> 
> There's been a discussion here a few months ago how to make the same English
> text translated differently in different contexts. It was important e.g. for
> the texts of the bottom bar whose translations have to fit in 6 characters.
> 
> It seems to me that this wasn't fully implemented.

Agreed.

> I don't know how that thread ended and I cannot find it now, but I found the
> Q_() and g_strip_context() functions in glib (what already we use anyway) so
> it seems to me that they're the best (and most standard) choice we could
> stick to.

mc uses gettext_ui(), which is equivalent to Q_.

> These functions/macros are only available from glib 2.4, so currently we
> would need to test for their presence and use an own implementation if older
> glib is being used, but this shouldn't be a problem, as implementing these
> functions is a trivial job, and as we know it from the flames of last week,
> there are some autoconf gurus also who can implement autodetection. :-)

I don't think autodetection is needed.  All that's needed is a
replacement Q_() implementation in src/glibcompat.c.

> I think that using such a standard interface (even if it's a new one and we
> need temporary hacks to support older glib) is a perfect way to go, and will
> be even much better if one day in the far-far future we can drop support for
> glib < 2.4.
> 
> If you like this idea, I can send patch to mc to introduce this feature,
> except for the autoconf part. But maybe autoconf magic isn't needed at all,
> since Q_() is a macro, a simple #ifdef Q_ will do it in mc's source.

Correct.

I've committed the Q_() support.  Fixing the translation is left for
you.

-- 
Regards,
Pavel Roskin

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

Re: Czech translation needs fixups

[Pavel Roskin]

Hi, Jindrich!

On Tue, 2005-10-04 at 14:35 +0200, Jindrich Novy wrote:

> Ok, just decided to translate the Czech po completely. The attached
> patch contains the complete Czech translation with the fixed duplicated
> keyboard shortcuts.

Applied, merged, committed.  Thank you!

After merging with the current mc.pot, we have:
981 translated messages, 5 fuzzy translations, 3 untranslated messages.

It would be great if you translate the new "plural" forms.  Finally, the
translation of "M bytes in N files" will be perfect in every language.
It wasn't perfect even in English - you could have "1 bytes in 2 files".

-- 
Regards,
Pavel Roskin

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

Re: Proposal for simplification

[Pavel Roskin]

Hi Leonard,

On Mon, 2005-10-03 at 23:11 +0200, Leonard den Ottolander wrote:
> Hi Pavel,
> 
> On Fri, 2005-09-30 at 18:02 -0400, Pavel Roskin wrote:
> > As I understand, there is a UTF-8 patch for S-Lang but not for ncurses.
> 
> Well Balint states ncurses has UTF-8 support and the UTF-8 support in
> slang2 is native, not an external patch.

I mean a patch for mc to add support for UTF-8 enabled terminals.  I
should have been more explicit, sorry.

> > You can ask the author of the patch about the motivation.
> 
> ? Are you speaking of my slang2 patch? If so then there must be a
> misunderstanding. If not then of which patch are you speaking?

I believe the patch was made by Red Hat long ago.

> > I assume that it's just easier to support one library.
> 
> I disagree. I hadn't grasped that you propose to drop ncurses.

The purpose is to have less work for the developers.  I'm sure that
support for UTF-8 enabled terminals will require different changes if
ncurses or S-Lang is used.

> By the way, should I commit the mcslang2 patch? It is an *addition* to
> the internal slang1. Any objections by anybody to go with 2 internal
> versions of slang for the moment?

I don't like this idea.  I suggest that we drop internal S-Lang
completely.  It takes too many efforts time to maintain compatibility
with several versions of S-Lang.  It adds more options to test.  It also
sets a bad example.

The reason why S-Lang was included in the first place was to simplify
life for those who don't have it.  Things have changed since then.  Most
users download precompiled versions with their distributions.  Those who
chose to compile mc can compile S-Lang.  mc has another dependency -
glib, and it is not included, so it needs to be compiled separately.

Our priority should be to make mc better.  Making it easy for a laymen
to compile should take the second seat.  Otherwise, mc will be dropped
by distributions as an obsolete piece of code.

Also, unbundling S-Lang will force us to make mc work perfectly with the
existing installed libraries (or at least with those that weren't too
badly patched).

-- 
Regards,
Pavel Roskin

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

Re: Proposal for simplification

[Pavel Roskin]

Hello, Egmont!

Thank you for your comments and your support.

For ncurses vs S-Lang, your arguments are very helpful.  It's hard for
me to argue in more details, but I see that the actual UTF-8 work done
is for S-Lang only.  Perhaps ncurses Unicode support wasn't fully
explored yet.  Maybe we need to defer the decision until both options
are explored.

As for gettext, I have discovered that ngettext() in already used in
src/info.c, so I added the requirement that ngettext() is supported and
bumped the minimal supported gettext version to 0.11.5.  I also added a
ngettext() call in src/screen.c, where it was badly needed to display
mini-status: "M byte(s) in N file(s)".  If ngettext() is outlawed, only
outlaws will use ngettext() :-)

VFS simplification is waiting for another timeslice.

-- 
Regards,
Pavel Roskin

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

Re: Proposal for simplification

[Pavel Roskin]

On Fri, 2005-09-30 at 17:09 +0200, Bálint Kardos wrote:
> Hi Pavel,
> 
> > As we are
> > moving to S-Lang 2, we get more libraries to test.  Adding UTF-8 support
> > would likely increase incompatibilities even further (although I would
> > like to be proven wrong on this issue).
> 
> as I understand ncurses has UTF-8 support, and it is widely used by 
> developers.
> Is S-Lang2 stable enough to rely on it as an only choice?

Time will show.  I think S-Lang is better maintained than ncurses, so
we'll submit patches if needed.

As I understand, there is a UTF-8 patch for S-Lang but not for ncurses.
You can ask the author of the patch about the motivation.  I assume that
it's just easier to support one library.

-- 
Regards,
Pavel Roskin

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

Re: Proposal for simplification

[Pavel Roskin]

On Wed, 2005-09-28 at 12:08 +0300, Pavel Tsekov wrote:
> Hello,
> 
> On Tue, 27 Sep 2005, Pavel Roskin wrote:
> 
> > 1) Support only S-Lang 2 and only as an external library.  Those who
> > need mc will get S-Lang.  I know, this is pretty harsh, but the next
> > release is probably months away, and S-Lang 2 will be ubiquitous by
> > then.
> 
> Most *nix variants have curses implementation. Why all of a sudden
> curses support should be dropped in favour of S-Lang ?

mc already prefers S-Lang on such systems.  Old curses (not curses)
support was already dropped and nobody complained. S-Lang and ncurses
have different API, which necessitates compatibility layer.  As we are
moving to S-Lang 2, we get more libraries to test.  Adding UTF-8 support
would likely increase incompatibilities even further (although I would
like to be proven wrong on this issue).  Restricting screen libraries to
S-Lang would likely simplify color management.  I believe some color
related code wasn't even written because of the need to support two
libraries.

-- 
Regards,
Pavel Roskin

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

Re: Proposal for simplification

[Pavel Roskin]

On Tue, 2005-09-27 at 23:22 +0200, Roland Illig wrote: 
> Pavel Roskin wrote:
> > 3) Support only versions of gettext that have ngettext(), i.e. drop
> > gettext 0.10.x.

I see no objections, so I've committed this.

> There had been the suggestion that we don't use internal gettext at all. 
> This would simplify at least the ./autogen.sh and the configure script. 
> It would also reduce the size of the tarball by about 80k.

I'm quite of ambivalent about 80k, and I don't see much simplification.
In fact, AM_ICONV and AC_PROG_RANLIB would have to be added to
configure.ac because they are not implied for external gettext.

I'm more concerned that non-GNU systems will need to have GNU gettext
and GNU iconv installed for i18n to work.  It's harder to compile them
than S-Lang (AFAIK), but on the other hand, not having i18n is more
acceptable than not being able to run mc at all.

I'm keeping internal gettext for now, but I'm open to arguments.

-- 
Regards,
Pavel Roskin

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

Proposal for simplification

[Pavel Roskin]

Hello!

I believe one thing that makes mc so hard to maintain is the amount of
various compile time options.  While it may be cool to have support for
e.g. ncurses or for a 5 years old version of gettext, changes do break
code, and the more options we try to support, the more likely is the
breakage.  In particular, writing correct configuration scripts is hard
and not rewarding, i.e. no matter how much time you invest, things will
break for someone a few months later.

I believe mc is an established project that can dictate some
dependencies to those who want to compile it.  Since all the
dependencies are free software, it's only matter of getting and
installing them.

I suggest that we do following:

1) Support only S-Lang 2 and only as an external library.  Those who
need mc will get S-Lang.  I know, this is pretty harsh, but the next
release is probably months away, and S-Lang 2 will be ubiquitous by
then.

2) Drop support for non-VFS builds.  When we have reports that VFS was
ported to Win32, there is no point to keep it optional.  VFS could also
provide an intermediate layer for the local filesystem - that's
something we cannot do when VFS is optional.

3) Support only versions of gettext that have ngettext(), i.e. drop
gettext 0.10.x.

-- 
Regards,
Pavel Roskin

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

Re: Reconfigure bugzilla to only allow reports by logged in users

[Pavel Roskin]

On Wed, 2005-08-03 at 20:59 +0200, Leonard den Ottolander wrote:
> Hi Pavel,
> 
> On Wed, 2005-08-03 at 18:38, Pavel Roskin wrote:
> > Please report it to Savannah admins as a bug.
> 
> Sure. What would be their address? [EMAIL PROTECTED]

See https://savannah.gnu.org/contact.php

Where to post if your call.

-- 
Regards,
Pavel Roskin

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

Re: Reconfigure bugzilla to only allow reports by logged in users

[Pavel Roskin]

On Wed, 2005-08-03 at 16:00 +0200, Leonard den Ottolander wrote:
> Hi Pavel,
> 
> On Tue, 2005-08-02 at 06:23, Pavel Roskin wrote:
> > > Would it be possible to reconfigure mc bugzilla so only logged in users
> > > can post (to) bug reports.
> 
> I see it is now indeed impossible to report new bugs without being
> logged in. Thanks.

Please report it to Savannah admins as a bug.

-- 
Regards,
Pavel Roskin

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

Re: Reconfigure bugzilla to only allow reports by logged in users

[Pavel Roskin]

Hi, Leonard!

On Sat, 2005-07-30 at 12:40 +0200, Leonard den Ottolander wrote:
> Hi Pavel,
> 
> Would it be possible to reconfigure mc bugzilla so only logged in users
> can post (to) bug reports.

Done.

-- 
Regards,
Pavel Roskin

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

Re: Release announcement on Savannah

[Pavel Roskin]

On Wed, 2005-07-27 at 23:25 +0200, Leonard den Ottolander wrote:
> Hi Pavel,
> 
> Could you please update Savannah to reflect the fact that we have had a
> release? Thanks.

Done.

-- 
Regards,
Pavel Roskin

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

Re: access to the mc homepage

[Pavel Roskin]

Hello, Roland!

On Sat, 2005-07-23 at 00:11 +0200, Roland Illig wrote:

> When I'm translating, I'm in most cases happy with pregenerated .po and 
> .pot files. Only in case of doubt I download the tarball. And I don't 
> compile a package just for translating it. I only use the line number 
> information in the .po file and open the editor on that file.
> 
> Translators should have to do as little as possible for translating a 
> file. Their job is translating, not installing a whole bunch of 
> dependencies to generate the translation files.

OK.  The script is called maint/send-po, the po files are in
http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/po/

-- 
Regards,
Pavel Roskin

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

Re: access to the mc homepage

[Pavel Roskin]

Hi, Roland!

On Thu, 2005-07-21 at 23:43 +0200, Roland Illig wrote:

> Currently, all releases will be built with line numbers stripped. That's 
> why I wanted to have the translation files available separately. Or 
> maybe we should switch the line numbers on for releases.

If that a real problem for translators?  I would think that the time to
download the tarball over a 14.4 kbps modem in some far part of the
world would be much more than the time needed to run msgmerge, even on a
genuine 386 system.

> >>I _could_ also put those files on my private web space, but I don't want 
> >>to open yet another location for mc's files. It's much nicer to have all 
> >>those things centralized. (That would also include pchels frequent 
> >>prereleases, if he wants.)
> > 
> > I think it would be confusing to have prereleases made by different
> > people on the same site.  But if it's needed, maybe this could be
> > handled by another script?  You give me the tag name, I run the script,
> > and the snapshot is uploaded.  How about that?
> 
> I'm not talking about prereleases but only about the PO files. My plan 
> is to have them at http://www.ibiblio.org/mc/translations/${date}/. That 
> would be the place where we can point the translators to.

I'm fine with this if it's actually requested by the translators.
However, I would prefer that we only keep the latest revision for every
active branch.  I know that ibiblio.org has lots of bandwidth, but let's
respect their free hosting of mc by not wasting their resources.

-- 
Regards,
Pavel Roskin

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

Re: Let's have a release!

[Pavel Roskin]

On Wed, 2005-07-20 at 12:11 -0400, Miguel de Icaza wrote:
> Hello,
> 
> > I think it is time to finally have a release of 4.6.1. I'm satisfied
> > with having had an official pre release and a few weeks time for
> > testing. Afaict all the other developers are anxious for a release as
> > well. Let's have it!
> 
> If Pavel does not beat me to it, I will do the release on the weekend.

Please go ahead.

-- 
Regards,
Pavel Roskin

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

Re: access to the mc homepage

[Pavel Roskin]

Hello, Roland!

On Thu, 2005-07-21 at 19:54 +0200, Roland Illig wrote:
> Hello Pavel,
> 
> I would like it if all developers could have write access to mc's 
> homepage at http://www.ibiblio.org/mc/.

I don't think it's right.  I don't see any need for every developer to
have access to the homepage.  Permissions should be minimal for security
reasons.

>  I am planning to publish the 
> current translation files (from HEAD) on a regular basis, so that we 
> have a point where translators can download them from.

That's better, although I think that snapshots should be sufficient.

I'm not doing them often because I'm running a 64-bit system (x86_64),
but I want to provide a 32-bit binary for Intel architecture, so I have
to do chroot as root, which is more time consuming than running a
script.  Maybe I should abandon the goal of providing a binary RPM.  I
don't know how popular they are.

If you think the translators need something else, you can send me a
script that would create the files you want to provide.  I'll take care
of the uploading part.

If you give sufficient arguments why you need to do it yourself, I'll
assist you in getting access to the homepage.

> I _could_ also put those files on my private web space, but I don't want 
> to open yet another location for mc's files. It's much nicer to have all 
> those things centralized. (That would also include pchels frequent 
> prereleases, if he wants.)

I think it would be confusing to have prereleases made by different
people on the same site.  But if it's needed, maybe this could be
handled by another script?  You give me the tag name, I run the script,
and the snapshot is uploaded.  How about that?

> How do you think about this? And if you think all developers (or at 
> least those who want) may have access, how does it work technically? How 
> to we get the accounts?

The accounts should be requested on ibiblio.org.  You may need my help
to get access to the mc areas (ftp and web).

-- 
Regards,
Pavel Roskin

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

Removal of 7-zip oipening support - accidental?

[Pavel Roskin]

Hello, Leonard!

I see that you have removed support for opening 7-Zip archives in
revision 1.79 of lib/mc.ext.in.  The commit comments don't mention 7-Zip
explicitly and it doesn't seem you meant to remove it:

revision 1.79
date: 2005/07/03 12:43:15;  author: leonardjo;  state: Exp;  lines: +36
-31
lib/mc.ext.in: Move matches for plain compressed files down.

I think it would be polite to you inform the author of the original
patch if you are undoing it.  Maybe you removed 7-zip opening support
accidentally?  CVS should prevent it, unless you do something gross.

One possible scenario would be if you copy the file from the working
directory, update from CVS and copy the file back to the working
directory.  If that was the case, please don't do it again.

I'm restoring 7-zip opening support, and if you want to remove it again,
I want to hear your arguments.

-- 
Regards,
Pavel Roskin

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

Re: [PATCH] add 'ualz' to MC extfs.

[Pavel Roskin]

Hello!

On Thu, 2005-07-14 at 19:41 +0900, SungHyun Nam wrote:
> Hello,
> 
> I added 'ualz' extfs script.
> I tested this patch with unalz-0.50.

It seems that your script would never report directories in the archive.
What's the reason?  Looking and the code of unalz (CUnAlz::IsFolder), it
seems to me that the directories can be stored in the archive.

Why don't you use the "-d" option to avoid "cd" in mcualz_copyout()?

I have put the script to 
http://ibiblio.org/mc/contrib/unalz-extfs/

I don't think it should be added to the main distribution because the
compression software (ALZip) is not free and not really popular, so mc
would in effect advertise it.

Also, unalz doesn't seem to be mature because it cannot extract files to
stdout.  Creating a temporary directory for every file would slow down
copying large amounts of files in mc.

-- 
Regards,
Pavel Roskin

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

Re: mc 4.6.1 pre5 has been released.

[Pavel Roskin]

Hello!

On Sat, 2005-07-02 at 12:33 +0200, Leonard den Ottolander wrote:
> Can we please put up an announcement under Latest News at
> http://savannah.gnu.org/projects/mc and one at
> http://www.ibiblio.org/mc/ ?

Done.

-- 
Regards,
Pavel Roskin

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

Re: Help in French

[Pavel Roskin]

Hello, Gilles!

On Wed, 2005-06-15 at 22:24 +0200, Gilles Casse wrote:
> Hello,
> 
> Most of the mc messages are translated in French; the help is still in
> English though. I would like to know if a lister expects to translate
> the help in French, just to avoid a possible double work.

See the doc directory in the mc sources.  The help file is produced from
localized manual and a localized file called xnc.hlp.

-- 
Regards,
Pavel Roskin

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

Re: New Maintainer for MC Project

[Pavel Roskin]

Hello!

Quoting Fudoki Wilkinson <[EMAIL PROTECTED]>:

> This message was not answered by Pavel until until 6 June, after the offer
> of help had been withdrawn.

Still, you didn't have my endorsement that you claimed you had.
"Go ahead" meant "post whatever you want to the list", not "take over the
project".

Also, you don't have my permission to post my private correspondence to public
mailing lists.  I regret I spent so much time on you.

> >>Any suggestions, "inside information", or advice you could offer will be
> >>appreciated and will be kept confidential.  Open Source does not mean we
> >>cannot have a personal conversation about something we are both
> >>interested in seeing succeed!

The above are your words from a private message you sent to me.

>From now on, I'm not going to discuss anything with you, in private or in
public.

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

Re: New Maintainer for MC Project

[Pavel Roskin]

Hello!

Sorry, I should have answered this long ago.

On Sat, 2005-06-04 at 05:58 -0700, Fudoki wrote:
>  Greetings All!
> 
>My name is Terry Wilkinson and I am on the Docs
> Team and also am the Public Relations Coordinator for
> the Krusader File Manager Project
> (http://krusader.sourceforge.net/index.php).  Our Team
> has been watching this list closely because most of us
> are regular MC users.  I have also been talking to our
> leadership, and to Pavel Roskin, about offering to
> become the new Maintainer of the Midnight Commander
> Project, and Pavel has encouraged me to do so.

This is not true.  In fact, it tried to discourage you from attempts to
take over the existing project.

That's what I wrote you:

"Fresh start needs developers.  If you have developers, you don't need
to talk to me.  Just start coding and show me your existing code if you
want me in your team."

>From another message:

"By the way, I think the new project shouldn't be called "Midnight
Commander"."

Either you misunderstood me or you are misrepresenting my words.  In
either case, I don't think you should take over the existing project.
If you want mc developers to join your project, show what you can offer
them.

-- 
Regards,
Pavel Roskin

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

Re: Addressing MC stagnation.

[Pavel Roskin]

Hi, Leonard!

On Mon, 2005-05-23 at 21:41 +0200, Leonard den Ottolander wrote:
> ?? Aren't you saying what I'm saying? MC_4_6_1_PRE should become
> mc-4.6.1 and HEAD should be used for the release of 4.7 (the viewer code
> is not well tested so I believe it shouldn't be used for 4.6.1). Where
> do we disagree?

I misunderstood you as saying we should use MC_4_6_1_PRE branch for 5.0
and further releases.

-- 
Regards,
Pavel Roskin

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

Re: [bug #7872] Suggested changes in Python syntax bindings

[Pavel Roskin]

On Mon, 2005-05-23 at 20:08 +, Leonard den Ottolander wrote:
> Follow-up Comment #7, bug #7872 (project mc):
> 
> My question is "why do we need the extra code to match '/usr/bin/env' if all
> we need to match is 'perl'?" It seems redundant. Like trying to match
> '/usr/bin/perl', '/usr/local/bin/perl' etc. instead of just 'perl'.

Good idea, let's do it for all interpreters.

-- 
Regards,
Pavel Roskin

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

Re: before committing translation files ...

[Pavel Roskin]

On Mon, 2005-05-23 at 11:58 +0200, Roland Illig wrote:
> Pavel Roskin wrote:
> > On Thu, 2005-05-19 at 13:24 +0200, Roland Illig wrote:
> > 
> >>please run the ./strip-location.sh script on all files you want to 
> >>commit. The locations are only redundant information for the translator. 
> >>To regenerate the locations, just run make po-update.
> >>
> >>Example:
> >>cd mc/po
> >>./strip-location.sh de.po
> >>cvs commit ChangeLog de.po
> >>make update-po
> >>
> >>The effect is that "cvs diff" is more readable.
> > 
> > 
> > I've added --no-location to all msgmerge invocations, so it should be
> > automatic (the patch is in the HEAD branch for now).
> 
> And how do the translators get their version with locations? ;)

Command-->Find File

Or by doing this:
msgmerge --update lang.po mc.pot

-- 
Regards,
Pavel Roskin

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

Re: before committing translation files ...

[Pavel Roskin]

On Thu, 2005-05-19 at 13:24 +0200, Roland Illig wrote:
> please run the ./strip-location.sh script on all files you want to 
> commit. The locations are only redundant information for the translator. 
> To regenerate the locations, just run make po-update.
> 
> Example:
>   cd mc/po
>   ./strip-location.sh de.po
>   cvs commit ChangeLog de.po
>   make update-po
> 
> The effect is that "cvs diff" is more readable.

I've added --no-location to all msgmerge invocations, so it should be
automatic (the patch is in the HEAD branch for now).

-- 
Regards,
Pavel Roskin

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

Re: GCC-4.0 warnings

[Pavel Roskin]

Hello, Roland!

On Wed, 2005-05-18 at 21:46 +0200, Roland Illig wrote:
> Leonard den Ottolander wrote:
> > Hi,
> > 
> > Here's a list of gcc-4.0 warnings against HEAD from 2005-05-04. Tarball
> > taken from the FC4t3 mc-4.6.1a-0.9.src.rpm. Removed all patches as not
> > to cause confusion between clean CVS and downstream patches. Grepped for
> > "warning" in the build log.
> 
> Thanks for the list.
> 
> If anyone wants to fix these warnings, please _think_ before committing. 
> Changing a variable from signed to unsigned or vice versa is not a 
> trivial thing.

Another thing.  It turns out gcc 4.0.0 is smart enough to check logic in
the called function if it's available.  This means that it may warn
about uninitialized variables if they were passed to a function that
doesn't always initialize them.

So you can get a warning in this situation:

int callee(int *out)
{
   if (bad_things)
  return -1;
   *out = 1;
   return 0;
}

void caller(void)
{
int val;

if (callee(&val) < 0)
return;

printf("%d\n", val);
}

The warning is shown only if callee() is defined in the same file, so
that gcc can check it.  You may need use -O3 flag to get the warning (I
guess it tells gcc to use inlining more aggressively).

While the code is correct, it's not obvious for gcc.  The "knee-jerk"
reaction could be to initialize val in caller(), but sometimes it may be
better to fix callee(), especially if it's used many times.  Even more
so if it's not documented that the pointer won't be initialized if
callee() returns a failure code.

I have fixed all warnings in HEAD except one introduced by you.  I guess
you can fix it better (I tried and it's not trivial, so you may want to
reverse some of your changes instead):

help.c: In function 'help_handle_key':
help.c:627: warning: passing argument 3 of 'check_movement_keys'
discards qualifiers from pointer target type

-- 
Regards,
Pavel Roskin

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

Re: Addressing MC stagnation.

[Pavel Roskin]

Hello, Leonard!

On Mon, 2005-05-23 at 00:09 +0200, Leonard den Ottolander wrote:
> Hi Miguel,
> 
> On Sun, 2005-05-22 at 23:46, Miguel de Icaza wrote:
> >   long time.  I propose that the current CVS gets released
> >   as MC 5.0 and if any issues are found with the release
> >   we release 5.0.1, 5.0.2 and so on to address these problems.
> 
> I would suggest if such a step would be made we use the MC_4_6_1_PRE for
> this. HEAD is somewhat experimental.

I disagree.  We would confuse everybody.  The 4.6.1 branch should be
released as 4.6.1 if at all (maybe as 4.6.2 if there we unofficial 4.6.1
releases).

It's the experimental code that should become 5.0 or 4.7 or whatever we
choose.  If it's too unstable, we could make some prereleases.

-- 
Regards,
Pavel Roskin

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

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

[Pavel Roskin]

On Thu, 2005-05-19 at 22:44 +0200, Leonard den Ottolander wrote:
> Hi,
> 
> On Thu, 2005-05-19 at 09:53, Oswald Buddenhagen wrote:
> > > 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 ... :(
> 
> Yeah. I almost sent out an April fools prank mail announcing the release
> of 4.6.1 with Pavel Roskin's address as the sender. As I don't know him
> that well I wasn't sure if he'd appreciate the joke so I abandoned the
> idea. But that fake test mail still looks very nice in my mailbox ;-) .

If I saw such joke, I would likely have asked GNU admins to close my
account on GNU machines.  I'm already getting much more spam to that
address than valid e-mails, including all mailing lists I'm subscribed
to.

-- 
Regards,
Pavel Roskin

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

Re: portability of mc

[Pavel Roskin]

On Fri, 2005-05-20 at 10:09 +0200, Roland Illig wrote:
> Pavel Roskin wrote:
> > On Wed, 2005-05-18 at 07:13 +0200, Roland Illig wrote:
> >>- other weird system limits?
> > 
> > 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.  

In Windows, "long" has always meant 32-bit, whether it's a 16-bit OS or
a 64-bit one.

-- 
Regards,
Pavel Roskin

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