<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.gnome.apps.mc.devel">
    <title>gmane.comp.gnome.apps.mc.devel</title>
    <link>http://blog.gmane.org/gmane.comp.gnome.apps.mc.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9358"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9357"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9356"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9355"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9354"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9350"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9347"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9346"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9345"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9344"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9343"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9342"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9341"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9340"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9339"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9338"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9337"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9336"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9335"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9334"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9358">
    <title>Re: [patch]: mc.ext updates (xz, libreoffice)</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9358</link>
    <description>&lt;pre&gt;Hi there,


For when the patch[1] for lzip[2]?.

References:
[1] https://www.midnight-commander.org/ticket/2673
[2] http://lzip.nongnu.org/lzip.html

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

&lt;/pre&gt;</description>
    <dc:creator>Matias A. Fonzo</dc:creator>
    <dc:date>2012-05-07T19:14:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9357">
    <title>Re: [patch]: mc.ext updates (xz, libreoffice)</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9357</link>
    <description>&lt;pre&gt;libreoffice patch is reported as
  https://www.midnight-commander.org/ticket/2723
but it looks like there were no progress for whatever reason.

.xz patch was recently accepted for upcoming 4.8.4 (thanks!)
  https://www.midnight-commander.org/ticket/2798

as well as support for .gem
  https://www.midnight-commander.org/ticket/2797

Cheers,
Dmitry.


On 7 May 2012 01:49, wwp &amp;lt;subscript-GANU6spQydw&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:
_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

&lt;/pre&gt;</description>
    <dc:creator>Dmitry Smirnov</dc:creator>
    <dc:date>2012-05-07T00:54:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9356">
    <title>Re: [patch]: mc.ext updates (xz, libreoffice)</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9356</link>
    <description>&lt;pre&gt;Hello,


On Sat, 5 Nov 2011 23:15:29 +0900 Osamu Aoki &amp;lt;osamu-8fiUuRrzOP0dnm+yROfE0A&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:


What's the status of this patch? It's apparently not in 4.8.1.3/4.8.3.


Regards,

&lt;/pre&gt;</description>
    <dc:creator>wwp</dc:creator>
    <dc:date>2012-05-06T15:49:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9355">
    <title>zipfs cache problem</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9355</link>
    <description>&lt;pre&gt;Dear Developers,

Thank you for this great piece of software!

I found that mc's zipfs caches the archive contents by using the file name
only. This can be a problem if a different file is used with the same name
later. As far as I know, this bug is still present in the newest mc as well.

Best regards,
Zoltan Kovacs
_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
&lt;/pre&gt;</description>
    <dc:creator>Kovács Zoltán</dc:creator>
    <dc:date>2012-05-04T10:21:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9354">
    <title>Re: Midnight Commander 4.8.1.2 (stable) released</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9354</link>
    <description>&lt;pre&gt;Hi Ladislav,

This is one of the reasons why the developers decided to quickly release a
followup stable 4.8.1.3, just a few days after this release went out.
 Please upgrade and your problem will be gone.

egmont

On Mon, Apr 23, 2012 at 11:21 AM, Ladislav Hagara
&amp;lt;ladislav.hagara-kMep9Rq2J44&amp;lt; at &amp;gt;public.gmane.org&amp;gt;wrote:

_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
&lt;/pre&gt;</description>
    <dc:creator>Egmont Koblinger</dc:creator>
    <dc:date>2012-05-03T14:36:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9350">
    <title>Re: mc.ext is problematic by nature</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9350</link>
    <description>&lt;pre&gt;On Sun, Apr 22, 2012 at 3:55 PM, Holger Herrlich
&amp;lt;holgerherrlich05&amp;lt; at &amp;gt;arcor.de&amp;gt; wrote:

Given the lack of positive reception at this point I couldn't care
less about convincing anybody.  I still want to express my thoughts
cleanly, though.


I didn't mean hardcoded, it's not the right word indeed.  What I meant
is that given the cross-platform nature of MC, chances are mc.ext
won't contain the right associations out of the box right after
installation.  It has to be edited which could be avoided on Linux
desktops (and maybe on some other platforms, too) in most cases by
using the feature that I am suggesting.

