Re: Announcement: this mailing list will be retired by the end of Oct 2022
Hello, well, now users (us) will have to go search for services (forum) instead of getting service delivered at home (ML), that's definitely a different approach and no real way to customize the delivery of such service. I don't clearly see the point in doing this, instead. of course, because of trying to tie everyone into clicks and monetization, what the web has now become. Emails are free and free of such monetization, the current web cannot allow this to keep going (see what Google did to emails). People I talked about this major turn around me are just disgusted and don't really want to run into web forums and live in a web browser. Prepare to see the audience being really different since now! Regards, -- wwp https://useplaintext.email/ pgp4aCPJZkH5X.pgp Description: OpenPGP digital signature ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander 4.8.27 released
Hell, On Wed, 6 Apr 2022 23:07:57 +0200 wwp via mc-devel wrote: > On Wed, 25 Aug 2021 17:50:01 +0200 wwp via mc-devel > wrote: > > > On Sun, 15 Aug 2021 16:36:26 +0200 (CEST) "Yury V. Zaytsev" > > wrote: > > > > > Hi there, > > > > > > I'm glad to announce the immediate availability of mc-4.8.27, a > > > maintenance and security release, just in time before leaving all of you > > > for a long overdue summer vacation! > > [snip] > > > > Thanks for this new release, and all the efforts underneath! > > > > Quickly built from the sources on a CentOS 7 system.. I notice that on > > a regular basis, mc starts w/ no subshell, most of the time with it. > > Nothing in output that would bring a tip, it's just that there is no > > subshell available from time to time. I'm tempted to say that it > > happens more when the system is busy (cpu), but I won't bet this is > > related. > > For the record, I can still reproduce this issue w/ mc 4.8.28. To be more precise, I only reproduce it when the system is a bit stressed (high cpu and memory use): running `mc -u` opens up immediately, whereas `mc -U` (or `mc`) takes 3 sec to open, but no sub-shell available. When the system is resting, `mc -U` behaves as expected, opens up quite immediately and with sub-shell. Regards, -- wwp https://useplaintext.email/ pgpkSBLwzGppL.pgp Description: OpenPGP digital signature ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander 4.8.27 released
Hello, On Wed, 25 Aug 2021 17:50:01 +0200 wwp via mc-devel wrote: > On Sun, 15 Aug 2021 16:36:26 +0200 (CEST) "Yury V. Zaytsev" > wrote: > > > Hi there, > > > > I'm glad to announce the immediate availability of mc-4.8.27, a maintenance > > and security release, just in time before leaving all of you for a long > > overdue summer vacation! > [snip] > > Thanks for this new release, and all the efforts underneath! > > Quickly built from the sources on a CentOS 7 system.. I notice that on > a regular basis, mc starts w/ no subshell, most of the time with it. > Nothing in output that would bring a tip, it's just that there is no > subshell available from time to time. I'm tempted to say that it > happens more when the system is busy (cpu), but I won't bet this is > related. For the record, I can still reproduce this issue w/ mc 4.8.28. Regards, -- wwp https://useplaintext.email/ pgpUGr5Tugh5z.pgp Description: OpenPGP digital signature ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander 4.8.27 released
Hello Yury, On Sun, 15 Aug 2021 16:36:26 +0200 (CEST) "Yury V. Zaytsev" wrote: > Hi there, > > I'm glad to announce the immediate availability of mc-4.8.27, a maintenance > and security release, just in time before leaving all of you for a long > overdue summer vacation! [snip] Thanks for this new release, and all the efforts underneath! Quickly built from the sources on a CentOS 7 system.. I notice that on a regular basis, mc starts w/ no subshell, most of the time with it. Nothing in output that would bring a tip, it's just that there is no subshell available from time to time. I'm tempted to say that it happens more when the system is busy (cpu), but I won't bet this is related. GNU Midnight Commander 4.8.27 Built with GLib 2.56.1 Built with S-Lang 2.2.4 with terminfo database With builtin Editor and Aspell support With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With internationalization support With multiple codepages support With ext2fs attributes support Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; Regards, -- wwp https://useplaintext.email/ pgplwap0ceqOW.pgp Description: OpenPGP digital signature ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.24-rc1
Hello Andrew, On Tue, 07 Jan 2020 17:45:28 +0300 Andrew Borodin wrote: > On Tue, 7 Jan 2020 14:15:21 +0100 wwp wrote: > > I think I have one more tiny issue to report.. I went back to 4.8.23, > > and at least two settings from the layout prefs were lost: command > > prompt and panel split. Maybe you changed the storage format for some > > config items? > > Yes. This is a result of [1]. > > Previously some options that are actually boolean were stored > as intreger 0/1. Now its are stored as yes/no. > > [1] https://midnight-commander.org/ticket/4039 Thanks, this all makes sense now! Regards, -- wwp https://useplaintext.email/ pgp5lWsce_9ki.pgp Description: OpenPGP digital signature ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.24-rc1
Hello Yury, On Wed, 01 Jan 2020 21:02:50 +0100 "Yury V. Zaytsev" wrote: > Hi there, > > TLDR; I would appreciate if you could please test the following tarball > on your systems and report any blocker regressions as compared to the > previous 4.8.23 release: > > https://www.midnight-commander.org/nopaste/tarball/mc-4.8.23-149-g06bf088bc.tar.xz > > $ sha256sum mc-4.8.23-149-g06bf088bc.tar.xz > bafd8a0556504c2806b77cd7506ac087d4ad050fbb4d711fbd7898fe493493fd > mc-4.8.23-149-g06bf088bc.tar.x > > I've built this tarball out of the latest master with translations from > Transifex pulled in on a fresh Fedora 31 VM, which I'm also going to use > to build the final release in about a week from now if nothing serious I think I have one more tiny issue to report.. I went back to 4.8.23, and at least two settings from the layout prefs were lost: command prompt and panel split. Maybe you changed the storage format for some config items? Regards, -- wwp https://useplaintext.email/ pgpnVHJW5XLux.pgp Description: OpenPGP digital signature ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.24-rc1
Hello Andrew, On Mon, 06 Jan 2020 16:18:32 +0300 Andrew Borodin wrote: > On Mon, 6 Jan 2020 12:45:57 +0100 wwp wrote: > > > > I noticed one regression: if I start mc, then start mcedit from > > subshell, I'll get: > > === > > GNU Midnight Commander is already running on this terminal. > > Subshell support will be disabled. > > === > > > > Back to 4.8.23 and the issue is gone, as expected. > > Notice if you run standalone mceditor, you haven't a subshell in it [1]. > > A new behavior (I can't say this is a bug) is a some kind of payment > for having a full-functional subshell in standalone > mceditor/mcviewer/mcdiffviewer. > Now if you run mcedit from mc it is the same as you run mc from mc > with all features. > > [1] https://midnight-commander.org/ticket/3380 Maybe not a bug, but the error message is quite useless and pretty nagging, IMO, in addition of behaving differently than formerly. Regards, -- wwp https://useplaintext.email/ pgpBsc3bEZiLq.pgp Description: OpenPGP digital signature ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.24-rc1
Hello Yury, On Wed, 01 Jan 2020 21:02:50 +0100 "Yury V. Zaytsev" wrote: > Hi there, > > TLDR; I would appreciate if you could please test the following tarball > on your systems and report any blocker regressions as compared to the > previous 4.8.23 release: > > https://www.midnight-commander.org/nopaste/tarball/mc-4.8.23-149-g06bf088bc.tar.xz > > $ sha256sum mc-4.8.23-149-g06bf088bc.tar.xz > bafd8a0556504c2806b77cd7506ac087d4ad050fbb4d711fbd7898fe493493fd > mc-4.8.23-149-g06bf088bc.tar.x > > I've built this tarball out of the latest master with translations from > Transifex pulled in on a fresh Fedora 31 VM, which I'm also going to use > to build the final release in about a week from now if nothing serious > comes up. I noticed one regression: if I start mc, then start mcedit from subshell, I'll get: === GNU Midnight Commander is already running on this terminal. Subshell support will be disabled. === Back to 4.8.23 and the issue is gone, as expected. GNU Midnight Commander 4.8.23-149-g06bf088bc Built with GLib 2.56.1 Using the S-Lang library with terminfo database With builtin Editor and Aspell support With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With internationalization support With multiple codepages support Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; Regards, -- wwp https://useplaintext.email/ pgpsYvUgow6br.pgp Description: OpenPGP digital signature ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander 4.8.16 released
Hello Yury, On Tue, 15 Mar 2016 09:13:05 +0100 (CET) "Yury V. Zaytsev" <y...@shurup.com> wrote: > On Tue, 15 Mar 2016, wwp wrote: > > >>> --enable-vfs-mcfs > >> > >> As it was already mentioned the last time, this option has been removed a > >> long time ago. > > > > BTW, does it mean that mcfs doesn't exist anymore? > > Yes, it does mean that mcfs doesn't exist anymore. > > > Also, if aspell is not there, what's missing or chosen alternatively? > > The option --enable-aspell is not active by default, and unless I'm mistaken, > it only means that you don't get aspell support in the editor. > > If it is activated manually, but the aspell headers are not found, nothing is > chosen alternatively, you simply get an error. (sorry for my former double-post, Yury) I see, thanks for this clarification! While I'm removing dust from my mc build options: I also noticed that mcserv also vanished, I don't even remember what it was, but apparently I don't miss it for years ;-). I notice that when configuring with slang, the configure summary doesn't mention it, whereas for ncurses it explicitely mentions it. See for instance (w/ --with-screen=slang or no --with-screen, same output here): [snip] Configuration: Source code location: . Compiler: gcc -std=gnu99 Compiler flags: -fdiagnostics-show-option -Wbad-function-cast -Wcomment -Wdeclaration-after-statement -Wfloat-equal -Wformat -Wformat-security -Wimplicit -Wignored-qualifiers -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wno-long-long -Wno-unreachable-code -Wparentheses -Wpointer-arith -Wpointer-sign -Wredundant-decls -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wswitch-default -Wtype-limits -Wundef -Wuninitialized -Wunreachable-code -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wwrite-strings -g -O2 File system:Midnight Commander Virtual Filesystem cpio, extfs, fish, ftp, sfs, sftp, smb, tar Screen library: Mouse support: gpm and xterm X11 events support: yes With subshell support: yes With background operations: yes Internal editor:yes with aspell support Diff viewer: yes Support for charset:yes Search type:glib-regexp Regards, -- wwp pgpy08mESFB8l.pgp Description: OpenPGP digital signature ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander 4.8.16 released
Hello, On Sun, 13 Mar 2016 19:53:14 +0100 (CET) "Yury V. Zaytsev" <y...@shurup.com> wrote: > Hi Laurent, > > Thanks for updating the packages! > > > --enable-vfs-mcfs > > As it was already mentioned the last time, this option has been removed a > long time ago. BTW, does it mean that mcfs doesn't exist anymore? Also, if aspell is not there, what's missing or chosen alternatively? Regards, -- wwp pgpovecB2K3fK.pgp Description: OpenPGP digital signature ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Relative symlinks
Hello Andrew, On Thu, 13 Oct 2011 08:32:38 +0400 Andrew Borodin aboro...@vmail.ru wrote: On Wed, 12 Oct 2011 20:34:39 +0200 wwp wrote: I'm still missing the feature. What happened to that patch? That patch is in mc since 4.7.3. commit 6d5c2628fe4d0907e492c775a262e771dd41d560 Author: Andrew Borodin aboro...@vmail.ru Date: Mon May 10 13:43:34 2010 +0400 Ticket #2042: added a capability to create relative symlinks. The original patch was posted by Anton Monroe akm at meer dot net to mc-devel@gnome.org mailing list: http://mail.gnome.org/archives/mc-devel/2006-April/msg00020.html Signed-off-by: Andrew Borodin aboro...@vmail.ru Eeek! How could I miss the Relative symlink menu entry? Sorry for the noise! :-/ Thanks, Andrew. Regards, -- wwp signature.asc Description: PGP signature ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Relative symlinks
Hello Anton,
On Tue, 4 Apr 2006 03:43:26 -0500 Anton Monroe a...@meer.net wrote:
I wanted an easy way to make relative symlinks in MC. I searched the
source directory and found there used to be such a feature, but it was
removed about four years ago. For good reason; it was ugly, convoluted,
completely undocumented, and it was broken as well.
So I decided to rewrite it.
However, I have a slight handicap-- I don't know C. So you may not want
to take this patch too seriously! But at least it might inspire one of
the developers to do it right.
But in fact it turned out to be very simple. I added a
'relative_symlink_cmd' function modeled on 'symlink_cmd'. The existing
'do_link' takes two possible values for the first parameter-- 0 = hard
link, 1 = symlink. I added another possibility, 2 = relative link. So
I don't think there is a risk of it breaking any existing features.
The old other_symlink feature used Ctrl-x Ctrl-l. I used Ctrl=X v
because it's easier for my to type. I doubt if that change will bother
anyone. I did not add it to the File Menu because that menu already
fills a 25-line screen.
The only small glitch I've noticed is that diff_two_paths doesn't
completely optimize a relative path if the file and its link are both in
the same directory. I'll post another message about that.
Criticism and suggestions are welcome.
Anton
--- doc/mc.1.in
+++ doc/mc.1.in
@@ -297,6 +297,13 @@
.B C-x s
run the symbolic link command.
.TP
+.B C-x v
+run the relative symbolic link command. See the
+.\LINK2
+File Menu
+.\File Menu
+section for more information about symbolic links.
+.TP
.B C-x i
set the other panel display mode to information.
.TP
@@ -966,6 +973,23 @@
.I Show mini-status
option is enabled. Use symbolic links when you want to avoid the
confusion that can be caused by hard links.
+.PP
+When you press (C-x s) Midnight Commander will automatically fill in the
+complete path+filename of the original file and suggest a name for the link.
+You can change either one.
+.PP
+Sometimes you may want to change the absolute path of the original into
+a relative path. An absolute path starts from the root directory:
+.PP
+.I /home/frodo/mc/mc - /home/frodo/new/mc
+.PP
+A relative link describes the original file's location starting from the
+location of the link itself:
+.PP
+.I /home/frodo/mc/mc - ../new/mc
+.PP
+You can force Midnight Commander to suggest a relative path by pressing
+(C-x v) instead of (C-x s).
.PP
.B Rename/Move (F6)
.PP
--- src/cmd.c
+++ src/cmd.c
@@ -914,7 +914,8 @@ do_link (int symbolic_link, const char *
char *s;
char *d;
- /* suggest the full path for symlink */
+ /* suggest the full path for symlink, and either the full or
+ relative path to the file it points to */
s = concat_dir_and_file (current_panel-cwd, fname);
if (get_other_type () == view_listing) {
@@ -923,6 +924,10 @@ do_link (int symbolic_link, const char *
d = g_strdup (fname);
}
+ if ( 2 == symbolic_link) {
+ s = diff_two_paths ((other_panel-cwd),s);
+ }
+
symlink_dialog (s, d, dest, src);
g_free (d);
g_free (s);
@@ -954,6 +959,16 @@ void symlink_cmd (void)
if (filename) {
do_link (1, filename);
+}
+}
+
+void relative_symlink_cmd (void)
+{
+char *filename = NULL;
+filename = selection (current_panel)-fname;
+
+if (filename) {
+ do_link (2, filename);
}
}
--- src/cmd.h
+++ src/cmd.h
@@ -40,6 +40,7 @@
void tree_cmd (void);
void link_cmd (void);
void symlink_cmd (void);
+void relative_symlink_cmd (void);
void edit_symlink_cmd (void);
void reverse_selection_cmd (void);
void unselect_cmd (void);
I'm still missing the feature. What happened to that patch?
Regards,
--
wwp
signature.asc
Description: PGP signature
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Theme support
Hello Morten, On Fri, 2 Oct 2009 15:44:17 +0200 Morten Bo Johansen m...@spamcop.net wrote: wwp subscr...@free.fr wrote: For the sake of the archives, I use this red one as root: errors=brightred,yellow:reverse=black,white: [...] Thanks for sharing this. Fwiw, I have used your settings in my .screenrc, like this: bind R screen -t 'mc/root' 6 env MC_COLOR_TABLE=errors=brightred, [...] sudo mc I also use a black one, if one's interested. Yes, please post it. Here it is (can't remember from where I got this one, I didn't create it): directory=cyan,black:normal=green,black:executable=brightgreen,black:selected=black,green:\ marked=yellow,black:markselect=yellow,green:link=brightcyan,black:stalelink=brightred,black:\ core=red,black:device=brightmagenta,black:special=brown,black:errors=white,red:reverse=black,green:\ gauge=red,blue:input=black,green:dnormal=green,black:dfocus=black,green:dhotnormal=yellow,black:\ dhotfocus=yellow,green:menu=black,green:menusel=green,black:menuhot=yellow,green:\ menuhotsel=yellow,black:helpnormal=green,black:helpitalic=red,black:helpbold=yellow,black:\ helplink=black,green:helpslink=yellow,green:viewunderline=brightred,black:editnormal=green,black:\ editbold=yellow,black:editmarked=black,green Regards, -- wwp signature.asc Description: PGP signature ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Theme support
Hello Marcel, On Thu, 1 Oct 2009 04:02:34 +0200 Marcel Pol m...@gmx.net wrote: Hello, There is an idea that's been on my mind for some time that I'd like to share. I'd like to discuss it on the list, and if there's some consensus about it make it into a ticket. For the record, I'm not a programmer, so the real work needs to be done by someone else. Problem: - The default blue theme of mc is nice, but it's also a bit dated looking. It should be easy to change to a different theme, that is more modern. We should provide some of those in the distribution of mc. - Also the changing of theme is quite hard now. When you have set Save settings on exit, and want to change your theme, you have to quit all instances of mc, then edit the ini file, with a digged up theme from somewhere, and restart mc, and hope the theme works out ok. It should be easy to change from within mc. Implementation: We could have an item in Options called Themes, which gives a submenu. This submenu gives a list of themefiles, located in /usr/share/mc/themes/ and ~/.mc/themes/. Selecting one of these themes saves the theme config in ~/.mc/theme instead of in the ini file. We could provide a set of default themes, like: Default_blue Red (for root user, optionally, if wanted) Transparent_black_on_white (can someone provide one?) Transparent_white_on_black, like: [Transparent white on black] base_color=normal=white,default:input=white,brown:errors=white,brightdefault:gauge=brown,black:selected=black,white:marked=yellow,default:markselect=yellow,white:directory=white,default:executable=brightgreen,default:link=lightgray,default:device=brightmagenta,default:special=brightmagenta,default:core=brightdefault,default:menu=black,white:menuhot=yellow,white:menuhotsel=brightdefault,black:dnormal=black,white:dfocus=white,lightgray:dhotnormal=yellow,white:dhotfocus=brightdefault,lightgray:editnormal=lightgray,black:editmarked=yellow,white Some considerations: - The location of theme files could also be based in /usr/share/themes and ~/.themes/ but since these themefiles are only used by mc, I think it would be less clutter and more straightforward to place them in a directory owned by mc. - The naming of the themes gives sometimes a really long name, like Transparent black on white. Maybe it's not a problem, but if it is, then I don't have a solution. - There's a possibility of a screwup, like selecting white text on a white background. There should be an easy way to get back to default blue. Just let the user manually delete ~/.mc/theme? - It could be an idea to overhaul the markup of the theme-files, and make it a bit more like .desktop files or similar, with entries like: Name=Transparent white on black Type=Theme file for Midnight Commander Hint=Transparent theme. It gives transparent panels, with white text, on a black or dark background. Don't use it on a white background. Base_color= [etc] Thoughts, comments? Interesting ideas, I always thought setting up a color theme for mc was a PITA. A simple but convenient theme editor would be nice, but I guess it's not a trivial work. For the sake of the archives, I use this red one as root: errors=brightred,yellow:reverse=black,white:gauge=black,gray:input=lightgray,red\ :normal=lightgray,red:selected=black,lightgray:marked=yellow,red:markselect=yellow,lightgray\ :dnormal=black,lightgray:dfocus=lightgray,black:dhotnormal=red,lightgray:dhotfocus=black,lightgray\ :menu=black,lightgray:menuhot=red,lightgray:menusel=lightgray,black:menuhotsel=lightgray,red\ :helpnormal=black,lightgray:helpitalic=grey,lightgray:helplink=blue,lightgray:helpslink=red,lightgray\ :directory=white,red:execute=brightgreen,red:link=green,red:device=brightmagenta,red:special=black,red:core=brightcyan,red\ :hidden=lightgray,red:temp=lightgray,red:doc=lightgray,red:archive=lightgray,red:source=lightgray,red:media=lightgray,red:graph=lightgray,red:database=lightgray,red I also use a black one, if one's interested. Regards, -- wwp signature.asc Description: PGP signature ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #6457] Check returned values of vfs_get_class() and vfs_op()
Follow-up Comment #3, patch #6457 (project mc): Okay, well, I didn't know where to make my comment exactly, maybe it worth reporting this lack to the patch author directly, then. ___ Reply to this item at: http://savannah.gnu.org/patch/?6457 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #6457] Check returned values of vfs_get_class() and vfs_op()
Follow-up Comment #5, patch #6457 (project mc): Thanks for reporting this upstream, Andrew. ___ Reply to this item at: http://savannah.gnu.org/patch/?6457 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Portability of $(expr) vs `expr` in bash
Hello Leonard, On Thu, 28 Jul 2005 23:26:18 +0200 Leonard den Ottolander [EMAIL PROTECTED] wrote: Hi, I'm wondering if the usage of $(expr) vs `expr` in bash scripts is portable, ie if we could get rid of all the unnecessary spawning of shells for such expressions by replacing the latter with the former. Some questions come to my mind: $(expr) is not supported by some shells (it's more a question of shell family than shell fresh-ness, excepted for bash itself), do you really mean bash in your post, or shell? If your concern is bash only: How old are the bash versions that don't support $(expr)? Are there really still some systems running such old and poor-featured bash versions? Do you still want to support such bash versions, aren't there other points that make support for these bash versions impossible? Would there be other interests in using `expr` anyway (excepted that `expr` works for non-bash shells)? My 2 cts. Regards, -- wwp ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #13091] Open a symlink to edit when save, erase symlink and make a new file.
Follow-up Comment #3, bug #13091 (project mc): GNU/Linux x86, FC3 running mc 4.6.1-pre4 from the sources (was: SuSE 8.x, mc 4.6.x from the sources and older mc versions): $ rm -f foo bar; touch foo; ln -s foo bar; ls -l foo bar lrwxrwxrwx 1 wwp users 3 May 16 17:08 bar - foo -rw-r--r-- 1 wwp users 0 May 16 17:08 foo $ mcedit bar (press F2 then F10) $ ls -l foo bar 0 -rw-r--r-- 1 wwp users 0 May 16 17:09 bar 0 -rw-r--r-- 1 wwp users 0 May 16 17:08 foo as you see, bar is no longer a symlink but a regular file. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13091 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #13091] Open a symlink to edit when save, erase symlink and make a new file.
Follow-up Comment #1, bug #13091 (project mc): I do my best to avoid this behaviour in mc for years :-\ (now w/ 4.6.1-pre4a). I hope it's not by design that mc replaces an edited symlink w/ the target file when saving/editing it! ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13091 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
File renaming helper request
Hello all, I wonder if there would be a way to allow easy 1-file renaming by including the filename itself in the Move dialog (when only 1 file is selected) so that the filename can just be changed. For instance, if I want to rename a very long filename in order to fix a typo in the filename, w/ mc 4.6.1-pre3 as w/ mc for ages, I press F6 over the file then I have to re-type the full filename (including the typo fix of course). This is not easy and I can even make typos more :-). If the filename was in the Move dialog, I would just have to change the incorrect character(s) instead of typing the full filename, which is not accurate for what I need. Any agreement? Regards, -- wwp ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: File renaming helper request
Hello /dev/rob0, On Sun, 27 Feb 2005 10:59:01 -0600 /dev/rob0 [EMAIL PROTECTED] wrote: [ CC'ed because I don't know if this address can post on mc-devel ] It appears that a few posts of mine already landed to mc-devel in the past year, nothing incorrect I hope. On Sunday 27 February 2005 10:26, wwp wrote: I wonder if there would be a way to allow easy 1-file renaming by including the filename itself in the Move dialog (when only 1 file is selected) so that the filename can just be changed. Shift-F6, although I seem to have problems with that in certain terminals, notably GNU screen(1). It's not in the pull-down menu, though. Wow. How could I miss that?! Wouldn't this thread be more appropriate on mc@gnome.org ? Yes you're right. I mis-chosen the target mailing list, thanks for telling me that (sorry for the noise) :-\. Thanks for your help! Regards, -- wwp ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Find file non-recursively
Hello Andrew, On Wed, 2 Feb 2005 17:42:11 +0200 (EET) Andrew V. Samoilov [EMAIL PROTECTED] wrote: Hello, Andrew and Pavel! I think 2+ years is quite for this patch to be commited to current ;-) Ah yes! Regards, -- wwp ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
