{5} Accepted, Active Tickets by Owner (Full Description) (52 matches)

Hi, please see http://www.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_06 for the specification of the POSIX ustar interchange format. GNU cpio (-Hustar), paxtar, and GNU tar --format=ustar all create archives of this format; bsdtar probably does as well. However, I cannot cd#utar or “Enter” them in both mc-4.6.1-16 (MirPorts?) and mc_3:4.7.0-1 (Debian sid). After looking at tar.c I think you only support the legacy or vendor-specific/proprietary GNU tar archive format. The new boot floppies of MirBSD as of today are ustar archives, with the bootsector squeezed into an ustar header and closely following the standard. Introspection would be nice.

Steps to reproduce: Navigate deeply into an archive containing long directory/file names. Alternately, extract the contents of such archive. The filenames will be cut off at some point.

Example: 1) wget http://sourceforge.net/projects/dspace/files/DSpace%20Stable/1.6.0/dspace-1.6.0-src-release.tar.bz2/download 2) navigate into the archive in mc 3) try to copy (extract) the contents of the archive 4) you will get overwrite prompt: "Target file "/home/dspac~DConfigura" already exists!"

Problem: The filenames are cut off at about 100 characters (length of the whole path inside the archive).

Proposed solution: a) remove the limit b) warn about this limit when entering the archive if the limit is reached for the archive being opened

open a source file => syntax highlighting is on now go to the menu to change the syntax (you don't even have to choose a different entry from the list) => syntax highlighting is gone

The division by zero prevention check in the inode count statistic is wrong, see attached patch.

If the panel sort order is not case sensitive, the dotfiles (hidden) are mixed up with the others, as if the dot were not there.

I think it's confusing as dotfiles are very special. A more user-friendly order would be dotdirs, dirs, dotfiles, files, same as with the case-sensitive order.

But the perfect solution would be dirs, files, dotdirs, dotfiles.

Open a utf-8 text file in mcedit from mc, record a macro to change some text on each line of the file, then run the macro okay for perhaps 4 times, then the macro no longer works correctly, starts deleting characters in the file sequentially instead, cannot exit macro run mode.

Debian Lenny system - i386 - locale is en_US - with KDE4 Running mc in a KDE konsole.

Using todays Git repo version 4.6.2 (April 7, 2009) which I built from the Git repo sources with libslang2.

GNU Midnight Commander 4.6.2 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish With builtin Editor Using system-installed S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm With support for X11 events With internationalization support Data types: char 8 int 32 long 32 void * 32 off_t 64 ecs_char 8

Thanks.

Original: http://savannah.gnu.org/bugs/?19651

Discussion:

Thu 26 Apr 2007 04:16:10 PM UTC, comment #8:

Does it help if you disable "Return does autoindent" from
Options -> General in the editor ?
	Pavel Tsekov <ptsekov>
Project Administrator
Sun 22 Apr 2007 09:32:43 PM UTC, comment #7:

bug in a bugfix...
i noticed bad flicker in the console and realized that the setcolor 
function does force a screen redraw.

therefore i moved its call to edit.c init()

now i get a green blinking _ in the console (no X) when i quit mc - 
much less anoying than the flicker.

any suggestions how to fix that?
	me <me4mc>
Sun 22 Apr 2007 09:56:32 AM UTC, comment #6:

mhh i browsed this menu @savannah and found that there is a 
difference between patch and bug and the bugs i submitted could have
 been patches - sorry for the trouble that might have caused, will 
use patches in future
	me <me4mc>
Sun 22 Apr 2007 09:50:04 AM UTC, comment #5:

yes it is!
because it is a feature that already works in other situations 
(single line)

reproduce:
start xterm
start mc in xterm
go to a file with newlines (eg COPYING)
edit it (F4)

press SHIFT and click-select some content over lines, do NOT use the
 mc cooledit buffer.

paste the selected text (using MIDDLE mouse) in a application like 
email or in the same editor, notice the blanks.

try the same if you cat the file on the terminal and notice that no 
blanks are in the other app:

example:
without patch (sorry bad to see)
SOL>
<EOL
SOL> Preamble
<- EOL
SOL> <EOL

with patch, or using nano or cat:

<EOL
Preamble<EOL
<EOL

i know that there are many terminals arround - maybe xterm isnt a 
good choice - maybe i have no choice at all

peace
	me <me4mc>
Sun 22 Apr 2007 09:31:31 AM UTC, comment #4:

Is it so hard to write a proper bug report ? I want to reproduce the
 problem myself and I couldn't - I failed because the lack of 
information. It is not correct to assume that everything has the 
same problem as you do. And how can I apply a patch if I do not 
understand what's going on.

I am sure Oswald can explain the problem to me but after all it is 
up to the submitter to describe the bug it sees.
	Pavel Tsekov <ptsekov>
Project Administrator
Sun 22 Apr 2007 09:22:16 AM UTC, comment #3:

i dont like the idea of changing the terminal just because a 
application misbehaves. my workarround for several years is to cat 
the current file - hopefully it's not a 60M log...

therefore created a patch (that only works for slang and mc 4.6.1) 
that uses a clear eol function to perform the action of clearing the
rest of the current line.
selection works fine for me now, but the display flickers on 
movement - something i can handle

@pavel: did you even read the post? the solution was in it - i hope 
in future we can improve understanding!

to make it work as described i had to create a new function in 
color.c&h that resets the color index 0. if anything simmilar exists
 please adopt the idea.

i dont care if this ever ends up in the main tree - it would save me
 the trouble of patching. once a year..

gentoo ebuild with use flag in testing phase maybe apears in sunrise
 overlay

peace
me
	me <me4mc>
Sat 21 Apr 2007 11:41:25 AM UTC, comment #2:

i understood immediately what he means. :-P

me: you can configure most *terms to strip trailing whitespace from 
the selection. without this, i would have freaked out long ago. :)
	Oswald Buddenhagen <ossi>
