Re: [PATCH] Manpage fixes

[Denys Vlasenko]

On Wed, Feb 10, 2016 at 9:01 PM, Yury V. Zaytsev <y...@shurup.com> wrote:
> On Wed, 2016-02-10 at 17:29 +0100, Denys Vlasenko wrote:
>>
>> Fixed a number of places with bad English.
>
> Hi Denys,
>
> Could you please re-send the patch as an attachment? Your mail client
> has corrupted it by inserting spurious line breaks...

Here it is.
From 599ae53df3bf2d691457d613d66c541b4849e8ef Mon Sep 17 00:00:00 2001
From: Denys Vlasenko <vda.li...@googlemail.com>
To: mc-devel@gnome.org
Subject: [PATCH] Manpage fixes

sentitive -> sensitive
cusor -> cursor
toglle-> toggle
"the the" -> the

Fixed a number of places with bad English.

Signed-off-by: Denys Vlasenko <vda.li...@googlemail.com>
---
 doc/man/mc.1.in |  9 +++---
 doc/man/mcedit.1.in | 93 +
 2 files changed, 49 insertions(+), 53 deletions(-)

diff --git a/doc/man/mc.1.in b/doc/man/mc.1.in
index 35725bd..4ea7a4b 100644
--- a/doc/man/mc.1.in
+++ b/doc/man/mc.1.in
@@ -90,7 +90,8 @@ as an alias to the appropriate shell script.
 .I \-s, \-\-slow
 Set alternative mode drawing of frameworks.
 If the section [Lines] is not filled, the symbol for the pseudographics
-frame is a space, otherwise the frame characters are taken from follow params.
+frame is a space, otherwise the frame characters are taken from following
+parameters.
 
 .B You can redefine the following variables:
 .TP
@@ -2122,8 +2123,8 @@ You can specify how the
 .\"LINK2"
 Quick search
 .\"Quick search"
-mode should works: case insensitively, case sensitively or be matched
-to the the panel sort order: case sensitive or not.
+mode should work: case insensitively, case sensitively or be matched
+to the panel sort order: case sensitive or not.
 .\"NODE "Confirmation"
 .SH "Confirmation"
 In this dialog you configure the confirmation options for file deletion,
@@ -3999,7 +4000,7 @@ list of extensions of files. Separated by ';' sign.
 .TP
 .I extensions_case
 (make sense only with 'extensions' parameter) make 'extensions'
