Follow-up Comment #14, patch #1042 (project mc):
Sure, please feel free to use a different dotdot patch. I'm not saying mine
is the best. I just want this functionality to be in.
As for my patch, I wasn't such an experienced programmer back then (three
years ago!). I just reworked that entire
Follow-up Comment #11, patch #1042 (project mc):
Done. Note that it's very old and probably won't apply to current codebase
without extensive tweaking. Please let me know if you have any problems.
___
Additional Item Attachment:
File
A new version of the hotlist patch with hotkey duplicates control is uploaded:
http://savannah.gnu.org/patch/index.php?func=detailpatchpatch_id=1042group_id=3521
* in new/edit entry/group, an error message is displayed, and the dialog is
redisplayed so that the user can change the hotkey
*
A new version of the hotlist patch:
http://savannah.gnu.org/patch/index.php?func=detailpatchpatch_id=1042group_id=3521
More fixes and cleanup:
* all declarations moved to block starts
* no highlighted letter hotkeys in buttons, but access keys specified
* reordered buttons so that most
Well, I understand you want to start with the top-level group every time.
I think both behavior can be useful, so this can be made a configuration
setting. Now with hotkeys, the hotlist is even more convenient to always
start with the root group, because it's easier to press ctrl-\ and a
Maybe we need a directory for contributed changes that don't integrate
well into the main codebase.
YES! I browsed this list's archives and found lots of proposed patches
that were never included into mc. I think we need to go through them once
again and sort them into those that must be
Now there is a Patches section on the mc BTS, so the situation is a
lot better.
I don't think so - it has a different purpose. Savannah account is a
temporary storage for patches that are to be discussed and eventually
either applied or rejected. What is needed, however, is a permanent
Ok, but imo you should treat '..' like a label and align it with other
labels (to conform with the filesystem metaphor).
Done, plus fixed a movelist bug
--
__
Sign-up for your own FREE Personalized E-mail at Mail.com
Good idea. Moreover mc homepage should be more informative. If nobody
protests, I could improve the mc homepage when I have more time, or
even rebuild it from scratch. I develop some commercial sites
(http://www.rpg-portal.pl http://www.nostromorpg.pl), so you could be
sure I know how things
As for me, I'd rather have the hotkeys assigned to the entries.
Me too. So I think the options are:
1. Warn the user if a new hotkey conflicts with that of a button, but perform no
further action.
2. (I'd prefer this one) Just remove all hotkeys from the buttons, to aviod any
confusion. This
2. (I'd prefer this one) Just remove all hotkeys from the buttons, to
aviod any confusion. This is reasonable because the buttons are
accessible not only via Tab, but by other keys (that cannot be entry
hotkeys anyway):
I think that would be inconsistent with other dialogs.
Yes, but
An updated hotlist patch uploaded:
http://savannah.gnu.org/patch/index.php?func=detailpatchpatch_id=1042group_id=3521
Since nobody complained, I removed insert/append buttons; now it's
one button saying add for new entry/group and done for
edit entry/group.
I also removed add current as
I just submitted a big patch for hotlist.c to savannah.gnu.org:
https://savannah.gnu.org/patch/index.php?func=detailpatchpatch_id=1042group_id=3521
It's against pre3 but not for inclusion in 4.6.0 release, maybe a next version.
Please test it and report your experience. It works for me but I'm
mc reports only 2147483 bytes [...]
if it was kilobytes: 2147483647==2**31-1?
Indeed! I found that the problem was that _FILE_OFFSET_BITS in my config.h was not
set. After I set it to 64 the problem disappeared. Apparently mc now uses 64-bit
values.
However there is another problem: now that
Indeed there was an error in sort_size function: it is declared as int, but it returns
a value of the type off_t which may be double. This results in a casting error and
wrong sorting for very big files. The patch is attached.
--
__
The Command / Show directory sizes menu item gives wrong values. For example, du -b
gives 5033406464 (approx 5Gb) for a subdir but mc reports only 2147483 bytes for the
same subdir. In another example, 35108 Kb is reported by du but 27733K is seen by mc.
Perhaps this latter case can be ascribed
Glenn:
I'm running mc with -r, but the only difference it makes
is that without -r, mc spits out an error message while
with -r it just freezes the prompt. I.e. the
difference is cosmetical, while the problem remains.
--
__
Sign-up for
Maybe the delay should be an integer variable in milliseconds? Different
terminals, different connections and different users will need different delays.
So we need two ini file parameters:
esc_mode={0|1|2}
where 0 means stick forever, 1 means stick
for some time (controlled by esc_delay)
Pavel, do I need to resend this to devel list and/or submit to the patch manager? Same
question about the quick sort case sensitivity patch? Will they be included in 4.60?
--- dir-old.c 2002-12-25 22:19:47.0 -0400
+++ dir.c 2003-01-11 21:25:52.0 -0400
@@ -501,7 +501,7 @@
I don't see any problem here that would not be a result of reusing a generic
subshell. mc doesn't track the state of the subshell after every keystoke sent
to the subshell. It only knows that it's safe to send commands to the subshell
after it has returned the prompt and no new data was sent
I meant this phrase:
BTW, File associations is more right name for Extension File.
Ah, OK. It doesn't matter to me personally how you call it, as long as it works.
Check this thread:
http://mail.gnome.org/archives/mc-devel/2002-July/msg00097.html
Just because users are free to modify
Now, even if files in a panel are sorted case insensitively, quick search (alt-s)
still is case sensitive. This is wrong, because if I don't care about case when
sorting files, chances are I care about it even less when doing a quick search. Here's
a patch that uses sensitive or insensitive
Except that you would not be able to use keys that are missing in the
label, functional keys in particular.
Yes, and besides, mc.menu does not use also, it stores hotkeys in a separate
field. So consistency dictates using the same approach in the hotlist - these two
constructs are similar
It is convenient to be able to view files of arbitrary charsets in
your native display charset, by having the source charset guessed
and files reencoded correspondingly on the fly. Here's how I
implemented this for Russian cyrillic encodings. Perhaps this might
be useful for someone.
First,
How can I prevent mc from losing the contents of the command line when I press ctrl-o?
--
__
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
Save up to $160 by signing up for NetZero Platinum
25 matches
Mail list logo