Sat 21 Apr 2007 11:20:23 AM UTC, comment #1:

Please, calm down. Finding a problem is the easy part - describing 
it properly, so that others can reproduce it, is of great importance
 if you want to get the problem solved.

From you bug report it is clear that you see some problem related 
the way copy/paste works in relation to the internal editor. 
However, I cannot understand what is actually wrong - please, do the
 following:

1) explain what do you do - copy/paste from where to where ?
2) explain what happens
3) explain what do you expect to happen
	Pavel Tsekov <ptsekov>
Project Administrator
Sat 21 Apr 2007 10:25:44 AM UTC, original submission:

i managed to find another x problem:
when you are in the *term and select some text all newlines are lost
 and filled up with spaces.

i managed to find the problem in the
editordraw.c in print_to_widget
the hline draws blanks at the rest of the line.

i understand that behaviour but there is a possibility to do this right:

SLtt_set_color (DEFAULT_COLOR_INDEX, NULL, "default", "default");
SLsmg_erase_eol();
or
clrtoeol()

however, i tryed to create that behaviour and failed because i 
cannot set the default color index (0) to blue/white.
the problem is that users with other color settings (me: 
black/green) could be angy if i hardcode blue/white

the default state is black/white - looks ugly but works.

if you could suggest how to properly set the fg/bg

should i create a new function in src/color.h?

any suggestions? 

ticket #192 makes my desktop's task bar pretty useless for distinguishing my mc instances: the actually visible part of every window's title is now identical. also, this additional information is useless in most cases. if you want to do that right, the display must be selective: show only info which differs from the defaults. the locality and ownership of the session can be determined by querying the utmp database (on the command line, that would be the tty and who commands). the less magic and more flexible approach would be allowing the user to specify what to put into the title manually - a patch has been proposed in http://mail.gnome.org/archives/mc-devel/2007-August/msg00004.html.

Need to hide ^M symbols at end of lines in text files with '\r\n' line ends.

Better way: create keybinding for toggle ^M symbols.

When viewing a file that no longer grows, the cursor's position is different in the slang and ncurses builds.

With slang, the cursor is in the upper right corner, on the percent sign. I think this is nice: most terminals show the cursor as a reverse colored and often blinking character cell, but it's not intrusive there.

With ncurses, the cursor wraps around to the beginning of the next line, that is, the bottom left corner of the actual file contents viewing area. I find it very intrusive there: it clutters up the space that should show me the file, and makes the first character much harder to read.

I believe the ncurses version should also move the cursor to the top row.

The following patch (against 4.7.0-pre1) makes the Home key go to the first column on first press, and then go to the beginning of non-whitespace -- if any.

From #83 It would be great if viewer would have key shortcut to run editor on the same file (so i view some file, understand that i need to edit it, then press, say Alt-F4 and get editor on this file from the same position). I thought that default editor behaviour (placing current line in the middle of the window) not convenient when switching from viewer to editor (thus is results in shifting text), so i modified abovementioned patch to disable such scrolling in this very case.

Original: http://savannah.gnu.org/bugs/?13953

Discussion:

Mon 03 Apr 2006 02:32:13 PM UTC, comment #4:

Reopening since SFS also leaves stale temporary files when 
operating on remote files. I am working on it.
	Pavel Tsekov <ptsekov>