-rule case sentitive (true) or not (false).
+rule case sensitive (true) or not (false).
 .PP
 `type' key may have values:
 .nf
diff --git a/doc/man/mcedit.1.in b/doc/man/mcedit.1.in
index 4f6cf47..8a04497 100644
--- a/doc/man/mcedit.1.in
+++ b/doc/man/mcedit.1.in
@@ -12,7 +12,7 @@ mcedit \- Internal file editor of GNU Midnight Commander.
 mcedit is a link to
 .BR mc ,
 the main GNU Midnight Commander executable. Executing GNU Midnight Commander
-under this name requests staring the internal editor and opening files
+under this name runs the internal editor and opens files
 specified on the command line. The editor is based on the terminal version of
 .B cooledit
 \- standalone editor for X Window System.
@@ -21,8 +21,8 @@ specified on the command line. The editor is based on the terminal version of
 .I "+lineno"
 Go to the line specified by number (do not put a space between the
 .I "+"
-sign and the number). Several line numbers are allowed but the last one will be
-actual and it will be applied to the first file only.
+sign and the number). Several line numbers are allowed but only the last one
+will be used, and it will be applied to the first file only.
 .TP
 .I "\-b"
 Force black and white display.
@@ -181,9 +181,7 @@ The currently tagged files.
 .I %T
 The tagged files in the unselected panel.
 .TP
-.I %u
-and
-.I %U
+.IR %u " and " %U
 Similar to the
 .I %t
 and
@@ -192,9 +190,7 @@ macros, but in addition the files are untagged. You can use this macro
 only once per menu file entry or extension file entry, because next time
 there will be no tagged files.
 .TP
-.I %s
-and
-.I %S
+.IR %s " and " %S
 The selected files: The tagged files if there are any. Otherwise the
 current file.
 .PP
@@ -218,23 +214,23 @@ in the
 menu.
 .SH CODE NAVIGATION
 .B mcedit
-can be used to navigation through code with tags files created by etags
-or ctags commands. If there is no file TAGS code navigation would not work.
-In example, in case of exuberant\-ctags for C language command will be:
+can be used for navigation through code with tags files created by etags
+or ctags commands. If there is no TAGS file code navigation will not work.
+For example, in case of exuberant\-ctags for C language command will be:
 .PP
 ctags \-e \-\-language\-force=C \-R ./
 .PP
-.B Meta\-Enter 
-show list box to select item under cursor (cusor should stand at end of
-word).
+.B Meta\-Enter
+shows list box to select item under cursor (cursor should stand at the end
+of the word).
 .PP
-.B Meta\-Minus 
-where minus is symbol "\-" go to previous function in navigation list (like a browser
-Back).
+.B Meta\-Minus
+where minus is symbol "\-" goes to previous function in navigation list
+(like browser's Back button).
 .PP
 .B Meta\-Equal
-where equal is symbol &qu

Re: [PATCH] isofs fix: do not skip all .dotfiles

[Denys Vlasenko]

On Thu, Oct 15, 2015 at 7:23 PM, Yury V. Zaytsev <y...@shurup.com> wrote:
> On Thu, 2015-10-15 at 18:56 +0200, Denys Vlasenko wrote:
>> There appears to be an easy bug in iso9660 helper:
>
> Hi Denys,
>
> Could you please be so kind as to make a ticket and attach the patches
> for both changes there?
> Your first patch looks nice and simple,

https://www.midnight-commander.org/ticket/3537

> and if you can check when the
> second bug occurs, fix and test it, I will make a branch and merge it...

I fear you will ask me to create another ticket.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

[PATCH] isofs fix: do not skip all .dotfiles

[Denys Vlasenko]

There appears to be an easy bug in iso9660 helper:

if (name ~ /^\.\.?/) next

means "skip all lines which start with one or two dots".
Author probably meant: if (name ~ /^\.\.?$/) next

I propose to not be cryptic and just check both possibilities separately.

The below trivial patch was tested to work: now I see
the file named ".dot" in a test iso file.

(Note: there seems to be another bug: SEMICOLON = "YES"
is not a correct comparison (should use ==),
it's assignment! As a result, sub(";1$", "", name);
is always executed).


--- a/src/vfs/extfs/helpers/iso9660.in
+++ b/src/vfs/extfs/helpers/iso9660.in
@@ -156,7 +156,8 @@ BEGIN {
   if (SEMICOLON = "YES") sub(";1$", "", name);
   ## sub(";[0-9]+$", "", name) ## would break copyout
   # skip . and ..
-  if (name ~ /^\.\.?/) next;
+  if (name == ".") next;
+  if (name == "..") next;
   printf "%s%s%s\n", attr, dir, name
 }'
 }
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

(smbfs_fake_share_stat): don't access to free'd memory wasn't needed

[Denys Vlasenko]

-vfs_path_t *vpath = vfs_path_from_str (path);
+vfs_path_t *vpath;

+vpath = vfs_path_from_str (path);
 p = smbfs_get_path (sc, vpath);
 vfs_path_free (vpath);

-g_free (p);
-if (p)
+if (p != NULL)
 {
 memset (buf, 0, sizeof (*buf));
 /*  show this as dir*/
 buf-st_mode =
 (S_IFDIR | S_IRUSR | S_IRGRP | S_IROTH | S_IXUSR |
S_IXGRP | S_IXOTH)  myumask;
+g_free (p);
 return 0;
 }
+g_free (p);
 return -1;



There was no bug.

free(p); if (p) ... is a valid code, since it doesn't access memory
pointed to by p, it only looks at the value of the pointer p.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: [PATCH 5/5 v2] keyboard input: when an unknown sequence is seen, purge all buffered input

[Denys Vlasenko]

On Mon, Feb 4, 2013 at 12:54 PM, Slava Zanko slavaza...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 31.01.2013 19:27, Oswald Buddenhagen wrote:

 the mc devs are rather insistent on their process and often simply
 ignore contributions on the list, so you may get a better response
 when you create trac tickets.

 It's is not the only reason, but yes, better to create a new ticket.

https://github.com/MidnightCommander/mc/issues/10

ping...
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

[PATCH] Fix code which depends on signed overflow in C (which isn't defined in C)

[Denys Vlasenko]

This is the fix for https://github.com/MidnightCommander/mc/issues/11


signed_overflow_fix.patch
Description: Binary data
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: [PATCH 5/5 v2] keyboard input: when an unknown sequence is seen, purge all buffered input

[Denys Vlasenko]

Ping...

On Thu, Oct 25, 2012 at 4:45 PM, Denys Vlasenko
vda.li...@googlemail.com wrote:
 When we see an unknown sequence, it is not enough
 to drop already received part - there can be more of it
 coming over e.g. a serial line.

 To prevent interpreting it as a random garbage,
 eat and discard all chars that follow.
 Small, but non-zero timeout is needed to reconnect
 escape sequence split up by a serial line.

 Before this change, Ctrl-Alt-Shift-Right_Arrow generates 1;8C
 bogus input in MC on my machine; after the change,
 nothing is generated.

 Signed-off-by: Denys Vlasenko vda.li...@googlemail.com
 ---
  lib/tty/key.c |   21 -
  1 files changed, 16 insertions(+), 5 deletions(-)

 diff --git a/lib/tty/key.c b/lib/tty/key.c
 index 9b97aa8..818b2e6 100644
 --- a/lib/tty/key.c
 +++ b/lib/tty/key.c
 @@ -1216,14 +1216,14 @@ correct_key_code (int code)
  /* 
 -
  */

  static int
 -xgetch_second (void)
 +getch_with_timeout (unsigned delay_us)
  {
  fd_set Read_FD_Set;
  int c;
  struct timeval time_out;

 -time_out.tv_sec = old_esc_mode_timeout / 100;
 -time_out.tv_usec = old_esc_mode_timeout % 100;
 +time_out.tv_sec = delay_us / 100u;
 +time_out.tv_usec = delay_us % 100u;
  tty_nodelay (TRUE);
  FD_ZERO (Read_FD_Set);
  FD_SET (input_fd, Read_FD_Set);
 @@ -1891,7 +1891,18 @@ get_key_code (int no_delay)
  seq_append = NULL;
  }
  if (bad_seq)
 +{
 +/* This is an unknown ESC sequence.
 + * To prevent interpreting its tail as a random garbage,
 + * eat and discard all buffered and quickly following 
 chars.
 + * Small, but non-zero timeout is needed to reconnect
 + * escape sequence split up by e.g. a serial line.
 + */
 +int paranoia = 20;
 +while (getch_with_timeout (old_esc_mode_timeout) = 0  
 --paranoia != 0)
 +continue;
  goto nodelay_try_again;
 +}
  }
  if ((d  127  d  256)  use_8th_bit_as_meta)
  {
 @@ -2009,8 +2020,8 @@ get_key_code (int no_delay)
  goto nodelay_try_again;
  }
  esctime.tv_sec = -1;
 -c = xgetch_second ();
 -keylog ( c=xgetch_second()=%d\n, c);
 +c = getch_with_timeout (old_esc_mode_timeout);
 +keylog ( c=getch_with_timeout(%d)=%d\n, 
 old_esc_mode_timeout, c);
  if (c == -1)
  {
  pending_keys = seq_append = NULL;
 --
 1.7.7.6

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

[PATCH 5/5] keyboard input: when an unknown sequence is seen, purge all buffered input

[Denys Vlasenko]

When we see an unknown sequence, it is not enough
to drop already received part - there can be more of it
coming over e.g. a serial line.

To prevent interpreting it as a random garbage,
eat and discard all chars that follow.
Small, but non-zero timeout is needed to reconnect
escape sequence split up by a serial line.
50 milliseconds seem to work well.

Before this change, Ctrl-Alt-Shift-Right_Arrow generates 1;8C
bogus input in MC on my machine; after the change,
nothing is generated.

Signed-off-by: Denys Vlasenko vda.li...@googlemail.com
---
 lib/tty/key.c |   22 +-
 1 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/lib/tty/key.c b/lib/tty/key.c
index 9b97aa8..593d0f6 100644
--- a/lib/tty/key.c
+++ b/lib/tty/key.c
@@ -1216,14 +1216,14 @@ correct_key_code (int code)
 /* 
-
 */
 
 static int
-xgetch_second (void)
+getch_with_timeout (unsigned delay_ms)
 {
 fd_set Read_FD_Set;
 int c;
 struct timeval time_out;
 
-time_out.tv_sec = old_esc_mode_timeout / 100;
-time_out.tv_usec = old_esc_mode_timeout % 100;
+time_out.tv_sec = delay_ms / 100u;
+time_out.tv_usec = delay_ms % 100u;
 tty_nodelay (TRUE);
 FD_ZERO (Read_FD_Set);
 FD_SET (input_fd, Read_FD_Set);
@@ -1891,7 +1891,19 @@ get_key_code (int no_delay)
 seq_append = NULL;
 }
 if (bad_seq)
+{
+/* This is an unknown ESC sequence.
+ * To prevent interpreting its tail as a random garbage,
+ * eat and discard all buffered and quickly following 
chars.
+ * Small, but non-zero timeout is needed to reconnect
+ * escape sequence split up by e.g. a serial line.
+ * 50 milliseconds seems to work well.
+ */
+int paranoia = 20;
+while (getch_with_timeout (50*1000) = 0  --paranoia != 
0)
+continue;
 goto nodelay_try_again;
+}
 }
 if ((d  127  d  256)  use_8th_bit_as_meta)
 {
@@ -2009,8 +2021,8 @@ get_key_code (int no_delay)
 goto nodelay_try_again;
 }
 esctime.tv_sec = -1;
-c = xgetch_second ();
-keylog ( c=xgetch_second()=%d\n, c);
+c = getch_with_timeout (old_esc_mode_timeout);
+keylog ( c=getch_with_timeout(%d)=%d\n, 
old_esc_mode_timeout, c);
 if (c == -1)
 {
 pending_keys = seq_append = NULL;
-- 
1.7.7.6

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

Re: [PATCH] do not abort on broken .cpio file

[Denys Vlasenko]

On Sunday 01 November 2009 11:59, Yury V. Zaytsev wrote:
 On Sun, 2009-11-01 at 03:02 +0100, Denys Vlasenko wrote:
 
  This wastes your time. Maybe it makes sense to allow
  trivial fixes to be applied without going through
  this process?
 
 What are your suggestions on how would you track what, from where and
 WHY gets into master, who reviewed the code before submission and
 checked that it builds / does not introduce regressions then?

For example, you can have a rule that committer is responsible for that.

If you have a few people in your team whom you trust
that they are organized enough to always do a compile test
and a basic run test before committing, then they may
be entrusted in fast-forwarding trivial stuff.

 I agree that it takes time, but it does not *waste* time, because
 afterward it makes much easier to figure out how and when a particular
 regression or bug was introduced.
 
 You think that your patch is trivial, but we have a record of one-liners
 introducing very weird and hard to find regressions. Sometimes it takes
 hours of bisecting to figure out what broke a particular feature...

Yep, happens all the time.

 Therefore, if you want to spare us some time, you are asked to create a
 ticket in the tracker and attach your patches there, so that we won't
 have to do it for you.

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

Re: [PATCH] do not abort on broken .cpio file

[Denys Vlasenko]

On Thursday 15 October 2009 16:21, Denys Vlasenko wrote:
 For some reason, mc aborts if .cpio magic as wrong.
 
 This trivial patch makes mc handle it gracefully.
 
 Please apply.

This is now fixed, thanks!

I am a bit surprised that for such a trivial fix,
you guys went to the trouble of creating a bug:

http://www.midnight-commander.org/ticket/1725

and went through 7 changes in that bug.

This wastes your time. Maybe it makes sense to allow
trivial fixes to be applied without going through
this process?

Just a sugeestion, feel free to disregard.
--
vda

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

Home / End in viewer does not work in recent git

[Denys Vlasenko]

Hi,

I built mc from recent git. Today I noticed that
Home / End key in the viewer do not jump to the
beginning / end of the viewed file. They work
in other places, so it does not seem to be a problem
with interpreting keycodes.

My git-fu is weak, I don't know how to identify
when exactly I did last git pull.
git log shows this:


commit ae3a0a85f7d3ae36d3beab75743e9ec7c3a3
Merge: c96af78 f3f975e
Author: Denys Vlasenko vda.li...@googlemail.com
Date:   Mon Oct 26 01:01:25 2009 +0100

Merge branch 'master' of git://midnight-commander.org/git/mc

commit f3f975ec16af8f702f5b3e0697cb87e806249018
Merge: 20cd37d acd0ed0
Author: Ilia Maslakov il.sm...@gmail.com
Date:   Sat Oct 24 15:24:47 2009 +

Merge branch '1627_widechar_in_viewer'

* 1627_widechar_in_viewer:
  fixed drawing zerowidth characters
  * Added g_unichar_iszerowidth() and g_file_set_contents() functions for
  Ticket #1627

commit acd0ed038db194f60423e7f1b0c5869086b31e22
Author: Ilia Maslakov il.sm...@gmail.com
Date:   Sat Oct 24 13:32:33 2009 +

fixed drawing zerowidth characters

Signed-off-by: Ilia Maslakov il.sm...@gmail.com
...
...


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

[PATCH] do not abort on broken .cpio file

[Denys Vlasenko]

For some reason, mc aborts if .cpio magic as wrong.

This trivial patch makes mc handle it gracefully.

Please apply.
--
vda


fix_abort_on_cpio.patch
Description: Binary data
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Flickering appeared in recent git

[Denys Vlasenko]

On Wed, Aug 19, 2009 at 8:23 PM, Patrick Winnertzwin...@debian.org wrote:
 Am Wed, 19 Aug 2009 19:37:49 +0200
 schrieb Denys Vlasenko vda.li...@googlemail.com:

 Hi,

 I rebuilt mc from newer git (two days ago) and I see
 a somewhat subtle effect.

 On screen updates, mc now flickers.

 The simplest way to see it is to open a large xterm window
 with mc file view (it is less noticeable on text consoles),
 press and hold Ctrl-R (refresh).

 In mc built from git a month ago or so, or in some old releases,
 nothing noticeable happens. In new mc, I see cursor appearing
 randomly in the panel, with the rest of line after cursor cleared
 and painted black. It happens on random lines and quickly disappears
 and reappears. It happens so often and takes so much time
 that Ctrl-R redraw cannot keep up with keyboard repeat -
 I release the keys but redraws continue for several seconds.

 This effect is not limited to Ctrl-R, it's just the easiest way to
 see  it. I see it all the time when screen is updated. For example,
 if I stand on a text file and press F4, Esc, F4, Esc repeatedly.
 And I do not see it with old mc in this case too.

 Does anybody else see this?
 Jepp I can reproduce this.  Can you please open a ticket on m-c.o?

Yes. Here is it:

http://www.midnight-commander.org/ticket/1582

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

[PATCH] trivial: de-inline large functions

[Denys Vlasenko]

Hi Slava, folks,

The attached patch de-inlines a few functions
which are large, or not-so-large but nevertheless
contain more than one function call,
or contain loops, or contain if's and at least one
function call, or contain largish objects on stack.

In my experience, in those cases the code size
growth is big enough to not inline stuff.

I guess some of the really big functions
are defined inline because they have, or had in the past,
just one callsite.

But for a few years gcc already does it automatically,
no need to do it by hand and risk code size explosion
when later during code evolution another callsite
is created. This optimization by hand is simply
no longer needed.

Anyway, here is the code size difference:

# size */.obj/src/mc
   textdata bss dec hex filename
 572337   17944  177820  768101   bb865 mc.t5/.obj/src/mc
 567697   17944  177820  763461   ba645 mc.t6/.obj/src/mc

Please apply.
-- 
vda
diff -d -urpN mc.5/edit/bookmark.c mc.6/edit/bookmark.c
--- mc.5/edit/bookmark.c	2009-07-10 23:39:18.0 +0200
+++ mc.6/edit/bookmark.c	2009-08-30 16:08:28.0 +0200
@@ -49,7 +49,7 @@
appended after each other and the last one is always the one found
by book_mark_found() i.e. last in is the one seen */
 
-static inline struct _book_mark *double_marks (WEdit * edit, struct _book_mark *p)
+static struct _book_mark *double_marks (WEdit * edit, struct _book_mark *p)
 {
 (void) edit;
 
diff -d -urpN mc.5/edit/edit.c mc.6/edit/edit.c
--- mc.5/edit/edit.c	2009-08-30 05:23:10.0 +0200
+++ mc.6/edit/edit.c	2009-08-30 16:08:37.0 +0200
@@ -634,7 +634,7 @@ edit_save_position (WEdit *edit)
 }
 
 /* Clean the WEdit stricture except the widget part */
-static inline void
+static void
 edit_purge_widget (WEdit *edit)
 {
 int len = sizeof (WEdit) - sizeof (Widget);
@@ -1030,7 +1030,7 @@ pop_action (WEdit * edit)
 }
 
 /* is called whenever a modification is made by one of the four routines below */
-static inline void edit_modification (WEdit * edit)
+static void edit_modification (WEdit * edit)
 {
 edit-caches_valid = 0;
 edit-screen_modified = 1;
diff -d -urpN mc.5/edit/syntax.c mc.6/edit/syntax.c
--- mc.5/edit/syntax.c	2009-08-30 05:23:10.0 +0200
+++ mc.6/edit/syntax.c	2009-08-30 16:08:23.0 +0200
@@ -131,7 +131,7 @@ mc_defines_destroy (gpointer key, gpoint
 }
 
 /* Completely destroys the defines tree */
-static inline void
+static void
 destroy_defines (GTree **defines)
 {
 g_tree_traverse (*defines, mc_defines_destroy, G_POST_ORDER, NULL);
@@ -292,7 +292,7 @@ compare_word_to_right (WEdit *edit, long
 return i;
 }
 
-static inline const char *xx_strchr (const unsigned char *s, int c)
+static const char *xx_strchr (const unsigned char *s, int c)
 {
 while (*s = '\005'  *s != (unsigned char) c) {
 	s++;
@@ -300,7 +300,7 @@ static inline const char *xx_strchr (con
 return (const char *) s;
 }
 
-static inline struct syntax_rule apply_rules_going_right (WEdit * edit, long i, struct syntax_rule rule)
+static struct syntax_rule apply_rules_going_right (WEdit * edit, long i, struct syntax_rule rule)
 {
 struct context_rule *r;
 int contextchanged = 0, c;
diff -d -urpN mc.5/src/achown.c mc.6/src/achown.c
--- mc.5/src/achown.c	2009-08-30 05:23:10.0 +0200
+++ mc.6/src/achown.c	2009-08-30 16:11:49.0 +0200
@@ -612,7 +612,7 @@ chown_advanced_done (void)
 }
 
 #if 0
-static inline void do_chown (uid_t u, gid_t g)
+static void do_chown (uid_t u, gid_t g)
 {
 chown (current_panel-dir.list[current_file].fname, u, g);
 file_mark (current_panel, current_file, 0);
diff -d -urpN mc.5/src/chown.c mc.6/src/chown.c
--- mc.5/src/chown.c	2009-08-30 05:23:10.0 +0200
+++ mc.6/src/chown.c	2009-08-30 16:09:24.0 +0200
@@ -215,7 +215,7 @@ chown_done (void)
 repaint_screen ();
 }
 
-static inline void
+static void
 do_chown (uid_t u, gid_t g)
 {
 if (mc_chown (current_panel-dir.list [current_file].fname, u, g) == -1)
diff -d -urpN mc.5/src/dialog.c mc.6/src/dialog.c
--- mc.5/src/dialog.c	2009-08-30 05:23:10.0 +0200
+++ mc.6/src/dialog.c	2009-08-30 16:10:57.0 +0200
@@ -587,7 +587,7 @@ void dlg_stop (Dlg_head *h)
 h-running = 0;
 }
 
-static inline void
+static void
 dialog_handle_key (Dlg_head *h, int d_key)
 {
 if (is_abort_char (d_key)) {
@@ -732,7 +732,7 @@ dlg_key_event (Dlg_head *h, int d_key)
 (*h-callback) (h, DLG_POST_KEY, d_key);
 }
 
-static inline int
+static int
 dlg_mouse_event (Dlg_head * h, Gpm_Event * event)
 {
 Widget *item;
@@ -826,7 +826,7 @@ void dlg_process_event (Dlg_head *h, int
 	dlg_key_event (h, key);
 }
 
-static inline void
+static void
 frontend_run_dlg (Dlg_head *h)
 {
 int d_key;
diff -d -urpN mc.5/src/find.c mc.6/src/find.c
--- mc.5/src/find.c	2009-08-30 05:23:10.0 +0200
+++ mc.6/src/find.c	2009-08-30 16:10:27.0 +0200
@@ -186,7 +186,7 @@ status_update (const char *text)
 label_set_text (status_label, 

Re: [PATCH] trivial: de-inline large functions

[Denys Vlasenko]

On Sunday 30 August 2009 20:55, Sergei Trofimovich wrote:
 On Sun, 30 Aug 2009 16:40:20 +0200
 Denys Vlasenko vda.li...@googlemail.com wrote:
 
  Hi Slava, folks,
  
  The attached patch de-inlines a few functions
  which are large, or not-so-large but nevertheless
  contain more than one function call,
  or contain loops, or contain if's and at least one
  function call, or contain largish objects on stack.
 
 Sure, inlines are generally useless in .c files.
 
  
  Please apply.
 
 Mind try to use 'git commit -s' / 'git format-patch' in order to
 just 'git am' received patch w/o manually patching, forcing us to invent
 commit message, forging original author,etc.?

Please find it attached.

--
vda
From 1f79eb139c2ef16b1fd32eb849b19dc46167c558 Mon Sep 17 00:00:00 2001
From: Denys Vlasenko vda.li...@googlemail.com
Date: Mon, 31 Aug 2009 03:54:10 +0200
Subject: [PATCH] De-inline a few functions which are large

...or not-so-large but nevertheless
contain more than one function call,
or contain loops, or contain if's and at least one
function call, or contain largish objects on stack.

In my experience, in those cases the code size
growth is big enough to not inline stuff.

I guess some of the really big functions
are defined inline because they have, or had in the past,
just one callsite.

But for a few years gcc already does it automatically,
no need to do it by hand and risk code size explosion
when later during code evolution another callsite
is created. This optimization by hand is simply
no longer needed.

Anyway, here is the code size difference:

   textdata bss dec hex filename
 572337   17944  177820  768101   bb865 mc.t5/.obj/src/mc
 567697   17944  177820  763461   ba645 mc.t6/.obj/src/mc

Signed-off-by: Denys Vlasenko vda.li...@googlemail.com
---
 edit/bookmark.c |2 +-
 edit/edit.c |4 ++--
 edit/syntax.c   |6 +++---
 src/achown.c|2 +-
 src/chown.c |2 +-
 src/dialog.c|6 +++---
 src/find.c  |2 +-
 src/hotlist.c   |2 +-
 src/menu.c  |6 +++---
 src/screen.c|8 
 src/tree.c  |2 +-
 src/tty/key.c   |2 +-
 src/viewer/datasource.c |2 +-
 vfs/vfs.c   |8 
 14 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/edit/bookmark.c b/edit/bookmark.c
index e838d16..00dfe8e 100644
--- a/edit/bookmark.c
+++ b/edit/bookmark.c
@@ -49,7 +49,7 @@
appended after each other and the last one is always the one found
by book_mark_found() i.e. last in is the one seen */
 
-static inline struct _book_mark *double_marks (WEdit * edit, struct _book_mark *p)
+static struct _book_mark *double_marks (WEdit * edit, struct _book_mark *p)
 {
 (void) edit;
 
diff --git a/edit/edit.c b/edit/edit.c
index c8e551a..118932a 100644
--- a/edit/edit.c
+++ b/edit/edit.c
@@ -634,7 +634,7 @@ edit_save_position (WEdit *edit)
 }
 
 /* Clean the WEdit stricture except the widget part */
-static inline void
+static void
 edit_purge_widget (WEdit *edit)
 {
 int len = sizeof (WEdit) - sizeof (Widget);
@@ -1030,7 +1030,7 @@ pop_action (WEdit * edit)
 }
 
 /* is called whenever a modification is made by one of the four routines below */
-static inline void edit_modification (WEdit * edit)
+static void edit_modification (WEdit * edit)
 {
 edit-caches_valid = 0;
 edit-screen_modified = 1;
diff --git a/edit/syntax.c b/edit/syntax.c
index df9e3ff..6ef4bfc 100644
--- a/edit/syntax.c
+++ b/edit/syntax.c
@@ -131,7 +131,7 @@ mc_defines_destroy (gpointer key, gpointer value, gpointer data)
 }
 
 /* Completely destroys the defines tree */
-static inline void
+static void
 destroy_defines (GTree **defines)
 {
 g_tree_traverse (*defines, mc_defines_destroy, G_POST_ORDER, NULL);
@@ -292,7 +292,7 @@ compare_word_to_right (WEdit *edit, long i, const char *text,
 return i;
 }
 
-static inline const char *xx_strchr (const unsigned char *s, int c)
+static const char *xx_strchr (const unsigned char *s, int c)
 {
 while (*s = '\005'  *s != (unsigned char) c) {
 	s++;
@@ -300,7 +300,7 @@ static inline const char *xx_strchr (const unsigned char *s, int c)
 return (const char *) s;
 }
 
-static inline struct syntax_rule apply_rules_going_right (WEdit * edit, long i, struct syntax_rule rule)
+static struct syntax_rule apply_rules_going_right (WEdit * edit, long i, struct syntax_rule rule)
 {
 struct context_rule *r;
 int contextchanged = 0, c;
diff --git a/src/achown.c b/src/achown.c
index 6b868c7..cdac098 100644
--- a/src/achown.c
+++ b/src/achown.c
@@ -612,7 +612,7 @@ chown_advanced_done (void)
 }
 
 #if 0
-static inline void do_chown (uid_t u, gid_t g)
+static void do_chown (uid_t u, gid_t g)
 {
 chown (current_panel-dir.list[current_file].fname, u, g);
 file_mark (current_panel, current_file, 0);
diff --git a/src/chown.c b/src/chown.c
index c1d2c8b..486f578 100644
--- a/src/chown.c

Flickering appeared in recent git

[Denys Vlasenko]

Hi,

I rebuilt mc from newer git (two days ago) and I see
a somewhat subtle effect.

On screen updates, mc now flickers.

The simplest way to see it is to open a large xterm window
with mc file view (it is less noticeable on text consoles),
press and hold Ctrl-R (refresh).

In mc built from git a month ago or so, or in some old releases,
nothing noticeable happens. In new mc, I see cursor appearing
randomly in the panel, with the rest of line after cursor cleared
and painted black. It happens on random lines and quickly disappears
and reappears. It happens so often and takes so much time
that Ctrl-R redraw cannot keep up with keyboard repeat -
I release the keys but redraws continue for several seconds.

This effect is not limited to Ctrl-R, it's just the easiest way to see  it.
I see it all the time when screen is updated. For example,
if I stand on a text file and press F4, Esc, F4, Esc repeatedly.
And I do not see it with old mc in this case too.

Does anybody else see this?
-- 
vda
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc

[Denys Vlasenko]

On Wednesday 15 July 2009 21:02, Ilia Maslakov wrote:
  --enable-charset ? ведь ради нее практически все затевалось :)
 
 
  Откуда linux-from-scratch пользователь знает, что
  configure --enable-charset есть хорошо?
 
  Он просто скачал .tar.gz и запустил configure.

 Ну давно хотим чтоб  --enable-charset было по умолчанию,

Ok, here is my report as a fresh user of it.

I rebuilt today's git with this option and mc says at startup:

--- Confirmation ---
-  -
- Chosen display charset (Settings-Display bits)  -
- or source codeset (in mcedit ctrl-t) -
- does not match one set via locale.   -
- Set correct codeset manually or press Fix it -
- to set locale default.   -
-  -
- Or set 'don't ask again' and press Skip  -
-  -
-  [ ] don't ask again -
-  -
-  [ Fix it ][ Skip ]-


There is no Settings-Display bits, it should be
Options-Display bits.

Ok, I select FIx it, go there and I see this:

--- Display bits ---
-  -
-  Input / display codepage:   -
-  Other 8 bit[ Select ]   -
-  -
-  [x] Full 8 bits input   -
-  -
-  -
- [ OK ] [ Cancel ]-


(FYI: my LANG is set to en_US.UTF-8).

So, what should I select here to stop that window from appearing?
[ Select ] button allows me to choose between 0  7-bit ASCII
and 1  Other 8 bit, none of those feels right.

I tried saving mc setup, hoping that needed fix is already there
and just needs to be saved, but I still get that screen on startup.

Please advice what to do.
--
vda
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Today's git seems to be broken

[Denys Vlasenko]

I simply run:

./autogen.sh
./configure
make

and it ends with

gcc -std=gnu99 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I.. -g -O2 -Wall -o mc achown.o background.o boxes.o chmod.o chown.o
cmd.o color.o command.o complete.o cons.handler.o dialog.o dir.o
execute.o ext.o file.o filegui.o filenot.o fileopctx.o find.o findme.o
glibcompat.o help.o hotlist.o info.o key.o keyxdef.o layout.o learn.o
listmode.o logging.o main.o menu.o mountlist.o mouse.o option.o
panelize.o popt.o poptconfig.o popthelp.o poptparse.o rxvt.o screen.o
setup.o slint.o subshell.o textconf.o tree.o treestore.o tty.o user.o
util.o utilunix.o view.o widget.o win.o wtools.o x11conn.o ecs.o
strutil.o strutilascii.o strutil8bit.o strutilutf8.o strescape.o
-Wl,--export-dynamic  ../edit/libedit.a ../vfs/libvfs-mc.a
-lgmodule-2.0 -ldl -lglib-2.0 -lslang search/.libs/libsearch.a
mcconfig/.libs/libmcconfig.a
view.o: In function `view_search_cmd':
/root/srcdevel/mc/fix/mc.t9/src/view.c:3328: undefined reference to
`str_convert_to_input'
collect2: ld returned 1 exit status
make[3]: *** [mc] Error 1
make[3]: Leaving directory `/root/srcdevel/mc/fix/mc.t9/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/srcdevel/mc/fix/mc.t9/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/srcdevel/mc/fix/mc.t9'
make: *** [all] Error 2

