[bug #17268] Shift+Enter weirdness

2006-08-16 Thread Pavel Tsekov

Update of bug #17268 (project mc):

  Status:None = Wont Fix   
 Open/Closed:Open = Closed 

___

Follow-up Comment #7:

Closing it as WONTFIX.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17268

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

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


[bug #17568] Cannot compile mc-2006-08-29

2006-08-30 Thread Pavel Tsekov

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

http://mail.gnome.org/archives/mc-devel/2006-August/msg00069.html


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17568

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

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


Re: Mouse support bugs and a couple of feature requests

2006-09-04 Thread Pavel Tsekov
On Sat, 2 Sep 2006, Stephan Sokolow wrote:

 3. The -x option prevents gpm from working at the console.

Why would you do that ?

 As for the feature requests:
 1. could you please add an option to start with MC hidden (equivalent to
 starting normally and then pressing Ctrl+o) so I can stick it at the end of
 my .bashrc comfortably?

But then you would end up in another shell - the one started by MC and not 
in your login shell. Do you really want that ?

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


Re: Mouse support bugs and a couple of feature requests

2006-09-04 Thread Pavel Tsekov
On Sat, 2 Sep 2006, Stephan Sokolow wrote:

 First, the bug:
 1. Running mc inside screen at the Linux console prevents gpm mouse support
 from working.

Seems to be a gpm problem. See what I've got in my syslog:

*** warning [client.c(183)]: Failed gpm connect attempt by uid 500 for vc 0

I ran MC under debugger in linux console both with screen and in plain 
console. When I am not running screen everything is normal. If I start 
screen I get the above message both in syslog and printed on the console 
... but the Gpm_Open() call doesn't report error. I'll try to research why
this happens but it is obvious that this problem is not MC related.

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


Re: Mouse support bugs and a couple of feature requests (fwd)

2006-09-04 Thread Pavel Tsekov
Stephan, please, keep the discussion on the mailing list.

I am forwarding your messages there.

-- Forwarded message --
Date: Mon, 4 Sep 2006 05:10:12 -0400
From: Stephan Sokolow [EMAIL PROTECTED]
To: Pavel Tsekov [EMAIL PROTECTED]
Subject: Re: Mouse support bugs and a couple of feature requests

On Monday September 4, 2006 04:41, you wrote:
 On Sat, 2 Sep 2006, Stephan Sokolow wrote:
 3. The -x option prevents gpm from working at the console.

 Why would you do that ?

Because -x is the only way to get mouse support working inside my
Yakuake--bash--screen--mc stack for some reason. My more important
complaint is that I can't get console mouse support when running MC inside
screen and yet every other GPM-supporting app works fine.


 As for the feature requests:
 1. could you please add an option to start with MC hidden (equivalent to
 starting normally and then pressing Ctrl+o) so I can stick it at the end
 of my .bashrc comfortably?

 But then you would end up in another shell - the one started by MC and not
 in your login shell. Do you really want that ?

My system already triggers a bash -- screen -- bash stack on login because
I've been too busy to solve my screen won't work as a login shell problem.

I just want an easy way to automate the start MC hidden part of a bash --
screen - mc -- bash stack.

If I can find the time to fix screen, I'll prune it down to screen -- mc --
bash.

-- 
deitarion/SSokolow
Stephan Sokolow
SSokolow.com Webmaster

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


Re: Mouse support bugs and a couple of feature requests (fwd)

2006-09-04 Thread Pavel Tsekov
On Mon, 4 Sep 2006, Pavel Tsekov wrote:

 -- Forwarded message --
 Date: Mon, 4 Sep 2006 06:03:52 -0400
 From: Stephan Sokolow
 To: Pavel Tsekov
 Subject: Re: Mouse support bugs and a couple of feature requests

 On Monday September 4, 2006 05:15, you wrote:
 On Sat, 2 Sep 2006, Stephan Sokolow wrote:
 First, the bug:
 1. Running mc inside screen at the Linux console prevents gpm mouse
 support from working.

 Seems to be a gpm problem. See what I've got in my syslog:

 *** warning [client.c(183)]: Failed gpm connect attempt by uid 500 for vc 0

 I ran MC under debugger in linux console both with screen and in plain
 console. When I am not running screen everything is normal. If I start
 screen I get the above message both in syslog and printed on the console
 ... but the Gpm_Open() call doesn't report error. I'll try to research why
 this happens but it is obvious that this problem is not MC related.

Screen uses a pseudo-terminal pair to communicate with the shells it 
starts. As such when you start MC it is running on the pseudo terminal
slave device - /dev/pts/1 for example. It is screen that is running on
the virtual console device (the real terminal) and not MC. gpm cannot
handle mouse events on anything other than Linux virtual console. So
requests from MC for mouse events on /dev/pts/1 should fail ... but
there is a patch in the RedHat version of gpm that removes a check which
is supposed to catch that condition. I guess you are using Fedora, right ?
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [PATCH] bad highlighting of Requires in spec

2006-09-04 Thread Pavel Tsekov
On Mon, 4 Sep 2006, Jindrich Novy wrote:

 2006-09-04  Jindrich Novy  jnovy at redhat dot com

* spec.syntax: Highlight Requires(phase): correctly.

The patch does more than that. I guess that if I commit that someone
would start complaining about it... So, I will for two more days
and commit after that.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: Mouse support bugs and a couple of feature requests (fwd)

2006-09-04 Thread Pavel Tsekov
 -- Forwarded message --
 Date: Mon, 4 Sep 2006 05:10:12 -0400
 From: Stephan Sokolow [EMAIL PROTECTED]
 To: Pavel Tsekov [EMAIL PROTECTED]
 Subject: Re: Mouse support bugs and a couple of feature requests

 On Monday September 4, 2006 04:41, you wrote:
 On Sat, 2 Sep 2006, Stephan Sokolow wrote:
 3. The -x option prevents gpm from working at the console.

 Why would you do that ?

 Because -x is the only way to get mouse support working inside my
 Yakuake--bash--screen--mc stack for some reason. My more important
 complaint is that I can't get console mouse support when running MC inside
 screen and yet every other GPM-supporting app works fine.

Wait, wait... I am confused now. What do you mean by console ? The linux
console (virtual console) or a terminal emulator in general ?

Basically, the '-x' option should be used when you know that your terminal 
emulator is xterm-like but it doesn't set the TERM variable to xterm 
i.e. as a hint to MC that it should expect xterm features. One of these
features is the xterm mouse reporting - it has nothing to do with gpm. 
xterm like terminals (when instructed to do so) generate special escape
sequences which indicate that a mouse event occured. MC reads these 
sequences (via its standard input stream) and interprets them when it 
thinks that it is runnning under xterm-like terminal emulator. This is 
different from gpm mouse event reporting - in this case MC must be linked 
to the gpm client library to read mouse events. gpm mouse reporting as
used by MC is useful only when running MC on the linux virtual console 
(linux console).

I've tried to run MC under yakuake and the mouse works as expected.
If it doesn't work for you it is most likely because the TERM variable
is set to something different from xterm. This is why you have to
pass the -x option to MC.

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


Re: patch for viewing DjVu files

2006-09-07 Thread Pavel Tsekov
On Thu, 7 Sep 2006, Nerijus Baliunas wrote:

 Anyone? It's really a simple patch, and Changelog is not really needed,
 but if you want it:

 2006-09-07  Nerijus Baliunas  [EMAIL PROTECTED]

* mc.ext.in: Add support for .djvu files.


I am just not sure what is the current policy for adding
entries to mc.ext.in. Otherwise its fine with me.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: Current CVS compile fails on Darwin with error in mountlist.c

2006-09-07 Thread Pavel Tsekov
On Thu, 24 Aug 2006, Frank Joerdens wrote:

 On 8/23/06, Pavel Tsekov [EMAIL PROTECTED] wrote:
 []
 Comment the line containing MOUNTED_GETMNTINFO_STATVFS in
 your config.h file. I have to fix this but have been quite
 busy in the last few weeks.

 Cool, it works. Thanks!

With the current CVS version everything should work
just fine. Please, test.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: patch for viewing DjVu files

2006-09-08 Thread Pavel Tsekov
On Thu, 7 Sep 2006, Nerijus Baliunas wrote:

 On Thu, 7 Sep 2006 19:46:39 +0400 (MSD) [EMAIL PROTECTED] wrote:

 I use kdvi for djvu, it more handy then djview:

 Open=if [ $DESKTOP_SESSION = kde ]; then (nohup kdvi %f ); else (nohup 
 djview %f ); fi

 No problem about using kdvi with me, but why nohup? No entry in
 mc.ext.in currently has it.

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


[bug #17220] mc -a (stickchars) is gone

2006-09-12 Thread Pavel Tsekov

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

Ping!

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17220

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

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


Re: Mouse support bugs and a couple of feature requests

2006-09-12 Thread Pavel Tsekov
On Mon, 11 Sep 2006, Morten Bo Johansen wrote:

 Stephan Sokolow [EMAIL PROTECTED] wrote:

 2. Running mc inside screen inside Konsole (or Yakuake) prevents mouse
 support unless explicitly run with the -x option.

 You will notice that If you have your $TERM set to something like
 screen(.*) then mouse actions do not work, this goes not only for mc, but
 for any other app (in my experience). However, if you set it to
 xterm(.*), then it works.

 I do not know if the reason for this is in screen, the terminal or the
 applications, but it is a little annoying.

MC recognizes only a couple of terminals as capable of xterm mouse 
reporting. It reads the value of the TERM  variable and compares
it a against a fixed list of strings - i.e. xterm, Eterm, etc.
An alternative approach would be to to make this list user
configurable as suggested here:

   https://savannah.gnu.org/bugs/?16910
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


[bug #17269] localized headers in .mc/history

2006-09-13 Thread Pavel Tsekov

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

I looked at that problem and the solution is pretty easy. Still I'd like to
discuss the issue with anyone interested so we can find the best way to solve
the problem.

Most of the problematic entries are created by an invocation of the function
nice_cd() located in src/cmd.c . Its first argument is a string to be used as
the heading of the dialog. The same string is also used to form the name of
the section in the history file where entries fed to the input field of the
dialog will be stored. A typical call to nice_cd() looks like this:

  nice_cd (_(Title string), ...)

So as you can see nice_cd() is passed a translated string - this is why a
translated section name is written to the history file. However this is
unnecessary since later the title string is translated one more time when
quick_dialog() is invoked to show the dialog. So, one way to solve the
problem is to change nice_cd() invocations like this:

  nice_cd (N_(Title string), ...)

However, this may not be the best solution since the programmer must know
that it should call nice_cd () with N_() instead of _(). So, maybe a better
way to solve the problem would be to add
a new argument to nice_cd() which will hold the history section name.

Any thoughts ?


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17269

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

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


[bug #17269] localized headers in .mc/history

2006-09-13 Thread Pavel Tsekov

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

My last comment may be slightly misleading. To clarify:

  nice_cd() and others use fg_input_dialog_help() which takes
  care of displaying the input dialog and derives history file
  section names from the input dialog heading.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17269

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

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


[bug #17269] localized headers in .mc/history

2006-09-13 Thread Pavel Tsekov

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

I think I'll proceed as following:


1) Currently fg_input_dialog_help() assumes that it is passed translated
strings. I won't change that because some of the callers pass as an argument
a string which is the result of sprintf() on translated template string.
However, I'll change
fg_input_dialog_help() to prevent the translation of the already translated
strings. Additionally I'll add comments to indicate that
fg_input_dialog_help() and any wrappers must take translated strings.

2) Next I'll change fg_input_dialog_help() to take a new argument
- the history section name. Then I will adjust all callers.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17269

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

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


[bug #17568] Cannot compile mc-2006-08-29

2006-09-18 Thread Pavel Tsekov

Update of bug #17568 (project mc):

  Status:None = Fixed  
 Open/Closed:Open = Closed 

___

Follow-up Comment #3:

I am closing as FIXED. Still if you see build failures feel free to reopen.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17568

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

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


[bug #17269] localized headers in .mc/history

2006-09-19 Thread Pavel Tsekov

Follow-up Comment #7, bug #17269 (project mc):

I am attaching a patch which adds a new argument to fg_input_dialog_help() -
the history section name. I've adjusted all callers (hopefully) to pass the
new argument. Please, test the patch. The patch should be applied against
latest CVS.

This patch doesn't attemt to change the section names. However, the current
choice for section names is really bad, IMHO. Maybe now is the time to rename
those names for good. I'd like to hear your opinion on that matter too.

___

Additional Item Attachment:

File name: history-section-names.patchSize:17 KB

http://savannah.gnu.org/bugs/download.php?file_id=10799

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17269

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

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


[bug #17823] hint changed when the window is resized

2006-09-22 Thread Pavel Tsekov

Update of bug #17823 (project mc):

  Status:None = Confirmed  
 Assigned to:None = ptsekov
Operating System:   GNU/Linux = All

___

Follow-up Comment #1:

I can confirm this. It seems this is the result of a set of patches, aiming
to fix a bug in the hintbar code, applied back in December 2002 and February
2003... I have an idea how to fix it but I want to do my homework so that I
won't introduce a new bug fixing that one.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17823

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

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


[bug #17874] Crashing inside liblow.c

2006-09-29 Thread Pavel Tsekov

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

The crash that you see has nothing to do with MC. The backtraces do not
provide any evidence to support your theory. It must be an gpm issue. 

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17874

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

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


[bug #17967] Little bugs in FC utf-8 patches

2006-10-11 Thread Pavel Tsekov

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

As you correctly noted this bug report belongs to the Redhat bugzilla. The
UTF-8 patches applied to MC are common between
all distros which use them.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17967

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

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


Removing rxvt.c ?

2006-10-17 Thread Pavel Tsekov
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).

Any thoughts ?

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


[bug #17220] mc -a (stickchars) is gone

2006-10-17 Thread Pavel Tsekov

Update of bug #17220 (project mc):

Category:None = Screen output  

___

Follow-up Comment #4:

Hmmm. It happens only with UTF-8 locales and UTF-8 capable terminals. I guess
it has something to do with UTF-8 version of MC (not supported here) or maybe
the RedHat supplied S-Lang library or the terminal emulator itself. Anyway, I
think filing this bug report against FC bugzilla would be more appropriate.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17220

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

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


Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.

2006-10-30 Thread Pavel Tsekov
Hello,

On Sun, 29 Oct 2006, Leonard den Ottolander wrote:

 Hi Christian,

 On Sat, 2006-10-28 at 23:48 +0200, Christian Hamar alias krix wrote:
 Attached patch implements this. This is not a proposition for a final
 solution, just a temporary hack for users of bash = 3.2.

 Do not use with versions of bash = 2.05b!

 Thx for the patch. It works with 3.2 (tested)

 If you can ride with BASH_VERSINFO then maybe this can be go to CVS.

 I suppose I will work with the BASH_VERSINFO environment variable. As
 you told me privately it was introduced in bash-2.0, so I suppose I will
 assume version  2 if the environment variable is not set.

IMO, if you intend to work on a fix you should follow the
suggestion of the bash maintainer to switch over to using
printf - not only for bash but for all cases.  Of course
a fallback may be required. After all according to bash
maintainer:

   Use of `echo' in portable applications has been deprecated for years.

See: http://www.mail-archive.com/bug-bash@gnu.org/msg02150.html

I guess the bash maintainer can give you insight on how to properly
detect the bash version (if at all necessary).
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [bug #18042] cannot specify port number in shell link

2006-11-01 Thread Pavel Tsekov
On Wed, 1 Nov 2006, Leonard den Ottolander wrote:

 Hello Andrew,

 On Mon, 2006-10-30 at 12:04 +, Andrew V. Samoilov wrote:
 Follow-up Comment #3, bug #18042 (project mc):

 Do I understand correctly that a port number *can* be combined with C _or_
 r?

 No. Look at utilvfs.c:vfs_split_url().
 No one syntax change. Only undocumented behaviour changed.
 It is possible to use /#sh:[EMAIL PROTECTED]:6789 right now.

 Maybe we should introduce a syntax change, because at least the
 combination of a port number and C are very welcome.

 What about a solution whereby the user can add any of these options, in
 any particular order, all separated by colons? Would that be a lot of
 work to implement?

 And fish uses port1 as 'C' option and port2 as 'r'.

 Possible solution is to use 0x11 and 0x12 instead of 1 and 2.

 That would probably get rid of the need for an extra parameter to
 separate the port number from other options.

The port clearly belongs to the url, as do the hostname, the username, the
password and the location. Options are hardly candidates to become part of 
the url. IMO, it would be better if MC pops up an url specific dialog for
each vfs if necessary so that the user could finer tune the connection. I 
think this would also help to add support for per connection settings i.e.
use passive ftp for one connection and active for another. Instead of 
simple hacks we'd better go with well designed features.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.

2006-11-01 Thread Pavel Tsekov
On Tue, 31 Oct 2006, Leonard den Ottolander wrote:

 On Mon, 2006-10-30 at 11:45 +0200, Pavel Tsekov wrote:
 IMO, if you intend to work on a fix you should follow the
 suggestion of the bash maintainer to switch over to using
 printf - not only for bash but for all cases.  Of course
 a fallback may be required. After all according to bash
 maintainer:

Use of `echo' in portable applications has been deprecated for years.

 See: http://www.mail-archive.com/bug-bash@gnu.org/msg02150.html

 Yes, I read that comment. However I'm not prepared to start breaking the
 functionality of shells that I never use.

This is a rather strange statement. As a developer you should try to
go beyond your personal preferences. Changes to the subshell shall be
tested with all supported shells and on as many platforms as possible.
From Chet Ramey's statement it is clear that using printf is the right
thing to do.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.

2006-11-01 Thread Pavel Tsekov
On Wed, 1 Nov 2006, Thomas Dickey wrote:

 On Wed, 1 Nov 2006, Pavel Tsekov wrote:

 Yes, I read that comment. However I'm not prepared to start breaking the
 functionality of shells that I never use.
 
 This is a rather strange statement. As a developer you should try to
 go beyond your personal preferences. Changes to the subshell shall be
 tested with all supported shells and on as many platforms as possible.
 From Chet Ramey's statement it is clear that using printf is the right
 thing to do.

 That's his statement.  Jim Meyering's comment is more reasonable.

His comment is related to coreutils and not bash. Anyway, he still
agrees that printf should be used. If this is the way to go why
shall we wait ?
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.

2006-11-01 Thread Pavel Tsekov
On Wed, 1 Nov 2006, Thomas Dickey wrote:

 On Wed, 1 Nov 2006, Pavel Tsekov wrote:

 On Wed, 1 Nov 2006, Thomas Dickey wrote:
 
 On Wed, 1 Nov 2006, Pavel Tsekov wrote:
 
 Yes, I read that comment. However I'm not prepared to start breaking the
 functionality of shells that I never use.
 
 This is a rather strange statement. As a developer you should try to
 go beyond your personal preferences. Changes to the subshell shall be
 tested with all supported shells and on as many platforms as possible.
 From Chet Ramey's statement it is clear that using printf is the right
 thing to do.
 
 That's his statement.  Jim Meyering's comment is more reasonable.
 
 His comment is related to coreutils and not bash. Anyway, he still
 agrees that printf should be used. If this is the way to go why
 shall we wait ?

 He's recommending it for new scripts, not recommending that one rewrite 
 existing scripts (and by noting that other shells retain the existing 
 treatment, is pointing out a problem).

Ok. Since I am not native english speaker I cannot judge whether
he is recommending it or not. In any case I can see why keeping
the old behaviour of 'echo' is important for large scripts, however
what we have in MC is nothing as big. I just feel that what Leonard
is proposing is a hack and not an actual solution.

 Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in 
 existing scripts to bother with 3.2.x).

Does this mean that you think that bash 3.3 will reinstantiate the old 
behaviour ?
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.

2006-11-01 Thread Pavel Tsekov
On Wed, 1 Nov 2006, Thomas Dickey wrote:

 On Wed, 1 Nov 2006, Pavel Tsekov wrote:

 Ok. Since I am not native english speaker I cannot judge whether
 he is recommending it or not. In any case I can see why keeping
 the old behaviour of 'echo' is important for large scripts, however
 what we have in MC is nothing as big. I just feel that what Leonard
 is proposing is a hack and not an actual solution.
 
 Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in 
 existing scripts to bother with 3.2.x).
 
 Does this mean that you think that bash 3.3 will reinstantiate the old 
 behaviour ?

 Not for this (echo -e is a dead issue, though some of the discussion there 
 touches on other problems). But it would be reasonable to expect it to fix 
 the syntax errors.  Before rushing off to change things to accommodate bash 
 3.2, it's worth checking if the fix will work with other shells.

The fix which Leonard proposes would not affect the other supported
shells. Look at subshell_name_quote() in subshell.c. I am beginning
to wonther whether do we really want to escape the characters
using echo or printf.

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


Re: [bug #18042] cannot specify port number in shell link

2006-11-01 Thread Pavel Tsekov
On Wed, 1 Nov 2006, Leonard den Ottolander wrote:

 On Wed, 2006-11-01 at 13:20 +0200, Pavel Tsekov wrote:
 IMO, it would be better if MC pops up an url specific dialog for
 each vfs if necessary so that the user could finer tune the connection. I
 think this would also help to add support for per connection settings i.e.
 use passive ftp for one connection and active for another. Instead of
 simple hacks we'd better go with well designed features.

 Agreed.

 But as Andrew also pointed out manpower is limited, so sadly we will
 sometimes have to use hacks if nobody is volunteering to invest time in
 the proper solution. They are not optimal, but in some cases better than
 not fixing breakage at all.

This is not a task which requires tremendous efforts. It is just a matter
of defining what we want to do and how we want to do it. And in the 
meantime there is an easy workaround - just set the port in ~/.ssh/config.

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


Re: find in viewer

2006-11-01 Thread Pavel Tsekov
On Thu, 2 Nov 2006, Nerijus Baliunas wrote:

 Hello,

 could this patch please be committed to cvs (I am attaching it for your 
 convenience)?
 BTW, how this patch works when two mc are running? If I search in 1st mc,
 then in 2nd mc, and then again in 1st mc, what will I get - last text from
 1st or 2nd? I'd prefer from 1st, i.e. different mc sessions to be independent.

This patch is not as good. Something else should be used. Reverting the 
original code that broke this feature might be better option for now. I'll 
try to do something about it till the weekend.

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


Re: [PATCH] mc crashes when temporary directory cannot be created

2006-11-27 Thread Pavel Tsekov
Hello Jindrich,

On Mon, 27 Nov 2006, Jindrich Novy wrote:

 there is a breakage in util.c and utilunix.c related to temporary files
 creation. The problem is that if a directory for temporary files cannot
 be created mc ends up in infinite loop caused by:

 tmpbase = concat_dir_and_file (mc_tmpdir (), prefix);

 in mc_mkstemps() which then calls mc_tmpdir() back infinitely and ends
 up in a stack underflow.

 The attached patch fixes it as it disables the creation of the temporary
 files when the temp. directory couldn't be created.

Ok. But... what happens if any of the following
error conditions occur ?

 if (lstat (buffer, st) == 0) {
 /* Sanity check for existing directory */
 if (!S_ISDIR (st.st_mode))
 error = _(%s is not a directory\n);
 else if (st.st_uid != getuid ())
 error = _(Directory %s is not owned by you\n);
 else if (((st.st_mode  0777) != 0700)
   (chmod (buffer, 0700) != 0))
 error = _(Cannot set correct permissions for directory 
%s\n);
 } else {

Wouldn't it cause the same loop as when mkdir() fails ?
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key

2006-11-30 Thread Pavel Tsekov
Hello Grigory,

On Wed, 29 Nov 2006, Grigory Trenin wrote:

 Here is a detailed description how to reproduce it:

 1) Open the Help Contents (press F1, Tab, Enter)
 2) Navigate some lines forward (press End or PageDown several times)
 3) Enter the selected topic (press Enter)
 4) Return back (press right arrow)
 5) Move to the top of Contents (press Home)
 6) Now try navigating the Contents using the up and down arrow keys.
 (for example, press down arrow for 5 times, then press up arrow).
 You will notice that when you press up arrow key the selection
 jumps to the top of window.

I can confirm the problem.

 The problem is in the help_handle_key() function:
 case KEY_UP:
 case ALT ('\t'):
 /* select previous link */
 new_item = select_prev_link (startpoint, selected_item);

 The 'startpoint' variable should be a pointer to the first byte
 displayed in the Help window. But here it has a wrong value - that's
 the problem. That's why select_prev_link() cannot find the link and
 returns NULL, and the selection moves to the first link in the window.

 I tried to find out what's wrong with the 'startpoint' variable.
 I came to the conclusion that 'startpoint' is used here erroneously
 instead of 'currentpoint' variable.

I am not convinced of that yet - see below. It's more likely
that the navigation code messes the value of 'startpoint'.

 'currentpoint' always contains a pointer to the first byte displayed,
 and it should be used here. And by the way, 'startpoint' variable
 seems to be totally useless.

This is not true - 'currentpoint' points to the first byte of
the currently disaplyed help contents, while 'startpoint'
points to the start of the current link/topic. 'startpoint'
gets messed after one returns back from following a link.


 So in my patch I replaced 'startpoint' with 'currentpoint' and
 removed the 'startpoint' variable completely.

I won't apply this patch yet. I want to investigate further.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [PATCH] mc crashes when temporary directory cannot be created

2006-11-30 Thread Pavel Tsekov


On Wed, 29 Nov 2006, Leonard den Ottolander wrote:

 Hello Jindrich,

 On Tue, 2006-11-28 at 13:21 +0100, Jindrich Novy wrote:
 IMO only removal of the fallback will prevent
 the infinite loop in any case as it shouldn't call mc_mkstemps() at all.

 That cure seems worse than the disease. Isn't the real problem the fact
 that mc_mkstemps() blindly concats tmpdir to the prefix instead of
 testing if mc_tmpdir() succeeded? Why not abort mc_mkstemps() if
 mc_tmpdir() returns /dev/null/?

 What about the attached (untested) patch?

 By the way, could you please add the -p option to your diffs?

There is an even simpler cure. In mc_tmpdir() when executing
the fallback code pass an absolute path to mc_mkstemps().
This will prevent the loop. However I am not yet conviced
that this is the best solution. I am still investigating.

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


Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key

2006-12-04 Thread Pavel Tsekov
Hello Grigory,

On Fri, 1 Dec 2006, Grigory Trenin wrote:

 Pavel Tsekov wrote:

 I won't apply this patch yet. I want to investigate further.

 Oh, now I see that I had hurried over to make that patch.
 I'll check everything and make another one. Without haste.

The problem is that the structure which stores the
history of the links followed stores only the
pointer to the start of the node and doesn't store
a pointer to the start of the currently displayed
area of a node. When following a link MC does this:

 history_ptr = (history_ptr+1) % HISTORY_SIZE;
 history [history_ptr].page = currentpoint;
 history [history_ptr].link = selected_item;
 currentpoint = startpoint = help_follow_link (...);

The start of the node in the history is erronously set
to 'currentpoint'. Then when going back to the previous
node via the left key the following code is executed via
prev_node_cmd():

 currentpoint = startpoint = history [history_ptr].page;
 selected_item = history [history_ptr].link;

This leads to incorrectly setting 'startpoint' to
the previously recorded value of 'currentpoint' which
is wrong.

I think the correct solution would be to keep both
'startpoint' and 'currentpoint' in the history but I am
open to suggestions.


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


Re: find in viewer

2006-12-08 Thread Pavel Tsekov
Hello,

On Fri, 8 Dec 2006, Nerijus Baliunas wrote:

 On Thu, 2 Nov 2006 09:51:58 +0200 (EET) Pavel Tsekov [EMAIL PROTECTED] 
 wrote:

 could this patch please be committed to cvs (I am attaching it for your 
 convenience)?
 BTW, how this patch works when two mc are running? If I search in 1st mc,
 then in 2nd mc, and then again in 1st mc, what will I get - last text from
 1st or 2nd? I'd prefer from 1st, i.e. different mc sessions to be 
 independent.

 This patch is not as good. Something else should be used. Reverting the
 original code that broke this feature might be better option for now. I'll
 try to do something about it till the weekend.

 Can this code please be reverted?

 On Thu, 18 May 2006 17:42:45 +0300 (EEST) Pavel Tsekov [EMAIL PROTECTED] 
 wrote:

 The following  commit broke it:

 http://cvs.savannah.gnu.org/viewcvs/mc/mc/src/view.c?sortby=dater2=1.336r1=1.335diff_format=u

 That change was done by rillig. Roland, could you please do it?
 The original problem description:
 Find in viewer does not remember its last search string:
 F3, F7, enter some text, Enter, F10. F3, F7 - search string
 field is empty. It used to remember earlier, and it doesn't
 happen with editor (editor remembers search string).

I have a patch for this but I am a bit busy right now -
moved to a new job. So if you wait a bit...

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


[bug #18476] Slow data transfer with FISH

2006-12-11 Thread Pavel Tsekov

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

Andrei, please, use the savannah bug reporting feature to comment on this
issue.

=
On Monday 11 December 2006 00:22, you wrote:
 Follow-up Comment #1, bug #18476 (project mc):

 Can you provide the output of 'mc -V' ? Did you compile MC from sources or
 you installed a binary package ? If you compiled it yourself where did you
 get the source from ?

I installed from FreeBSD ports.

GNU Midnight Commander 4.6.1
Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, smbfs
With builtin Editor
Using included S-Lang library with termcap database
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18476

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

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


[bug #18476] Slow data transfer with FISH

2006-12-11 Thread Pavel Tsekov

Update of bug #18476 (project mc):

  Status:None = Fixed  
 Open/Closed:Open = Closed 

___

Follow-up Comment #3:

The FreeBSD binary package is based on the original MC 4.6.1 tarball, which
is quite old now, and some patches. The slow ssh transfer issue which you
reported is fixed in CVS using a patch from Dmitry Butskoy. You can read the
following discussion to find out more:

  http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186456

So either point the FreeBSD mc maintainer to this discussion, so that he/she
can add the patch to the set of patches applied to the FreeBSD package or
built MC yourself from CVS or a snapshot tarball. You can get the latest
snapshot tarball from
http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18476

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

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


Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key

2006-12-12 Thread Pavel Tsekov
Hello Grigory,

On Mon, 11 Dec 2006, Grigory Trenin wrote:

 Pavel Tsekov wrote:

 I am not convinced that this patch is better than your first
 one. Its basically the same and removes a valid check - it
 doesn't fix the issue.

 It does fix the _original_ issue. And that one you are talking about
 is quite a different thing (see below).
 It isn't related to the original issue.
 Anyway, saving/restoring 'startpoint' in history won't fix it either.

 Try the following:

 COLS = 126
 LINES = 60

 1) F1 (Help)

 2) Select contents and hit Enter

 3) Press Page Down

You should end up on Executing operating systems commands

 4) Press Up

 You should notice that the marker doesn't select the
 previous link as it should.

 Why do you expect it?

My mistake. Sorry. I'll review the patch more carefully.
You are not annoying me - I just want to make sure that
a given fix doesn't introduce new issues. In this case
I was fooled.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: mc, ftp and filmview

2006-12-14 Thread Pavel Tsekov
BHello,

On Thu, 14 Dec 2006, Admiral wrote:

 Halo, I am from belarus, i know English not so good. My problem in Russian
 language here: http://linuxforum.ru/index.php?showtopic=30151
 Now, I try to write in English. In our local homenet we have ftp-server. There
 are many video-files in it. When I write mplayer
 ftp://ftp.server.local/films/verygoodfilm.avi; it start to play film
 immediately. But when I connect to ftp from mc and twice press to left button
 of mouse, mc previously download film completely, and then starts mplayer for
 playing movie. This is very bad, because films have big sizes and they are
 downloads very long time. How can I change it?

You cannot. This is by design. If you want to stream the movies
just use mplayer passing it the url.

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


Re: mc, ftp and filmview (fwd)

2006-12-15 Thread Pavel Tsekov

Hello,

Please, keep the discussion on the list.

Unfortunately, there is no such shortcut.

-- Forwarded message --
Date: Fri, 15 Dec 2006 08:08:00 +0200
From: Admiral [EMAIL PROTECTED]
To: Pavel Tsekov [EMAIL PROTECTED]
Subject: Re: mc, ftp and filmview

? ? ?? 14 ??? 2006 15:53 ?? :

BHello,

On Thu, 14 Dec 2006, Admiral wrote:

Halo, I am from belarus, i know English not so good. My problem in
Russian language here: http://linuxforum.ru/index.php?showtopic=30151
Now, I try to write in English. In our local homenet we have ftp-server.
There are many video-files in it. When I write mplayer
ftp://ftp.server.local/films/verygoodfilm.avi; it start to play film
immediately. But when I connect to ftp from mc and twice press to left
button of mouse, mc previously download film completely, and then starts
mplayer for playing movie. This is very bad, because films have big sizes
and they are downloads very long time. How can I change it?


You cannot. This is by design. If you want to stream the movies
just use mplayer passing it the url.

OK, but can you tell me a hotkey in mc to copy a full address of file in
command line?___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: mc, ftp and filmview (fwd)

2006-12-15 Thread Pavel Tsekov
Hello Grigory,

On Fri, 15 Dec 2006, Grigory Trenin wrote:

 OK, but can you tell me a hotkey in mc to copy a full address of file in
 command line?

 Try Ctrl+Shift+Enter.
 It may not work on some terminals, but it works for me.
 It will copy the full pathname to the command line, eg:
 /#ftp:ftp.server.local/films/verygoodfilm.avi

 However, you have to edit it a bit (replace /#ftp to ftp://)
 so that mplayer could understant it.

Unfortunately, this may not always help since the path
printed here may not be the real path or it may be
unaccessible due to specific ftp server setup.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [PATCH] Prevent jumping beyond file end in the viewer

2006-12-20 Thread Pavel Tsekov
Hello Andrzej,

On Wed, 20 Dec 2006, andrzej zaborowski wrote:

 in the hex viewer the GoTo (F5) command allows you to jump beyond
 end of file and even to view or edit data there. This is because the
 address given by user is not checked for correctness anywhere.
 Eventually, in src/view.c:view_file_load_data, the address is passed
 to lseek() whose return value is checked, but it turns out lseek'ing
 beyond end of file is legal and not an error. This immediately results
 in Bad Things (tm) like at the return from view_file_load_data the
 ds_file_datalen is actually negative. Attached diff fixes this.

Thanks for your bugreport! I won't apply your patch though but
a slightly modified one. I won't the viewer to display a warning
box, reading something like Invalid offset or something, instead
of just doing nothing. I'll let you know when I commit the patch.

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


Re: [PATCH] corrupted free inodes list

2006-12-20 Thread Pavel Tsekov
Hello Mikulas,

On Wed, 20 Dec 2006, Mikulas Patocka wrote:

 I've found on three machines (I wonder that no one noticed it so far) that mc 
 displays incorrect information on inode count, for example:

Which version of MC are you using ?

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


Re: [PATCH] corrupted free inodes list

2006-12-20 Thread Pavel Tsekov
On Wed, 20 Dec 2006, Pavel Tsekov wrote:

 Hello Mikulas,

 On Wed, 20 Dec 2006, Mikulas Patocka wrote:

 I've found on three machines (I wonder that no one noticed it so far) that mc
 displays incorrect information on inode count, for example:

 Which version of MC are you using ?

Please, ignore the last message.

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


Re: [PATCH] corrupted free inodes list

2006-12-21 Thread Pavel Tsekov
Hello Mikulas,

On Wed, 20 Dec 2006, Mikulas Patocka wrote:

 Hello Mikulas,

 On Wed, 20 Dec 2006, Mikulas Patocka wrote:

 I've found on three machines (I wonder that no one noticed it so far) that
 mc displays incorrect information on inode count, for example:

 Which version of MC are you using ?

 Stock 4.6.1 --- but I looked to CVS at
 http://cvs.savannah.gnu.org/viewcvs/mc/mc/ and it has int values in
 struct my_statfs too.

Yes. I'll deal with that issue and let you know when I am
ready.

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


Re: [PATCH] corrupted free inodes list

2006-12-23 Thread Pavel Tsekov
On Fri, 22 Dec 2006, Thomas Dickey wrote:

 On Fri, 22 Dec 2006, Leonard den Ottolander wrote:

 Hi Mikulas,

 On Wed, 2006-12-20 at 02:15 +0100, Mikulas Patocka wrote:
 --- maybe you could change double to long long but I'm not sure if it
 exists on all machines --- a configure test would probably be needed.

 Yes. Using floats for discrete counters is not such a good idea.

 It's likely to be slower, but if you don't exceed the precision of the
 mantissa, you won't lose information.

 The general reader, taking into account the comment about discrete is
 likely to assume that you meant information would be lost.  Since that's
 not the case (for the assumed 48 bits), it's worth clarifying the comment.

I am working to get this fixed. I plan to use code from
coreutils's df to calculate the percent. I also resurrected
the files fsusage.[ch] where originally the get_fs_usage()
function resided. fsusage.[ch] come from gnulib/coreutils/filutils
and its maintainers had switched to uintmax_t to collect
the disk usage statistic for a long time now. I'll let you
know when I am done. If someone is willing to help take a
look at show_dev() in coreutils's source code. I am also
wondering whether we won't to import human.[ch] from gnulib.
IMO, it makes sense, but still this code does bit more than
what we need but maybe in the long term its worth to rely
on a known good and supported code instead of a homebrew
solution.

Please, let me know what do you think.

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


Re: Midnight commander patches

2006-12-26 Thread Pavel Tsekov
Hello Sergey,

000-mc-4.6.1-fers.patch - MC already offers a
find Recursively checkbox in the Find File
dialog

001-mc-4.6.1-fh.patch - This patch (or variation
of it) has been posted to the list several times.
You might want to search the mailing list archives
as to why it has been rejected.

003-mc-4.6.1-svp.patch - The viewer already
supports saving the file position. You can
enable it by setting mcview_remember_file_position
to 1.

I'll take a look at the clock patch and the
Find first entry patch.

Thanks!

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


Re: Menu and extension file items

2006-12-27 Thread Pavel Tsekov

On Tue, 26 Dec 2006, Ruslan Fedyarov wrote:

 Hi dear MC developers,

 Thank you for your lightning fast wonderful program!

 I have a proposal to add the following stuff to standard menus:

I think you should add those to .mc.menu or ~/.mc/mc.menu. Different
users have different preferences that's why the user menu is user
configurable trough the files above.

 I'd also appreciate having simple automount like in Krusader. It looks
 in /etc/fstab for directory queried and mounts one that match. Automount
 daemon works poor on my system.

I don't know whether this is useful or not - I'll let others
comment.

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


Re: Midnight commander patches

2006-12-27 Thread Pavel Tsekov
Hello Sergey,

On Tue, 26 Dec 2006, Pavel Tsekov wrote:

 000-mc-4.6.1-fers.patch - MC already offers a
 find Recursively checkbox in the Find File
 dialog

According to the patch description this patch does
the following:

[...]
Add checkboxes Find first entry and
Recursive search in MC find dialog
[...]

First of all the text Find first entry is misleading.
At first I thought that the idea was that it will match
the first file given a pattern and will stop. When I
looked at the patch I saw that what you meant is that
turning on this option will stop the scan of the file
contents once a match is found. I hope someone from
the other developers on this list will help with naming
this option properly. Next, I noticed that with your
patch the scan will not really stop after a match is
found - the code will keep reading the file till his end.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [PATCH] Prevent jumping beyond file end in the viewer

2006-12-30 Thread Pavel Tsekov
Hello Andrzej,

On Wed, 2006-12-20 at 13:50, Pavel Tsekov wrote:

 On Wed, 20 Dec 2006, andrzej zaborowski wrote:
 
  in the hex viewer the GoTo (F5) command allows you to jump beyond
  end of file and even to view or edit data there. This is because the
  address given by user is not checked for correctness anywhere.
  Eventually, in src/view.c:view_file_load_data, the address is passed
  to lseek() whose return value is checked, but it turns out lseek'ing
  beyond end of file is legal and not an error. This immediately results
  in Bad Things (tm) like at the return from view_file_load_data the
  ds_file_datalen is actually negative. Attached diff fixes this.
 
 Thanks for your bugreport! I won't apply your patch though but
 a slightly modified one. I won't the viewer to display a warning
 box, reading something like Invalid offset or something, instead
 of just doing nothing. I'll let you know when I commit the patch.

I've commited a slightly modified version of your patch -
view_file_load_data() doesn't trash the buffer contents if
an invalid offset is specified. I think it's better this
way but it might changed in the future. I also added a 
dialog box to display a warning message if an invalid offset
was specified.

Thanks!


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


Re: [PATCH] mc crashes when temporary directory cannot be created

2006-12-30 Thread Pavel Tsekov
Hello Jindrich,

On Thu, 2006-11-30 at 20:04, Pavel Tsekov wrote:
 On Wed, 29 Nov 2006, Leonard den Ottolander wrote:
 
  Hello Jindrich,
 
  On Tue, 2006-11-28 at 13:21 +0100, Jindrich Novy wrote:
  IMO only removal of the fallback will prevent
  the infinite loop in any case as it shouldn't call mc_mkstemps() at all.
 
  That cure seems worse than the disease. Isn't the real problem the fact
  that mc_mkstemps() blindly concats tmpdir to the prefix instead of
  testing if mc_tmpdir() succeeded? Why not abort mc_mkstemps() if
  mc_tmpdir() returns /dev/null/?
 
  What about the attached (untested) patch?
 
  By the way, could you please add the -p option to your diffs?
 
 There is an even simpler cure. In mc_tmpdir() when executing
 the fallback code pass an absolute path to mc_mkstemps().
 This will prevent the loop. However I am not yet conviced
 that this is the best solution. I am still investigating.

I am attaching a patch which passes an absolute path to mc_mkstemps()
when invoked from mc_tmpdir(). What do you think about this fix ?
I may add a comment why it is necessary to call mc_mkstemps() with
an absolute path. By the way I think we should add a check whether 
the environment variable TMPDIR contains an absolute path. Anyway, I'll
leave this for another patch.

Index: src/utilunix.c
===
RCS file: /sources/mc/mc/src/utilunix.c,v
retrieving revision 1.88
diff -u -p -r1.88 utilunix.c
--- src/utilunix.c	27 Jul 2005 15:03:25 -	1.88
+++ src/utilunix.c	30 Dec 2006 18:44:22 -
@@ -280,19 +280,18 @@ mc_tmpdir (void)
 	}
 }
 