&lt;/pre&gt;</description>
    <dc:creator>László Monda</dc:creator>
    <dc:date>2012-04-22T14:47:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9347">
    <title>Re: mc.ext is problematic by nature</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9347</link>
    <description>&lt;pre&gt;László Monda:


On my Gentoo shared-mime-info is installed because of some dependencies,
but there is no desktop at all. Only icewm. There are no system level
defaults. ;)

Hartmut
&lt;/pre&gt;</description>
    <dc:creator>Hartmut Figge</dc:creator>
    <dc:date>2012-04-22T00:43:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9346">
    <title>Re: mc.ext is problematic by nature</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9346</link>
    <description>&lt;pre&gt;First of all, sorry for the very late reply.

On Tue, Apr 10, 2012 at 9:24 AM, Holger Herrlich
&amp;lt;holgerherrlich05&amp;lt; at &amp;gt;arcor.de&amp;gt; wrote:

The advantages are respecting system-level defaults and behaving
consistently.  (And please let's not go again into whether the
freedesktop standards constitute as system level standards because
it's the best that we have on Linux desktops and it's fairly widely
available.)

It has been emphasized in this thread that MC is a cross-platform
application that can run on Linux desktops, Linux servers, OpenWrt,
Android, etc.  If so, then it doesn't make a damn sense to provide a
single hardcoded association file (mc.ext) for all these platforms.

The freedesktop standards pertain to Linux desktops, Android surely
has something else and some systems don't have anything.


I don't want anything in mc.ext to be changed.  I'd rather want a
checkbox option under Options -&amp;gt; Configuration called something like
"override mc.ext associations with native ones" which would override
the mc.ext open actions with the associations that are defined on the
system level.

&lt;/pre&gt;</description>
    <dc:creator>László Monda</dc:creator>
    <dc:date>2012-04-21T11:04:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9345">
    <title>Re: translator help</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9345</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

11.04.2012 02:52, Marco Ciampa wrote:
Transifex have console client named tx. I constantly updated
translations from Transifex via 'tx' utility. For example:
tx pull
fetch translations (*.po files) from Transifex
tx push -l it
send it.po to Transifex

But if you want make direct commits to repo, just sign in to
github.com and tell me your github's account name. I'll add you to
pusher's list.


- -- 
WBR, Slavaz.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+HHLYACgkQb3oGR6aVLpr5AgCaAnownWy7RKFn1vqMCJ5GOXa+
VR0An0kFHiu89u69Erl4720iIFkrjYN6
=XBvM
-----END PGP SIGNATURE-----
_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

&lt;/pre&gt;</description>
    <dc:creator>Slava Zanko</dc:creator>
    <dc:date>2012-04-12T18:19:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9344">
    <title>translator help</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9344</link>
    <description>&lt;pre&gt;I used to be the Italian MC translator.
Now I cannot access the git archive.
I was not active for a long time and MC needs to be updated.

May I re-gain vc write permission again?

I cannot think that a web interface is a good thing for a 
caracter-space constrained application as is MC. Messages needs to be
finely space calibrated...only a compilation could test it well. IMHO a
translator needs to compile and test the program _before_ committing to
any user-frendly web interface as Transiflex...in this regard Transiflex
could easily drive to translation(positional/space) errors...

TIA

&lt;/pre&gt;</description>
    <dc:creator>Marco Ciampa</dc:creator>
    <dc:date>2012-04-10T23:52:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9343">
    <title>Re: mc appends apostrophe to PATH environment variable [solved]</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9343</link>
    <description>&lt;pre&gt;Hi!


Trying to dig into the problem I found that .bashrc has been tampered
by a script of the installation process. This only manifests
when .bashrc is called explicitly, as it is done by mc start. So it is
NOT an mc bug.

...  but as the same tapering happened on two machines this tampering
may be part of the Gentoo installation system (or controlling scripts
of the installation). So please note that the problem resides within
the .bashrc script, if anybody else stumbles over this PATH tampering
on mc start. Look carefully at the quotes in .bashrc and double check
there pairing.