I'd hazard to guess src/charsets.c is not wired up into Makefile machinery...
--
vda
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

[BUG] memory leak in src/file.c::copy_dir_dir()

[Denys Vlasenko]

Hi,

Noticed this memory leak while working on another problem.
Watch variable d:

char *d;

/* First get the mode of the source dir */
  retry_src_stat:
if ((*ctx-stat_func) (s, cbuf)) {
return_status =
file_error (_( Cannot stat source directory \%s\ \n %s ), s);
if (return_status == FILE_RETRY)
goto retry_src_stat;
return return_status;
}

if (is_in_linklist (dest_dirs, s, cbuf)) {
/* Don't copy a directory we created before (we don't want to copy.
   infinitely if a directory is copied into itself) */
/* FIXME: should there be an error message and FILE_SKIP? - Norbert */
return FILE_CONT;
}

d = strutils_shell_unescape (_d);

/* Hmm, hardlink to directory??? - Norbert */
/* FIXME: In this step we should do something
   in case the destination already exist */
/* Check the hardlinks */
if (ctx-preserve  cbuf.st_nlink  1
 check_hardlinks (s, d, cbuf) == 1) {
/* We have made a hardlink - no more processing is necessary */
g_free(d);
return return_status;
}

if (!S_ISDIR (cbuf.st_mode)) {
return_status =
file_error (_( Source \%s\ is not a directory \n %s ), s);
if (return_status == FILE_RETRY)
//bug: leaking d
goto retry_src_stat;
g_free(d);
return return_status;
}