-if (!error) {
-	tmpdir = buffer;
-} else {
+if (error != NULL) {
 	int test_fd;
-	char *test_fn;
+	char *test_fn, *fallback_prefix;
 	int fallback_ok = 0;
 
 	if (*error)
 	fprintf (stderr, error, buffer);
 
 	/* Test if sys_tmp is suitable for temporary files */
-	tmpdir = sys_tmp;
-	test_fd = mc_mkstemps (test_fn, mctest, NULL);
+	fallback_prefix = g_strdup_printf (%s/mctest, sys_tmp);
+	test_fd = mc_mkstemps (test_fn, fallback_prefix, NULL);
+	g_free (fallback_prefix);
 	if (test_fd != -1) {
 	close (test_fd);
 	test_fd = open (test_fn, O_RDONLY);
@@ -306,16 +305,19 @@ mc_tmpdir (void)
 	if (fallback_ok) {
 	fprintf (stderr, _(Temporary files will be created in %s\n),
 		 sys_tmp);
+	g_snprintf (buffer, sizeof (buffer), %s, sys_tmp);
 	error = NULL;
 	} else {
 	fprintf (stderr, _(Temporary files will not be created\n));
-	tmpdir = /dev/null/;
+	g_snprintf (buffer, sizeof (buffer), %s, /dev/null/);
 	}
 
 	fprintf (stderr, %s\n, _(Press any key to continue...));
 	getc (stdin);
 }
 
+tmpdir = buffer;
+
 if (!error)
 	mc_setenv (MC_TMPDIR, tmpdir, 1);
 
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


[bug #17220] mc -a (stickchars) is gone

2006-12-30 Thread Pavel Tsekov

Update of bug #17220 (project mc):

  Status:None = Invalid
 Open/Closed:Open = Closed 

___

Follow-up Comment #5:

Closing as INVALID. Either file this report in RedHat's bugzilla or reopen it
here if there is strong evidence that this bug is not caused by a Fedora
patch/lib.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17220

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

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


Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key

2006-12-30 Thread Pavel Tsekov
Hello Grigory,

On Mon, 2006-12-04 at 19:45, Grigory Trenin wrote:

 Pavel Tsekov wrote:
 
  I think the correct solution would be to keep both
  'startpoint' and 'currentpoint' in the history but I am
  open to suggestions.
 
 
 Yes, I thought about it too. This is a good and safe fix.
 But I have a suggestion.
 Actually, 'startpoint' is used only once at line 315 of help.c:
 
 p = current_link - 1;
 if (p = start)
 return 0;
 p = search_char_node (p, CHAR_LINK_START, -1);
 return p;
 
 Here 'current_link' is the pointer to the currently
 selected (highlighted) link, and 'start' == 'startpoint'.
 Since there can be no situation when currently selected link
 is outside of the current topic, (p = start) expression
 becomes true only in one rare case - when the first text in the node
 is a link, for example:
 ^D[Topic name]^ASome link^BSome link^C
 
 In that case 'p' will point to ']' character, and 'start_point' will
 point to ^A, so (p = start) condition will be true. But
 this check for (p = start) condition is not really necessary,
 because search_char_node() will not search beyond the topic
 boundaries, it will stop at ^D character and return NULL.
 
 So, if that check and the 'startpoint' variable itself are not
 really necessary and can be eliminated, why should we mess with
 saving/restoring 'startpoint' in the history?
 
 Please look at a new patch - what do you think?
 There I removed 'startpoint' as well as the first argument of
 select_prev_link() function. And after calling it there is no sense to
 check if (selected_item = last_shown) - this will never happen,
 so I removed it also.

Ok. I think your arguments are reasonable. If the help viewer code was
better organized I'd probably have insisted on keeping the variable
holding the start of the node. However, I think that currently
'startpoint'
brings more confusion than benefit, so I've applied your patch.

Thanks!

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


[bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !

2007-01-01 Thread Pavel Tsekov

Update of bug #3836 (project mc):

  Status:Works For Me = Need Info  
 Open/Closed:  Closed = Open   


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?3836

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

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


Re: [bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !

2007-01-02 Thread Pavel Tsekov
Hello Egmont,

And of course you're right! :) The strange thing is that your comment
doesn't show in the comments for bug # 3836 ?!.

On Tue, 2 Jan 2007, Egmont Koblinger wrote:


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

 Some time ago dpkg had a bug: when it removed a package that contained a
 symlink to /dev/null, it chmod'ed /dev/null to 000. The problem was that it
 did a chmod() instead of lchmod(), or stat() instead of lstat() or something
 like that on the file to be removed.

 Obviously if mc changed /dev/null to 600 for everyone, we would all know
 about it and it would be already fixed. On the other hand I have no reason to
 doubt the reporter.

 So I guess that the bug might be that mc (or maybe its wrapper script)
 chmod's something to 600, and this something (a temp file maybe) happens to
 be a symlink to /dev/null on the reporter's system due to some special setup
 or env var or special wrapper script or something like that...


___

 Reply to this item at:

  http://savannah.gnu.org/bugs/?3836

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

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

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


Re: [PATCH] mc crashes when temporary directory cannot be created

2007-01-02 Thread Pavel Tsekov
Hello,

On Tue, 2 Jan 2007, Jindrich Novy wrote:

 On Sat, 2006-12-30 at 20:51 +0200, Pavel Tsekov wrote:
 There is an even simpler cure. In mc_tmpdir() when executing
 the fallback code pass an absolute path to mc_mkstemps().
 This will prevent the loop. However I am not yet conviced
 that this is the best solution. I am still investigating.

 I am attaching a patch which passes an absolute path to mc_mkstemps()
 when invoked from mc_tmpdir(). What do you think about this fix ?
 I may add a comment why it is necessary to call mc_mkstemps() with
 an absolute path. By the way I think we should add a check whether
 the environment variable TMPDIR contains an absolute path. Anyway, I'll
 leave this for another patch.

 Thanks for the patch. Do you plan to convert the relative paths to
 absolute ones when detected?

I think TMPDIR should be ignored in this case. What's your opinion ?

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


Re: [PATCH] mc crashes when temporary directory cannot be created

2007-01-02 Thread Pavel Tsekov
Hello,

On Tue, 2 Jan 2007, Jindrich Novy wrote:

 On Tue, 2007-01-02 at 16:28 +0200, Pavel Tsekov wrote:
 On Tue, 2 Jan 2007, Jindrich Novy wrote:
 On Sat, 2006-12-30 at 20:51 +0200, Pavel Tsekov wrote:
 There is an even simpler cure. In mc_tmpdir() when executing
 the fallback code pass an absolute path to mc_mkstemps().
 This will prevent the loop. However I am not yet conviced
 that this is the best solution. I am still investigating.

 I am attaching a patch which passes an absolute path to mc_mkstemps()
 when invoked from mc_tmpdir(). What do you think about this fix ?
 I may add a comment why it is necessary to call mc_mkstemps() with
 an absolute path. By the way I think we should add a check whether
 the environment variable TMPDIR contains an absolute path. Anyway, I'll
 leave this for another patch.

 Thanks for the patch. Do you plan to convert the relative paths to
 absolute ones when detected?

 I think TMPDIR should be ignored in this case. What's your opinion ?

 So some hardcoded value such as /tmp will then be assumed in case of
 relative path in TMPDIR?

Yep. It already is:

 sys_tmp = getenv (TMPDIR);
 if (!sys_tmp) {
 sys_tmp = TMPDIR_DEFAULT;
 }

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


Re: [PATCH] mc crashes when temporary directory cannot be created

2007-01-02 Thread Pavel Tsekov
On Tue, 2 Jan 2007, Jindrich Novy wrote:

 On Tue, 2007-01-02 at 16:28 +0200, Pavel Tsekov wrote:
 On Tue, 2 Jan 2007, Jindrich Novy wrote:
 On Sat, 2006-12-30 at 20:51 +0200, Pavel Tsekov wrote:
 There is an even simpler cure. In mc_tmpdir() when executing
 the fallback code pass an absolute path to mc_mkstemps().
 This will prevent the loop. However I am not yet conviced
 that this is the best solution. I am still investigating.

 I am attaching a patch which passes an absolute path to mc_mkstemps()
 when invoked from mc_tmpdir(). What do you think about this fix ?
 I may add a comment why it is necessary to call mc_mkstemps() with
 an absolute path. By the way I think we should add a check whether
 the environment variable TMPDIR contains an absolute path. Anyway, I'll
 leave this for another patch.

 Thanks for the patch. Do you plan to convert the relative paths to
 absolute ones when detected?

 I think TMPDIR should be ignored in this case. What's your opinion ?

 So some hardcoded value such as /tmp will then be assumed in case of
 relative path in TMPDIR?

Btw. does it make sense to use relative TMPDIR ?!

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


Re: [PATCH] mc crashes when temporary directory cannot be created

2007-01-02 Thread Pavel Tsekov
On Tue, 2007-01-02 at 16:53, Jindrich Novy wrote:

   I am attaching a patch which passes an absolute path to mc_mkstemps()
   when invoked from mc_tmpdir(). What do you think about this fix ?
   I may add a comment why it is necessary to call mc_mkstemps() with
   an absolute path. By the way I think we should add a check whether
   the environment variable TMPDIR contains an absolute path. Anyway, I'll
   leave this for another patch.
  
   Thanks for the patch. Do you plan to convert the relative paths to
   absolute ones when detected?
  
   I think TMPDIR should be ignored in this case. What's your opinion ?
  
   So some hardcoded value such as /tmp will then be assumed in case of
   relative path in TMPDIR?
  
  Yep. It already is:
  
   sys_tmp = getenv (TMPDIR);
   if (!sys_tmp) {
   sys_tmp = TMPDIR_DEFAULT;
   }
 
 It sounds good for me then ;-)

The patch is in CVS now. I'll add a check for TMPDIR being an absolute
path later today.


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


Please, do not post to savannah bug database

2007-01-03 Thread Pavel Tsekov
Hello,

The savannah bug database is currently experiencing some problems and
bug comments are lost. Please, do not post until further notice.

Thanks!

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


Re: [PATCH] Help Viewer - mouse issues

2007-01-03 Thread Pavel Tsekov
Hello Grigory,

On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote:

 Here are 3 patches to the mouse issues in the Help Viewer.

[...]
 3) mouse-linkfollow.patch
 When following a link with a mouse, an extra '\n' is insterted
 at the top of the window (just follow any link with a keyboard,
 then return back, and follow the same link with a mouse,
 and you should see the difference).
[...]

How about fixing help_follow_link() instead ? IMO, this
would be a proper fix if we agree that the leading '\n'
is not desired. The help format documentation says:

  The hypertext file is a file that may have one or more nodes.
   Each node ends with a ^D character and starts with a bracket,
   then the name of the node and then a closing bracket.

I don't see anything about the newline being part of the
node header and that it needs to be stripped. However,
as you noted above if the keyboard is used to follow a link
the newline is stripped. So, IMO, either the documentation
is buggy and we have to fix it and fix help_follow_link()
too or the key handling code is wrong to assume that it 
has to move beyond the newline. Any thoughts ?


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


Re: [PATCH] Help Viewer - mouse issues

2007-01-03 Thread Pavel Tsekov
On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote:

 2) mouse-offbytwo.patch
 Last two lines of the help window (the bottom line and a frame)
 are not mouse-clickable. So the user will not be able to follow
 a link with a mouse, if it is situated at the bottom line.
 And the frame needs to be clickable because it serves a special
 purpose - page scrolling.

This is patch is OK, but there are still problems.
See this:

  create_dlg (0, 0, help_lines + 4, HELP_WINDOW_WIDTH + 4,
^^

HELP_WINDOW_WIDTH already is large enough to hold the dialog
frame. As a resylt if you try to click on the right hand side
of the dialog you dont get any movement. I'd like to fix this
before applying your patch so I can commit both fixes.
Unfortunately removing the + 4 part is not enough to properly
fix the problem. It seems like man2hlp is producing output
with line lengths larget than HELP_TEXT_WIDTH which is incorrect
IMO. I'll investigate and let you know what have I found. In
the meantime if you want to help me - you are welcome :)


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


Re: [PATCH] Help Viewer - mouse issues

2007-01-03 Thread Pavel Tsekov
On Wed, 2007-01-03 at 22:43, Grigory Trenin wrote:
 Pavel Tsekov wrote:
 
 How about fixing help_follow_link() instead ? IMO, this
 would be a proper fix if we agree that the leading '\n'
 is not desired.
   
 
 Good point!
 Certainly, this would be better.
 
  The help format documentation says:
 
   The hypertext file is a file that may have one or more nodes.
Each node ends with a ^D character and starts with a bracket,
then the name of the node and then a closing bracket.
 
 I don't see anything about the newline being part of the
 node header and that it needs to be stripped. However,
 as you noted above if the keyboard is used to follow a link
 the newline is stripped. So, IMO, either the documentation
 is buggy and we have to fix it and fix help_follow_link()
 too or the key handling code is wrong to assume that it 
 has to move beyond the newline. Any thoughts ?
   
 
 It is man2hlp.c who always puts newline after the node header:
 fprintf (f_out, \004[Contents]\n);
 ...
 fprintf (f_out, %c[%s], CHAR_NODE_END, buffer);
 col++;
 newline ();

Yep.

 Besides, newlines are also present in the template - xnc.hlp file.
 
 It is interesting, however, that move_backward2(), which
 is called when the up key is pressed, assumes '\n' as a part
 of the node header, but move_to_top(), which is called when
 the home key is pressed - doesn't.
 
 As for me, I don't like that leading '\n', but it is probably
 a matter of taste. IMHO it is better to fix help_follow_link(),
 move_to_top(), and documentation...

I don't like it either :) But I'd like to hear from the other
people on this list, if possible, before doing anything.

 But I remember (it was 2 months ago, I guess) you suggested
 to rip line wrapping code out of man2hlp and to put it in the
 Help Viewer... If you still plan to do it, may be it would be better
 to patch man2hlp.c also not to insert '\n' after the node header...

Hmm. I don't really understand why the '\n' is necessary - and
since the code is quite old perhaps noone remebers anymore. I'll 
play with the code a bit and see if I be able to determine whether
the newline is of any importance. I'll see if the changelogs will
be of any help too.


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


No MC snapshot since 2006-12-28

2007-01-04 Thread Pavel Tsekov
Would you check why the snapshot is not being generated ?


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


Re: [PATCH] Help Viewer - mouse issues

2007-01-04 Thread Pavel Tsekov
On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote:

 1) mouse-rightbutton.patch
 Returning to a previous node by pressing right mouse button
 doesn't work in xterm. It works only in Linux console with GPM.
 The problem is that help_event() catches only GPM_UP event,
 and it seems that xterm doesn't report which mouse button
 was released. Handling GPM_DOWN instead of GPM_UP will fix it.

I had this idea now. How about fixing the code that captures mouse
events from xterm instead ? I.e. when it receives a mouse down event
it will record which key was pressed and it will copy this information
to the mouse up event ? I'm CC-ing to the xterm developer just in 
case he can give some insight.


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


Re: No MC snapshot since 2006-12-28

2007-01-04 Thread Pavel Tsekov
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 ?


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


Re: [PATCH] Help Viewer - mouse issues

2007-01-04 Thread Pavel Tsekov
On Thu, 2007-01-04 at 22:33, Grigory Trenin wrote:
 Pavel Tsekov wrote:
 
 I had this idea now. How about fixing the code that captures mouse
 events from xterm instead ? I.e. when it receives a mouse down event
 it will record which key was pressed and it will copy this information
 to the mouse up event ?
 
 
 This will be not always reliable. Suppose such situation:
 a user presses left mouse button, then (without releasing it)
 presses right mouse button, and finally, he releases one of these
 buttons. How do we know which button (left or right) was released?

Well, we don't :) But who will do this anyway ? I mean it's 
pointless :)


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


Re: No MC snapshot since 2006-12-28

2007-01-05 Thread Pavel Tsekov
On Fri, 2007-01-05 at 01:27, Pavel Roskin wrote:
 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).

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


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


[bug #18689] Config checkboxes not acting on mouse click

2007-01-05 Thread Pavel Tsekov

Update of bug #18689 (project mc):

  Status:None = Confirmed  

___

Follow-up Comment #1:

Oh, well. The mouse event is directed to the groupbox (the frame holding
other widgets inside it). The bad thing is that the groupbox is rather
simplistic widget and it doesn't know anything about the widgets that are
displayed inside it :( IMO, the real solution to this problem should involve
teaching the groupbox that it holds other widgets (i.e. making it a real
container widget). A simplistic solution would be to skip groupboxes when
dispatching mouse events.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18689

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

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


[bug #18695] tab completion vs. spaces and escaping

2007-01-05 Thread Pavel Tsekov

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

Sounds familiar...

  http://savannah.gnu.org/bugs/?16176

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18695

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

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


Re: [PATCH] Help Viewer - mouse issues

2007-01-05 Thread Pavel Tsekov
On Fri, 2007-01-05 at 02:32, Grigory Trenin wrote:
 Pavel Tsekov wrote:
 
 On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote:
 
 This is patch is OK, but there are still problems.
 See this:
 
   create_dlg (0, 0, help_lines + 4, HELP_WINDOW_WIDTH + 4,
 ^^
 
 HELP_WINDOW_WIDTH already is large enough to hold the dialog
 frame. As a resylt if you try to click on the right hand side
 of the dialog you dont get any movement. I'd like to fix this
 before applying your patch so I can commit both fixes.
 Unfortunately removing the + 4 part is not enough to properly
 fix the problem. It seems like man2hlp is producing output
 with line lengths larget than HELP_TEXT_WIDTH which is incorrect
 IMO. I'll investigate and let you know what have I found. In
 the meantime if you want to help me - you are welcome :)
   
 
 
 So, there are two ways to get rid of that empty space on the right:
 
 1) Shrink the window from 63 chars to HELP_TEXT_WIDTH (58 chars).
This will cause some difficulties due to the usage of preformatted
text - need to revise the help files for all languages, to check
if they fit in the window, and fix them if necessary.
 
 2) Expand HELP_TEXT_WIDTH to the effective window width (63 chars).
IMHO this is better. Besides, I think it would be nice to leave
a margin in one column between a text and a frame.
Should I try and do it?
What do you think?

Implementing either solution would not remove the necessity of this:

[...]
need to revise the help files for all languages, to check
if they fit in the window, and fix them if necessary.
[...]

To fix this there should be no preformatted pages involved, IMO. But
I may be wrong.


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


Re: [PATCH] Help Viewer - mouse issues

2007-01-06 Thread Pavel Tsekov
On Sat, 6 Jan 2007, Grigory Trenin wrote:

 Pavel Tsekov wrote:

 Implementing either solution would not remove the necessity of this:

 [...]
 need to revise the help files for all languages, to check
 if they fit in the window, and fix them if necessary.
 [...]

 To fix this there should be no preformatted pages involved, IMO. But
 I may be wrong.


 Well, sometimes preformatting is useful.
 Of course, it shouldn't be used for regular text, as it is used now.
 But in some nodes config files samples (like mc.menu) are given,
 and it is necessary to preserve indents and avoid line wraping
 for them.

 Besides, man2hlp handles a limited number of groff commands,
 it doesn't handle .ce command for example, so it is not
 possible to center lines with man2hlp. It is done by
 preformatting now. If we decide to eliminate all preformatting,
 it is necessary to patch man2hlp to center lines.

 I don't know whether the result will cover the efforts.
 May be it is easier just to leave that space on the right as is,
 and make it mouse-clickable?

Well, we can go with the simple solution for now  - but it
should be documented somewhere to prevent further confusion.
As to whether it is worth the effort - think about this:
Me and you together spent a considerable amount of time on a
simple issue - was it worth it ? I think making the things right
will allow the developer to spend his time on more pressing issues.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [PATCH] Help Viewer - mouse issues

2007-01-06 Thread Pavel Tsekov
On Wed, 2007-01-03 at 23:03, Pavel Tsekov wrote:
 On Wed, 2007-01-03 at 22:43, Grigory Trenin wrote:
  Pavel Tsekov wrote:
  
  How about fixing help_follow_link() instead ? IMO, this
  would be a proper fix if we agree that the leading '\n'
  is not desired.

  
  Good point!
  Certainly, this would be better.
  
   The help format documentation says:
  
The hypertext file is a file that may have one or more nodes.
 Each node ends with a ^D character and starts with a bracket,
 then the name of the node and then a closing bracket.
  
  I don't see anything about the newline being part of the
  node header and that it needs to be stripped. However,
  as you noted above if the keyboard is used to follow a link
  the newline is stripped. So, IMO, either the documentation
  is buggy and we have to fix it and fix help_follow_link()
  too or the key handling code is wrong to assume that it 
  has to move beyond the newline. Any thoughts ?

  
  It is man2hlp.c who always puts newline after the node header:
  fprintf (f_out, \004[Contents]\n);
  ...
  fprintf (f_out, %c[%s], CHAR_NODE_END, buffer);
  col++;
  newline ();
 
 Yep.
 
  Besides, newlines are also present in the template - xnc.hlp file.
  
  It is interesting, however, that move_backward2(), which
  is called when the up key is pressed, assumes '\n' as a part
  of the node header, but move_to_top(), which is called when
  the home key is pressed - doesn't.
  
  As for me, I don't like that leading '\n', but it is probably
  a matter of taste. IMHO it is better to fix help_follow_link(),
  move_to_top(), and documentation...
 
 I don't like it either :) But I'd like to hear from the other
 people on this list, if possible, before doing anything.

If anyone has something to add to this issue it's about time.
Otherwise I'll move to fixing this issue one way or the other.


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


[bug #16029] MC doesn't open if network gateway inaccessible.

2007-01-07 Thread Pavel Tsekov

Update of bug #16029 (project mc):

  Status:   Need Info = None   

___

Follow-up Comment #6:

The problem is due to the outdated samba library included with MC.
You can find out more here:

  http://mail.gnome.org/archives/mc/2006-September/msg00047.html

We actually don't need info any more since we know what's the cause of the
hang - changing the status to None.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?16029

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

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


Re: [PATCH] Help Viewer - mouse issues

2007-01-10 Thread Pavel Tsekov
On Tue, 2007-01-09 at 19:08, Grigory Trenin wrote:
 Pavel Tsekov wrote:
 
 
  Well, we can go with the simple solution for now  - but it
  should be documented somewhere to prevent further confusion.
  As to whether it is worth the effort - think about this:
  Me and you together spent a considerable amount of time on a
  simple issue - was it worth it ? I think making the things right
  will allow the developer to spend his time on more pressing issues.
 
 
 I am not quite satisfied with that simple solution too.
 What do you think if I convert xnc.hlp to mandoc format
 and patch man2hlp respectively?
 I think it will be sufficient to add to man2hlp support
 of these two troff commands:
 1) '.ce' (to center lines)
 2) '.ti' (temporary indent - to support right indention of the
first line of the paragraph).