Project AdministratorIn charge of this item.
Thu 23 Mar 2006 03:04:46 PM UTC, comment #3:

I've just commited a fix:

http://cvs.savannah.gnu.org/viewcvs/mc/vfs/extfs.c?root=mc&sortby=date&r2=1.125&r1=1.124&diff_format=u

The temporary files used to remain only if MC exited before the vfs 
"garbage collector" kicked in.
	Pavel Tsekov <ptsekov>
Project AdministratorIn charge of this item.
Mon 01 Aug 2005 10:01:00 PM UTC, comment #2:

Hi Pavel,

Hope you don't mind me assigning this issue to you :) .
	Leonard den Ottolander <leonardjo>
Project Member
Mon 01 Aug 2005 08:56:00 AM UTC, comment #1:

The suggested patch won't do i.e. it is not the right thing to do. 
I am currently investigating .
	Pavel Tsekov <ptsekov>
Project AdministratorIn charge of this item.
Wed 27 Jul 2005 02:40:48 PM UTC, original submission:

Mc 4.6.1 doesn't clean up tempfiles. This happens with mc-4.6.1 on 
Mandriva Cooker.
This is with and without the utf8 patch.
I only tried it with an rpm, and the cpio file remains in the 
/tmp/mc-user directory after a restart of mc.

$ mc --version
GNU Midnight Commander 4.6.1
Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, undelfs
With builtin Editor
Using system-installed S-Lang library with terminfo database
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With internationalization support
With multiple codepages support

A patch is available in the mc-devel archive at:
http://mail.gnome.org/archives/mc-devel/2005-May/msg00228.html
This patch has been made by Dieter Jurzitza on Suse 9.3. 

I can remove/copy patches from diff filesystem but I cannot copy to it and I cannot save changes to patches in diff filesystem. It was possible in older versions of mc. I searched for a corresponding ticket but it seems no one reported it before.

name_quote(), which returns a newly allocated string, is used in many places where a static buffer (eg. on stack) would be fully sufficient.

Original: http://savannah.gnu.org/bugs/?23513

Discussion:

Sat 07 Jun 2008 07:57:22 AM UTC, original submission:

the editor needs a read-only mode. in this mode, cursor navigation 
would work as normal, but any attempt to modify the content would 
pop up a confirmation dialog requesting to switch the mode.
the mode would be initialized from the file's access rights. a 
manual toggle (and possibly a command line switch to be able to use 
the editor as a viewer) would be provided. 

Formatted manual pages using UTF-8 charset are handled incorrectly by mc-4.7-pre2.

Problem 1: Accented characters in bold (yellow) text are displayed incorrectly: the letter, followed by a dot, then the letter once again, all in white.

Problem 2: Search does not find text that are bold or underlined (yellow or red) and contain accented letters. Exception: it finds if only the first character is accented, but highlights the match incorrectly.

I attach such a formatted manpage (emitted by groff-utf8) for your convenience - you might have to press F9 in mcview.

The following patch adds a primitive scroll indicator to the file panels. It will display only on the active panel, and only if necessary.

Attached patch (against 4.7.0-pre1) does this.

Tadaaa! The feature you've all been waiting for!

Forget the old limit of 8 background and 16 foreground colors. From now on Midnight Commander can use all the 256 colors, as your favorite terminal emulator supports them - or not, in which case it's not going to stay your favorite terminal for long.

And... just here, just now: Order one right now (dial 1-800-256-COLORZ), and get a free bonus: the ability to specify some non-color attributes, including bold (for any color, no longer confused with brighness), underline (ideal for hotkeys), and blink (strictly only for those under the age of 10).

And if one bonus wasn't convincing enough, you get a second extra, too! An example skin that's totally different from the current ones (dark on bright, making it a "noon commander"), heavily using 256 colors and the new attributes. Don't worry, it does not blink!

If you're a user, just apply the patch, compile and install mc, open a decent terminal emulator (e.g. xterm, gnome-terminal, konsole, iterm, putty, and probably lots of others) and start mc with this command:

TERM=xterm-256color mc --skin=sand256

Should you want to create your own brand new skin, everything's described in the updated documentation and in the sand256.ini file.

If you're an mc developer, please read on here for some boring technical details behind the design decisions I made in my patch. Otherwise you can stop here and enjoy the patch :)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Using the legacy colors, there's a huge confusion whether the single "bold" attribute actually means "bold" (so only 8 colors in total) or "bright" (ending up with 16 foreground and 8 background colors) or both bold and bright at the same time. The actual behavior depends on the terminal itself. 256 colors are supposed to end this confusion. The first 16 of these colors are supposed to correspond to the legacy 8 normal and 8 bright colors, and bold becomes a separate flag applicable to any of them. E.g. you can have red in normal width, red in bold, brightred in normal width, and brightred in bold.

