'other 8 bit'
Hi!
I use mc in other locales with charset conversion (--enable-charset,
Ctrl-T in viewer). However, I confused by 'Other 8 bit' item in that
conversion menu. I prefer to use current locale charmap.
Who can explain me the main purpose of that?
P.S In attached patch I have changed 'Other 8 bit' to 'Current
charmap'. At begin, the discussion had started here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155974
Thanks for replying!
--
With best regards,
Andy Shevchenko. mailto: [EMAIL PROTECTED]
--- mc-4.6.1-pre3/src/boxes.c.current-charmap 2005-04-27 12:54:29.0
+0300
+++ mc-4.6.1-pre3/src/boxes.c 2005-04-27 12:54:29.0 +0300
@@ -554,7 +554,7 @@ sel_charset_button (int action)
char buf[64];
new_display_codepage = select_charset (new_display_codepage, 1);
cpname = (new_display_codepage 0)
- ? _(Other 8 bit)
+ ? _(Current charmap)
: codepages[new_display_codepage].name;
/* avoid strange bug with label repainting */
@@ -579,7 +579,7 @@ init_disp_bits_box (void)
label_new (3, 4, _(Input / display codepage:)));
cpname = (new_display_codepage 0)
- ? _(Other 8 bit)
+ ? _(Current charmap)
: codepages[new_display_codepage].name;
cplabel = label_new (4, 4, cpname);
add_widget (dbits_dlg, cplabel);
--- mc-4.6.1-pre3/src/selcodepage.c.current-charmap 2004-09-01
20:46:53.0 +0300
+++ mc-4.6.1-pre3/src/selcodepage.c 2005-04-27 12:54:29.0 +0300
@@ -67,7 +67,7 @@ select_charset (int current_charset, int
}
if (seldisplay) {
g_snprintf (buffer, sizeof (buffer), %c %s,
- get_hotkey (n_codepages), _(Other 8 bit));
+ get_hotkey (n_codepages), _(Current charmap));
LISTBOX_APPEND_TEXT (listbox, get_hotkey (n_codepages), buffer,
NULL);
}
@@ -93,19 +93,11 @@ do_select_codepage (void)
{
const char *errmsg;
-if (display_codepage 0) {
- source_codepage = select_charset (source_codepage, 0);
- errmsg =
- init_translation_table (source_codepage, display_codepage);
- if (errmsg) {
- message (1, MSG_ERROR, %s, errmsg);
- return -1;
- }
-} else {
- message (1, _(Warning),
-_(To use this feature select your codepage in\n
- Setup / Display Bits dialog!\n
- Do not forget to save options.));
+source_codepage = select_charset (source_codepage, 0);
+errmsg =
+ init_translation_table (source_codepage, display_codepage);
+if (errmsg) {
+ message (1, MSG_ERROR, %s, errmsg);
return -1;
}
return 0;
--- mc-4.6.1-pre3/src/charsets.c.current-charmap2004-08-30
13:38:00.0 +0300
+++ mc-4.6.1-pre3/src/charsets.c2005-04-27 12:59:57.0 +0300
@@ -24,8 +28,11 @@
#include stdio.h
#include string.h
#include iconv.h
+#include langinfo.h
+#include locale.h
#include global.h
+#include tty.h /* UTF8 */
#include charsets.h
int n_codepages = 0;
@@ -35,6 +42,21 @@ struct codepage_desc *codepages;
unsigned char conv_displ[256];
unsigned char conv_input[256];
+static const char *
+get_current_charmap (void)
+{
+static int init = -1;
+static char *charmap = NULL;
+
+if (init == -1) {
+ char *lc_ctype = setlocale (LC_CTYPE, );
+ charmap = nl_langinfo (CODESET);
+ setlocale (LC_CTYPE, lc_ctype);
+ init = 0;
+}
+return charmap;
+}
+
int
load_codepages_list (void)
{
@@ -119,19 +141,17 @@ free_codepages_list (void)
}
}
-#define OTHER_8BIT Other_8_bit
-
const char *
get_codepage_id (int n)
{
-return (n 0) ? OTHER_8BIT : codepages[n].id;
+return (n 0) ? get_current_charmap () : codepages[n].id;
}
int
get_codepage_index (const char *id)
{
int i;
-if (strcmp (id, OTHER_8BIT) == 0)
+if (strcmp (id, get_current_charmap ()) == 0)
return -1;
for (i = 0; codepages[i].id; ++i)
if (strcmp (id, codepages[i].id) == 0)
@@ -172,9 +192,17 @@ init_translation_table (int cpsource, in
iconv_t cd;
const char *cpsour, *cpdisp;
+cpsour = get_codepage_id (cpsource);
+cpdisp = get_codepage_id (cpdisplay);
+
+if ((cpsour == NULL) || (cpdisp == NULL)) {
+ g_snprintf (errbuf, sizeof (errbuf), _(Cannot get correct codepage
id));
+ return errbuf;
+}
+
/* Fill inpit - display tables */
-if (cpsource 0 || cpdisplay 0 || cpsource == cpdisplay) {
+if ((strcasecmp(cpsour, cpdisp) == 0) || cpsource == cpdisplay) {
for (i = 0; i = 255; ++i) {
conv_displ[i] = i;
conv_input[i] = i;
@@ -187,9 +215,6 @@ init_translation_table (int cpsource, in
conv_input[i] = i;
}
-cpsour = codepages[cpsource].id;
-cpdisp = codepages[cpdisplay].id;
-
/* display - inpit table */
cd = iconv_open (cpdisp, cpsour);
[OT] Re: [bug #12223] shift keys should change function menu descriptions
Hello, This is a pure off topic message. On Tue, 17 May 2005, Leonard den Ottolander wrote: There are at least 2 people who share this opinion, as *I* (not Oswald) was the one to close the bug. Well, don't you think that having an opinion requires you to understand the problem first ? Your opinion is based only on a comment from Oswald. Should we now start a topic about who is trustworthy and who is not ? I personally prefer to rely on someone's trustworthyness as a last option. What I am trying to achieve is to separate the wheat from the chaf. I don't think anyboy will be looking at this issue soon, we are short on developers - when was the last time *you* reviewed or submitted a patch? - hence I closed this bug, so it's easier for me to see the forest through the trees. Same happened for a report from Roland, a valued and active developer, because his report was so closely related to another bug that they should probably be fixed in conjunction. I bow before you, mighty Leo and Roland. Thank you mighty MC gods! When you ask for patches first think whether are you going to review them. And no - MC is not short on developers. IMHO, MC is short on ideas where to go next . So, Leo thank you one more time for excercising you newly granted rights on Savannah. I wonder if it was the lack of rights that prevented you in the past from active participation in Savannah bugs database. It's also cool that Roland have CVS commit access because otherwise we woldn't be able to benefit from his valuable contributions. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #12223] shift keys should change function menu descriptions
Follow-up Comment #11, bug #12223 (project mc): Pavel, is it possible to receive notification when these modifier keys are pressed too? If not, then it is not possible. And are you saying it is possible to, in an xterm, query pressed modifier keys? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=12223 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #12223] shift keys should change function menu descriptions
Follow-up Comment #12, bug #12223 (project mc): pavel wrote: MC already has code which queries the keyboard modifiers on these systems. what does it use them for? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=12223 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #12223] shift keys should change function menu descriptions
Follow-up Comment #13, bug #12223 (project mc): Oskar and Oswald, take a look at src/key.c, get_modifier(). ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=12223 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #8135] Ftp connection to proxy uses always active mode
Follow-up Comment #1, bug #8135 (project mc):
The offending code in ftpfs.c is this:
static int
ftpfs_open_archive_int (struct vfs_class *me, struct vfs_s_super *super)
{
int retry_seconds, count_down;
/* We do not want to use the passive if we are using proxies */
if (SUP.proxy)
SUP.use_passive_connection = 0;
Is there any reason why we should not use passive mode over proxies?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=8135
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #11138] CRITICAL - /dev/pts/N are not freed in kernel 2.6
Update of bug #11138 (project mc): Status:None = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #9: Closing as this is(/was) a kernel issue, not an mc issue. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=11138 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #8135] Ftp connection to proxy uses always active mode
Follow-up Comment #2, bug #8135 (project mc): Please be so kind to test this patch. ___ Additional Item Attachment: File name: passive_proxy.patchSize:2 KB Add extra option to allow passive ftp over proxy http://savannah.gnu.org/bugs/download.php?item_id=8135item_file_id=2510 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=8135 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[PATCH] Re: [bug #8135] Ftp connection to proxy uses always active mode
Hi,
On Wed, 2005-05-18 at 15:01, Leonard den Ottolander wrote:
Please be so kind to test this patch.
___
Additional Item Attachment:
File name: passive_proxy.patchSize:2 KB
Add extra option to allow passive ftp over proxy
http://savannah.gnu.org/bugs/download.php?item_id=8135item_file_id=2510
Maybe I get more response if I also send this patch to the list
directly...
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
--- src/boxes.c.000 2004-09-25 15:46:23.0 +0200
+++ src/boxes.c 2005-05-18 14:49:50.0 +0200
@@ -689,7 +689,7 @@ tree_box (const char *current_dir)
#ifdef USE_VFS
#if defined(USE_NETCODE)
-#define VFSY 16
+#define VFSY 17
#define VFS_WIDGETBASE 9
#else
#define VFSY 8
@@ -706,6 +706,7 @@ static char *ret_directory_timeout;
static char *ret_ftp_proxy;
static int ret_use_netrc;
static int ret_ftpfs_use_passive_connections;
+static int ret_ftpfs_use_passive_connections_over_proxy;
#endif
static QuickWidget confvfs_widgets [] = {
@@ -714,6 +715,8 @@ static QuickWidget confvfs_widgets [] =
{ quick_button, 12, VFSX,VFSY - 3, VFSY, N_(OK),
0, B_ENTER, 0, 0, button-ok },
#if defined(USE_NETCODE)
+{ quick_checkbox, 4, VFSX, 12, VFSY, N_(Use passive mode over proxy), 0, 0,
+ ret_ftpfs_use_passive_connections_over_proxy, 0, check-use-passive-mode-proxy },
{ quick_checkbox, 4, VFSX, 11, VFSY, N_(Use passive mode), 0, 0,
ret_ftpfs_use_passive_connections, 0, check-use-passive-mode },
{ quick_checkbox, 4, VFSX, 10, VFSY, N_(Use ~/.netrc), 0, 0,
@@ -755,6 +758,7 @@ configure_vfs (void)
ret_use_netrc = use_netrc;
ret_ftpfs_use_passive_connections = ftpfs_use_passive_connections;
+ret_ftpfs_use_passive_connections_over_proxy = ftpfs_use_passive_connections_over_proxy;
g_snprintf(buffer3, sizeof (buffer3), %i, ftpfs_directory_timeout);
confvfs_widgets[7].text = buffer3;
confvfs_widgets[9].text = ftpfs_anonymous_passwd;
@@ -776,6 +780,7 @@ configure_vfs (void)
ftpfs_directory_timeout = atoi(ret_directory_timeout);
use_netrc = ret_use_netrc;
ftpfs_use_passive_connections = ret_ftpfs_use_passive_connections;
+ ftpfs_use_passive_connections_over_proxy = ret_ftpfs_use_passive_connections_over_proxy;
g_free (ret_directory_timeout);
#endif
}
--- vfs/ftpfs.h.000 2004-08-17 11:17:43.0 +0200
+++ vfs/ftpfs.h 2005-05-18 14:34:49.0 +0200
@@ -10,6 +10,7 @@ extern int ftpfs_always_use_proxy;
extern int ftpfs_retry_seconds;
extern int ftpfs_use_passive_connections;
+extern int ftpfs_use_passive_connections_over_proxy;
extern int ftpfs_use_unix_list_options;
extern int ftpfs_first_cd_then_ls;
--- vfs/ftpfs.c.000 2005-01-20 18:47:10.0 +0100
+++ vfs/ftpfs.c 2005-05-18 14:38:32.0 +0200
@@ -105,6 +105,7 @@ int ftpfs_retry_seconds = 30;
/* Method to use to connect to ftp sites */
int ftpfs_use_passive_connections = 1;
+int ftpfs_use_passive_connections_over_proxy = 0;
/* Method used to get directory listings:
* 1: try 'LIST -la path', if it fails
@@ -698,8 +699,8 @@ ftpfs_open_archive_int (struct vfs_class
/* We do not want to use the passive if we are using proxies */
if (SUP.proxy)
- SUP.use_passive_connection = 0;
-
+ SUP.use_passive_connection = ftpfs_use_passive_connections_over_proxy;
+
retry_seconds = 0;
do {
SUP.failed_on_login = 0;
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #8135] Ftp connection to proxy uses always active mode
Follow-up Comment #3, bug #8135 (project mc): Forgot to update the indexes of the referenced items. This version should fix that. ___ Additional Item Attachment: File name: passive_proxy.patchSize:3 KB Add extra option to allow passive ftp over proxy http://savannah.gnu.org/bugs/download.php?item_id=8135item_file_id=2511 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=8135 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Re: [bug #8135] Ftp connection to proxy uses always active mode
Hi,
On Wed, 2005-05-18 at 15:18, Leonard den Ottolander wrote:
Maybe I get more response if I also send this patch to the list
directly...
I forgot to fix the indexes of the referenced items in the dialog. This
version should fix that.
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
--- src/boxes.c.000 2004-09-25 15:46:23.0 +0200
+++ src/boxes.c 2005-05-18 15:59:37.0 +0200
@@ -689,7 +689,7 @@ tree_box (const char *current_dir)
#ifdef USE_VFS
#if defined(USE_NETCODE)
-#define VFSY 16
+#define VFSY 17
#define VFS_WIDGETBASE 9
#else
#define VFSY 8
@@ -706,6 +706,7 @@ static char *ret_directory_timeout;
static char *ret_ftp_proxy;
static int ret_use_netrc;
static int ret_ftpfs_use_passive_connections;
+static int ret_ftpfs_use_passive_connections_over_proxy;
#endif
static QuickWidget confvfs_widgets [] = {
@@ -714,6 +715,8 @@ static QuickWidget confvfs_widgets [] =
{ quick_button, 12, VFSX,VFSY - 3, VFSY, N_(OK),
0, B_ENTER, 0, 0, button-ok },
#if defined(USE_NETCODE)
+{ quick_checkbox, 4, VFSX, 12, VFSY, N_(Use passive mode over proxy), 0, 0,
+ ret_ftpfs_use_passive_connections_over_proxy, 0, check-use-passive-mode-proxy },
{ quick_checkbox, 4, VFSX, 11, VFSY, N_(Use passive mode), 0, 0,
ret_ftpfs_use_passive_connections, 0, check-use-passive-mode },
{ quick_checkbox, 4, VFSX, 10, VFSY, N_(Use ~/.netrc), 0, 0,
@@ -755,13 +758,14 @@ configure_vfs (void)
ret_use_netrc = use_netrc;
ret_ftpfs_use_passive_connections = ftpfs_use_passive_connections;
+ret_ftpfs_use_passive_connections_over_proxy = ftpfs_use_passive_connections_over_proxy;
g_snprintf(buffer3, sizeof (buffer3), %i, ftpfs_directory_timeout);
-confvfs_widgets[7].text = buffer3;
-confvfs_widgets[9].text = ftpfs_anonymous_passwd;
-confvfs_widgets[4].text = ftpfs_proxy_host;
+confvfs_widgets[8].text = buffer3;
+confvfs_widgets[10].text = ftpfs_anonymous_passwd;
+confvfs_widgets[5].text = ftpfs_proxy_host;
#endif
g_snprintf (buffer2, sizeof (buffer2), %i, vfs_timeout);
-confvfs_widgets [3 + VFS_WIDGETBASE].text = buffer2;
+confvfs_widgets [4 + VFS_WIDGETBASE].text = buffer2;
if (quick_dialog (confvfs_dlg) != B_CANCEL) {
vfs_timeout = atoi (ret_timeout);
@@ -776,6 +780,7 @@ configure_vfs (void)
ftpfs_directory_timeout = atoi(ret_directory_timeout);
use_netrc = ret_use_netrc;
ftpfs_use_passive_connections = ret_ftpfs_use_passive_connections;
+ ftpfs_use_passive_connections_over_proxy = ret_ftpfs_use_passive_connections_over_proxy;
g_free (ret_directory_timeout);
#endif
}
--- vfs/ftpfs.h.000 2004-08-17 11:17:43.0 +0200
+++ vfs/ftpfs.h 2005-05-18 14:34:49.0 +0200
@@ -10,6 +10,7 @@ extern int ftpfs_always_use_proxy;
extern int ftpfs_retry_seconds;
extern int ftpfs_use_passive_connections;
+extern int ftpfs_use_passive_connections_over_proxy;
extern int ftpfs_use_unix_list_options;
extern int ftpfs_first_cd_then_ls;
--- vfs/ftpfs.c.000 2005-01-20 18:47:10.0 +0100
+++ vfs/ftpfs.c 2005-05-18 14:38:32.0 +0200
@@ -105,6 +105,7 @@ int ftpfs_retry_seconds = 30;
/* Method to use to connect to ftp sites */
int ftpfs_use_passive_connections = 1;
+int ftpfs_use_passive_connections_over_proxy = 0;
/* Method used to get directory listings:
* 1: try 'LIST -la path', if it fails
@@ -698,8 +699,8 @@ ftpfs_open_archive_int (struct vfs_class
/* We do not want to use the passive if we are using proxies */
if (SUP.proxy)
- SUP.use_passive_connection = 0;
-
+ SUP.use_passive_connection = ftpfs_use_passive_connections_over_proxy;
+
retry_seconds = 0;
do {
SUP.failed_on_login = 0;
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #8135] Ftp connection to proxy uses always active mode
Update of bug #8135 (project mc): Status:None = Ready For Test Assigned to:None = leonardjo ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=8135 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #2422] PHP syntax update (full function list)
Update of patch #2422 (project mc): Status:None = Done ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=2422 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Can't close Savannah patches
Hi Pavel, I am unable to close patches in Savannah bugzilla. The open/close item cannot be modified. However I can change the status. Could this be fixed? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #7472] ftpfs: failed; nowhere to fallback to
Follow-up Comment #2, bug #7472 (project mc): See patch 3727 (https://savannah.gnu.org/patch/?func=detailitemitem_id=3727). Does that fix your issue? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7472 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #1129] tilde expansion fix
Update of patch #1129 (project mc): Status:None = Done ___ Follow-up Comment #1: I believe all tilde expansion issues have been fixed in CVS. Please correct me if I'm wrong. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=1129 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #1628] Fix for segfault on large syntax file
Update of patch #1628 (project mc): Status:None = Done ___ Follow-up Comment #4: This has been in CVS for a while now. Report may be closed. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=1628 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #3224] perl and diff syntax
Update of patch #3224 (project mc): Status:None = Done ___ Follow-up Comment #1: Both are in CVS. Can be closed. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=3224 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #3223] perl and diff syntax
Update of patch #3223 (project mc): Status:None = Duplicate ___ Follow-up Comment #1: Duplicate of patch 3224. Already in CVS. Report can be closed. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=3223 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #10645] Directorys like 1234 - foobar are displayed as - foobar on ftpfs and cannot be viewed
Update of bug #10645 (project mc): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: This is a duplicate of bug 4327. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=10645 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #1299] avoid tmpdir removal/substitution
Update of patch #1299 (project mc): Status:None = In Progress ___ Follow-up Comment #1: I'm a bit confused by the summary: avoid tmpdir removal/substitution. Isn't the point of this patch to actually *cause* the substitution of tmpdir when the original location cannot be written to? ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=1299 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
GCC-4.0 warnings
Hi, Here's a list of gcc-4.0 warnings against HEAD from 2005-05-04. Tarball taken from the FC4t3 mc-4.6.1a-0.9.src.rpm. Removed all patches as not to cause confusion between clean CVS and downstream patches. Grepped for warning in the build log. Leonard. -- mount -t life -o ro /dev/dna /genetic/research utilvfs.c:216: warning: pointer targets in assignment differ in signedness utilvfs.c:218: warning: pointer targets in assignment differ in signedness utilvfs.c:223: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness utilvfs.c:637: warning: pointer targets in passing argument 1 of 'is_localized_month' differ in signedness utilvfs.c:739: warning: pointer targets in passing argument 1 of 'is_localized_month' differ in signedness boxes.c:259: warning: pointer targets in passing argument 1 of 'g_strdup' differ in signedness boxes.c:260: warning: pointer targets in passing argument 1 of 'g_strdup' differ in signedness cmd.c:847: warning: pointer targets in passing argument 2 of 'push_history' differ in signedness command.c:196: warning: pointer targets in initialization differ in signedness complete.c:780: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness complete.c:784: warning: pointer targets in assignment differ in signedness complete.c:788: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness complete.c:790: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness complete.c:794: warning: pointer targets in initialization differ in signedness complete.c:794: warning: pointer targets in initialization differ in signedness complete.c:831: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness complete.c:864: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness complete.c:921: warning: pointer targets in passing argument 1 of 'try_complete' differ in signedness file.c:168: warning: pointer targets in passing argument 1 of 'x_basename' differ in signedness file.c:168: warning: pointer targets in initialization differ in signedness file.c:173: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness file.c:174: warning: pointer targets in passing argument 2 of 're_match' differ in signedness file.c:240: warning: pointer targets in passing argument 1 of 'g_strdup' differ in signedness file.c:240: warning: pointer targets in initialization differ in signedness file.c:1873: warning: pointer targets in passing argument 2 of 'transform_source' differ in signedness file.c:1873: warning: pointer targets in assignment differ in signedness file.c:1968: warning: pointer targets in passing argument 2 of 'transform_source' differ in signedness file.c:1968: warning: pointer targets in assignment differ in signedness find.c:167: warning: pointer targets in passing argument 2 of 'regcomp' differ in signedness find.c:303: warning: pointer targets in passing argument 1 of 'g_strdup' differ in signedness find.c:325: warning: pointer targets in passing argument 1 of 'g_strdup' differ in signedness find.c:336: warning: pointer targets in passing argument 1 of 'g_strdup' differ in signedness find.c:337: warning: pointer targets in passing argument 1 of 'g_strdup' differ in signedness learn.c:93: warning: pointer targets in assignment differ in signedness learn.c:101: warning: pointer targets in passing argument 1 of 'strcmp' differ in signedness learn.c:101: warning: pointer targets in passing argument 1 of 'strcmp' differ in signedness learn.c:102: warning: pointer targets in passing argument 1 of 'strcmp' differ in signedness learn.c:102: warning: pointer targets in passing argument 1 of 'strcmp' differ in signedness learn.c:106: warning: pointer targets in assignment differ in signedness learn.c:107: warning: pointer targets in passing argument 1 of 'convert_controls' differ in signedness learn.c:107: warning: pointer targets in assignment differ in signedness learn.c:109: warning: pointer targets in passing argument 2 of 'define_sequence' differ in signedness main.c:1528: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness main.c:1610: warning: pointer targets in assignment differ in signedness menu.c:115: warning: pointer targets in assignment differ in signedness panelize.c:236: warning: pointer targets in passing argument 1 of 'g_strdup' differ in signedness panelize.c:291: warning: pointer targets in assignment differ in signedness poptconfig.c:28: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness poptconfig.c:32: warning: pointer targets in assignment differ in signedness poptconfig.c:38: warning: pointer targets in assignment differ in signedness poptconfig.c:51: warning: pointer targets in passing argument 1 of 'poptParseArgvString' differ in signedness poptconfig.c:63: warning: pointer targets in passing argument 1 of 'strdup' differ in
Re: [OT] Re: [bug #12223] shift keys should change function menu descriptions
Hi Pavel, (Could you please adjust your clock? I missed your post as it is dated 6 years back so it ended up somewhere down in my list.) On Tue, 1999-05-18 at 10:56, Pavel Tsekov wrote: This is a pure off topic message. I was trying to explain my motivations for closing that bug report to Felix. I did that in the appropriate bug report which is also CC-ed to this list. Sure I could have mailed him privately, but I felt I should publicly explain my actions. On Tue, 17 May 2005, Leonard den Ottolander wrote: There are at least 2 people who share this opinion, as *I* (not Oswald) was the one to close the bug. Well, don't you think that having an opinion requires you to understand the problem first ? Your opinion is based only on a comment from Oswald. Should we now start a topic about who is trustworthy and who is not ? I personally prefer to rely on someone's trustworthyness as a last option. So I trusted Oswald's opinion on this matter. He never stated fixing this problem is impossible, but that it's rather difficult. Because I don't see that issue fixed soon I decided to close that report. I also clearly indicated multiple times that if people have patches to submit they are welcome to reopen the report. I'm just trying to close out some of the bugs that I don't expect to be fixed soon. This way I hope to get a better overview of the issues that need to be fixed. What I am trying to achieve is to separate the wheat from the chaf. I don't think anyboy will be looking at this issue soon, we are short on developers - when was the last time *you* reviewed or submitted a patch? - hence I closed this bug, so it's easier for me to see the forest through the trees. Same happened for a report from Roland, a valued and active developer, because his report was so closely related to another bug that they should probably be fixed in conjunction. I bow before you, mighty Leo and Roland. Thank you mighty MC gods! You must misunderstand the above paragraph. What I indicated to Felix is that he is not the only one suffering from me closing bugs, but Roland (the valued and active developer ;) ) as well. And yes, I know that paragraph sounds a bit arrogant, but hey, I have been doing a lot of work on mc in the last 12 months and I didn't quite appreciate Felix's attitude of big mouthing people about issues he clearly has even less understanding about than I do. And on the matter of Roland's actions that you do not always seem to appreciate: I agreed with you that it's probably better if Roland would work on the viewer in a separate branch, and I stated that in a mail to this list. But just as you I can't force him to do just that. I would appreciate it if you would try to distinguish between his and my actions. I don't feel I'm responsible for his (whether they are good or bad). And yes, although I do not always agree with his actions and methods I do value his commitment and effort. When you ask for patches first think whether are you going to review them. ? I closed that bug as I don't expect any patches to pop up any time soon, but they are very welcome. Why do you think I am touching bugzilla in the first place? And no - MC is not short on developers. IMHO, MC is short on ideas where to go next . Well if that is the case then why are there still so many open issues in bugzilla that nobody seems to address? So, Leo thank you one more time for excercising you newly granted rights on Savannah. I wonder if it was the lack of rights that prevented you in the past from active participation in Savannah bugs database. I've been touching a lot of bugs and closing out a couple of fixed and duplicated entries. So I made a judgement with which you don't agree on one of them. I'm sorry about that, but I've already indicated that I'll reopen that bug if that makes a difference (either to you or the reporter). But for practical purposes that won't really matter. Regarding my overzealousness to close bugs in bugzilla, you might want to ask around in the Fedora fora if there are any complaints about my behaviour wrt RedHat/Fedora bugzilla (try #fedora-bugs or #fedora-devel). I've closed the occasional bug there that I shouldn't have closed but I don't believe I ever offended people by making such a mistake. I'm sorry I offended you. You must see all this in the light of having to break some eggs to make an omelet. And no irreversible harm has been done by me closing that bug report. You have noticed I might be a bit zealous in closing out bugs but I believe until now I've taken good care about doing commits to CVS, which I believe is what really matters. Bugzilla is a tool to help development you know. It's also cool that Roland have CVS commit access because otherwise we woldn't be able to benefit from his valuable contributions. That's a beef you have to take up with him. If you don't appreciate his commits please discuss that with him, or here on the list. I'm glad
Re: [OT] Re: [bug #12223] shift keys should change function menu descriptions
On Tue, May 18, 1999 at 11:56:15AM +0300, Pavel Tsekov wrote: And no - MC is not short on developers. IMHO, MC is short on ideas where to go next . that's probably the best joke i heard in years. ;) it's 100% contradicting proski's statement from some months back. but as you seem to suffer from boredom, you'll certainly happily and timely implement all my feature requests i'll shortly insert into bugzilla (not that i haven't posted them before, but heck). ;) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: GCC-4.0 warnings
Leonard den Ottolander wrote: Hi, Here's a list of gcc-4.0 warnings against HEAD from 2005-05-04. Tarball taken from the FC4t3 mc-4.6.1a-0.9.src.rpm. Removed all patches as not to cause confusion between clean CVS and downstream patches. Grepped for warning in the build log. Thanks for the list. If anyone wants to fix these warnings, please _think_ before committing. Changing a variable from signed to unsigned or vice versa is not a trivial thing. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: MC_ARG_ENABLE_DEVELOPER_MODE
Pavel Roskin wrote: I'm removing MC_ARG_ENABLE_DEVELOPER_MODE now because in my opinion, it doesn't provide any useful value at all. If you want that code restored, please provide arguments and _tested_ code. I'm also removing m4/ri-gcc-warnings.m4, which is now unused. That reminds me that I could also remove all code from you that is faulty. I think it is more polite to ask the developer who introduced things to remove them, except in urgent or very obvious ones. I already admitted I had introduced some bugs, but they weren't intentional. Without these bugs I find the developer mode quite useful. Just look at my proposed patch for the viewer, which uses that mode extensively. Perhaps you then see what my intention was. I also planned to #define NDEBUG depending on MC_ENABLE_DEBUGGING_CODE, but this issue seems to have gone. :( Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
subscribe
Title: Message subscribe ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #12223] shift keys should change function menu descriptions
Follow-up Comment #14, bug #12223 (project mc): it does exactly what i expected: the modifiers are used to enhance action keystrokes, to salvage some configurations that don't report the modifier state with the keystroke. this is completely different from what this report requests. when do you want to obtain the modifier state? via polling? and for pure ttys that don't report the modifier state without an action keystroke at all? oh, well, who cares. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=12223 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