Sorry for the noise.
 
Harald
_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

&lt;/pre&gt;</description>
    <dc:creator>ralda-Mmb7MZpHnFY&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-04-04T16:32:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9342">
    <title>mc appends apostrophe to PATH environment variable</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9342</link>
    <description>&lt;pre&gt;Hi!

I just found that mc appends an apostrophe to the PATH environment
variable, rendering the last entry in the search path unusable. As this
has not been seen before, it looks to me that one of the last updates
introduced this.

The problem can easily be reproduced:
- enter a valid PATH specification
- export PATH
- env|grep ^PATH= shows correct value
- startup mc (not using the wrapper scripts)
- enter the command "env|grep ^PATH="

-&amp;gt; PATH environment variable has an appended apostrophe now


I'm currently using:
GNU Midnight Commander 4.8.2
Built with GLib 2.30.3

Build and installed on up to date Gentoo based system.

Feel free to ask for more information, if required. I'm not subscribed
so please mail me.

--
Harald
_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

&lt;/pre&gt;</description>
    <dc:creator>ralda-Mmb7MZpHnFY&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-04-04T15:24:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9341">
    <title>Re: mc.ext is problematic by nature</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9341</link>
    <description>&lt;pre&gt;
Yes, I did because I use mc on dozens of servers and on two OpenWrt
routers on a regular basis.  I suggested not taking system level
associations if the relevant directories are not present on a system.


I didn't say that the current standards are perfect but these are the
best that we have for now.  Currently basic filename associations for
Office file formats and PDF don't work out of the box from mc on a
modern Linux desktop and let's not even speak about dozens of others.

mc could take the list of associations that are based on the
*currently installed* applications on a system and use those out of
the box.  I think it'd be a huge advantage by itself.


Although I doubt that it's a showstopper please elaborate on that.

&lt;/pre&gt;</description>
    <dc:creator>László Monda</dc:creator>
    <dc:date>2012-04-09T10:04:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9340">
    <title>Re: mc.ext is problematic by nature</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9340</link>
    <description>&lt;pre&gt;2012/4/8 Szabó Gergely &amp;lt;szg&amp;lt; at &amp;gt;subogero.com&amp;gt;:

As I said a bit earlier in a related discussion the relevant standards are
http://www.freedesktop.org/wiki/Specifications/mime-actions-spec and
http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
which are implemented by Gnome 3 and which are supposed to be
implemented by major desktops.


I'd check whether the shared-mime-info package (which implements the
above standards) is installed and not try to read system level
defaults if it's not.


Although these are rather exotic environments in these cases I'd check
whether the relevant directories are available on the system and not
try to read those system level defaults if they're not there.


Given that the above standards define a directory hierarchy the
associations are easily readable from within an SSH session.


Yes, and respecting system level defaults also has definite advantages.




&lt;/pre&gt;</description>
    <dc:creator>László Monda</dc:creator>
    <dc:date>2012-04-09T00:00:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9339">
    <title>Re: mc.ext is problematic by nature</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9339</link>
    <description>&lt;pre&gt;On Sun, Apr 8, 2012 at 10:00 PM, Holger Herrlich
&amp;lt;holgerherrlich05&amp;lt; at &amp;gt;arcor.de&amp;gt; wrote:

The relevant standards are
http://www.freedesktop.org/wiki/Specifications/mime-actions-spec and
http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec

I'm not sure about every window manager but Gnome 3 adheres to this
standard and probably some major ones, too.  Lots of freedesktop.org
standards such as these define many basic architectural building
blocks of modern Linux desktops.


I can't see what dragging windows has to do with filename associations.


At this point it's not hard to tell that your opposition to the idea
of mc.ext going away is strong.  Instead of hurting mc.ext in any ways
I'd like to emphasize the advantages of respecting system defaults
(and making them overridable through mc.ext).


Please realize that if you defined all the associations that you care
about in mc.ext you couldn't care less with system level defaults
because those would be overridden by mc.ext.


You made your point clear, mc.ext has its advantages.  So as taking
system level defaults, I think.

&lt;/pre&gt;</description>
    <dc:creator>László Monda</dc:creator>
    <dc:date>2012-04-08T22:48:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9338">
    <title>Re: mc.ext is problematic by nature</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9338</link>
    <description>&lt;pre&gt;
Hello,

I think the problem is that Unices don't have the concept of
system level defaults. Gnome and KDE do, but they are not the system.
What would you do on a text-only Debian Squeeze server? Or an Android
phone? Or an OpenWRT router?
Even if the computer had Gnome, what would you do if you were
connected to the machine through a text-only ssh-session?

So it's all up to the user or, in our case, mc.ext.

Best regards
Gergely Szabo
_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

&lt;/pre&gt;</description>
    <dc:creator>Szabó Gergely</dc:creator>
    <dc:date>2012-04-08T20:50:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9337">
    <title>Re: mc.ext is problematic by nature</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9337</link>
    <description>&lt;pre&gt;On Sun, Apr 8, 2012 at 8:33 PM, Holger Herrlich
&amp;lt;holgerherrlich05&amp;lt; at &amp;gt;arcor.de&amp;gt; wrote:

Regarding your example, the user can (and should) change this
association on the system level.  Also, this example is rather an
exception than the norm as system level assiociations are usually
fairly relevant.

I agree however that eliminating mc.ext is probably overkill, but
system level defaults should be taken into consideration and mc.ext
could provide a way to override those.

&lt;/pre&gt;</description>
    <dc:creator>László Monda</dc:creator>
    <dc:date>2012-04-08T19:00:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9336">
    <title>Re: mc.ext is problematic by nature</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9336</link>
    <description>&lt;pre&gt;
Please note that this solution is applied in firefox such that !wine!
notepad is launched for text files in linux -- no way to disable the
feature.

Regards Holger
_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
&lt;/pre&gt;</description>
    <dc:creator>Holger Herrlich</dc:creator>
    <dc:date>2012-04-08T18:33:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9335">
    <title>mc.ext is problematic by nature</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9335</link>
    <description>&lt;pre&gt;Hi List,

Upon reinstalling Linux I had to face mc.ext having lots of
associations that refer to outdated applications.  This is a specific
case but there's a general problem.

The first problem is that MC is supposed to be a cross-platform file
manager and as such it's not possible to cherry-pick applications that
are the best on every platform.  The second problem is that these
applications are in flux and the most popular ones will change by
time.

There are lots of tickets requesting mc.ext changes because of the
above.  On the long run this is a fight against windmills.

Has anybody considered using platform-specific native registries of
file associations instead of using mc.ext?

(Maybe mc.ext shouldn't be deprecated but platform-specific native
registries should be the default and those could be overridden in
mc.ext.)

&lt;/pre&gt;</description>
    <dc:creator>László Monda</dc:creator>
    <dc:date>2012-04-06T22:04:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9334">
    <title>Midnight Commender 4.8.2 (latest) released</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9334</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

mc-4.8.2 now released.

Download page: http://www.midnight-commander.org/downloads?order=id&amp;amp;desc=1