If your $TERM is set up for 256 colors, current mc behaves differently for bright colors depending on whether it uses slang or ncurses. If compiled with ncurses, mc itself translates the word "brightred" into normal red (color 1) with the bold attribute. If using slang, slang interprets the word "brightred", and it uses the correct semantics when 256 colors are available: it really becomes brightred (color 9), without being bold. My patch modifies the ncurses version behave the same way as the slang version does: interpret the word "brightred" correctly when 256 colors are available. (And of course the same for all 8 colors - red is just an example.) Apart from this change, my patch shouldn't introduce any other visible changes to any currently valid color configurations - let me know if it's not the case.

Currently a cell's look is specified by two fields: foreground and background color. The "bold/bright" flag, with is weird semantics, is incorporated in the foreground color both at the user-facing places (e.g. you have to specify "brightred" instead of "red" as foreground color in the config file), as well as in the source (the actual foreground value becomes COLOR_RED | A_BOLD).

The way 256 colors clearly separate the color itself from the boldness, as well as the desire to add support for underlined characters required me to revise this situation. Combining the attributes with the foreground color would have caused a lot of confusion and hacks both in the config file format as well as the internal representation. So I decided to separate them, as they are actually separate properties. From now on there are three fields: foreground, background and attributes. (When in 8 color mode, the brightness of the fg color and the bold attribute will still eventually be merged into a single property, e.g. "brightred;black" and "red;black;bold" will end up being the same color - but not when in 256 color mode.) Slang does the magic automatically on its own (interprets "brightred" differently for 8-color and 256-color terminals), for ncurses we manually do this right before allocating the colors with init_pair(), that is, keep the two properties separate as long as we can.

The structure containing these fg + bg + attr values is oddly still called color_pair, maybe it could be renamed. Not very surprisingly, separating the three properties often ended up in a cleaner code with less black magic.

So instead of two fields only, now a third field can be added containing the attributes. This works everywhere (I believe), I've tested in the command line, in the MC_COLOR_TABLE env var, in skin files, and in editor's syntax highlight files. Multiple attributes should be appended by the "+" sign, I chose this sign because it's intuitive (not only for geeks who'd probably prefer the bitwise OR "|"), and it's not a special shell character, so you can still specify any colors and attributes in the command line without worrying about quoting or escaping them. Since the empty string has the special meaning of falling back to the default, and the default might have some attributes, there has to be a way to specify "no flags": you can use any nonempty invalid string (such as "none").

The editor syntax highlight rules required to be able to specify the third field (attributes) without specifying the second (that is, not to modify the background). Unfortunately the whitespace-separated config file format does not allow it. Therefore I chose to introduce the special word "base" meaning mc's base colors.

A note on cooledit compatibility: cooledit exits with "Bus error" seeing an extra token (attributes) at the end of the line. Given that it's clearly not by design but due to a bug, given that's cooledit has one of the ugliest UIs I've ever seen, given that despite being an X application it supports a stunning number of 27 (yep: twenty-seven) colors (instead of 16 million) for no particular reason, and given that cooledit's not been maintained in the last 5 years, I just don't think it's important at all.

About color names: The words "color0" to "color255" are directly understood by slang, just as legacy color names ("red" and such). 256colors.pl (distributed in xterm's source) shows the colors using their 0..255 numbers, so I think it's convenient to allow these numbers to be used in the config files. On the other hand, I believe that names such as "rgb123" and "gray7" (inspired by the joe text editor, see its c.jsf file) are more intuitive and clearly more readable, similarly to the English names of legacy colors.

These are not understood by slang though, so mc has to parse and convert them. For the legacy 16 colors I decided to use the English names as the canonical ones rather than color0..color15, that is, the English names are sent to slang (though it equally understands color0..color15 too). This is for better compatibility: I haven't checked whether all ancient slangs support the colorN names, but this way we don't have to worry about it.

Let me know if you have any questions or concerns, I'm happy to answer them.

1) Use catdvi instead of dvi2tty and improve code 2) Add djvu support

Thanks to Denis Briand.

Forwarded from Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347738

From: Marco Herrn <marco@mherrn.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: when opening zip file that contains the same file twice, mc behaves oddly
Date: Thu, 12 Jan 2006 13:09:43 +0100

When a zip file contains a file with the same path and name more than
once, mc doesn't display all the information.

For example the bribblebox from bribble.com (available from
http://prdownloads.sourceforge.net/bribble/bribble-1.5.35.tar.bz2?download)
contains a Java Archive File (jar) which is in fact a zipfile with a
specific structure (The jarfile is
bribble-1.5.35/server/bribble-1_5_35.jar). This archive contains the
file META-INF/MANIFEST.MF twice. (Of course this is wrong and the
jar-file can be considered broken).

These two MANIFEST.MF files have different content, so they can be
distinguished. When opening this file in mc, there are two META-INF
directories, each of which contains two MANIFEST.MF files. When
viewing these MANIFEST.MF files (via F3), all four show the content of
the same one.

It would be of course better, if mc would display only one META-INF
directory with two MANIFEST.MF files. And viewing them should of
course display the correct contents, not the same content for both.

I hope I made the problem clear. It can be easily reproduced by
downloading the above mentioned tar.bz2, unpacking it and viewing the
jar-file in mc. To view the actual contents, the unzip tool can be
used, for example 'unzip -l bribble-1.5.35/server/bribble-1_5_35.jar'


Regards
Marco

I would have fixed this bug, but I don't know Perl :-( I think that duplicate directories should be trivial to filter, but I am not sure of what to do with duplicate files.

If you give them the same name, then the VFS will not able to tell which one to show. If you give them different name it's not obvious that these files are duplicate.

Maybe give them different names like with a special character that can not occur in the filenames? Then it's quite obvious that there's something wrong with the archive.

Thanks!

Original: http://savannah.gnu.org/bugs/?13737

Discussion:

Mon 11 Jul 2005 07:56:26 PM UTC, original submission:

i often accidentally do minor modifications (mostly partial escape 
sequences) which i undo of course. anyway, afterwards i still don't 
know if this was the only modification.

some considerations for the implementation:
- movements don't change the modified status, so you can't just 
check whether the undo stack is at the last file save point
- undo of changes past the last file save point must re-assert the 
modified status
- at file save points, it would make sense to stop undoing if it 
results from keyboard auto-reapeat (which can be assumed if the 
same sequence arrives (lets say) fife times within one second). 
undo will be resumed when the key is re-asserted after a pause. 

the titles of comments in tickets contain no number, which makes it hard to refer to them. that the reply function creates references with actual numbers makes it look outright silly ...

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

Discussion:

Mon 25 Dec 2006 03:23:40 PM UTC, comment #8:

For me the most useful solution to this issue would be, if tagging 
of one or more directories would trigger calculation and displaying 
of the size of the trees below them. TC for a well known proprietary
OS provides this feature.

A keybinding to recalculate sizes of ALL directories in current 
panel would be very useful addition to the menue entry we already 
have, I agree to Pawel.
	Roland Eggner <robiol262>
Tue 16 May 2006 05:59:54 PM UTC, comment #7:

It works with C-space as expected, move-down is ok, I need it 
working that way. Maybe F3 on some dir shouldn't move down. Besides,
is there any shortcut to recalculate sizes of all subdirs in current
panel? I would be great to have one.
	Pawel Misiak <pavelsky>
Mon 27 Feb 2006 10:09:02 PM UTC, comment #6:

Reopening.

It would be nice if this could be toggled back, and maybe C-space 
shouldn't move down...
	Leonard den Ottolander <leonardjo>
Project Member
Sat 28 Jan 2006 08:56:14 AM UTC, comment #5:

This feature exists in the current development version. Press 
C-space.
	Roland Illig <rillig>
Project MemberIn charge of this item.
Tue 19 Apr 2005 10:28:27 PM UTC, comment #4:

I think it is a very stupid idea since F3 means VIEW and has since 
Norton Commander V1.

It would however be a useful feature... moreso than the tree view.
	Coenraad Loubser <tunasashimi>
Sat 05 Mar 2005 01:16:17 PM UTC, comment #3:

FC/2 & FC/W performs this function with Ctrl-Q. I use it all the 
time.
	Felix Miata <mrmazda>
Mon 14 Feb 2005 09:17:19 AM UTC, comment #2:

FAR Manager (http://farmanager.com/) uses contains this feature too.
	Lukas Jelinek <luk>
Sun 13 Feb 2005 12:36:29 AM UTC, comment #1:

PS. I saw it in Dos Navigator (when I use DOS :-P )

Pleas see yourself:
http://www.ritlabs.com/dn/
	Anonymous
Sun 13 Feb 2005 12:32:30 AM UTC, original submission:

I would like propose one very useful patch:
When the cursor is at directory and You press F3,
midnight commander display size of all files in directory.

It could be display in column "size", or at down of the screen.
What do You think about this idea ?
I think its very useful.