The fix is simple: move g_free(d) up two lines.

Please, can someone with write access do this? Thanks.
--
vda
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

[PATCH] wire up visible_{tabs, tws} in editor's config dialog (fix bug 1384)

[Denys Vlasenko]

From bug 1384 description:

=
I like a new feature of specially displayed tabs
and trailing spaces, but sometimes they are getting
in the way. For example, when I want to cut-and-paste
with the mouse, I usually do not want it.

Also, inevitably there will be users which actively
dislike this feature. It's better for the project
if it supports those users too.

The most comprehensive solution would be two-fold:

Add a config option for it in F9-Options-General
(takes care of those users who hate whitespace
highlighting and want it off by default), and

Add a menu item to F9-Edit to toggle whitespace
highlighting temporarily with a key combination.
=

I discovered that this is already conditionalzed in the code,
just not tweakable by config dialog.

6.patch fixes it, and also it makes _trailing_ tabs
to show up as tabs if visible_tabs = 0 but visible_tws = 1.

Please apply.

7.patch is follow-up whitespace and formatting cleanup,
no code changes. Apply it if it looks ok to you.
It does not relate to the fix per se, just catering to my
perfectionist itch.

Signed-off-by: Denys Vlasenko vda.li...@googlemail.com
--
vda
diff -d -urpN mc.5/edit/editdraw.c mc.6/edit/editdraw.c
--- mc.5/edit/editdraw.c	2009-06-29 14:06:35.0 +0200
+++ mc.6/edit/editdraw.c	2009-07-01 15:21:53.0 +0200
@@ -442,7 +442,7 @@ edit_draw_this_line (WEdit *edit, long b
 		case '\t':
 		i = TAB_SIZE - ((int) col % TAB_SIZE);
 		col += i;
-		if (use_colors  visible_tabs) {
+		if (use_colors  (visible_tabs || (visible_tws  q = tws))) {
 			if (p-style  MOD_MARKED)
 			c = (p-style);
 			else
diff -d -urpN mc.5/edit/editoptions.c mc.6/edit/editoptions.c
--- mc.5/edit/editoptions.c	2009-06-29 14:06:35.0 +0200
+++ mc.6/edit/editoptions.c	2009-07-01 15:21:53.0 +0200
@@ -38,7 +38,7 @@
 #include ../src/dialog.h	/* B_CANCEL */
 #include ../src/wtools.h	/* QuickDialog */
 
-#define OPT_DLG_H 19
+#define OPT_DLG_H 21
 #define OPT_DLG_W 72
 
 static const char *key_emu_str[] =
@@ -67,6 +67,8 @@ edit_options_dialog (void)
 int toption_save_position = option_save_position;
 int tedit_confirm_save = edit_confirm_save;
 int tedit_syntax_highlighting = option_syntax_highlighting;
+int tedit_visible_tabs = visible_tabs;
+int tedit_visible_tws = visible_tws;
 int tedit_persistent_selections = option_persistent_selections;
 int toption_return_does_auto_indent = option_return_does_auto_indent;
 int toption_backspace_through_tabs = option_backspace_through_tabs;
@@ -81,16 +83,16 @@ edit_options_dialog (void)
 	{quick_button, 2, 10, OPT_DLG_H - 3, OPT_DLG_H, N_(OK), 0,
 	 B_ENTER, 0, 0, NULL, NULL, NULL},
 	/* 2 */
-	{quick_label, OPT_DLG_W / 2, OPT_DLG_W, OPT_DLG_H - 7, OPT_DLG_H,
+	{quick_label, OPT_DLG_W / 2, OPT_DLG_W, OPT_DLG_H - 6, OPT_DLG_H,
 	 N_(Word wrap line length: ), 0, 0, 0, 0, NULL, NULL, NULL},
 	/* 3 */
-	{quick_input, OPT_DLG_W / 2 + 24, OPT_DLG_W, OPT_DLG_H - 7,
+	{quick_input, OPT_DLG_W / 2 + 24, OPT_DLG_W, OPT_DLG_H - 6,
 	 OPT_DLG_H, , OPT_DLG_W / 2 - 4 - 24, 0, 0, 0, edit-word-wrap, NULL, NULL},
 	/* 4 */
-	{quick_label, OPT_DLG_W / 2, OPT_DLG_W, OPT_DLG_H - 6, OPT_DLG_H,
+	{quick_label, OPT_DLG_W / 2, OPT_DLG_W, OPT_DLG_H - 7, OPT_DLG_H,
 	 N_(Tab spacing: ), 0, 0, 0, 0, NULL, NULL, NULL},
 	/* 5 */
-	{quick_input, OPT_DLG_W / 2 + 24, OPT_DLG_W, OPT_DLG_H - 6,
+	{quick_input, OPT_DLG_W / 2 + 24, OPT_DLG_W, OPT_DLG_H - 7,
 	 OPT_DLG_H, , OPT_DLG_W / 2 - 4 - 24, 0, 0, 0,
 	 edit-tab-spacing, NULL, NULL},
 	/* 6 */
@@ -99,36 +101,41 @@ edit_options_dialog (void)
 	/* 7 */
 	{quick_checkbox, OPT_DLG_W / 2 + 1, OPT_DLG_W, OPT_DLG_H - 10,
 	 OPT_DLG_H, N_(Syntax highlighting), 8, 0, 0, 0, NULL, NULL, NULL},
-	/* 7 */
+	/* 8 */
 	{quick_checkbox, OPT_DLG_W / 2 + 1, OPT_DLG_W, OPT_DLG_H - 11,
-	 OPT_DLG_H, N_(Save file position), 0, 0, 0, 0, NULL, NULL, NULL},
+	 OPT_DLG_H, N_(Visible tabs), 8, 0, 0, 0, NULL, NULL, NULL},
 	/* 9 */
 	{quick_checkbox, OPT_DLG_W / 2 + 1, OPT_DLG_W, OPT_DLG_H - 12,
-	 OPT_DLG_H, N_(Confirm before saving), 6, 0, 0, 0, NULL, NULL, NULL},
+	 OPT_DLG_H, N_(Visible trailing spaces), 8, 0, 0, 0, NULL, NULL, NULL},
 	/* 10 */
 	{quick_checkbox, OPT_DLG_W / 2 + 1, OPT_DLG_W, OPT_DLG_H - 13,
-	 OPT_DLG_H, N_(Fill tabs with spaces), 0, 0, 0, 0, NULL, NULL, NULL},
+	 OPT_DLG_H, N_(Save file position), 0, 0, 0, 0, NULL, NULL, NULL},
 	/* 11 */
 	{quick_checkbox, OPT_DLG_W / 2 + 1, OPT_DLG_W, OPT_DLG_H - 14,
-	 OPT_DLG_H, N_(Return does autoindent), 0, 0, 0, 0, NULL, NULL, NULL},
+	 OPT_DLG_H, N_(Confirm before saving), 6, 0, 0, 0, NULL, NULL, NULL},
 	/* 12 */
 	{quick_checkbox, OPT_DLG_W / 2 + 1, OPT_DLG_W, OPT_DLG_H - 15,
-	 OPT_DLG_H, N_(Backspace through tabs), 0, 0, 0, 0, NULL, NULL, NULL},
+	 OPT_DLG_H, N_(Fill tabs with spaces), 0, 0, 0, 0, NULL, NULL, NULL},
 	/* 13 */
 	{quick_checkbox, OPT_DLG_W / 2 + 1, OPT_DLG_W, OPT_DLG_H - 16

My experience with current'ish git

[Denys Vlasenko]

Hi Slava, all,

I am happy to see that your development efforts on MC did not remain
just good intentions.

Now you face a har part: how to make your project successful.

I will try to help, at least by reporting bugs.

Currently, I have 5 bugs reported total. One is already fixed:
#411make loops, rerunning configure ad infinitum
and I can confirm it works now. Thanks!

This one is marked as a dup:
#1386   editor: F7 search does not remember last search string across
editing sessions

These are open:
#414Regression: shell patterns in copy dialog do not work
#1384   Whitespace highlighting should be optional
#1385   File search dialog is more difficult to use compared to 4.6.1


A word on the project in general.

Any open-source project requires not only technical skill, but also
some social skills. Projects fail when they are closed-minded, where
developers assume I'm the boss - you are the idiot mentality.

It is not always easy to remember that users come to you with their
complains because they are using your software, and something is not
working right. Indirectly, they bring you an important thing:
they do debugging for you in various scenarios you personally
never use.

Caring for users' bug reports and bugs in bugzilla is not a very
inspiring work, but if you do it regularly, you are taking
an invisible advantage of the work users already did before
they wrote an email/bug report: *they diagnosed a problem for you*.
You do not need to do it by now.

And also you show users that their efforts are not wasted.
It's very frustrating to spend days creating a bug report
for a project, only to see it staying open for months/years,
with not a single comment from developers...
Don't let your users feel this way.

If you can't fix it right away, at least let reporter know
what you think: It is not a bug (explain why),
This is easy to fix, This is hard to fix etc.

Sometimes you can write in a few lines how this can be fixed
(after all, you know the source better than the reporter,
and may see what the solution will be), and hint that it will
go faster if someone can try to make a patch
and user will do it for you! ;) ;)

Yes, some users are newbies, and some are real idiots who can abuse
your attention. But not all of them. Filter out idiots,
direct newbies to Google/Wiki/other info sources,
work with the rest.

If you'll do it, you'll notice that some of your users will start
helping you more. They will send patches, not just bug reports.

Don't know how useful above mumblings are... those are just my thoughts
about ways to be a successful project.

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

Re: My experience with current'ish git

[Denys Vlasenko]

On Monday 29 June 2009 17:20, Slava Zanko wrote:
 Denys Vlasenko wrote:
  Caring for users' bug reports and bugs in bugzilla is not a very
  inspiring work, but if you do it regularly, you are taking
  an invisible advantage of the work users already did before
  they wrote an email/bug report: *they diagnosed a problem for you*.
  You do not need to do it by now.
 
 At now, too much open bugs and feature request. Some bugs very old, some
 bugs we have added themselves... Very hard to balance before priority of
 bugs. For one man bug very critical, for others - not important...

I usually prioritize so that I fix easy bugs,
ask for more info in bugs with unclear description,
explain what user did wrong in non-bugs,
let user know when I can't reproduce a bug.
When no more info comes from user for these cases,
I close the bug in a month or so.

This way, only harder bug remain in the bugzilla.
So it stays manageable.


It's ok when you have many bugs. It may take some time before you
will be able to fix bugs faster than they appear. For some complex
projects like compiler or web browser, it's nearly impossible :)

What is wrong is when a project stops treating bugzilla as
a TODO list, stops trying to shrink it and starts to see it
as an endless supply of user's whining.


 Relative to us, is this mean, that we need to write comment in any case
 into new bugreport?

Yes, this is useful. Do not leave a fresh bug with no comments for months.


  Don't know how useful above mumblings are... those are just my t
  houghts 
  about ways to be a successful project.
 
 Denys, big thanks for you help. Our work (development of mc) looks not
 good from other side, I'm understand it :(.

I do not imply that you are not doing maintainer's work good enough.
So far it looks ok.

For example, search dialog now matches old version regarding
keyboard navigation. Someone fixed a bug I whined about! Thanks! :)

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