Major changes and fixes since 4.8.1
(https://www.midnight-commander.org/wiki/NEWS-4.8.2)

- - Core

  * Added new flag -X (--no-x11) to allow dont't use X11 to get the
state of modifiers Alt, Ctrl, Shift
  * Support of '~' as home dir in 'Start at:' field in 'Find File' dialog
  * Support of '~' as home dir in hotlists
  * Learn of 'Back Tab' is possible now in 'Learn keys' dialog
  * Optional '0x' prefix for hexadecimal search
  * Dynamically resize panels
  * New bindings (ScrollLeft, ScrollRight) for scroll long filenames
in panels

- - VFS

  * Internal VFS reorganization

- - Editor

  * Added as.syntax

- - Viewer

  * Added action bindings for backward search

- - Misc

  * Added hotkeys for all radio/check-buttons in search/replace dialogs
  * New file bindings:
    - .m4v, .ts - video
    - djv - DjVu
  * Simplify mc.menu - remove LZMA|LZ and change p7 to 7z
  * Updated list of known browsers: gnome-moz-remote mozilla firefox
konqueror opera
  * Added MC_HOME environment variable to set up home directory of MC
  * Lot of code cleanup

- - Fixes

  * Compile failure of 4.8.1 on xBSD because "Undefined symbols:
_posix_fallocate"
  * MC deletes the wrong file because of forced panel reload before
file operation
  * Cannot chdir to directory if directory name contains the dollar sign
  * Incorrect panel size after change panel split type
  * Wrong total bytes counter for subdirs in copy/move dialog
  * Display corruption in panels after window shrink
  * Command line is unaccessible from tree panel
  * Extra confirmation before delete an empty hotlist group
  * Can't open an edit zero-length file from VFS in mcedit
  * mcedit crashes when ~/.config is a file
  * mcedit: reset selection after END/HOME/PgDn/PgUp
  * 'make check' fails on arm and alpha (-z muldefs)

- -- 
WBR, mc development team.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9oaY0ACgkQb3oGR6aVLppPsgCfUlpAFIDwaOdKQ10FSXGqhpph
Df8AoIOWoiNeJnrnk59FpsANgzmyL/YM
=T0UV
-----END PGP SIGNATURE-----
_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

&lt;/pre&gt;</description>
    <dc:creator>Slava Zanko</dc:creator>
    <dc:date>2012-03-20T11:27:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9333">
    <title>Midnight Commander 4.8.1.1 (stable) released</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.mc.devel/9333</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

mc-4.8.1.1 now released (stable).

Download page: http://www.midnight-commander.org/downloads?order=id&amp;amp;desc=1

Major changes and fixes since 4.8.1:
(http://www.midnight-commander.org/wiki/NEWS-4.8.1.1)

Version 4.8.1.1

- - Core

  * Added new flag -X (--no-x11) to allow dont't use X11 to get the
state of modifiers Alt, Ctrl, Shift
  * Support of '~' as home dir in 'Start at:' field in 'Find File' dialog
  * Support of '~' as home dir in hotlists
  * Learning of 'Back Tab' now is possible from 'Learn keys' dialog
  * Optional '0x' prefix for hexadecimal search

- - Editor

  * Added as.syntax

- - Viewer

  * Added action bindings for backward search

- - Misc

  * Added hotkeys for all radio/check-buttons in search/replace dialogs
  * New file bindings:
      - .m4v, .ts - video
      - djv - DjVu
  * Simplify mc.menu - remove LZMA|LZ and change p7 to 7z
  * Updated list of known browsers: gnome-moz-remote mozilla firefox
konqueror opera
  * Added MC_HOME environment variable to set up home directory of MC

- - Fixes

  * Compile failure of 4.8.1 on xBSD because "Undefined symbols:
_posix_fallocate"
  * MC deletes the wrong file because of forced panel reload before
file operation
  * Cannot chdir to directory if directory name contains the dollar sign
  * Incorrect panel size after change panel split type
  * Wrong total bytes counter for subdirs in copy/move dialog
  * Display corruption in panels after window shrink
  * Command line is unaccessible from tree panel
  * Extra confirmation before delete an empty hotlist group
  * Can't open an edit zero-length file from VFS in mcedit
  * mcedit crashes when ~/.config is a file
  * mcedit: reset selection after END/HOME/PgDn/PgUp
  * 'make check' fails on arm and alpha (-z muldefs)

- -- 
WBR, mc development team..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9oY20ACgkQb3oGR6aVLpqO3gCgg3CdQeJmgU4e63dEejC5CeBZ
LZAAnixvnZ3BTE60KrcKui4aNFYoLGJR
=momv
-----END PGP SIGNATURE-----
_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

&lt;/pre&gt;</description>
    <dc:creator>Slava Zanko</dc:creator>
    <dc:date>2012-03-20T11:01:01</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.gnome.apps.mc.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gnome.apps.mc.devel</link>
  </textinput>
</rdf:RDF>