Sound nice. Do you have a patch already ? :) Btw. after those
changes do you think that xnc.hlp will still be necessary ?

P.S. Your help is much appreciated!


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


[bug #18766] Not re-sorted at panel swap

2007-01-13 Thread Pavel Tsekov

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

Uhm, well.. It seems this behaviour is by design:

[...]
Tue Aug 29 14:33:16 1995  Jakub Jelinek

* layout.c (swap_panels): Fixed. Now it should work fine and if
there are both view_listings, then it just swappes their content
(and not formats etc.), so that you may have one format in the left
and a different one in the right panel and if you want to see some
things that are in the left for a file on the right, you just C-u.
[...]

And also from the swap_panels() in layout.c:

  /* Change everything except format/sort/panel_name etc. */

As I understand it the idea is to have a super-fast way to view some file
attributes which are not displayed in the other view but are displayed in the
current panel view. I noticed that this 
function is not documented very well - IMO the documentation is not clear on
what this command's purpose is :)



___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18766

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

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


[bug #18767] Panel sort order: fallback to name

2007-01-13 Thread Pavel Tsekov

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

I don't know if the Unsorted view make sense but I know that the GNU 'ls'
has a -U option which is supposed to print unsorted entries. 


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18767

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

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


[bug #18767] Panel sort order: fallback to name

2007-01-13 Thread Pavel Tsekov

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

Egmont, I've just verified that GNU ls does what you suggest in the 
situation described below. I'll apply a patch soon.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18767

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

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


[bug #18767] Panel sort order: fallback to name

2007-01-13 Thread Pavel Tsekov

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

I've commited a patch:
http://cvs.sv.gnu.org/viewcvs/mc/mc/src/dir.c?sortby=dater2=1.67r1=1.66diff_format=u


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18767

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

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


[bug #18767] Panel sort order: fallback to name

2007-01-15 Thread Pavel Tsekov

Update of bug #18767 (project mc):

  Status:None = Fixed  
 Open/Closed:Open = Closed 

___

Follow-up Comment #5:

Well, the guy who posted the bug report below seemed to use the Unsorted
mode:

  http://savannah.gnu.org/bugs/?func=detailitemitem_id=13549

Maybe, there are others too. As for myself - I never used it but still I
don't mind it. However if you want to discuss the Unsorted mode, please, open
a new bugreport. I am closing this one now.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18767

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

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


Re: view like 'tail -f'

2007-01-16 Thread Pavel Tsekov
Hello,

On Tue, 2007-01-16 at 00:18, [EMAIL PROTECTED] wrote:
 Suggestion: modify the internal viewer so that it can act like 'tail -f'.

Would you mind entering your request in the bug database
at savannah.gnu.org ?

Thanks!

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


Re: calculate directory size

2007-01-18 Thread Pavel Tsekov
Hello,

On Thu, 18 Jan 2007, [EMAIL PROTECTED] wrote:

 I have a suggestion again: calculation of directory size on pressing F3
 and/or on marking directory, maybe as an option. Many file managers have
 this feature. I'd like to see it in Midnight Commander too.
 I don't mind entering my request in the bug database.

This request is already in the bug database. See this for exmaple:

   http://savannah.gnu.org/bugs/?11951

Btw. I don't remember whether we had a discussion why F3 isn't 
appropriate. Comment #4 in the discussion above refers to
F3 being using to invoket NC's viewer. While I do remember
that F3 on a file invoked that viewer I don't NC handy to
verify what it does when F3 is pressed on a directory. Anyway
I happen to agree that if most of the NC-like file managers
out there do this we should do it too.

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


Re: [PATCH] Help Viewer - mouse issues

2007-01-20 Thread Pavel Tsekov
Hello,

On Wed, 2007-01-03 at 23:03, Pavel Tsekov wrote:

 Hmm. I don't really understand why the '\n' is necessary - and
 since the code is quite old perhaps noone remebers anymore. I'll 
 play with the code a bit and see if I be able to determine whether
 the newline is of any importance. I'll see if the changelogs will
 be of any help too.

Ok. I now understand why the newline after the header is necessary.
It is there to faciliate the editor of the template file (xnc.hlp).
Other than that the newline is really unnecessary. So, I'll keep
it there, I'll document it in the node header format and apply a
patch to make all help.c functions deal consistently with it.


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


[bug #18977] Case insensetive search in mc doesn't work

2007-02-08 Thread Pavel Tsekov

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

Please, read the link below - this is the expected behaviour:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351562

Anyway, I'll take a look at those patches.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18977

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

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


[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow

2007-02-18 Thread Pavel Tsekov

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

I cannot reproduce this problem with a CVS version of MC. Are you using are
self-built MC or a binary package which comes with some distribution ? The
bug that you are experiencing may be due to the UTF-8 patches used by some
distros. If that is the case it'd be best to file this bug report against
your distro's bug database.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18913

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

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


[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow

2007-02-18 Thread Pavel Tsekov

Update of bug #18913 (project mc):

Category:None = Editor 


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18913

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

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


[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow

2007-02-20 Thread Pavel Tsekov

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

Originally posted by Richard Blakie:

I am using the original Red-Hat RPM release for Fedora Core 5 provided on
their site. The release is mc-4.6.1a-35.fc5.i386.rpm

Does this mean that if compiled with UTF-8, it could cause problems in
ISO8859-1 ? I am not sure what options the package is compiled with but I
will try and find out. 

I just tested on UBUNTU and it does not have this problem. Do you know of
anything I could look at to know about what MC was compiled with ?

Thanks in advance from Toronto, Canada


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18913

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

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


[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow

2007-02-20 Thread Pavel Tsekov

Update of bug #18913 (project mc):

Operating System:GNU/Hurd = GNU/Linux  

___

Follow-up Comment #3:

Richard,

Fedora's rpm comes with UTF-8 support built-in - no need to try and find
out.

I don't have Fedora installed right now so I cannot test and see what's
wrong. I'll try to play with the Ubuntu MC package since I have Ubuntu
installed on my laptop. Anyway, I think the output of the command 'locale'
would be useful to reproduce the crash, so, please, post it here in this bug
report. And then again - it might be worth to open a bug report in Fedora's
bugzilla.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18913

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

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


[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow

2007-02-20 Thread Pavel Tsekov

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

Originally posted by Richard Blakie:

Hello Pavel, this is my 'locale' output:

LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=

I am investigating the redhat problem reports. I will let you know. But since
the problem does not exist in the UBUNTU release, your guess is probably
right
: it has something to do with either 1-)the fedora MC release or 2-)the
Fedora system configuration. Although my default is en_US.UTF-8, I often have
to deal with french files for Quebec. So I can't change my system to all
UTF-8.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18913

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

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


[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow

2007-02-20 Thread Pavel Tsekov

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

Richard could you use the Post a Comment savannah's bug tracking facility
instead of personally messaging me ?


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18913

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

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


[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow

2007-02-20 Thread Pavel Tsekov

Follow-up Comment #7, bug #18913 (project mc):

Using MC from CVS i.e. (without the UTF-8 patch) I don't see the crash. So it
really makes sense to move the discussion to Fedora's bug tracking facility
and maybe post a link to this discussion there.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18913

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

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


[bug #18913] Segmentation fault, internal editor, with iso-8859-1 Ctrl/Arrow

2007-02-20 Thread Pavel Tsekov

Update of bug #18913 (project mc):

  Status:None = Wont Fix   
 Open/Closed:Open = Closed 

___

Follow-up Comment #9:

Ok. Closing as won't fix. If someone feels that this is really a bug in MC
and not the UTF-8 patch, please, feel free to reopen.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18913

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

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


[bug #18977] Case insensetive search in mc doesn't work

2007-02-20 Thread Pavel Tsekov

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

I took a look at the patch and it is pretty straightforward. However it is
not what we want - it misuses the case Sensitive mark under the Content
field - that flag is related to the data entered into the Content field and
not the Filename field. I'll modify the dialog and adjust the code to do the
right thing.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18977

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

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


Re: view like 'tail -f'

2007-02-22 Thread Pavel Tsekov
Hello,

On Tue, 16 Jan 2007, [EMAIL PROTECTED] wrote:

 Suggestion: modify the internal viewer so that it can act like 'tail -f'.

Why do you think it is usefull to have this functionality ? What
are its use cases ?

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


Re: maybe a bug in copy files

2007-02-22 Thread Pavel Tsekov
Hello Lubomir,

On Mon, 22 Jan 2007, Lubomir Grajciar wrote:

 When I try to copy file(s) with unchecked preserve atributes
 checkbox as regular user, copied files hasn't attributes based on my
 umask.

 My umask is: 0022
 Copied file attributes: 600

 When I try to create a new file (for example with shift-F4), it is
 created with right attributes (644).

Thanks for noticing and reporting this! It is indeed a bug and
it has been here for the last 5 years.

For the curious - there is a thread with a subject of Problems
with vfs / ftpfs started on 27 Feb 2002. As it can be
seen the patch posted by Andrew calls chmod() on the target
file only if preserve attributes is set. However, it has to
be called in both cases since the destination file is created
with mode 600 initially due to security concerns - more info
can be found in file.c .

I'll revert that patch.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: maybe a bug in copy files

2007-02-22 Thread Pavel Tsekov
Hello Egmont,

On Thu, 22 Feb 2007, Egmont Koblinger wrote:

 Hi,

 [...] As it can be
 seen the patch posted by Andrew calls chmod() on the target
 file only if preserve attributes is set. However, it has to
 be called in both cases since the destination file is created
 with mode 600 initially due to security concerns - more info
 can be found in file.c .

 I think this is overcomplicated... open() does not create the file with the
 permission taken from its third argument, it masks it with umask. So
 currently the file is not created with mode 600, but with mode (600 
 ^umask).

 What's wrong with the following simple solution?

 When creating the file, pass the permissions of the old file to the open()
 call. This way it will have no more permissions than the original file, and
 no more permission than umask suggests.

 When copying is finished, call chmod() only if preserve attributes is set.

 /* Create the new regular file with small permissions initially,
do not create a security hole.  FIXME: You have security hole
here, btw. Imagine copying to /tmp and symlink attack :-( */

 while ((dest_desc = mc_open (dst_path, O_WRONLY | (ctx-do_append ?
 O_APPEND : (O_CREAT | O_TRUNC)), 0600))  0) {

I remember that there is a discussion somewhere on the mailing list
as to what this security concern is. I will try to dig it and see
whether it really makes sense to do it the way it currently is.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: maybe a bug in copy files

2007-02-22 Thread Pavel Tsekov
Hello,

On Thu, 22 Feb 2007, Pavel Tsekov wrote:

 I remember that there is a discussion somewhere on the mailing list
 as to what this security concern is. I will try to dig it and see
 whether it really makes sense to do it the way it currently is.

Here it is:

http://mail.gnome.org/archives/mc-devel/2006-June/msg00063.html

Shall we discuss how to create the file in a secure manner
and avoid the call to mc_chmod() ?

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


Request for discussion - how to make MC unicode capable

2007-02-24 Thread Pavel Tsekov
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.

Thanks!


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


Re: maybe a bug in copy files

2007-02-26 Thread Pavel Tsekov
Hello,

On Mon, 26 Feb 2007, Egmont Koblinger wrote:

 On Thu, Feb 22, 2007 at 05:44:39PM +0200, Pavel Tsekov wrote:

 Here it is:

 http://mail.gnome.org/archives/mc-devel/2006-June/msg00063.html

 Shall we discuss how to create the file in a secure manner
 and avoid the call to mc_chmod() ?

 I think we're talking about two separate issues.

 One is how to safely create a file (without race condition) so that we
 really create _that_ file and not another one via a new symlink. The answer
 is O_EXCL.

 The other issue is how to create the file with the right permissions so that
 we don't leak information. I guess I proposed a cleaner solution for this
 than the current one.

 I can't see any correlation between these two issues.

Ok. Maybe we are talking about different issues. What I was talking
about was that the current code in MC requires the chmod() that i've
ressurected. From what I understand you was talking that if we change
the code we may avoid the chmod() call at the end. Is this right ?
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


<    1   2   3   4   5   6   7   8   >