[PATCH] trivial optimization in file.c::panel_operate()

[Denys Vlasenko]

Hi Slava,

I noticed an incorrectly indented if() in file.c::panel_operate().
Took a better look, and found out it can be tweaked in several ways.

This patch is the result.
It contains the following trivial optimizations:

* merged two identical dest_dir_ = g_strdup (dest_dir) ops.
* simplified check for trailing '/' (no need to strcmp 1-char string).
* since g_free (NULL) is safe, merged two separate
  if empty string then bail out code paths.
* fixed wording in a comment.

Slava, is it ok to send patches in attachments?

Do you want kernel-style Signed-off-by lines in patch submissions?
--
vda
diff -d -urpN mc.1/src/file.c mc.2/src/file.c
--- mc.1/src/file.c	2009-06-16 16:57:06.0 +0200
+++ mc.2/src/file.c	2009-06-17 14:58:30.0 +0200
@@ -1806,19 +1806,18 @@ panel_operate (void *source_panel, FileO
 	else
 	dest_dir = panel-cwd;
 	/*
-	 * Add trailing backslash only when do non-locally ops.
+	 * Add trailing backslash only when do non-local ops.
 	 * It saves user from occasional file renames (when destination
 	 * dir is deleted)
 	 */
-	if (force_single)
-	/* just copy */
-	dest_dir_ = g_strdup (dest_dir);
-	else
+	if (!force_single
+	  dest_dir[0]
+	  dest_dir[strlen(dest_dir)-1] != PATH_SEP) {
 	/* add trailing separator */
-	if (*dest_dir  strcmp(dest_dir[strlen(dest_dir)-1], PATH_SEP_STR)) {
-		dest_dir_ = g_strconcat (dest_dir, PATH_SEP_STR, (char*)0);
+	dest_dir_ = g_strconcat (dest_dir, PATH_SEP_STR, (char*)0);
 	} else {
-		dest_dir_ = g_strdup (dest_dir);
+	/* just copy */
+	dest_dir_ = g_strdup (dest_dir);
 	}
 	if (!dest_dir_) {
 	file_op_context_destroy (ctx);
@@ -1830,11 +1829,7 @@ panel_operate (void *source_panel, FileO
 			  single_entry, do_bg);
 	g_free(dest_dir_);
 
-	if (!dest) {
-	file_op_context_destroy (ctx);
-	return 0;
-	}
-	if (!*dest) {
+	if (!dest || !dest[0]) {
 	file_op_context_destroy (ctx);
 	g_free (dest);
 	return 0;
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Further Midnight Commander development

[Denys Vlasenko]

On Fri, Feb 13, 2009 at 7:20 PM, Pavel Tsekov ptse...@gmx.net wrote:
 You might not be aware but I am (still) one of the two official MC
 maintainers.

De jure, maybe you are. De facto, the project is an orphan.

How many more times do I need to submit my patches
to get your attention?

How many millennia do we need to wait to get UTF-8 support?



Slava, how can I start committing fixes to devel branch
of your effort?
Basically, I need a mini-HOWTO:

1. What source control system is in use?
   (In case reader is not familiar with one,
   giove an URL to the doc, and also mention
   three most needed commands how to check out
   the tree?, How to update checked-out tree? and
   how to commit local changes to the tree?

2. What mailing list do I need to use for posting patches
   prior to applying them to the tree?

3. Do I need to get approval from someone (as a reply
   on that list?), and can I apply the patch after that
   (IOW: do I have write access?), or do I need to hand
   the patch to someone else?


Regarding (3). MC project is in such sorry state now,
it can't possibly become worse if someone will start working
on it. At worst, the effort can be just dropped,
if the set of people with write access will prove incapable
of going decent work, and we will be back at 4.6.2 (IIRC).

So let's not get busy erecting overly restrictive rules
regarding development, WE BADLY NEED DEVELOPMENT TO HAPPEN.

Regarding stable and devel branches, yes, this is a usual
practice for projects of moderate size. Let's do it that way.
Say, stable will have 4.7.0, 4.7.1, 4.7.2 releases planned
with moderately simple fixes only,
and devel will evolve for some time to create new stable
4.8.x branch sometime in the future.

We need to stop talking about great plans and start coding.
Give me a devel branch to play with! :) :) :)
--
vda
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Re[2]: Further Midnight Commander development

[Denys Vlasenko]

On Mon, Feb 16, 2009 at 3:02 PM, Pavel Tsekov ptse...@gmx.net wrote:
 Hello Denys,

 Monday, February 16, 2009, 3:15:45 PM, you wrote:

 On Fri, Feb 13, 2009 at 7:20 PM, Pavel Tsekov ptse...@gmx.net wrote:
 You might not be aware but I am (still) one of the two official MC
 maintainers.

 De jure, maybe you are. De facto, the project is an orphan.

 How many more times do I need to submit my patches
 to get your attention?

 If I am not mistaken most of your patches were incomplete  and you
 wouldn't bother to fix them.

Oh really. I just checked.

http://mlblog.osdir.com/gnome.apps.mc.general/2004-10/index.shtml
http://www.mail-archive.com/mc-devel@gnome.org/msg05103.html

24/10/2004 - I posted the patch for the 1st time
sometime later - I added it to bug database as well
07/11/2005 - patch was rediscovered and an active discussion started
(which means there was more than one reply per year)
12/08/2006 - patch got applied

By this time, of course, I didn't track the fate of the patch.

THREE YEARS for a teensy patch like this???!!

http://mlblog.osdir.com/gnome.apps.mc.general/2004-10/txt4mW4MB9qlO.txt

You are glacial.


Another patch, which I posted more than once, and this one
is not applied:

http://www.mail-archive.com/mc-devel@gnome.org/msg05526.html

You didn't even have any objections. You just dropped the ball.

You know, I have more interesting things to do in this life
than spending three more years getting it applied.
Especially that it is a bit bigger, who knows, maybe
I'm being optimistic about three years here...

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

Re: Further Midnight Commander development

[Denys Vlasenko]

On Monday 16 February 2009 20:17, Pavel Tsekov wrote:
 So you want to bitch... I really cannot help you with that.

How much did I bitch in these years while the patch
was lying around? URL please.

In case you did not notice, I want to code.
I want to help MC to improve and sligtly more
than glacial pace.

 If enough 
 people complained that you patch wasn't included in the tree I guess
 it would have been included.

Look at the stats of the list. They are pitiful.

2008-November: [ Thread ] [ Date ] [ Author ]   [ Gzip'd Text 28226 bytes ]
2008-October:  [ Thread ] [ Date ] [ Author ]   [ Gzip'd Text 22216 bytes ]
2008-September:[ Thread ] [ Date ] [ Author ]   [ Gzip'd Text 19325 bytes ]
2008-August:   [ Thread ] [ Date ] [ Author ]   [ Gzip'd Text 32094 bytes ]
2008-July: [ Thread ] [ Date ] [ Author ]   [ Gzip'd Text 35622 bytes ]
2008-June: [ Thread ] [ Date ] [ Author ]   [ Gzip'd Text 95316 bytes ]
2008-May:  [ Thread ] [ Date ] [ Author ]   [ Gzip'd Text 6232 bytes ]
2008-April:[ Thread ] [ Date ] [ Author ]   [ Gzip'd Text 8738 bytes ]
2008-March:[ Thread ] [ Date ] [ Author ]   [ Gzip'd Text 62349 bytes ]

April 2008. Whole SIX mails during a month?
October. Twelve mails. Yeah. That's the spark of activity.

Most people *ignored your list* as nothing was happening here.
Me included.


  Another patch, which I posted more than once, and this one
  is not applied:
 
  http://www.mail-archive.com/mc-devel@gnome.org/msg05526.html
 
  You didn't even have any objections. You just dropped the ball.
 
 I made an observation and you failed to follow up.

I wonder how many users of my project I would piss off
with attitudes like that.

 Obviously I must have red the patch and the code since I made
 that observation. I spent some of my time on it but you wouldn't
 care to explain why the patch is necessary.

Read my mail again. I did explain how to see the bug in action,
it's quite trivial.

 Sorry - it doesn't work like that. 

We'll see.

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

Re: Further Midnight Commander development

[Denys Vlasenko]

2008/12/23 Patrick Winnertz win...@debian.org:
 Am Monday 22 December 2008 21:02:21 schrieben Sie:
 Patrick Winnertz wrote:
  If yes I'll set up a trac on my private server until I find a better
  solution. If this repro is ready I'll ping you and we can start to
  migrate you patches into the git repro. Is this okay for you (and the
  rest of the team?)

 Team vote 100% yes
 We are ready to work with you.
 Cool.

 So please:

 All people who wants to have write access to the repro should send mail
 (preffered signed) to me (win...@debian.org) and I'll create a new ssh account
 for committing into the git repro.

 Furthermore I would need  the usernames for trac.. I'll create random
 passwords and send them then to you indiviually so that you can change them
 after that.

 After this I'll/We'll could start to migrate the stuff from the mc.redhat-
 club.org team into this repro.

I would like to participate. vda.linux or vda_linux
are my preferred usernames.
--
vda
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Resolving symlinked dirs when execing command

[Denys Vlasenko]

Hi Pavel,

On Thursday 11 October 2007 14:40, Pavel Tsekov wrote:
  $ pwd
  /auto/software
  
  It differs from what happens under e.g. shell:
  
  sh-3.1$ cd /software
  sh-3.1$ pwd
  /software
  
  Why mc resolves dir and cd'es into it before it forks a child?
 
 I am not able to reporoduce this behaviour. If you want me to track it
 down you'll have to give more details. I tried with latest CVS version of MC 
 with subshell support enabled. I created a link to a random directory and 
 entered it via cd linkname entered from the prompt widget, then I pressed 
 Ctrl + O and in the subshell I ended up in linkname and not in the resolved 
 directory. Also running `pwd' from the prompt widget did not print the 
 resolved dir but linbkname.

I was wrong. In Unix, there is no remebering of which
symlink you followed by chdir'ing here. shell just tries
to help with that. pwd builtin will lie, but real
current directory cannot be a symlink:

sh-3.1$ ls -l /software
lrwxrwxrwx1 root root   14 Jun 26 12:23 /software - 
/auto/software

sh-3.1$ cd /software

sh-3.1$ pwd
/software   === shell lied to you

sh-3.1$ /bin/pwd
/auto/software == truth

--
vda

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

Re: GNU Midnight Commander 4.6.2-pre1

[Denys Vlasenko]

On Thursday 13 September 2007 09:30, Pavel Tsekov wrote:
 Hello,
 
 I've prepared the fist pre-release of GNU Midnight Commander 4.6.2 . Please, 
 download it and give it a try.

I found the following issues:


Alt-O behavior changes for the worse:

4.6.1: make inactive panel show the same dir as active one

4.6.2: make inactive panel show the .. if we stand on non directory
   or directory we stand on.

I find 4.6.1 behavior more consistent and useful.


F5-copying a file on itself bring Error: FILE and FILE are the same file
without buttons. Pressing ESC dismisses it

But if you did this on a big directory (e.g. kernel source tree),
you will get Error: FILE2 and FILE2 are the same file, then
Error: FILE3 and FILE3 are the same file

Error: FILE91476981243 and FILE91476981243 are the same file
...
without the possibility to stop the stream of messages.
mc insists on making you see them all.
On big directory, you may need to hold ESC depressed for minutes
in order to dismiss them all.

I sent a patch which fixes this by adding [skip] and [abort] buttons.
In case it was missed, I attach it again now. Applies with some offsets,
run-tested.


I am pleased with some new and improved features. For example, Find file
how has [x] Regular expression. Good work, thanks!
--
vda
diff -urpN mc-4.6.1.org/src/file.c mc-4.6.1.cp/src/file.c
--- mc-4.6.1.org/src/file.c	2005-05-27 16:19:18.0 +0200
+++ mc-4.6.1.cp/src/file.c	2007-05-18 16:00:23.0 +0200
@@ -458,6 +458,25 @@ enum {
 DEST_FULL			/* Created, fully copied */
 };
 
+static int warn_same_file(const char *fmt, const char *a, const char *b)
+{
+char *msg;
+/* We don't expect %d etc, just %s, so strlen(fmt) should be ok */
+int n = strlen(fmt) + strlen(a) + strlen(b) + 1;
+
+msg = malloc(n);
+if (msg) {
+	snprintf(msg, n, fmt, a, b);
+	n = query_dialog (MSG_ERROR, msg,
+		D_ERROR, 2, _(Skip), _(Abort));
+	free(msg);
+	do_refresh ();
+	if (n) /* 1 == Abort */
+	return FILE_ABORT;
+}
+return FILE_SKIP;
+}
+
 int
 copy_file_file (FileOpContext *ctx, const char *src_path, const char *dst_path,
 		int ask_overwrite, off_t *progress_count,
@@ -512,12 +531,9 @@ copy_file_file (FileOpContext *ctx, cons
 
 if (dst_exists) {
 	/* Destination already exists */
-	if (sb.st_dev == sb2.st_dev  sb.st_ino == sb2.st_ino) {
-	message (1, MSG_ERROR,
-		_( `%s' and `%s' are the same file ), src_path, dst_path);
-	do_refresh ();
-	return FILE_SKIP;
-	}
+	if (sb.st_dev == sb2.st_dev  sb.st_ino == sb2.st_ino)
+	return warn_same_file(_( `%s' and `%s' are the same file ),
+src_path, dst_path);
 
 	/* Should we replace destination? */
 	if (ask_overwrite) {
@@ -1043,22 +1059,8 @@ move_file_file (FileOpContext *ctx, cons
 
 if (mc_lstat (d, dst_stats) == 0) {
 	if (src_stats.st_dev == dst_stats.st_dev
-	 src_stats.st_ino == dst_stats.st_ino) {
-	int msize = COLS - 36;
-	char st[MC_MAXPATHLEN];
-	char dt[MC_MAXPATHLEN];
-
-	if (msize  0)
-		msize = 40;
-	msize /= 2;
-
-	strcpy (st, path_trunc (s, msize));
-	strcpy (dt, path_trunc (d, msize));
-	message (1, MSG_ERROR,
-			_( `%s' and `%s' are the same file ), st, dt);
-	do_refresh ();
-	return FILE_SKIP;
-	}
+	 src_stats.st_ino == dst_stats.st_ino)
+	return warn_same_file(_( `%s' and `%s' are the same file ), s, d);
 
 	if (S_ISDIR (dst_stats.st_mode)) {
 	message (1, MSG_ERROR,
@@ -1161,22 +1163,8 @@ move_dir_dir (FileOpContext *ctx, const 
 } else
 	destdir = concat_dir_and_file (d, x_basename (s));
 
-if (sbuf.st_dev == dbuf.st_dev  sbuf.st_ino == dbuf.st_ino) {
-	int msize = COLS - 36;
-	char st[MC_MAXPATHLEN];
-	char dt[MC_MAXPATHLEN];
-
-	if (msize  0)
-	msize = 40;
-	msize /= 2;
-
-	strcpy (st, path_trunc (s, msize));
-	strcpy (dt, path_trunc (d, msize));
-	message (1, MSG_ERROR,
-		_( `%s' and `%s' are the same directory ), st, dt);
-	do_refresh ();
-	return FILE_SKIP;
-}
+if (sbuf.st_dev == dbuf.st_dev  sbuf.st_ino == dbuf.st_ino)
+	return warn_same_file(_( `%s' and `%s' are the same directory ), s, d);
 
 /* Check if the user inputted an existing dir */
   retry_dst_stat:
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Getting ready for a release

[Denys Vlasenko]

On Tuesday 04 September 2007 09:57, Pavel Tsekov wrote:
 Hello,
 
 As it has been discussed on the mailing list a new release of MC is long 
 overdue. So... I plan to release a new version of MC by mid October. This 
 gives us about a month (till the end of September) for final testing, bug 
 reporting, fixing, updating translations and other related tasks - the last 
 two are to be used by translators to update the MC translation. I hope that 
 everyone interested will participate in this process so that we can finally 
 release a new version.
 
 There are three full weeks by the end of September which can be used to 
 release at most 3 pre-releases and give each a week of testing and polishing 
 (depending on the user feedback). I am going to wait till the end of this 
 week for your suggestions on how to use the remaining three weeks and make a 
 plan according to them, then I'll publish the first pre-release on Monday. 
 This reminds me that we have another problem to solve -
 how are we going to number the new release ? Please, share your thoughts on 
 that too.

Please include the following patches:

[PATCH] 'a' and 'b' are the same file/directory message box needs Abort 
button.
http://www.mail-archive.com/mc-devel@gnome.org/msg05524.html

and

Fwd: [PATCH] make old escmode key timeout configurable
http://osdir.com/ml/gnome.apps.mc.devel/2004-10/msg00212.html

Attached versions of these patches apply cleanly to 1.6.1.

Thanks,
--
vda
diff -urpN mc-4.6.1.org/src/key.c mc-4.6.1/src/key.c
--- mc-4.6.1.org/src/key.c	2005-06-08 14:27:19.0 +0200
+++ mc-4.6.1/src/key.c	2007-05-18 13:49:17.0 +0200
@@ -73,7 +73,7 @@
 			 (t2.tv_usec-t1.tv_usec)/1000)
 			 
 /* timeout for old_esc_mode in usec */
-#define ESCMODE_TIMEOUT 100
+#define ESCMODE_TIMEOUT keyboard_key_timeout
 
 /* Linux console keyboard modifiers */
 #define SHIFT_PRESSED 1
@@ -85,6 +85,7 @@
 int mou_auto_repeat = 100;
 int double_click_speed = 250;
 int old_esc_mode = 0;
+int keyboard_key_timeout = 100;	/* settable via env */
 
 int use_8th_bit_as_meta = 0;
 
@@ -427,6 +428,10 @@ init_key (void)
 {
 const char *term = getenv (TERM);
 
+char *kt = (char *)getenv(KEYBOARD_KEY_TIMEOUT_US);
+if (kt != NULL)
+	keyboard_key_timeout = atoi(kt);
+
 /* This has to be the first define_sequence */
 /* So, we can assume that the first keys member has ESC */
 define_sequences (mc_default_keys);
diff -urpN mc-4.6.1.org/src/utilunix.c mc-4.6.1/src/utilunix.c
--- mc-4.6.1.org/src/utilunix.c	2005-07-23 18:52:03.0 +0200
+++ mc-4.6.1/src/utilunix.c	2007-05-18 13:42:31.0 +0200
@@ -240,8 +240,9 @@ mc_tmpdir (void)
 struct stat st;
 const char *error = NULL;
 
-/* Check if already initialized */
-if (tmpdir)
+/* Check if already initialized and still exists */
+/* (some people run automatic /tmp cleaners...) */
+if (tmpdir  lstat (tmpdir, st) == 0)
 	return tmpdir;
 
 sys_tmp = getenv (TMPDIR);
diff -urpN mc-4.6.1.org/src/file.c mc-4.6.1.cp/src/file.c
--- mc-4.6.1.org/src/file.c	2005-05-27 16:19:18.0 +0200
+++ mc-4.6.1.cp/src/file.c	2007-05-18 16:00:23.0 +0200
@@ -458,6 +458,25 @@ enum {
 DEST_FULL			/* Created, fully copied */
 };
 
+static int warn_same_file(const char *fmt, const char *a, const char *b)
+{
+char *msg;
+/* We don't expect %d etc, just %s, so strlen(fmt) should be ok */
+int n = strlen(fmt) + strlen(a) + strlen(b) + 1;
+
+msg = malloc(n);
+if (msg) {
+	snprintf(msg, n, fmt, a, b);
+	n = query_dialog (MSG_ERROR, msg,
+		D_ERROR, 2, _(Skip), _(Abort));
+	free(msg);
+	do_refresh ();
+	if (n) /* 1 == Abort */
+	return FILE_ABORT;
+}
+return FILE_SKIP;
+}
+
 int
 copy_file_file (FileOpContext *ctx, const char *src_path, const char *dst_path,
 		int ask_overwrite, off_t *progress_count,
@@ -512,12 +531,9 @@ copy_file_file (FileOpContext *ctx, cons
 
 if (dst_exists) {
 	/* Destination already exists */
-	if (sb.st_dev == sb2.st_dev  sb.st_ino == sb2.st_ino) {
-	message (1, MSG_ERROR,
-		_( `%s' and `%s' are the same file ), src_path, dst_path);
-	do_refresh ();
-	return FILE_SKIP;
-	}
+	if (sb.st_dev == sb2.st_dev  sb.st_ino == sb2.st_ino)
+	return warn_same_file(_( `%s' and `%s' are the same file ),
+src_path, dst_path);
 
 	/* Should we replace destination? */
 	if (ask_overwrite) {
@@ -1043,22 +1059,8 @@ move_file_file (FileOpContext *ctx, cons
 
 if (mc_lstat (d, dst_stats) == 0) {
 	if (src_stats.st_dev == dst_stats.st_dev
-	 src_stats.st_ino == dst_stats.st_ino) {
-	int msize = COLS - 36;
-	char st[MC_MAXPATHLEN];
-	char dt[MC_MAXPATHLEN];
-
-	if (msize  0)
-		msize = 40;
-	msize /= 2;
-
-	strcpy (st, path_trunc (s, msize));
-	strcpy (dt, path_trunc (d, msize));
-	message (1, MSG_ERROR,
-			_( `%s' and `%s' are the same file ), st, dt);
-	do_refresh ();
-	return FILE_SKIP;
-	}
+	 src_stats.st_ino == dst_stats.st_ino)
+	

Re: Getting ready for a release

[Denys Vlasenko]

On Tuesday 04 September 2007 10:18, Oswald Buddenhagen wrote:
 On Tue, Sep 04, 2007 at 10:57:42AM +0200, Pavel Tsekov wrote:
  how are we going to number the new release ?
  
 4.7. no exaggerated humbleness, please.

4.7.0.

Fixes can go to stable 4.7.x,
big changes to eventual 4.8.0...
--
vda

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

Re: Getting ready for a release

[Denys Vlasenko]

On Tuesday 04 September 2007 09:57, Pavel Tsekov wrote:
 Hello,
 
 As it has been discussed on the mailing list a new release of MC is long 
 overdue. So... I plan to release a new version of MC by mid October. This 
gives us about a month (till the end of September) for final testing, bug 
reporting, fixing, updating translations and other related tasks - the last 
two are to be used by translators to update the MC translation. I hope that 
everyone interested will participate in this process so that we can finally 
release a new version.

I am currently watching this Google tech talk:

http://kernel.org/doc/video.html

April 19, 2007 Release Management in Large Free Software Projects - Martin 
Michlmayr (Debian)

ABSTRACT: Time based releases are made according to a specific time interval, 
instead of making a release when a particular functionality or set of 
features have been implemented. This talk argues that time based release 
management acts as an effective coordination mechanism in large volunteer 
projects and shows examples from seven projects that have moved to time based 
releases: Debian, GCC, GNOME, Linux, OpenOffice, Plone, and X.org.

Direct link to video: 

http://video.google.com/videoplay?docid=-5503858974016723264


Maybe it will be interesting to you too.
--
vda
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel