Re: Help testing release candidate / mc-4.8.23-rc1

[Egmont Koblinger via mc-devel]

Thanks for the quick fix!

I've verified the behavior after an F9. (I didn't do an extensive
walkthrough of the UI, I hope you're confident that shortcuts work
everywhere else too as expected :))

egmont

On Tue, Jun 18, 2019 at 8:38 AM Andrew Borodin  wrote:
>
> On Mon, 17 Jun 2019 22:56:45 +0200 Egmont Koblinger via mc-devel wrote:
> > There's a severe usability regression: After pressing F9 the hotkeys
> > (e.g. O for Options, then L for Layout) don't work.
>
> Thanks for the bugreport.
> Fixed in 7eaa51c79bb74e6e650935e23895c62073ff46c5.
>
> --
> A.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Help testing release candidate / mc-4.8.23-rc1

[Egmont Koblinger via mc-devel]

git bisect points to f5f78ea658 "Ticket #212: implement keybinding for menu."

e.

On Mon, Jun 17, 2019 at 10:56 PM Egmont Koblinger  wrote:
>
> Hi guys,
>
> There's a severe usability regression: After pressing F9 the hotkeys
> (e.g. O for Options, then L for Layout) don't work.
>
> cheers,
> egmont
>
> On Sun, Jun 16, 2019 at 9:14 PM 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.22 release:
> >
> > https://www.midnight-commander.org/nopaste/tarball/mc-4.8.22-166-gcd16697a3.tar.xz
> >
> > $ sha256sum mc-4.8.22-166-gcd16697a3.tar.xz
> > c518e0c746fd6755dd0733e70356c8e6a37bda4122c222de961ab78db24780fa  
> > mc-4.8.22-166-gcd16697a3.tar.xz
> >
> > I've built this tarball out of the latest master with translations from
> > Transifex pulled in on a fresh Fedora 30 VM, which I'm also going to use
> > to build the final release in about a week from now if nothing serious
> > comes up.
> >
> > Many thanks!
> >
> > --
> > Sincerely yours,
> > Yury V. Zaytsev
> >
> >
> > ___
> > mc-devel mailing list
> > https://mail.gnome.org/mailman/listinfo/mc-devel
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Help testing release candidate / mc-4.8.23-rc1

[Egmont Koblinger via mc-devel]

Hi guys,

There's a severe usability regression: After pressing F9 the hotkeys
(e.g. O for Options, then L for Layout) don't work.

cheers,
egmont

On Sun, Jun 16, 2019 at 9:14 PM 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.22 release:
>
> https://www.midnight-commander.org/nopaste/tarball/mc-4.8.22-166-gcd16697a3.tar.xz
>
> $ sha256sum mc-4.8.22-166-gcd16697a3.tar.xz
> c518e0c746fd6755dd0733e70356c8e6a37bda4122c222de961ab78db24780fa  
> mc-4.8.22-166-gcd16697a3.tar.xz
>
> I've built this tarball out of the latest master with translations from
> Transifex pulled in on a fresh Fedora 30 VM, which I'm also going to use
> to build the final release in about a week from now if nothing serious
> comes up.
>
> Many thanks!
>
> --
> Sincerely yours,
> Yury V. Zaytsev
>
>
> ___
> mc-devel mailing list
> https://mail.gnome.org/mailman/listinfo/mc-devel
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: change default configuration

[Egmont Koblinger via mc-devel]

On Fri, Jul 27, 2018 at 7:28 PM, Oswald Buddenhagen <
oswald.buddenha...@gmx.de> wrote:

>
> fwiw, i always found that default setting rather surprising and
> counter-productive, too. the vim/emacs/etc. hardliners will find the way
> to launch their personal deity, err, preferred editor soon enough, while
> average joe (in as far as he uses mc at all) won't appreciate being
> dropped into vi by default ("how do i quit that crap?!" was also my
> first experience).
>

I fully agree, and recommend to change the default to mcedit.

cheers,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

ncurses-6.1 vs. slang-2.3.1 broken

[Egmont Koblinger]

FYI:

This combination:

- MC compiled against S-Lang,
- S-Lang version 2.3.1 (or older),
- terminfo (ncurses) version 6.1 (or newer),
- TERM=xterm-256color

breaks the arrow keys and probably much more.

This is because slang reads the binary terminfo files manually, rather than
via libtinfo, and ncurses-6.1 switched to a new binary format for some of
its files (including xterm-256color but not xterm).

Solution:
- Upgrade to S-Lang pre2.3.2-19 or newer
- Downgrade to ncurses/terminfo 6.0 or older

Workaround:
- export TERM=xterm

But most importantly, anyone encountering this should immediately notify
their distribution, pointing them to e.g.
http://lists.gnu.org/archive/html/bug-ncurses/2018-01/msg00053.html .

This is not a bug in Midnight Commander, nor in the terminal emulator.


cheers,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Help testing release candidate / mc-4.8.20-rc1

[Egmont Koblinger]

Hi,

403 Forbidden.

cheers,
e.

On Sat, Nov 18, 2017 at 7:59 PM, 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.19 release:
>
> https://www.midnight-commander.org/nopaste/tarball/
> mc-4.8.19-128-g92f190e.tar.xz
>
> $ sha256sum mc-4.8.19-128-g92f190e.tar.xz
> d4106d955c586cf593a0558c9c27d51d09dfcca7ea6386873b0922cd5d05add6
> mc-4.8.19-128-g92f190e.tar.xz
>
> I've built this tarball out of the latest master with translations from
> Transifex pulled in on a fresh Fedora 25 VM which I'm also going to use
> to build the final release.
>
> I'd particularly appreciate feedback regarding builds on platforms that
> we aren't regularly using ourselves (non-Linux), like FreeBSD, Solaris,
> etc. If no serious regressions are going to be uncovered, we'll probably
> release 4.8.20 in the week to come...
>
> Many thanks!
>
> P.S. Known build problem on macOS 10.13 High Sierra can be currently
> worked around by forcing utimensat support to off during the build:
>
>   $ export ac_cv_func_utimensat=no
>
> --
> Sincerely yours,
> Yury V. Zaytsev
>
>
>
> ___
> mc-devel mailing list
> https://mail.gnome.org/mailman/listinfo/mc-devel
>
>
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: [PATCH] Initialize struct stat st_[acm]tim.tv_nsec when present

[Egmont Koblinger]

Hi guys,

It is a regression (on my Fedora at least), as timestamps were preserved
> with the earlier mc versions.
>

As far as I understand the current story, this is probably due to some
other change since mc didn't change its relevant code recently.

Also, generally it's not feasible to make a release each time a regression
is fixed. Each release fixes twenty bugs and introduces two new, that's the
way it goes :-D

That being said, this timestamp issue plus the pending mcview growing
issues (which are also quite notable usability problems) are I believe a
good reason to schedule a .20 release for the not-so-distant future (let's
say, within a month or so).

cheers,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: A requirement for the current user to own ttys

[Egmont Koblinger]

On Sun, Mar 12, 2017 at 10:08 PM, Egmont Koblinger <egm...@gmail.com> wrote:

> So, again, if I'm not mistaken, cons.saver basically does the following:
> Based on the ownership, permissions etc. of _/dev/ttyX_, it either grants
> or denies access to _/dev/vcsaX_. You cannot examine the ttyX and the vcsaX
> story independently from each other. They are both part of 1 single complex
> story.
>

Note: I've not checked the source. This is what I firmly believe cons.saver
does, but I might be mistaken. Please correct me if I'm wrong.

e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: A requirement for the current user to own ttys

[Egmont Koblinger]

Hi,

Why do you think on my system I cannot access vcs* devices. As far as I
> remember I never said that.
>

You did include the output of "ls -l /dev/vcs*" on your system, showing
that they're owned by vcsa and chmod 600. So, they are not directly
accessible to your 'echo' or 'ghost' users. They might be accessible via
cons.saver.


> I am sorry if didn't make it clear. On my system cons.saver is owned by
> the vcsa user and has the setuid bit. vcs* devices are owned by the vcsa
> user as well, and the user has read/write permissions.
>

> Once again, my questions were only about tty devices. I do not know why
> you're answering questions I never asked.
>
>
I am not sure if the same security policy should be applied to vcs* devices.
>

So, again, if I'm not mistaken, cons.saver basically does the following:
Based on the ownership, permissions etc. of _/dev/ttyX_, it either grants
or denies access to _/dev/vcsaX_. You cannot examine the ttyX and the vcsaX
story independently from each other. They are both part of 1 single complex
story.


Cheers,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: A requirement for the current user to own ttys

[Egmont Koblinger]

Hi,

On Sun, Mar 12, 2017 at 12:54 AM, Key Offecka  wrote:

>
> if the user (the real user, not the effective one) is root then permission
> check is successful
> else
>   if the user owns the resource then permission check is successful
>   else
> if the user belongs to the group owning the resource then permission
> check is successful
>

I guess we should also add "and the resource is read-writable by its group"


> else deny the access
>

What do you mean by "the resource" in the lines above? There are at least
two pieces of resource in the game, the tty and the vcsa (maybe more, I
don't know). We'd need a much more precise description.

So, I think the main question here: isn't mc too paranoid?
>

It could easily be, dunno.


> To answer this question we could try answering some more specific
> questions:
>
> How do you think
> 1) is it OK that in the descried example root has that dumb terminal?
> 2) if a user doesn't own the tty device but is a member of a group owning
> the tty, should that user have the dumb terminal?
>

There are two sides of the story: the user-expected behavior and the
technical possibilities. Not sure if the two match here. Normally I'd
always put the user-facing behavior first and do the technical bits to
implement the expected user-facing behavior. Having a setuid/setgid bit
changes the game quite a bit, compromises might become necessary, not
having a security hole becomes the number one priority even if the
user-facing behavior suffers from drawbacks.

What I would say is: If the actual real user has the sufficient access to
the tty and vcsa devices even without a setuid/setgid bit (in other words:
they could compile and install a modified version of cons.saver for
themselves which removes all the current verifications and just tries to
operate on the devices and would succeed even without the setuid/setgid
bits) then the checks we have in place should not introduce any obstacles.
There's no point in denying something that a non-setuid/setgid appication
could do.

This definitely covers your 1st point. Root should always have access.

I am not convinced about the 2nd. On my system (Ubuntu) the vcsa devices
belong to the tty group and have read-write perms for this group, so on my
system, yes. On your system where these vcsa devices cannot normally be
accessed by a member of the tty group _and_ the real user is not the same
as the tty's owner, I'm not convinced yet why permission should be granted.

Note that there's also the capabilities subsystem which I know nothing
about.

On the both questions personally I answer: no and no. It's not OK that root
> has the dump terminal, in my opinion it's not OK for a member of the tty
> group to have the dumb terminal.
>

This is a heavily security sensitive topic. Any change should be backed up
by something stronger than an "in my opinion", any loosening should be
thoroughly reviewed, and if there's any doubt, we should err on the side of
being paranoid and restrictive rather than risking a
security/privacy/dataleakage hole.

I'm not against improving the situation at all, but I'd like to see a
strong justification behind every requested change, examining why that
change cannot be used maliciously much rather than why it solves something
on your setup.


cheers,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: A requirement for the current user to own ttys

[Egmont Koblinger]

Hi,

On Sat, Mar 11, 2017 at 7:50 PM, Konstantin I. 
wrote:

> Hi,
>
> > Nope. Via "sudo", the first user is allowed to execute certain commands
> on behalf of the second, not the other way around.
>
> I didn't say "via sudo"
>
You did mention "sudo" a couple of times. You keep talking about "first"
and "second" user, in order to have these you must switch user by some
means. sudo, su, perhaps ssh localhost -- can you think of any other means?


> I said: the second user (`ghost` in this example) is authorised to act on
> behalf of `echo`.
>
This is an absolutely false expectation. It's not how things are working
(and I'm not talking about mc here). The second user does _not_ have access
to the first user's belongings. Try sudoing from a normal user to another
normal one, and then remove a file of the first user. You'll be denied
access.


> How it's done is irrelevant. You mentioned PAM. Ok. Let it be PAM.
>
In that case mc-devel is probably not the right forum to discuss it ;) I
admit it sucks on Linux that it's hard to discuss cross-component issues
and even much harder to come to an agreement and a followup implementation.


> >He has no direct access to the vcsa3 device
>
> Or she, but anyway they have indirect access via the sticky bit. So it
> shouldn't be a problem.
>
There's no sticky bit in the game, I assume you meant the setuid or setgid
bit.

I assume you utterly miss the responsibility of a setuid or setgid app.
It's _not_ that it is granted tons of permissions via this bit and then can
just freely go ahead and do whatever the filesystem's permissions allow
them.

Due to the setuid/setgid bit, it _becomes_ the responsibility of this
helper to explicitly check plenty of conditions to decide whether or not to
grant access to the desired device.

It would be unacceptable if I could log in to a machine with ssh, and then
using the setuid or setgid cons.saver binary I could mess with the consoles
that probably root is using locally. cons.saver _must_ explicitly deny this
from happening.

Maybe the checks it's doing are imperfect, maybe they are a bit too strict
or paranoid and could be loosened up, I don't know. (Note: I can't recall
ever touching or even examining this code. I'm not defending the particular
implementation, I'm defending the overall design.)


> Please take a look at my ls -la outputs. Not only is tty3 owened by echo
> but it's owned also by the tty group. And as you saw ghost is a pretty
> powerful user. The user is a part of the tty group as well. But mc doesn't
> care. It also doesn't care whether this is root or not.
>
It's still unclear to me: What do you expect cons.saver to do differently?


> > implementing alternate screen support in the Linux tty driver, or using
> a graphical emulator. I can't see how mc could solve this issue.
>
> That would be overkilling.
>
No, IMO that would not be overkilling, that would be the proper solution.
Also, all other apps (well, their users) would benefit from this: The
previous contents would be restored upon quitting from vim, emacs, less and
so on.

It could be a matter of taste, but I definitely prefer the graphical
emulators' behavior here. It makes no sense to me to leave (almost) a
screenful of these apps onscreen at an arbitrary position where I happened
to stand when I quit, and to lose the last screenful of my bash activity
whereas older activity is still accessible with Shift+PageUp.

And on a totally irrelevant note (although I'm not sure if I should mention
this, I absolutely don't want to initiate a flame war): I personally don't
see any reason to use the Linux console over graphical terminal emulators,
except for rare critical events. As such, convenience like Ctrl+O after a
sudo is absolutely unimportant for me. Systems that don't have graphical
environment (that is, servers) should be accessed remotely. Graphical
terminal emulators support more features than the Linux console, have a
magnitudes larger scrollback that you don't lose when you switch to a
different one, can search in the scrollback, look so much nicer, are more
configurable, can be arranged freely using your favorite desktop
environment, you can see more of them at the same time, you don't have to
type your password every time you with to have a new one, let alone you can
have other essential apps (e.g. browsers) visible and even copy-paste
between them and so on and so forth. (I used to be a heavy Linux console
user, even "startx"-ing only for those short times when I needed a
graphical app, geez, that was so last century...)

Why not just to follow standard *nix conventions? To respect root
> privileges at least. May I dare to ask to respect group permissions as well
> ;-)
>
Could you please be more specific? I do not understand what you're
_exactly_ asking for. E.g. "respect root privileges" is way too generic,
and if I take it as a setuid root cons.saver should allow any user to
save/restore the contents of any vcs (that's what 

Re: A requirement for the current user to own ttys

[Egmont Koblinger]

Hi,

The requirement here is that the second user (`ghost` in this example) is
> authorised to act on behalf of `echo`.
>

Nope. Via "sudo", the first user is allowed to execute certain commands on
behalf of the second, not the other way around. During this, the second
user doesn't have any access to the first user's resources (e.g. files
under its home). As such, it's utterly irrelevant whether tty3 is owned by
'echo' (the first user) or not. It's not owned by 'ghost' (the second
user), so no access.

If you wish to grant access to tty3 for 'ghost', this should be done by
sudo or the pam framework or whatever, definitely not mc.


> echo:/etc/init.d$ groups ghost
> ghost : users root tty wheel
>

Seems your 'ghost' is a pretty power user. E.g. he can write to the tty
devices, or even hijack the data that's being typed there. Definitely not
something a regular user should have. Plus the root and wheel groups. As
such, you might just as well put the vcsa devices in a group and chmod 660
and hence allow the ghost user to directly access them.


> Question: does mc work in this case as it was designed?
>

It's a compromise due to the lack of alternate screen support. I'd say mc
was designed to paint on the alternate screen, but due to lack thereof it
needed to find a workaround.

behaviour I would expect: in the example above mc shouldn't stop after
> executing commands and should show previous command output.
>

mc is being executed as user 'ghost'. He has no direct access to the vcsa3
device, and the corresponding tty3 is owned by 'echo'. How do you think
mc's cons.saver should figure out that it's safe to grant access?


> I think to achieve the goals you mentioned above (to not allow others to
> see what they shouldn't see) another solution should be found. Do you agree?
>

Yup, like implementing alternate screen support in the Linux tty driver, or
using a graphical emulator. I can't see how mc could solve this issue. If
you can, let us know.


cheers,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: A requirement for the current user to own ttys

[Egmont Koblinger]

Hi,

> All you say about vcs* sounds reasonable, unfortunately according to the
code, the tty owner is the problem.

What do you mean the tty owner is the _problem_? What kind of problem?

I believe it's not the _problem_, it's the piece of information we rely on
to figure out if cons.saver is being run as a legitime user.

> Disregarding of what was the intention,  disregarding of what you were
trying to achieve and what security hole to close, do you think, that sort
of comparison is valid here?

I'm not aware of the details of the code and don't have time to dig into
it, sorry.

As far as I understand, your problem is: You expect that if the real user
is root, cons.saver should dutifully perform its role rather than bail out
due to some ownership mismatch. Am I right? If so, I believe it's a fair
request, although possible security implications should be double checked.
Could you please file a new bug for this?

Thanks,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: A requirement for the current user to own ttys

[Egmont Koblinger]

Hi,

cons.saver, as you apparently know this, is the helper binary responsible
for restoring the contents of the Linux console when you quit mc or press
Ctrl+O. A helper is required since the Linux console does not have an
"alternate screen" that graphical terminal emulators have.

In order to be able to do this, it needs read/write access to /dev/vcsa*.

When you log in on the console, the corresponding /dev/tty* becomes owned
by you but /dev/vcsa* don't. I believe the reason behind it is that there
is a way to revoke the tty from you, but there is no way to revoke the vcsa
access. That is, when you log out, you might keep a background process
running which still has access to it via a previously opened file
descriptor, and subsequently as someone else logs in, you could spy on the
console's contents.

As such, since /dev/vcsa* is not owned by the desired user, cons.saver
needs to be setgid tty (or setuid root).

Setuid/setgid apps must have all these kinds of precautions that you're
asking about, they need to duplicate the permission checks because they are
not being run as the actual real user. It's crucial that someone not
actually sitting in front of the tty cannot trick cons.saver into tampering
with the tty's contents.

Hope this explains the situation.

I'm not sure why something is checked twice, but it can easily be in order
to avoid a race condition (or could easily be a harmless bug as well).

egmont


On Fri, Mar 10, 2017 at 1:06 AM, Key Offecka  wrote:

> Hi,
>
> I am looking at the
>
> main (int argc, char **argv)
>
> function in
>
> src/consaver/cons.saver.c
>
> There are calls like
>
> st.st_uid != uid
>
> fstat (console_fd, ) >= 0 && st.st_uid == uid
>
> fstat (console_fd, ) < 0 || st.st_uid != uid
>
> The last one is especially strange taking into account that it appears
> twice
>
> if (seteuid (euid) < 0
> || lseek (vcsa_fd, 0, 0) != 0
> || fstat (console_fd, ) < 0 || st.st_uid != uid
> || read (vcsa_fd, buffer, buffer_size) != buffer_size
> || fstat (console_fd, ) < 0 || st.st_uid != uid)
>
> This all is taken from the commit e9fd11bfcd1dab97e3ba423bcfb8b6ca1088b11c
> which is the latest at this moment
>
> It looks to me MC tries inventing its own permission scheme rather than
> relying on the system set up.
> Consider there is a user in the system who is allowed to read/write and to
> do whatever they want with vcs, tty and with whatever files else you may
> only wish. root is one obvious candidate but nothing restricts us to set up
> another user taking advantaged of  all those system security facilities.
> There is a traditional UNIX permission scheme, SeLinux may be involved if
> needed. And now comes MC, and introduces a hardcoded/unconfigurable/solid
> as a stone requirement for the current user to be the owner of the files.
> Why so?
>
> I believe there is case and that code is called to cover it. But
> unfortunately I do not see the reason. And this is my question, I would
> appreciate if anybody could explain what security issue was addressed here?
> In my particular case this code introduces an inconvenience, so I just
> removed it and feel total happy without it. But still am a little bit
> concerned about possible consequences which I do now understand at the
> moment.
>
> My case I mentioned above is as follows:
>
> Log into, say, tty3 as a normal user, say `echo`. The tty3 ownership
> changes, and the `echo` user becomes the owner of tty3 which sounds
> reasonable.
> Now sudo as another user who has all access permissions to tty and vcs, In
> my case this is root.
> Press Control+O, MC screws up the background shell, the root user sees the
> blank screen rather than previously executed commands and MC starts
> thinking the terminal is dumb asking to press any key after executing
> commands. And this happens for the root user! MC overwrote the root
> privileges! Does it sound reasonable to you?
>
> Any explanations are welcome.
> Thank you.
>
> --
> Konstantin I.,
>
>
> ___
> mc-devel mailing list
> https://mail.gnome.org/mailman/listinfo/mc-devel
>
>
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc misdetects 256 color support on rxvt

[Egmont Koblinger]

On Wed, May 4, 2016 at 5:44 PM,  wrote:

> I know for a fact that rxvt has 256
> color support because configure outputs:
> --enable-256-color
>

According to my understanding, this means that you cannot know for sure
whether it supports 256 colors because it can be compiled with or without
this feature, upon your request.

egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: small request

[Egmont Koblinger]

On Thu, Apr 28, 2016 at 9:55 AM, solarflow99  wrote:

> Perhaps having something like "save directory paths", "other-dir" or
> similar as Paul mentioned could be added with the default to just be ON.
> This could always be overridden by unchecking it and saving settings.
>
This is complicated. Not especially to implement, but to present on the UI
in a manner that's obvious to users.

So, you'd move one single option to the realm of another config. How about
also boundling current_is_left with this option? Why, or why not?

How about all the other options? What if someone else wants a different
option to be saved upon exit? Will we introduce another meta-option for
them?

Where would the new option "save directory paths" belong? Would this option
itself be saved according to the already existing "auto-save setup" or
according to itself?

  But no one will ever complain about having this back because no one
> complained until it was lost when mc 4.8 came out :)
>
(Assuming it was indeed changed with 4.8) no one except you complained
about it for the last 4.5 years, which is also a good way to measure the
importance of such an option.

While I understand your request and the rationale behind it, I'm really
uncertain that mc should move in this direction.

How about, for the time being, you enable auto-save and create a simple
wrapper script for yourself that replaces your mc configs (restores
everything except for other_dir) before starting up mc?

I'm also thinking that _if_ we're indeed concerned that this and only this
particular option deserves a special treatment, I'm wondering whether
other_dir is better to be remembered globally or per-terminal. Maybe the
latter, in which case we might go towards "mc -P" printing it in a certain
format, and mc.sh storing it in an environment variable (somewhat similar
concept to how the current directory is handled now)...


cheers,
egmont


> Would this really be too hard?
>
> We're talking about default fresh install settings. I don't like mc saving
> settings unless I tell it, also. But to make things easy for new users,
> what should the default setting be?
>
> I vote for auto-save. It makes mc "seem" smart.
>
>
> --
> Peace and Cheer
> ___
> mc-devel mailing list
> https://mail.gnome.org/mailman/listinfo/mc-devel
>
> ___
> mc-devel mailing list
> https://mail.gnome.org/mailman/listinfo/mc-devel
>
>
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: small request

[Egmont Koblinger]

Well, I don't :) but I get your point.

So, to be sure... you're arguing that other_dir should be an exception and
should always be saved, even if the other options aren't?

cheers,
egmont



On Tue, Apr 26, 2016 at 10:53 PM, solarflow99 <solarflo...@gmail.com> wrote:

> I didn't mean to save every change, its just other_dir never saves the
> last directory you were in.  It always used to, thats why I felt the new
> behaviour was wrong.  I find it really annoying to always lose the
> directory I was in, on the opposite panel, don't you?
>
>
>
> On Tue, Apr 26, 2016 at 1:45 PM, Egmont Koblinger <egm...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I personally prefer it being disabled. This way I can quickly change any
>> setting (e.g. panel listing format) knowing it won't persist and my config
>> won't be overwritten. Otherwise I'd eventually end up with a config that
>> slowly, step by step diverges very far away from my original preference, or
>> it would take a significant amount of ongoing effort to manually revert
>> everything that I change just for a couple of seconds.
>>
>> What makes you think the default setting is "wrong"? I don't think
>> there's an objective truth which vaule is the "good" and which is the
>> "wrong". It's a matter of personal taste, and that's why it's configurable.
>>
>> I don't see a solid reason to set one value or the other as the default,
>> and as such, I'd personally prefer to keep it unchanged from the value
>> that's been the default in the last couple of years.
>>
>> cheers,
>> egmont
>>
>>
>> On Tue, Apr 26, 2016 at 8:19 PM, solarflow99 <solarflo...@gmail.com>
>> wrote:
>>
>>> https://mail.gnome.org/archives/mc/2016-April/msg0.html
>>>
>>> Is there any chance this can be set as default, its no use having these
>>> default settings to be wrong.
>>>
>>>
>>> ___
>>> mc-devel mailing list
>>> https://mail.gnome.org/mailman/listinfo/mc-devel
>>>
>>>
>>
>
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: small request

[Egmont Koblinger]

Hi,

I personally prefer it being disabled. This way I can quickly change any
setting (e.g. panel listing format) knowing it won't persist and my config
won't be overwritten. Otherwise I'd eventually end up with a config that
slowly, step by step diverges very far away from my original preference, or
it would take a significant amount of ongoing effort to manually revert
everything that I change just for a couple of seconds.

What makes you think the default setting is "wrong"? I don't think there's
an objective truth which vaule is the "good" and which is the "wrong". It's
a matter of personal taste, and that's why it's configurable.

I don't see a solid reason to set one value or the other as the default,
and as such, I'd personally prefer to keep it unchanged from the value
that's been the default in the last couple of years.

cheers,
egmont


On Tue, Apr 26, 2016 at 8:19 PM, solarflow99  wrote:

> https://mail.gnome.org/archives/mc/2016-April/msg0.html
>
> Is there any chance this can be set as default, its no use having these
> default settings to be wrong.
>
>
> ___
> mc-devel mailing list
> https://mail.gnome.org/mailman/listinfo/mc-devel
>
>
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Egmont Koblinger]

On Sun, Nov 8, 2015 at 10:29 PM, Yury V. Zaytsev  wrote:

> Sure, I can try to find time to help... Are you on IRC?

Nope.  I can join if I know there's something particular going on that
I know about in advance and happen to be available at that time, but
generally I prefer offline discussions (bugtracker, mailing list).

Thanks for the links!  It's new to me that I can edit the wiki page, I
guess you guys just recently granted me permissions.

I'll let you know if I get stuck somewhere.


thanks,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Egmont Koblinger]

Hi,

My git knowledge is pretty accurately described by
http://xkcd.com/1597/ , so the first time I'll do that branching and
merging (esp. the latter) it'd be great if someone double checked on
me.

Also: What are the steps to be performed before/after a commit?  I
mean, run the unittests (make tests -- that's it?), check if the code
is formatted (make indent -- correct?), update the NEWS file (how?),
anything else?


thanks,
egmont


On Sun, Nov 8, 2015 at 9:49 PM, Yury V. Zaytsev <y...@shurup.com> wrote:
> On Fri, 2015-11-06 at 19:43 +0100, Egmont Koblinger wrote:
>
>> For minor changes, such as a followup bugfix in the viewer (e.g. 3531)
>> I wouldn't want to wait for more than a couple of days; let's say a
>> week at most.  Does this sound okay?
>
> A week would be fine with me for minor changes, and I trust your
> judgment on what's minor enough... sadly, I can't keep track of changes
> on this timescale, but hopefully Andrew will keep an eye and yell if
> something goes very very wrong.
>
> You probably already know this, but there is a helpful report page on
> Trac which among other things can show tickets waiting for a review...
> you can use that to check for tickets that need feedback.
>
> As far as I can see, you've accepted the GitHub invitation, so you
> should have access to the repository by now, and you've got Trac admin
> privileges as well, so that you can ravage the tickets and the wiki.
>
> Let me know if there is anything else I can do for you. I'll be checking
> the mailing lists from time to time, but one way to catch my attention
> in the case of emergency is to put me explicitly on CC.
>
> --
> Sincerely yours,
> Yury V. Zaytsev
>
>
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Egmont Koblinger]

On Sun, Nov 8, 2015 at 10:43 PM, Yury V. Zaytsev  wrote:

> Sure, I also prefer pull to push, but I find realtime to be much more
> efficient when it comes to stuff like "can you hand-hold me while I'm
> merging a branch for the first time".

Sure, let's do so at one point.

Thanks,
e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Egmont Koblinger]

Thanks to all of you guys!

On Thu, Nov 5, 2015 at 10:13 PM, Yury V. Zaytsev  wrote:

> How about doing it the other way around from now on? You put the branch
> on review, and if there is no vote coming, and no one vehemently objects
> on technically substantiated grounds, it can go into master after 4
> weeks, or I can rubber-stamp it if you want to keep the formalities :-)

Could we make it more flexible based on the weight of the change?
E.g. for an mcview rewrite 4 weeks is totally reasonable.  For
user-visible changes such as dimming wrapped lines (3546) it's also
okay for me to wait that long for input, to give you time to speak up
against it or come up with alternative approaches.

For minor changes, such as a followup bugfix in the viewer (e.g. 3531)
I wouldn't want to wait for more than a couple of days; let's say a
week at most.  Does this sound okay?

> The obligations anyone here has are at best the "moral" ones. There is
> no signing of contracts involved in getting commit access. Only I'd
> expect you not wiping the repository after a tequila party, feeling
> responsible for fixing stuff you happened to break, being careful with
> the private keys if you need/want access to more infra, etc. and in
> general keep the pills handy. I don't think this would be a problem,
> would it?

This is of course obvious.  (I didn't sign anything for gnome-terminal
either, at least I can't remember... I might have had to click once on
some legal stuff, but definitely nothing more than that.)


Thanks a lot,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

mc and me

[Egmont Koblinger]

Hi guys,

I've been thinking about writing something like this for quite a long time...

Some of you might know that I like contributing to various open source
projects as a hobby.  Some of you might know what my top hobby project
is.  mc is the second in the line.

Recently I've devoted a much bigger portion of my hobby time to that
other project (gnome-terminal/vte), probably mostly because I'm
welcome there.  I have git access (I didn't request, they recommended
it to me), I can submit the trivial changes straight away, while I
still ask the main developer's opinion on bigger ones.  Sometimes we
disagree, I try to convince him, but if I fail, it's his choice.
Sometimes he reverts a patch that he disagrees with.  Despite these,
contributing there is fun.

We've talked a lot about the development process not being anywhere
near as smooth as it should be.  On one hand there's noone to blame:
it's just a bunch of guys all spending their free time on the project.
On the other hand: I think it would be the responsibility of the
current developers to allow others to contribute more easily, and step
out of the way if they're the bottleneck.

I think I have contributed quite some useful features and generally
good quality code, and hope that I could build up certain reputation
and trust in the team.  Some guys here have already recommended that I
get git access, although I never asked.

The time has come.  The current way of so slowly getting feedback or
acceptance on my contributions is not going to work anymore.  I'm
tired of this, really tired.  I'm happy to contribute as long as it's
fun.  Probably #3534 comment 18 was the last straw (a one-character
change probably not making it into the next release).  No, I didn't
get offended, I didn't take it personally.  It could have been the
lack of feedback on any other ticket, there's been so many recently.

I just realized it doesn't work.  I realized it's no longer fun.

The question is: backwards, or forwards?

Hereby I'm requesting to become a member of the team, with git access,
getting to know the development process, policies (e.g. which changes
require approval, when to git branch, etc.), and requesting to get
faster responses to my patches that require review – or to be able to
submit them if I don't get response in a certain amount of time.  (We
can still revert a change later if someone disagrees.)

I'm sorry, but next to a full-time job, another hobby coding project,
and some weird thing called life, I'd like to make it clear that I
can't take on any responsibility.  I'm happy to help and improve mc
whenever/wherever I feel like, keep doing what I did so far and do
even more, but without obligations.  Can you guys make it easier for
me?  Do you trust me enough?

If so, let's move forward!

If not, I'll replace mc by another hobby where I have much more fun.

Thanks a lot,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Please release 4.8.15

[Egmont Koblinger]

Hi guys,

Ping - any plans??

4.8.14 is the longest lived release of the 4.8 era despite of its
nasty segfault. I remember the days when a bug like this caused a
follow-up release in just a few days.

Please make a .15 release ASAP!

If there are 2-3 more fixes you'd like to sqeeze in, sure, go ahead
and apply them quickly (and please include #3534 as well).

If there are 10-15 fixes you'd like to squeeze in, please forget it --
release a .15 now and a .16 when you're ready with those!  Please
don't delay the segfault fix any further!

thanks,
e.

On Sun, Oct 18, 2015 at 9:22 PM, Egmont Koblinger <egm...@gmail.com> wrote:
> Hi guys,
>
> Now that the infamous segfault is finally fixed, could we please have
> a new release in the very near future?
>
> mc -- according to a certain way of counting -- will be 21 years old
> by the end of this month (see last year's 20th birthday mail).  It
> means it'll be allowed to buy alcoholic drinks in the U.S.  I think
> this is a perfect reason to celebrate with a cool release, isn't it?
> :)
>
> I'd personally like to see #3534 fixed (failure if PROMPT_COMMAND ends
> in a semicolon -- the first patch from the ticket is the safer one),
> other than that I'm totally okay with current master.  Just please
> don't commit last minute heavy changes ;)
>
> cheers,
> egmon
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Midnight Commander not compiles on Debian Squeeze

[Egmont Koblinger]

Hi Andrey,

This was introduced by a recent patch created by me that fixes a
segfault (a critical bug in 4.8.14). libc6's version is irrelevant,
glib matters here. I think so far mc required a glib that's not older
than about 7 years if I remember correctly. This change makes it
require glib-2.26 which is 5 years old.

I'm personally absolutely okay with this requirement and wouldn't want
to replace with a more complex, more hackish solution to support old
systems. It's reasonable to expect that you can't update apps after a
while wihtout updating the core system, and 5 years is a very long
time in computer science.

The configure checks should, of course, be updated to explicitly fail
on glib version checking. I forgot to do this, and I'm asking
mainstream developers to do it for me.

Mainstream developers might disagree with me and find it important to
support older systems. In that case I'd leave it for them to fix it.
I'm happy to improve mc and make it a better product, looking towards
the future, and of course making sure it runs on reasonably new
systems. But I have no personal interest in making it run on 5 year
old boxes, sorry. If you're happy with a base system that's 5 years
old, I'm assuming you should be happy with an mc from those days too.

Anyway, thanks for the heads-up, I didn't pay attention to the age of
the library call I'm introducing, and I'd definitely find a workaround
if it was let's say a 2-year old feature. But with 5 years my
recommendation is to bump the required glib version by mc developers,
and for you to upgrade your system or manually "git revert" this
change for the time being (re-introducing the potential segfault for
yourself).

Thanks,
Egmont

On Mon, Oct 19, 2015 at 2:14 PM, Andrey Tataranovich
 wrote:
> Hello,
>
> While compiling e0c16d739926f194c72459f41124b161849e88a3 from
> master branch I've got following error on Debian Squeeze host:
>
> /bin/bash ../libtool  --tag=CC   --mode=link gcc -std=gnu99
> -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-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-function -Wunused-label -Wunused-parameter -Wunused-result
> -Wunused-value -Wunused-variable -Wwrite-strings  -g -O2 -g -Wall -O2
> -o mc main.o libinternal.la ../lib/libmc.la libtool: link: gcc
> -std=gnu99 -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-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-function -Wunused-label -Wunused-parameter -Wunused-result
> -Wunused-value -Wunused-variable -Wwrite-strings -g -O2 -g -Wall -O2 -o
> mc main.o  ./.libs/libinternal.a ../lib/.libs/libmc.a -lslang -lgpm
> -lssh2 /usr/lib/libgmodule-2.0.so -lrt /usr/lib/libglib-2.0.so
> -pthread ./.libs/libinternal.a(lt58-regex.o): In function
> `mc_search__g_regex_match_full_safe': 
> /tmp/buildd/mc-4.8.14~git20151019/lib/search/regex.c:268:
> undefined reference to `g_regex_get_compile_flags' collect2: ld
> returned 1 exit status make[4]: *** [mc] Error 1 make[4]: Leaving
> directory `/tmp/buildd/mc-4.8.14~git20151019/src'
>
> Debian Squeeze libc6 version is 2.11.3.
>
> --
> WBR, Andrey Tataranovich
> ___
> mc-devel mailing list
> https://mail.gnome.org/mailman/listinfo/mc-devel
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Midnight Commander not compiles on Debian Squeeze

[Egmont Koblinger]

Hi :)
I'm drunk now but i think i included the version number in the prev mail.
See the doc of g-regex-get-compole-flags to get it :)

Sent from mobile
On Oct 19, 2015 9:25 PM, "Yury V. Zaytsev"  wrote:

> On Mon, 2015-10-19 at 20:30 +0300, Andrey Tataranovich wrote:
> >
> > Glib version check should be introduced in this case. My opinion - if
> > configure completes without error, then compilation should go without
> > error too. Otherwise it is a FTBFS bug.
>
> Hi Andrey,
>
> If you can come up a one-liner patch to make it compatible with old
> glib, we can think of applying it; I have nothing against supporting
> older glib per se, unless it comes with too much of a maintenance
> cost... but I'm not really sure if it's worth it.
>
> Back when I was taking care of backporting mc to older RHELs, I simply
> used to build newer glib statically from within the package and link mc
> to it... that's the route I'd suggest you to go if you care about
> backporting mc to Squeeze.
>
> Hi Egmont,
>
> Could you please be so kind as to tell me what's the minimal version
> required now? I can look into bumping the version in the configure
> check... as soon as I manage to get to it :-/
>
> Thanks!
>
> --
> Sincerely yours,
> Yury V. Zaytsev
>
>
>
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Migration to Travis CI and help with tests

[Egmont Koblinger]

On Sun, Oct 18, 2015 at 10:24 PM, Yury V. Zaytsev  wrote:

> ../../../src/viewer/datasource.c: In function ‘mcview_load_command_output’:
> ../../../src/viewer/datasource.c:398:16: error: declaration of ‘pipe’ shadows 
> a global declaration [-Werror=shadow]
>
> I would appreciate if someone could have a look and provide a patch. For
> now, I have simply disabled this warning.

I _guess_ it conflicts with the pipe(2) system call included from
unistd.h; you'd just have to rename that variable.

Ps. Thanks for whatever you're doing, I have no clue what this "Travis
CI" is, I even had to copy-paste it to a terminal to figure out if
that's a lowercase L or an uppercase i :D

cheers,
e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Please release 4.8.15

[Egmont Koblinger]

Hi guys,

Now that the infamous segfault is finally fixed, could we please have
a new release in the very near future?

mc -- according to a certain way of counting -- will be 21 years old
by the end of this month (see last year's 20th birthday mail).  It
means it'll be allowed to buy alcoholic drinks in the U.S.  I think
this is a perfect reason to celebrate with a cool release, isn't it?
:)

I'd personally like to see #3534 fixed (failure if PROMPT_COMMAND ends
in a semicolon -- the first patch from the ticket is the safer one),
other than that I'm totally okay with current master.  Just please
don't commit last minute heavy changes ;)

cheers,
egmon
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Call for help: Please test patch to 3449

[Egmont Koblinger]

Friendly ping...
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc-4.8.14 hangs on select for 10 seconds at startup

[Egmont Koblinger]

The upstream ticket for this issue (caused by the semicolon at the end
of PROMPT_COMMAND) is at:
https://www.midnight-commander.org/ticket/3534

e.

On Mon, Jun 1, 2015 at 2:53 AM, Mooffie  wrote:
> On 6/1/15, Mike Smithson  wrote:
>> On startup it hangs for 10 seconds, apparently on a select() call.
>> I've edited this strace dump for brevity:
>> ...
>> 04:20:19 read(6, "-S", 128) = 2
>> 04:20:19 select(9, [6 8], NULL, NULL, {9, 971293}) = 1 (in [6], left {9,
>> 971287})
>> 04:20:19 read(6, "TO", 128) = 2
>> 04:20:19 select(9, [6 8], NULL, NULL, {9, 971287}) = 1 (in [6], left {9,
>> 971281})
>> 04:20:19 read(6, "P ", 128) = 2
>> 04:20:19 select(9, [6 8], NULL, NULL, {9, 971281}) = 1 (in [6], left {9,
>> 971275})
>> 04:20:19 read(6, "$$", 128) = 2
>> 04:20:19 select(9, [6 8], NULL, NULL, {9, 971275}) = 1 (in [6], left {9,
>> 971269})
>> 04:20:19 read(6, "'\r\n", 128)  = 3
>> 04:20:19 select(9, [6 8], NULL, NULL, {9, 971269}) = 1 (in [6], left {9,
>> 970702})
>> 04:20:19 read(6, "bash: PROMPT_COMMAND: line 1: sy"..., 128) = 128
>> 04:20:19 select(9, [6 8], NULL, NULL, {9, 970702}) = 1 (in [6], left {9,
>> 970700})
>> 04:20:19 read(6, "STOP $$'\r\n[miven@cobra ~]$ ", 128) = 27
>> 04:20:19 select(9, [6 8], NULL, NULL, {9, 970700}) = 0 (Timeout)
>> ...[10 seconds of nothing]...
>
>
> Two people report the same (or similar) problem here:
>
> https://bbs.archlinux.org/viewtopic.php?id=131530
>
> See the last three comments there: try clearing the PROMPT_COMMAND env
> variable, or disabling your keybindings in .inputrc (such bindings can
> also be in your shell's startup file(s) in the form of "bind"
> command(s)).
> ___
> mc-devel mailing list
> https://mail.gnome.org/mailman/listinfo/mc-devel
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Call for help: Please test patch to 3449

[Egmont Koblinger]

After 2 weeks of testing, the patch seems to be good.

Dear devels, please apply it and release 4.8.15 in the very near future, thanks!

egmont


On Mon, Sep 14, 2015 at 11:02 PM, Egmont Koblinger <egm...@gmail.com> wrote:
> Nevermind, I ended up filing 3524 and 3525.
>
> Everything correlates with everything in weird ways...
>
> On Mon, Sep 14, 2015 at 10:08 PM, Egmont Koblinger <egm...@gmail.com> wrote:
>> On Mon, Sep 14, 2015 at 8:47 PM, Yury V. Zaytsev <y...@shurup.com> wrote:
>>
>>> Does it only fix the segfault (which would be already awesome), or it
>>> also fixes the side problem of the "whole words" thing that I have
>>> discovered while investigating the segfault?
>>
>> The segfault only. The other one (comment 16) totally fell through the 
>> cracks.
>>
>> Could you please open a separate bugreport for that, so that it's
>> easier to keep track of that?
>>
>> In the mean time I've also found another bug...
>>
>>
>> thanks,
>> egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Call for help: Please test patch to 3449

[Egmont Koblinger]

Hi,

The latest stable release (4.8.14) has an infamous segfault bug that's
been unresolved for half a year now.

I created a patch, it's attached to
https://www.midnight-commander.org/ticket/3449

Could you guys please test this patch thoroughly?

It seems to work for me, but I haven't had the change to stress-test
it. It would be nice to test the trickier cases as well, e.g. when the
system locale vs. the file's charset don't match (you alter the
charset in mcview with Alt+E), etc., whatever you can think of.

It would be great to have a 4.8.15 release in the near future (let's
say within a month) if everything's fine.

Thanks,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Call for help: Please test patch to 3449

[Egmont Koblinger]

Nevermind, I ended up filing 3524 and 3525.

Everything correlates with everything in weird ways...

On Mon, Sep 14, 2015 at 10:08 PM, Egmont Koblinger <egm...@gmail.com> wrote:
> On Mon, Sep 14, 2015 at 8:47 PM, Yury V. Zaytsev <y...@shurup.com> wrote:
>
>> Does it only fix the segfault (which would be already awesome), or it
>> also fixes the side problem of the "whole words" thing that I have
>> discovered while investigating the segfault?
>
> The segfault only. The other one (comment 16) totally fell through the cracks.
>
> Could you please open a separate bugreport for that, so that it's
> easier to keep track of that?
>
> In the mean time I've also found another bug...
>
>
> thanks,
> egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Call for help: Please test patch to 3449

[Egmont Koblinger]

On Mon, Sep 14, 2015 at 8:47 PM, Yury V. Zaytsev  wrote:

> Does it only fix the segfault (which would be already awesome), or it
> also fixes the side problem of the "whole words" thing that I have
> discovered while investigating the segfault?

The segfault only. The other one (comment 16) totally fell through the cracks.

Could you please open a separate bugreport for that, so that it's
easier to keep track of that?

In the mean time I've also found another bug...


thanks,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Plans for Midnight Commander development

[Egmont Koblinger]

I think the top priority right now should be to fix the regex crash
issue and release a 4.8.15. Then figure out what to do :)

Unfortunately I won't be able to work on it any time soon.


e.

On Wed, Aug 12, 2015 at 2:28 PM, Pavel Tsekov ptse...@gmx.net wrote:
 Hello Yury,

 Sunday, May 31, 2015, 9:30:49 PM, you wrote:

 It seems that I'm the only member of the current team left who still
 wants to go on with the project, so here is my current plan.

 So, it is this time again? :) I'd be happy to help with any
 development related efforts.

 Best regards,
 Pavel Tsekov

 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site

[Egmont Koblinger]

Another thing that occurred to me: to save on long term development costs,
we should simplify the codebase and get rid of alternatives.

Slang and ncurses - keep one, drop the other

Glib regex and pcre - same

Charset: there are 5 possibilities handled by branches throughout the code
(built with/without codeset support; if with: data is utf8 or 8bit, display
is utf8 or 8bit) - let the most generic code branch handle all cases.

Plugins: IIRC some folks already asked for multiple possible languages to
write plugins in - hell, no, choose one and stick to that.

Etc...

Let's not put things on meta level unless there's a good reason. Let's
maintain 1 filemanager, not many at once.

e.

Sent from mobile
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc is over!?

[Egmont Koblinger]

Btw i fixed gnome-terminal's key sequences about a year ago

Sent from mobile
On May 28, 2015 11:57 PM, Steve Rainwater srainwa...@ncc.com wrote:

 Hi all,

 I'm another long time user of mc. I've used it on Windows, Solaris,
 HP-UX, and currently on GNU/Linux (mostly Fedora and CentOS). I use it
 daily and find it an indispensable tool. Thanks to everyone who's worked
 on it over the years! If mc development is really coming to an end
 without new developers, I'm willing to devote a little time to working
 on it. I'm a C programmer and have submitted patches here and there to
 other projects like Apache and LibXML2.

 I don't really care much about new mc features but I would like to see
 work done on fixing bugs. There are mc bugs that have annoyed me for
 many years, like the keybinding breakage with with GNOME terminal that
 happened four or five years back and still isn't fixed.

 Can someone point me to the developer resources like the source code
 repo? I guess a good starting point is check out the current code and
 get it compiling. Do new developers need to create an account anywhere
 to get access?

 -Steve


 On Thu, 2015-05-28 at 20:03 +0100, Michal Pirgl wrote:
  Hi
 
  I have been using mc for many years and I would like to thank to
  everyone who spent their time on this project.
 
  I also cannot promise 20hrs in a week but I would like to
  participate/develop as much as I can to help in free time.
 
  Regards,
  Michal
 
 
 
  From: Mike Smithson mdooligan gmail com
  To: mc-devel gnome org
  Cc: mc gnome org
  Subject: Re: mc is over!?
  Date: Thu, 28 May 2015 07:26:22 -0700
 
  
 
  Bah. Mc is not over. Things change, that's all.
 
  I've been into mc since I don't know when. The first time I
  used it. Mid/late 90s I'm guessing. I saw how it floundered
  in the 4.6 series. I shrugged and kept tweaking and hacking my
  version. A few years went by and I looked it up again, purely
  out of curiosity.
 
  I was delighted that someone had given it a full work over into
  the 4.8 series. There were some persistent, puzzling, and very
  annoying bugs that are now gone.
 
  Excellent work, gentlemen. Thank you very much.
 
  My list of personal patches went from ~30 down to ~5, where they
  sit now, mostly minor interface tweaks. Mc works, and it works
  very well. If development stagnates for a while, so be it. There
  is actually very little to do. Mc is as close to perfect as
  software gets. There will always be bugs and minor tweaks, and
  that's what needs to be worked on, now and forever.
 
  Yes, mc in its current incarnation is a model from the 1990s. I
  like it that way. I'm not a big fan of C++. I also don't like
  eye candy in a tool that is all about functionality and utility,
  and I very much appreciate a file manager that can operate when
  XWindows cannot, or the system is barely bootable.
 
  It's the perfect size: big enough to be feature-rich and highly
  usable, yet small enough that a single individual can
  (theoretically) get his head around the entire code base. It's
  also fun to hack.
 
  I cannot guarantee 20hrs/week, but I would be very interested to
  work through bug reports and small enhancement requests at my
  own pace, and see what I can get done.
 
  As a last thought for this email:
 
  I suppose what we have here is a complete lack of consensus as to
  the direction to take if we were to move into a 5.0 series.
  My thinking is along the lines of complete modularity: a basic
  interface design (that already exists) and everything else is
  plugins. What if I want to use mc for inventory control? Make a
  plugin to work with SQL instead of filesystem. Perhaps there
  needs to be room for people to experiment with this sort of
  thing. A 4.9beta branch that starts off as mess and arguments but
  slowly gets sorted into something with vision.
 
  That's my 2 cents worth.
 
  Take care, and best wishes for those who are moving on to bigger
  and better things. Thank you for your labors.
 
 
 
  --
  Peace and Cheer
  ___
  mc-devel mailing list
  https://mail.gnome.org/mailman/listinfo/mc-devel


 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc is over!?

[Egmont Koblinger]

You ask for source code repo and stuff? Do apologize to me,it's alot of
shots andd beers speaking of me right now, but if you ask these questions
and couldn't figure out the answers for yourself (I mean: the answer is
straight there on the opening homepage of mc) then i'm afraid you might not
be the kind of person the project's looking for. Sry

Sent from mobile
On May 28, 2015 11:57 PM, Steve Rainwater srainwa...@ncc.com wrote:

 Hi all,

 I'm another long time user of mc. I've used it on Windows, Solaris,
 HP-UX, and currently on GNU/Linux (mostly Fedora and CentOS). I use it
 daily and find it an indispensable tool. Thanks to everyone who's worked
 on it over the years! If mc development is really coming to an end
 without new developers, I'm willing to devote a little time to working
 on it. I'm a C programmer and have submitted patches here and there to
 other projects like Apache and LibXML2.

 I don't really care much about new mc features but I would like to see
 work done on fixing bugs. There are mc bugs that have annoyed me for
 many years, like the keybinding breakage with with GNOME terminal that
 happened four or five years back and still isn't fixed.

 Can someone point me to the developer resources like the source code
 repo? I guess a good starting point is check out the current code and
 get it compiling. Do new developers need to create an account anywhere
 to get access?

 -Steve


 On Thu, 2015-05-28 at 20:03 +0100, Michal Pirgl wrote:
  Hi
 
  I have been using mc for many years and I would like to thank to
  everyone who spent their time on this project.
 
  I also cannot promise 20hrs in a week but I would like to
  participate/develop as much as I can to help in free time.
 
  Regards,
  Michal
 
 
 
  From: Mike Smithson mdooligan gmail com
  To: mc-devel gnome org
  Cc: mc gnome org
  Subject: Re: mc is over!?
  Date: Thu, 28 May 2015 07:26:22 -0700
 
  
 
  Bah. Mc is not over. Things change, that's all.
 
  I've been into mc since I don't know when. The first time I
  used it. Mid/late 90s I'm guessing. I saw how it floundered
  in the 4.6 series. I shrugged and kept tweaking and hacking my
  version. A few years went by and I looked it up again, purely
  out of curiosity.
 
  I was delighted that someone had given it a full work over into
  the 4.8 series. There were some persistent, puzzling, and very
  annoying bugs that are now gone.
 
  Excellent work, gentlemen. Thank you very much.
 
  My list of personal patches went from ~30 down to ~5, where they
  sit now, mostly minor interface tweaks. Mc works, and it works
  very well. If development stagnates for a while, so be it. There
  is actually very little to do. Mc is as close to perfect as
  software gets. There will always be bugs and minor tweaks, and
  that's what needs to be worked on, now and forever.
 
  Yes, mc in its current incarnation is a model from the 1990s. I
  like it that way. I'm not a big fan of C++. I also don't like
  eye candy in a tool that is all about functionality and utility,
  and I very much appreciate a file manager that can operate when
  XWindows cannot, or the system is barely bootable.
 
  It's the perfect size: big enough to be feature-rich and highly
  usable, yet small enough that a single individual can
  (theoretically) get his head around the entire code base. It's
  also fun to hack.
 
  I cannot guarantee 20hrs/week, but I would be very interested to
  work through bug reports and small enhancement requests at my
  own pace, and see what I can get done.
 
  As a last thought for this email:
 
  I suppose what we have here is a complete lack of consensus as to
  the direction to take if we were to move into a 5.0 series.
  My thinking is along the lines of complete modularity: a basic
  interface design (that already exists) and everything else is
  plugins. What if I want to use mc for inventory control? Make a
  plugin to work with SQL instead of filesystem. Perhaps there
  needs to be room for people to experiment with this sort of
  thing. A 4.9beta branch that starts off as mess and arguments but
  slowly gets sorted into something with vision.
 
  That's my 2 cents worth.
 
  Take care, and best wishes for those who are moving on to bigger
  and better things. Thank you for your labors.
 
 
 
  --
  Peace and Cheer
  ___
  mc-devel mailing list
  https://mail.gnome.org/mailman/listinfo/mc-devel


 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site

[Egmont Koblinger]

Hi guys,

I'm sorry to hear about this... but honestly it didn't surprise me.  I
think anyone could have seen that this was going to happen, it was only a
matter of time - few months, a year or two maybe.

What I'm really sad about is that the issue has been raised a couple of
times already, yet (former) maintainers didn't take the time and effort to
involve new people in the project.  I would probably be a smoother
transition now if they did.

I disagree that a 20hrs/week commitment is required from someone.  I don't
think it's the right model, and we're unlikely to find anyone.  There were
times (about a year ago) when I had tons of time to contribute, yet
mainstream dev's resources were the bottleneck in reviewing these changes.
At other times they were active but I didn't have time to contribute.

Instead, I believe it should be a core with 3-5 people who have similar
working style and similar vision of the project, and each contribute just a
few hours per week.  There'd be code review for every nontrivial change,
but it could be done by anyone from this team who happens to have some free
time.  IMO that's the way to avoid bottlenecks, yet guarantee a certain
level of code quality.  1-2 people at the core will always be bottleneck,
and allowing write access to pretty much anyone who has already contributed
something could easily lead to the whole project falling apart due to no
clear goals, no clear coding and quality standards, every random hacker
with hardly any coding experience pushing for their unmaintainable dirty
solution to be committed.  And, that being said, while I'm open bringing in
brand new folks (e.g. Luca), I'm quite conservative here and would prefer
to see him joining conversations at some tickets and posting several great
patches (that is, gaining trust in those who already have some) before
giving him write access.  I'd be happy to see Mooffie on the team right
away, his work (along with his style and the contents of the homepage)
totally convinced me.

I'm sorry to say this, but I myself cannot guarantee anything and cannot
make any commitments.  I'm spending a long vacation right now where I was
planning to do some coding on my primary hobby project (gnome-terminal),
and maybe address one or two issues on my secondary hobby project (mc); all
subject to my mood.  After this vacation I'll start a new job which will
require 100% of me.  So I'd rather stay an occasional contributor as I am
now, and not devote myself to anything with mc.

G-t is my personal hobby project in the sense that I do hunt down and
address bugs that cause problems to other people but I myself don't
particularly care about.  Mc never reached this level for me, I never took
time to look at bugs and patches that I myself wasn't personally interested
in.  Don't ask me why it turned out this way, I don't know - maybe it was
because on g-t I got quick feedback of my work, whereas on mc I often had
to wait for so long that I almost lost interest, and often missed the free
time I had when I could have worked on these issues.

As for the current segfault issue, I think the broken change should be
reverted for now and a .15 released until we come up with a proper
solution.  Generally it would be good to make releases closer to each
other, let's say every 2 months or so, and much sooner when some critical
bug sneaks in.  This is because I think most users will use mc as shipped
by their distros, and distros pick the newest tarball at a random time,
hardly ever caring about backporting a fix from git, let alone from trac
discussions and vagrant patches.

Anyway... I really don't have any wise words on how it should work out from
here.  Let's hope we manage to come up with something great.

Giant thanks to you guys who maintained this project for years, I'm sad to
see you go, and wish you all the best!

e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: [ANN] mc^2

[Egmont Koblinger]

Hi,

On Sun, May 10, 2015 at 10:49 AM, Yury V. Zaytsev y...@shurup.com wrote:

 Egmont, would you be able to do as much? Formally you are not part of
 the core team, but then again, if Andrew ends up being alone to look at
 all this stuff, another pair of eyes would definitively be of help...


Thanks for thinking about me, it's very kind of you!  I'm happy to take a
more thorough look if my time permits, but please don't rely on me; also
I'm not the right person to comment on the big picture as I'm not familiar
with mc that much.  I'm more likely to send nitpicking comments only.

cheers,
e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: [ANN] mc^2

[Egmont Koblinger]

On Sun, May 10, 2015 at 1:05 PM, Yury V. Zaytsev y...@shurup.com wrote:


 The problem is that the definition of important is in the eyes of the
 beholder. I'm sorry, but I personally couldn't care less about #1652,
 simply because I don't. I recognize that it might be a deal breaker for
 you, but not for me.

 However, do I personally care a lot about the list of tickets that
 mooffie has shown a solution for with his patch. Is it surprising that
 I'm excited about it?


Big +1 for this response.  Mooffie's work doesn't address one-off bugs or
feature requests, but provides a much better ground for speeding up
development and adding cool features.  It's way more interesting to me than
any other open mc bug.

cheers,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: [ANN] mc^2

[Egmont Koblinger]

On Sun, May 10, 2015 at 1:25 PM, Paul Sokolovsky pmis...@gmail.com wrote:

Brief response, and we've heard each other's opinion, and I'm not trying to
convince anyone or go into endless debates/flames.

Trivia quiz or what? Ok, unix rewrote multics bloat, lives so far,
 multics dead for big decades. gcc rewrote a lot of older vendor
 compiler crap. llvm/clang rewrote gcc to let vendors do more compiler
 crap. Etc, etc.


And compare the engineer staffing of these projects to mc's.  Okay, I
should rephrase my question: in a project that hardly has resources to fix
even the most critical bugs (e.g. currently there's a segfault in 4.8.14
and no solution yet), what are the changes of successfully reimplementing
20 years of work from scratch?  I believe it's 0.  Not
zero-point-lots-of-zeros-one, but zero.


 Does that mean that you've got commit access?


No, I don't have. (Why is it relevant?)


 Yup, it's so complicated because it's written in C. People write in C
 when target microcontrollers with 16K code size and 0.5K RAM size. It's
 hilarious to write application-level software in C.


IMHO not any more hilarious as writing application-level software in a
script language.  Anyway, once can e.g. do a C - C++ transition in small
incremental steps, without starting over from scratch.  You can't do a C -
python transition this way.


 Less features is good. I consider mc a unix tool, it's not replacement
 for command line (or overbloated vendor IDEs), it should do not too
 many things, but do it right.


mc already does lots of things.  Some are important to you while others
never use them.  Some are intensively being used by others, yet you
wouldn't care about those.  If you reimplement not too many things, for
most users it'll be a failure that lacks important features, and will stick
to the old version.


 Or frustrated users and quitting developers if development model's not
 right, as we discussed here (from your premise) end of last year.


Exactly.  I believe Mooffie's approach is a much nicer step in solving this
problem than a complete rewrite would be.


Nice speech, but can we please have simpler issues which waited in
 queue for years be tackled first?


Not sure what you mean by this.  I know that many bugs weren't addressed,
but in the mean time many others were.  Mooffie's work provides a better
ground for quicker development in the future.  He's not solving issues one
by one, but helps solving any subsequent ones more effectively.  Yet you
argue that instead we should focus on continuing fixing bugs one by one...


Anyway, Mooffie has shown us some code.  You don't quite like it, you'd
take a totally different approach.  Okay, your turn, convince us, show us
the code please ;)


cheers,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: [ANN] mc^2

[Egmont Koblinger]

On Sun, May 10, 2015 at 12:41 PM, Morten Bo Johansen m...@spamcop.net
wrote:

 How about S-Lang? It is already used for the terminal stuff in
 mc.


I think it would be a terrible choice.  A language hardly anyone has even
heard about, and whose library handling is hardly used by any project other
than mc.  It's been even proposed couple of times that mc should drop slang
support and stick with the much more widespread ncurses.


e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: [ANN] mc^2

[Egmont Koblinger]

On Sun, May 10, 2015 at 2:54 PM, Paul Sokolovsky pmis...@gmail.com wrote:


 ... and the conversation is focused around priority of things to do,
 which I argue should be fixing old bugs, then proceed with new things.
 Because is exciting new is the only thing you're after, then
 rewriting mc would be the best way to get a lot of that new and
 exciting.


No project can ever realistically reach the there are no more bugs, so we
can work on exciting new features state.  E.g. on my other hobby project,
where I've contributed much more work than to mc, I've fixed maybe about
100 bugs, yet the number of open tickets is higher than when I started.
Not because I code in such a quality (sure I do make mistakes every now and
then), but because new ones are discovered and new features are requested.
And as you fix the most important ones, the bar goes lower and suddenly the
previously less important ones become the most important now.  It's a never
ending story.

Of course aiming for the other end is also terrible, the one where you
don't care about bugs, yet wish to add tons of new features and keep aiming
higher and higher.

A reasonable balance needs to be found.

mc has hardly received any new features recently (definitely nothing along
the lines of scripting support), but has received many-many bugfixes.  You
can't say feature freeze until all bugs are fixed, probably bugs are
discovered in a higher rate than fixed and we'd never get anywhere.  A
project needs to evolve, even when it's not bugfree.  And also don't forget
that plugin support would actually get us closer to fixing quite a few bugs.


Your arguments make me feel that you're personally offended because your
pet peeve bug didn't get fixed so far, and in turn you'd like to stop
getting something new accepted, just because you'd do it differently.
Well, do _it_ (not something else) the way you'd like to see it, and I'm
sure we'll seriously consider accepting that.  Until then, Mooffie's work
is what we have, and I see no reason to put any obstacle to this.  Just
beacuse, oh my god, there's another bug that we could've fixed so far but
we haven't...


e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: [ANN] mc^2

[Egmont Koblinger]

On Thu, May 7, 2015 at 11:53 PM, Paul Sokolovsky pmis...@gmail.com wrote:

 Hello,

 On Thu, 7 May 2015 23:27:23 +0200
 Egmont Koblinger egm...@gmail.com wrote:

  Hi,
 
  Did you... er... did you just rewrite half of mc... adding plugins and
  stuff...??

 It would be indeed cool to remove all that gnome-ish bloat accumulated
 by decades, but - what a disappointment - home page says that to
 accomplish such feat there is no need to modify MC’s main code..

 Generally one good approach to deal with the situation would be to
 rewrite mc completely in a scripting language. Extra points for using
 language in which array indexing starts with e or pi, or going straight
 to Brainfuck. No, I'm ironic with the last sentence on Lua choice, but I
 really think the way out of the maze is rewriting mc from scratch, and
 then surely in a decent scripting language.


I was obviously exaggerating when I said Mooffie rewrote half of mc's
code.  I haven't look at the changes to the C code yet, but as some
comments on the homepage suggest, it's probably only a very small fraction
of the C code he touched and mostly pretty lightweight changes.

Have you ever seen a complete rewrite of a project (that's bigger than a
few weeks of hacking) succeed?  I have not.  This would require at least
100x (but rather 1000x) the work Mooffie has probably already spent.  There
are no engineering resources for that.  Recently I've spent about a week
rewriting the viewer, probably noone else would've done it if I hadn't.
There's a ticket to rewrite the vfs component, noone's working on that.
Regex handling should be carefully cleaned up, noone's working on that.
Tty handling is overly complicated, nobody's working on it.  But you'd
rewrite the whole project from scratch!?  And then the rewrite would be
missing tons of features because you were lazy to port them, would contain
tons of brand new bugs or bugs that had been fixed long ago.  It's pretty
much guaranteed to be a big failure -- and easily not just a failure of the
rewrite but also cause a(n even bigger) decline of the main project, as
many times you recah a point where the old project is already considered
obsolete and is unmaintained, in favor of the new one which stands on
better technical grounds, yet is totally incomplete and lacks tons of
things from the old one.

Successful redesigns almost always happen in small steps, maintaining the
usability and quality of the project throughout the steps.  You might
eventually replace nearly every component, and the road might eventually
become longer than if you had rewrote from scratch, but it's viable because
you get satisfied users and passionate developers all the way through,
rather than just hacking on something that's not used by anyone; and it's
viable because it's not risky: you can stop working on it anytime and leave
positive benefits behind rather just having wasted tons of time.

As for whether mc's core should be written in C or lua or whatever...
compiled or interpreted, strict or loose types, whatever...  My personal
preference probably doesn't matter too much, yet I'd like to quietly
mention that my last python project (port someone else's app against a new
API) got stalled in a mostly working state where the parts I've tested
work, yet the parts I haven't (because I don't know how to reach that code)
probably still call the API using its old method names, wrong order of
parameters, and nobody tells me this.  Had it been written in a compiled
language, the compiler probably would have helped me do a complete port in
the same amount of time.

As for the plugin API:  If you write the core of mc in whichever scripting
language and allow a plugin to hook up against _any_ of its
methods/variables then you discard the very basic principle that caused all
programming language to move at least slightly towards object-oriented
approach.  If you allow a plugin to do anything, it becomes a nightmare
where you can no longer perform internal refactorings because you don't
know how many 3rd party plugins you'd break, or by seeing breakages 3rd
party plugin authors would back off from the project.

On the other hand, if you define a clear API that plugins code against,
then it's not really relevant anymore whether the core and the plugins are
written in the same programming language or not.  Now, I don't know
anything about lua, but allegedly it's really good for this kind of plugin
stuff, writing hooks to a C code.

But let's put all this question aside.  We might be arguing for years what
would be the best language for mc core and what would be the best language
for the plugins, and it'd take us nowhere.  The most important factor in
the decision should be what we already have.  We can't reimplement 20 years
of work in mc core.  We might reimplement Mooffie's lua code in
python/ruby/whatever but apart from spending weeks on it, would it make it
any better?

The biggest value is that we already do have a decent mc written in C

Re: [ANN] mc^2

[Egmont Koblinger]

Hi,

How much work would it be to port your branch to 4.8.14 or git head
(they're pretty much the same now)?

I'd really like to use your version for daily work (and maybe even start
writing plugins) to gather feedback.  On the other hand, mc-4.8.14 contains
some of my work that I really wouldn't want to live without.  And of course
I wouldn't want to switch back-n-forth between two versions either.

Thanks a lot,
egmont


On Thu, May 7, 2015 at 10:23 PM, Mooffie moof...@gmail.com wrote:

 Hi guys!

 I've just published a branch of MC with Lua support:

   http://www.typo.co.il/~mooffie/mc-lua/docs/html/

 See the screenshots link.

 Also see the other documents link for background (especially
 HISTORY).

 Many, many tickets can be solved with mc^2, but I don't want to spam
 the ticket queue with my posts, so I've prepared a list of some such
 tickets (see other documents - TICKETS).

 (But in a few tickets I *will* comment: in tickets I believe a
 constructive discussion could ensue, or where I feel people are truly
 in need of a solution.)

 ==

 Now, I guess I'll be attacked for one reason or another. Let me save
 your time by attacking myself for you:

 ==

 Q: Is this a 'fork' of MC? Are you trying to split the community?

 A: No, this is not a fork (as per Wikipedia's definition). It's intended
to be food for thought for the MC community. My hope is that
eventually the principle behind mc^2 will be adopted by MC.

 ==

 Q: Is seems that you've invested a lot of time in this. Gosh, why
 waste human resources?! Especially on something that nobody's
 going to use?

 A: The time I waste here is negligible in comparison to the time and
efforts wasted by tens of people who have tried to contribute code
to MC over the years.

The principle behind mc^2, if adopted by MC, is going to put an end
to this waste of human resources.

 ==

 Q: But why use Lua?!?! Why not pick the language that starts
 with 'P'?! Why not make it work with any language?!??!

 A: Let's not talk about languages/VMs *right now*. Please, as much as
it's tempting.

Right now, the language is not the issue. The issue is the
principle, of having some extension language.

The language/VM is obviously something everybody will have
something to say about. You will. But not now.

If every passerby here will now emit his 2 cents opinion/rant,
it will kill the vision/project. It will start a Holy War. It will
derail the discussion from the mainroad to the gutters. It's the
least constructive thing that could happen. It means death.

In the future, when we know the principle will be regarded favorably
by MC's maintainers, we could open this issue and discuss things.

One thing's for sure: You can't give an opinion about the subject
without considering it for at least a week (or a month, I'd say).
There are various facets to consider. There are threads of thoughts
to be picked and discarded. There are insights to be acquired. You
can't just barge in with use Python!!, use Parrot!, use
GObject!. As the Chinese saying goes, Opinions are like belly
buttons: everybody has one. It should take more, much more, than
an opinion to affect the discussion.

So, again: let's not talk about languages now.

(For the record: I recorded my reasons for choosing Lua in
other documents - HISTORY.)
 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: [ANN] mc^2

[Egmont Koblinger]

Hi,

Did you... er... did you just rewrite half of mc... adding plugins and
stuff...??

At this moment all I can say is:  WOW!


e.

On Thu, May 7, 2015 at 10:23 PM, Mooffie moof...@gmail.com wrote:

 Hi guys!

 I've just published a branch of MC with Lua support:

   http://www.typo.co.il/~mooffie/mc-lua/docs/html/

 See the screenshots link.

 Also see the other documents link for background (especially
 HISTORY).

 Many, many tickets can be solved with mc^2, but I don't want to spam
 the ticket queue with my posts, so I've prepared a list of some such
 tickets (see other documents - TICKETS).

 (But in a few tickets I *will* comment: in tickets I believe a
 constructive discussion could ensue, or where I feel people are truly
 in need of a solution.)

 ==

 Now, I guess I'll be attacked for one reason or another. Let me save
 your time by attacking myself for you:

 ==

 Q: Is this a 'fork' of MC? Are you trying to split the community?

 A: No, this is not a fork (as per Wikipedia's definition). It's intended
to be food for thought for the MC community. My hope is that
eventually the principle behind mc^2 will be adopted by MC.

 ==

 Q: Is seems that you've invested a lot of time in this. Gosh, why
 waste human resources?! Especially on something that nobody's
 going to use?

 A: The time I waste here is negligible in comparison to the time and
efforts wasted by tens of people who have tried to contribute code
to MC over the years.

The principle behind mc^2, if adopted by MC, is going to put an end
to this waste of human resources.

 ==

 Q: But why use Lua?!?! Why not pick the language that starts
 with 'P'?! Why not make it work with any language?!??!

 A: Let's not talk about languages/VMs *right now*. Please, as much as
it's tempting.

Right now, the language is not the issue. The issue is the
principle, of having some extension language.

The language/VM is obviously something everybody will have
something to say about. You will. But not now.

If every passerby here will now emit his 2 cents opinion/rant,
it will kill the vision/project. It will start a Holy War. It will
derail the discussion from the mainroad to the gutters. It's the
least constructive thing that could happen. It means death.

In the future, when we know the principle will be regarded favorably
by MC's maintainers, we could open this issue and discuss things.

One thing's for sure: You can't give an opinion about the subject
without considering it for at least a week (or a month, I'd say).
There are various facets to consider. There are threads of thoughts
to be picked and discarded. There are insights to be acquired. You
can't just barge in with use Python!!, use Parrot!, use
GObject!. As the Chinese saying goes, Opinions are like belly
buttons: everybody has one. It should take more, much more, than
an opinion to affect the discussion.

So, again: let's not talk about languages now.

(For the record: I recorded my reasons for choosing Lua in
other documents - HISTORY.)
 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

HUP poll

[Egmont Koblinger]

Hi,

Just for fun:  The Hungarian Unix Portal's current poll is about mc
(http://hup.hu/szavazasok/20150330/a_midnight_commander), where the
options are (in order):

- no clue what it is
- is only for noobs (not installed)
- installed, but I seldom use it
- the first thing I install on a new system
- other, I'll describe
- only interested in the result

Check out the site for the current results :)


cheers,
e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: HUP poll

[Egmont Koblinger]

On Mon, Mar 30, 2015 at 9:35 PM, Paul Sokolovsky pmis...@gmail.com wrote:

 How can one vote? ;-)

You can't :)

Seriously: You have to register to the site, which, due to lot of
previous trolling/spamming activities, is a manual process requiring
approval from the site's maintainer, and you need a referrer or a
justification why you wish to be a member. I'm not kidding; follow the
link regisztráció from the top-left box, and then use some online
translate tool to get a feeling. (Beware: both Google and Bing
translates the math question incorrectly. I thought recognizing
numbers was one of the easiest bits of translation.) I wish you good
luck if you choose to accept the challenge :D

e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Ticket comment rejected and lost

[Egmont Koblinger]

Dear developers,

So, it's happening again, and I'm pissed off again.  The following
comment to bug 3417:


I'm really not happy with this change, it breaks quite a few skins,
including the default one with TERM=xterm (that is, 256 colors are
*not* available and bold+bright is indeed bold).  The result is quite
ugly as the vertical bar changes to bold, and I don't like its
foreground color change either.  See the screenshot, it was taken with
konsole.  (Note: konsole hand-draws the line drawing characters and
applies bold to them.  The issue might not be visible with other
terminals that either take these chars from the font (if the bold font
doesn't actually make these bolder), or if the terminal hand-draws
these chars but doesn't apply bold, such as gnome-terminal.)

Could you please revert the change (especially if a .14 release is due
soon as I suspect)?

We should understand how the said skin wants to look like, and if
necessary, maybe introduce a new color for that position and update
the existing skins too.


is considered spam with *** 99.82% *** probability?!?!?  Wat???

How on earth am I supposed to file a comment, then?


Guys, seriously, I'm sick and tired of all this.

We've spoken up many-many times that the development infrastructure of
mc is dying.  We've asked you guys many times to fix this.
Practically nothing (or at least nothing visible) has happened.

PLEASE be this the very next issue that you FIX.

Not play around, not fiddle with, not hack a little bit, not tune some
parameter, not experiment with something that might work, but:

FIX.

Period.

THANK. YOU.


I'm just about to give up contributing to mc at all.  It's just not
worth it _for me_ when I can't even file a freaking comment.

Please get back to me ONCE when you've FIXED it.  I don't care when it
happens.  Take your time.  But when it happens, when you come back to
me and say it's fixed, I do expect it to be fixed once and for all.
If it still rejects a message for me after that, you won't hear about
me for a very long time.  Probably until brand new developers take
over the project's maintenance.


egmont



On Mon, Feb 23, 2015 at 5:57 PM, Andrew Borodin aboro...@vmail.ru wrote:
 On Mon, 23 Feb 2015 17:16:19 +0100 Egmont Koblinger wrote:
 Actually, I got the same message again.  I can't submit my newest bug report.

 Sorry. I still hope to make spam filter more corresponding to spam and ham.
 For last day, there 3 real spam messages was banned.


 (Which, for reference is: F2 followed by F1 brings up an error about
 missing help.)


 I've created the ticket.

 --
 Andrew
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Ticket comment rejected and lost

[Egmont Koblinger]

Actually, I got the same message again.  I can't submit my newest bug report.

(Which, for reference is: F2 followed by F1 brings up an error about
missing help.)


e.

On Tue, Feb 10, 2015 at 10:41 AM, Egmont Koblinger egm...@gmail.com wrote:
 Cool, thanks!

 e.

 On Tue, Feb 10, 2015 at 8:05 AM, Andrew Borodin aboro...@vmail.ru wrote:
 On Mon, 9 Feb 2015 14:59:53 +0100 Egmont Koblinger wrote:
 So... I wanted to submit a comment to ticket 2027... I logged in,
 wrote about 10-15 lines, and after clicking Submit I was given an
 error, something like Submission rejected because of suspected spam
 (can't remember the exact words).

 I'm sorry! That's my fault. I played with anti-spam settings some days
 ago. Some spam was blocked but some ham was blocked too. I returned
 previous settings.

 --
 Andrew
 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Ticket comment rejected and lost

[Egmont Koblinger]

Hi,

So... I wanted to submit a comment to ticket 2027... I logged in,
wrote about 10-15 lines, and after clicking Submit I was given an
error, something like Submission rejected because of suspected spam
(can't remember the exact words).  Then I hit FF's back button, got
back to the ticket's page, with my comment just whooops being gone
(although FF remembers these fields, unless there's some JS magic to
clear them).

We've spoken up many times how the current bugtracker doesn't function
properly.  Allegedly there has been some work, but I still see
duplicate reports and tons of spam on the list; honestly,
unfortunately I can't see any improvement.  Quite the opposite to be
honest, it just ate my work, considered me a spammer, and have no idea
if (and why) it'll refuse it again.  Anyway, I'll save externally
before hitting submit.

e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Bug tracker doesn't work

[Egmont Koblinger]

On Sat, Dec 13, 2014 at 1:36 PM, Paul Sokolovsky pmis...@gmail.com wrote:

 I can confirm this behavior when posting comments to tickets too.

I can see some of the developers (most notable probably andrew_b and
slavazanko) still creating branches, fixing bugs on random one-off
basis.

In the mean time, you can see in the archives of mc-bugs that it's
full of duplicate reports (actually many bugs filed like 5-10 times
due to broken trac) and full of spam and fake registrations.

Dear developers, dear Andrew, Slava and others,

I'd like you to understand that at this point that fixing the
development architecture and process of mc is the most critical issue,
pretty much blocking everything else.

Apparently you don't have much time, that's okay, but please stop
spending that little time on one-off minor bugfixes, and please please
pretty-pretty-please focus all your efforts on fixing trac and fixing
the problem with lack of developer resources.  Please work on getting
new people on the project, work on getting yourselves out of the way
from being the bottlenecks.

At this point, you spending your time on fixing issues like pasting in
mcedit (to mention one random) won't get the project anywhere other
than its grave.  You need to fix the development processes so that
others can join the effort and they can fix pasting in mcedit and
hundreds of similar technical issues, without being blocked by a
broken bugtracker and nonresponsive developers.


thanks,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Happy 20th Birthday!

[Egmont Koblinger]

Recently I did some digging about the history of mc.  It's unclear when the
first version was released, the oldest I could find is mc-0.3 released on
Apr 29, 1994 [1].

Version 1.0, the first one bearing the name Midnight Commander was
released on Oct 29, 1994 [2]; exactly 20 years ago.  (If you wonder what
the original name was: check out the links!)

A short blog entry from its author is at [3].

A very long, interesting story about mc's history can be read at [4].

Sadly, as this post points out, mc almost died twice already – and the
really sad aspect that casts a shadow to the current birthday is that I
personally feel it's dying again for the third time.

The initial passion from the new maintainers has faded.  They hardly have
time to work on the project.  Many patches or important bugreports go
unnoticed for long months or even years.  Some tickets have heated
technical discussions between some non-maintainers, yet the maintainers
remain silent.  Some contributors have already expressed that they've lost
motivation due to the lack of response from developers, and alas more
(including myself) are likely to follow.  (This whole issue has been raised
in [5].)  I really don't know how this problem could be solved... I'm just
hoping that we'll be able to figure out something.

Anyways, for now, let's celebrate 20 years of Midnight Commander :)


[1] http://www.informatica.co.cr/linux-desktops/research/1994/0504.html
[2] http://www.informatica.co.cr/linux-desktops/research/1994/1031.html
[3] http://tirania.org/blog/archive/2009/Oct-06.html
[4] http://www.softpanorama.org/OFM/Paradigm/Ch04/mc.shtml
[5] https://www.midnight-commander.org/ticket/3004
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Midnight Commander 4.8.13 released

[Egmont Koblinger]

On Sat, Sep 6, 2014 at 1:56 AM, toothpik toothp...@gmail.com wrote:

 I am an instant fan of the new gray-green-purple

I'm happy to hear this, I'm really glad you like it :)  (I created
these skins, I myself also prefer the green-purple variant.)

egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc startup with single specified path

[Egmont Koblinger]

Please start with looking around in the bugtracker or compiling the
development version next time :)  The issue is already fixed for the
forthcoming 4.8.11.


egmont

On Fri, Oct 18, 2013 at 3:44 PM, Mike Smithson mdooli...@gmail.com wrote:
 Hello.

 I'm having some puzzlement over the initial startup behavior of mc-4.8.10
 when paths are specified on the command line.

 To quote the manual:

 [quote]
If  both  paths  are specified, the first path name is the directory
 to
show in the left panel; the second path name is  the  directory  to
 be
shown in the right panel.

If one path is specified, the path name is the directory to show in
 the
active panel; current directory is shown in the passive panel.

If no paths are specified, current directory is  shown  in  the
 active
panel;  value  of  other_dir  from  panels.ini is the directory to
 be
shown in the passive panel.
 [/quote]

 Paragraph #1:
 This seems correct and intuitive.

 Paragraph #2:
 What I *expect* to happen when I specify only one path on the command line,
 is for that directory to appear in the left panel with the focus on it. As
 it works right now, it appears to be random which panel it shows up in, and
 which panel has focus. I know that it depends on the last time I hit Save
 Setup and the setting of current_is_left in panels.ini, but it always seems
 to do the wrong thing. As a matter of fact, the behavior I'm witnessing, is
 that that specified directory appears in the *inactive* panel, and the CWD
 appears in the *active* panel. I think that is counter-intuitive, a bit
 annoying, and exactly *not* what the manual says.

 Paragraph #3:
 This also seems correct and intuitive. Resort to default behavior if nothing
 is specified.

 ---

 I believe the issue is in midnight.c, static void create_panels(), around
 lines 619-624 and 646-651, both bits are identical, and they shouldn't be:
 [code]
 else/* mc_run_param0 != NULL  mc_run_param1 ==
 NULL */
 {
 /* one argument */
 current_dir = NULL; /* assume current dir */
 other_dir = (char *) mc_run_param0;
 }
 [/code]
 Is it just me, or does this seem *exactly* backwards?

 I've changed these bits like this (the 1st is when the left panel is
 active):

 [code]
 --- midnight.c~ 2013-08-02 11:02:40.0 -0700
 +++ midnight.c  2013-10-16 13:59:48.541659334 -0700
 @@ -619,8 +619,8 @@ create_panels (void)
  else/* mc_run_param0 != NULL  mc_run_param1
 == NULL */
  {
  /* one argument */
 -current_dir = NULL; /* assume current dir */
 -other_dir = (char *) mc_run_param0; /* Wrong. */
 +current_dir = (char *) mc_run_param0; /* Left panel gets the
 path */
 +other_dir = NULL; /* assume other dir */
  }
  }
  else
 @@ -648,6 +648,7 @@ create_panels (void)
  /* one argument */
  current_dir = NULL; /* assume current dir */ ;
  other_dir = (char *) mc_run_param0; /* Left panel gets the path
 */
 +boot_current_is_left = TRUE; /* make left panel active (user
 called it, there must be a reason.) */
  }
  }
 [/code]

 and it now behaves the way I would expect.

 After doing a bit more research, it looks as if create_panels() was freshly
 re-written for 4.8.10. In 4.8.9 I see this bit:
 [code]
 if (mc_run_param0 != NULL)
 {
 current_dir = NULL;
 other_dir = (char *) mc_run_param0;
 }
 else
 {
 current_dir = NULL;
 other_dir = mc_run_param1;
 }
 [/code]
 Hmmm... Is it even possible to have mc_run_param1 *without* mc_run_param0?
 Also, what if both are set? No wonder it got re-written.

 --
 Peace and Cheer
 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: MC Tabs

[Egmont Koblinger]

Oh, I've found your keymap :)

Most of the Ctrl+Alt+letter combos are taken by my window manager, so
I'm back to entering Meta by pressing Escape.  Still, Esc followed by
C-Left or C-Right or C-g don't work for me, I'm not sure why.

On Tue, Oct 15, 2013 at 8:37 PM, Egmont Koblinger egm...@gmail.com wrote:
 Hi Cosmin,

 This is a very interesting idea.  Please let me give feedback after 5
 minutes of using it :) Please note that I'm not an official mc
 developer, just an occasional contributor.

 I always wondered why mc has hardcodedly only 2 panels, not allowing
 more.  E.g. the screen could be divided in 2x2 parts and copy/move
 operations could have a direction (horizontal, vertical or diagonal).
 Your new feature approaches a similar goal.

 To accomplish the above mentioed goal, i.e. to be able to have 3
 panels and quickly copy between *any* two, your patch desperately
 lacks the move this tab to the other panel (or something similar)
 option with menu entries and convenient shortcuts, or maybe ^U could
 just swap two tabs but not two whole panels.  Or, tabs should not be
 per-panel but common to the two, in each panel you could easily jump
 to any of the tabs.

 Basic tab operations (next/prev/new/close) should also be something
 that has convenient short hotkeys by default, and those hotkeys are
 mentioned in the F9 dropdown.

 The current UI trend (apart from a couple of legacy apps that had tab
 support before it became widely used) is to place tabs on the top,
 rather than the bottom.

 The create tab and such menu options operate on the currently active
 panel, rather than on the Left/Right panel according to whose menu
 entry is selected.  (E.g. Left panel is active, invoke Right-Create,
 a new tab should be created on the right panel.)

 Tabs should be selectable by a single mouse click (also scrolling
 should be doable by mouse if too many tabs are open to fit).

 Having non-ascii characters (don't forget about CJK either) cause
 artifacts with highlighing the active tab (the end of the tab bar gets
 the highlighed background too).

 Sure there are a couple of more issues, but I kind of like your idea
 and would welcome such a feature.  Nice work for a start!

 One more thing: please use unified diffs, they are much more reable
 and more portable to newer mc versions.


 egmont

 On Mon, Oct 14, 2013 at 8:20 PM, Cosmin Popescu
 cosminpope...@members.fsf.org wrote:
 Dear mc developers,

 Please find attached my contribution to mc: tabs like Total Commander has.

 I am a regular midnight commander user. I use it for all my file exploring
 needs on several systems. I use it under Arch Linux and Ubuntu at home,
 under Red Hat on various servers that I administer and under Cygwin on
 Windows 7 at work.

 One of the things that was missing were the tabs and I hated all the time,
 when I needed to copy some files from a location to several locations to
 have to change the folder so many times.

 You will find an archive containing several patches that will add tabs to MC
 and a keymap file to map some shortcuts for the tabs. Another message will
 follow with some screen shots.

 Inside the archive there is an executable file called apply-patch that will
 apply all the pathes on the required files. To install the patch, just
 un-archive the patch.tar.gz inside the root folder of mc-4.8.10 archive, cd
 to patch and run ./apply-patch.

 I've implemented the following:

 * Create tab (creates a new tab)
 * Close tab (closes an existing tab, if the tab is not the only one)
 * Rename tab (changes the title of the current tab)
 * Next tab (changes the current tab)
 * Previous tab (changes the current tab)
 * Go to tab (displays a list of tabs from which the user can select one to
 switch to)
 * Tabs options (some tabs options)
 * Tabs sessions (the current opened tabs can be saved into sessions that can
 be later restored).

 In the tabs options there is an option to restore the last tabs session.
 Please note that if this is checked, the current opened folder in the
 current panel will not be the folder from which mc is launched, but the
 folder that was last current when mc was closed.

 From a technical point of view, the tabs are a simple list of structures
 containing a name (which can be NULL in which case the name of the current
 tab is the name of the current folder) and a path (a vfs_path_t structure)
 containing the current path of the tab. Whenever a tab is created, a new tab
 structure is added in the list. When a tab is changing the mc will do a
 simple cd by calling the do_cd function. I think that the implementation is
 pretty much straight forward.

 The only thing a little bit complex might be the display_info function. That
 function will determine if all the tabs can be displayed, if not will
 calculate which can be displayed starting from the current tab to the left
 and then to the right if there is still space.

 All my code is added between #ifdef WITH_TABS and #endif directives

Re: bad mc-edit paste behavior?

[Egmont Koblinger]

Felix: Switch it off with F9 - Options - General - Return does
autoindent. This feature is very useful e.g. when writing source code.

MC Developers: It would be cool to have autoindent disabled when pasting,
I've commented on https://www.midnight-commander.org/ticket/2661


On Sun, Sep 15, 2013 at 6:16 PM, Felix Miata mrma...@earthlink.net wrote:

 http://lists.opensuse.org/**opensuse-kde/2013-09/msg00072.**htmlhttp://lists.opensuse.org/opensuse-kde/2013-09/msg00072.htmlseems
  to describe a bug in mc-edit. Is the responder there correct that
 auto-indent switched off would stop the bad behavior? Should it need to be?
 Adding all those spaces and/or tabs doesn't make any sense to me regardless
 of how line endings are handled.
 --
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

 Felix Miata  ***  http://fm.no-ip.com/
 __**_
 mc-devel mailing list
 https://mail.gnome.org/**mailman/listinfo/mc-develhttps://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: bad mc-edit paste behavior?

[Egmont Koblinger]

Paul, please see the ticket I linked in my previous post. There is a
standard way of solving this problem, mc should go for that rather than its
own hacks. I'm working on the patch right now.


On Sun, Sep 15, 2013 at 7:07 PM, Paul Sokolovsky pmis...@gmail.com wrote:

 Hello,

 On Sun, 15 Sep 2013 12:16:53 -0400
 Felix Miata mrma...@earthlink.net wrote:

  http://lists.opensuse.org/opensuse-kde/2013-09/msg00072.html seems to
  describe a bug in mc-edit. Is the responder there correct that
  auto-indent switched off would stop the bad behavior? Should it need
  to be? Adding all those spaces and/or tabs doesn't make any sense to
  me regardless of how line endings are handled.

 I've been having that problem for ages - with Gnome though. If you
 think about it, it's logical, assuming pasting is handled by terminal
 emulator, and not mc itself. And term emu can only implement pasting by
 sending pasted content as key presses, including spaces and tab, and
 mcedit, with autoindent on, has no idea that it's something else but
 keypresses, so blindly applies autoindent as usual.

 So, long ago I indeed worked that around by going to setting and
 turning autoindent off then on (boring!). Then however I noticed that
 depending on the way you paste you may be able to work it around by
 several paste attempts. For example, Gnome terminal has 3 ways to
 paste: menu command, Ctrl+Shift+V, Shift+Ins. So far, my background
 pattern matcher didn't find exact rule what works better, it seems to
 be just non-deterministic, though intuitively, Shift+Ins appear to work
 better.

 The way to resolve it would be to handle paste on mc side, and knowing
 that mc already has some X integration, I may imagine, when Shift+Ins
 works, that's what happens. The culprit is that it doesn't work all the
 time and with all paste methods. Which probably partly due to braindead
 X clipboard design (multiple buffers, etc).

 --
 Best regards,
  Paul  mailto:pmis...@gmail.com
 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: bad mc-edit paste behavior?

[Egmont Koblinger]

 I don't write code, but I've never turned it off either, would rather not
 need to,


It might make sense to turn it off by default, although I find this a
really minor priority question. You can easily turn it off for yourself and
then save your setup, and you're done forever :)

bye,

egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: bad mc-edit paste behavior?

[Egmont Koblinger]

On Sun, Sep 15, 2013 at 7:07 PM, Paul Sokolovsky pmis...@gmail.com wrote:



 So, long ago I indeed worked that around by going to setting and
 turning autoindent off then on (boring!). Then however I noticed that
 depending on the way you paste you may be able to work it around by
 several paste attempts. For example, Gnome terminal has 3 ways to
 paste: menu command, Ctrl+Shift+V, Shift+Ins.


Yup it's a real nightmare.  I'm really not sure what happens in the three
different cases.  My patch fixes the menu command.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: bad mc-edit paste behavior?

[Egmont Koblinger]

On Mon, Sep 16, 2013 at 12:40 AM, Felix Miata mrma...@earthlink.net wrote:


  It might make sense to turn it off by default, although I find this a
 really minor priority question. You can easily turn it off for yourself
 and
 then save your setup, and you're done forever :)


 I don't understand this response. I purposely have not tried to disable
 auto indent because it's something I routinely use.


Sorry, apparently I misunderstood you.

Can you try my patch with xterm or gnome-terminal?  Konsole doesn't support
the desired feature and I couldn't patch it in in about half an hour, so I
just filed them a request.




 OTOH, I don't use it quite enough to have figured out why it sometimes
 auto indents a half tab instead of a full tab on a line start.

 --
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

 Felix Miata  ***  http://fm.no-ip.com/
 __**_
 mc-devel mailing list
 https://mail.gnome.org/**mailman/listinfo/mc-develhttps://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: bad mc-edit paste behavior?

[Egmont Koblinger]

Okay I managed to come up with a patch for Konsole too :)
It's at https://bugs.kde.org/show_bug.cgi?id=324946

Just in case you feel like recompiling both konsole and mc to get this cool
feature :)


On Mon, Sep 16, 2013 at 1:04 AM, Egmont Koblinger egm...@gmail.com wrote:

 On Mon, Sep 16, 2013 at 12:40 AM, Felix Miata mrma...@earthlink.netwrote:


  It might make sense to turn it off by default, although I find this a
 really minor priority question. You can easily turn it off for yourself
 and
 then save your setup, and you're done forever :)


 I don't understand this response. I purposely have not tried to disable
 auto indent because it's something I routinely use.


 Sorry, apparently I misunderstood you.

 Can you try my patch with xterm or gnome-terminal?  Konsole doesn't
 support the desired feature and I couldn't patch it in in about half an
 hour, so I just filed them a request.




 OTOH, I don't use it quite enough to have figured out why it sometimes
 auto indents a half tab instead of a full tab on a line start.

 --
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

 Felix Miata  ***  http://fm.no-ip.com/
 __**_
 mc-devel mailing list
 https://mail.gnome.org/**mailman/listinfo/mc-develhttps://mail.gnome.org/mailman/listinfo/mc-devel



___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: How screen content saving handled in xterm case?

[Egmont Koblinger]

I think you're looking for alternate screen buffer.

egmont


On Mon, Sep 2, 2013 at 11:39 AM, Paul Sokolovsky pmis...@gmail.com wrote:

 Hello,

 Yesterday I spent couple of hours trying to trace how shell screen
 content is working in case of xterm terminal. While handling in case of
 linux console is very visible, and otherwise there're some checks for
 xterm/rxvt stuff, but I couldn't find exact escape sequence(s)/exact
 place where saving is done in case of xterm.

 I also tried to approach it from the other side, by looking at xterm
 escape sequences docs, http://www.xfree86.org/current/ctlseqs.html ,
 and neither could find something which is clearly usable for screen
 saving, like command read char/rect.

 So, any hints how that magic is done? What I'm trying to do is to
 figure out why Android terminal emulators don't save screen content
 with mc.


 Thanks,
  Paul  mailto:pmis...@gmail.com
 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Midnight-commander.org is down

[Egmont Koblinger]

Hey,

Purely out of curiosity:  Have you thought about moving development hosting
entirely to the cloud (e.g. sourceforge, savannah, google code, ...)?  If
you have and decided not to, what were the reasons in maintaining your own
server (hardware, os, application setups, backup etc...)?  To me this
sounds like a huge overhead and probably a huge cost too for something
others could freely take care of for you.

Thanks a lot,
egmont


On Fri, Apr 26, 2013 at 7:50 AM, Slava Zanko slavaza...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi folks,

 Our server donated by RWTH, Germany has blown up. Folks at OSU OSL
 (http://osuosl.org/) are willing to provide us with a new server. So
 in near time we will migrate to new server (it's will take some time
 for setting up some services/programs as it was on old server). I
 hope, it's will not take so much time, our estimations: a week.

 Please, be patient and sorry for inconvenience.

 Thank you.

 - --
 WBR, Slavaz.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (GNU/Linux)

 iEYEARECAAYFAlF6FaUACgkQb3oGR6aVLppV+ACfWk3QC1F/HQn8hGw1QHHYJjay
 PPkAnj5tuywd3m+Jdp846A1rH17iIe+Q
 =vx+1
 -END PGP SIGNATURE-
 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: stable vs. latest

[Egmont Koblinger]

Hi guys,

I notified the maintainer of distrowatch.org, asked him to update the
regexps that figure out the latest stable mc release.

He told me - and unfortunately I can only agree with him - that the wording
on MC's homepage is very confusing.  It mentions two releases, latest and
latest stable, people would obviously think that the latest refers to
unstable.  The comment that tries to clarify the situation is more
confusing rather than clarifying, how come you recommend not to use the
stable?

He insist - and again, I cannot disagree with it - that his page promotes
the latest *stable* of all software.  Given mc's new development model and
the wording used right now, he would stick with 4.8.1.7 forever.

Could you please reconsider the terminology, or the contents current
homepage?

E.g. you might begin to call the current releases 'stable', e.g. 4.8.8 is
the first stable of the 4.8.x series.

Or, you might want to remove the former stable 4.1.8.7 from the main
homepage and keep it only in the Downloads section.  Or something like
this...

Thanks a lot,
egmont



On Thu, Feb 21, 2013 at 2:03 PM, Felix Miata mrma...@earthlink.net wrote:

 On 2013-02-21 13:42 (GMT+0400) Andrew Borodin composed:


  On Wed, 20 Feb 2013 14:33:02 +0100 Egmont Koblinger wrote:


  Andrew:  Is it that soon there will be a 4.9.1.x stable and 4.9.x devel
 series?


  No, not soon. 4.8.x series is still continued. 4.9 should be well stable,
 without major and annoying defects and with some major features.


 Above response leaves me quite confused. :-(


  Or you give up this development model and stick to a single branch
 from now on?


  Yep.


 You mean eventually there will be only one version instead of two?


  If the latter, I think it should be made obvious on the
 homepage (maybe when 4.8.8 is released), and the Our release workflow
 page should also be updated.


  Yes, certainly.


 My original thread starter question hasn't really been answered yet. Who
 is the 4.8.1.x branch for, since it seems major distro's latest releases
 are using 4.8.x, with openSUSE that doesn't even release using latest in
 4.8.1.x line the only exception I'm aware of?

 --
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

 Felix Miata  ***  http://fm.no-ip.com/
 __**_
 mc-devel mailing list
 https://mail.gnome.org/**mailman/listinfo/mc-develhttps://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: stable vs. latest

[Egmont Koblinger]

Andrew:  Is it that soon there will be a 4.9.1.x stable and 4.9.x devel
series?  Or you give up this development model and stick to a single branch
from now on?  If the latter, I think it should be made obvious on the
homepage (maybe when 4.8.8 is released), and the Our release workflow
page should also be updated.

thanks,
egmont

On Wed, Feb 20, 2013 at 5:36 AM, Andrew Borodin aboro...@vmail.ru wrote:

 On Tue, 19 Feb 2013 15:19:11 -0500 Felix Miata wrote:
  Last Debian, Fedora  *buntu releases had 4.8.x. Current Gentoo is 4.8.7.
  Mageia 3 is about to be released with 4.8.7. So, why does the
 stable/4.8.1.x
  branch even exist?

 There is no stable branch anymore. 4.8.1.7 was the last release in 4.8.1.x
 branch. 4.8.1-stable and master branches have more and more differences,
 and
 patch backporting from master to stable and vice versa becomes more and
 more
 hardly. We try make stability in master as much as possible.

 --
 Andrew
 ___
 mc-devel mailing list
 https://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: stable vs. latest

[Egmont Koblinger]

Strictly IMHO (I'm not a developer, just a casual contributor):

I've also wondered about this... MC follows the standard model of two
concurrent branches (devel containing new and riskier changes, vs. stable
for obvious bugfixes but no big changes or new features; where every once
in a while the devel branch is stablized to the new stable and a new devel
is branched out).  It's only the numbering that's a bit unusual (not the
standard x.even.y = stable, x.odd.y = devel, but something more
complicated), but it's clearly noted on the homepage which version is
stable and which is devel.

So I guess this is a very good question, but I'm afraid MC developers are
not the right people to answer this.  I think you should ask distributions
why they choose the devel version, it's their decision (their fault if
you wish).  I think we'd all be eager to hear their reasons.

egmont

On Tue, Feb 19, 2013 at 9:19 PM, Felix Miata mrma...@earthlink.net wrote:

 Last Debian, Fedora  *buntu releases had 4.8.x. Current Gentoo is 4.8.7.
 Mageia 3 is about to be released with 4.8.7. So, why does the
 stable/4.8.1.x branch even exist?
 --
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

 Felix Miata  ***  http://fm.no-ip.com/
 __**_
 mc-devel mailing list
 https://mail.gnome.org/**mailman/listinfo/mc-develhttps://mail.gnome.org/mailman/listinfo/mc-devel

___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: Midnight Commander 4.8.1.2 (stable) released

[Egmont Koblinger]

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
ladislav.hag...@unob.czwrote:

  mc-4.8.1.2 now released (stable).
 
  I just compile it and test it.
 
  Something is broken with bz2, xz and gz support, 7z is OK.
 
  If I press Enter on bz2 archive I get red error Cannot open tar
  archive mc-4.8.1.2.tar.bz2/ubz2:// but if I press Enter second time
  (while error message is shown) bz2 support works OK, the bz2 archive
  is opened.



 My colleague has the same problem [1]:

 I have now done some tests.
 I usually use F3 to look at archives - that works

 If I just press Enter, the Red box appears, but only for tar type archives.

 xx.diff.gz opens directly (one file)
 xx.xz  opens directly (one file)

 but for multifile archives
 xx.tgz requires a second step
 xx.tar.bz2 - 2 steps
 xx.tar.xz - 2 steps

 xx.7z opens directory


 [1] http://lists.ibiblio.org/pipermail/sm-commit/2012-April/038472.html

 --
 Ladislav Hagara




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

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

Re: Getting ready for a release

[Egmont Koblinger]

On Tue, Sep 04, 2007 at 10:57:42AM +0200, Pavel Tsekov wrote:

 how are we going to number the new release ?

/me votes for 4.6.2. As far as I followed the development, there's nothing
really brand new huge or conceptual change that would make calling it 4.7
reasonable, it only contains plenty of small bugfixes.

Being a maintainer of a distro what I see is that by now every Linux
distribution that matters has switched to using UTF-8, and mc is amongst the
really very very few packages that still need to be patched to work
correctly in such environments. (I think mc is the only one where lack of
utf-8 support is immediately seen by the users and makes it nearly unusable
in such systems). Hence distros will still have to patch mc for UTF-8, just
as they did with 4.6.1. It also implies that users won't be able to simply
download and compile and use this brand new mc - they'll have to wait for
their distributors to update the package, which probably don't happen
immediately due to the work required on their side.

So IMHO UTF-8 support out of the box is a must for the version named 4.7.


-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Bugs should be reported to mc-devel@gnome.org

[Egmont Koblinger]

On Thu, Apr 12, 2007 at 09:07:38AM +1000, Jeremy Dawson wrote:

 No, but I'm sorry I don't want to be bothered explaining the difference. 
 Try thinking about it yourself.

Nice to hear it from somebody who obviously didn't try to think how to quit
mc :-)

 As I believe I said in my original email, I went for the Help function 
 (bottom left hand corner).  Why was that such a stupid thing to do?

The symptoms that you described are definitely not how mc should behave in a
proper system. Maybe you have a completely braindamaged outdated system with
faulty libraries. (Btw you haven't provided any details - OS type and
version, mc version, terminal emulator, terminal settings, env variables
etc.) Maybe you were using a terminal smaller than 80x24.

You have to believe: if your system is installed properly, it _is_ easy to
find out how to quit. It does print 10 Quit at the lower right corner
(supposing you have at least 80 columns). The pulldown menu is fully
functional, you can find Quit there, too. The help system is perfectly
usable too. If this is not what you experience, you have a broken system.
Complain to your OS vendor or sysadmin.

 Not my version of it - at least, searching for any of the following:
 Quit, quit, Exit, exit came up with nothing (except searching for quit 
 found the word quite).  Mind you I was looking at the man page for 
 mcedit - that's the program that was running, according to ps.

And what if you wrote _this_ as a bug report? The manual page of mcedit
doesn't mention how to quit. This would have been a useful report.

Do you know what my biggest problem is? (And it seems to me that I'm not the
only one on this list.) It is that you think you sent a bug report, but
that's not true. You sent complaints. And that's pretty different. Bug
reports are very welcome. Complains aren't really I guess.

 They do have a concise guide to the most commonly used commands.  It is 
 clearly apparent, in each, how to quit the application.  IN fact I've 
 just tried them out - it's easier than I'd remembered.  Why don't you?

[ and from your subsequent mail: ]

 Which is why you're in no position to judge whether mc(edit) is more or
 less newbie-friendly than pine, mutt or lynx.  The newbies are the
 ones to judge that.

I've tried them too, and I remember seeing lots of newbie people launching
them for the first time. I saw and remember how they judged them. Let's take
pine for example.

When you start it for the first time, a Welcome to Pine ... do you want
to be counted? message appears with a long text. If you've ever read
anything about software usability, you probably know that people don't read
long texts. Yes, right, they simply don't read them. They just hit random
keys, or ask someone what to do. If they read it, they'd know to press E for
Exit, and then Q for Quit - extremely logical.

You seem to forget that while your mother tongue may be English, it's not
the case for many people. Still, pine talks to them in English. They may not
understand a single word.

When you start mutt for the first time, it probably asks something like
/home/foo/Mail does not exist. Create it? A newbie doesn't understand a
single word of it, has no clue what it means and what to answer, and no
option is provided here to quit without answering this question.

Lynx is the only one of these three where it is clear how to quit -- should
this be the most important thing you want to do with an application.

And I also saw newbies using the basic features of mc without any problem.

By the way, IMHO anyone wishing to use newbie-friendly software only should
close all the terminals immediately and start using graphical applications.
Terminal apps are for those who are willing to learn and experience in hope
of a more effective future use of the system.



-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Bugs should be reported to mc-devel@gnome.org

[Egmont Koblinger]

On Wed, Apr 11, 2007 at 09:02:44AM +1000, Jeremy Dawson wrote:

 A program which grabs my window, from which I can't tell how to quit? 
 You must be joking.

sleep 1 = it's just another program you can't tell how to quit, right?
It doesn't have docs for that. Do you think you should report that to the
coreutils folks?

In mc, the bottom right corner shows how to quit, or how to pull down the
menu where you can find the quit option, too. You can also invoke the menu
with the mouse. There's also a built-in help that documents these.

As you wrote, you had looked up this e-mail address in mc's manual page. So
you know what man pages are and how to read them. Haven't you found the info
on how to quit mc there? Surprisingly it _is_ written there, too.

 I'll tell you something you don't know - if you want to learn about 
 software which is usable by someone who hasn't been taught how

pine, mutt or lynx as user-friendly, and even more, newbie-friendly
software??? You really must be joking...


What's your goal with your bug report?

Do you want to _use_ mc, become familiar with it? Or just complain that you
were unable to quit and don't want to see it any more? (It seems to me that
no-one around here cares about the latter one.)

Doesn't your window have an X button in the upper-right corner that closes
this window? Perfect way for beginners to quit any application - usually
they find it on their own.


Ps. I'm not a developer, just a guy who uses mc regularly and send some
minor patches sometimes. But I strangely stare at your mails and can't
understand them... I just have a feeling that if 1 out of 1 users (who
actually has a university's domain name in his e-mail address) have no clue
how to use it then it's probably not the software's fault.


-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and utf8

[Egmont Koblinger]

Hi,

I'm very glad to hear that there's going to be some work on it!


 My work leader is author of the original utf-8 patch for mc.

Oh my God... Who is he? (Just for curiosity.) There were lots of names:
Jakub Jelinek, Vladimir Nadvornik, Jindrich Novy - AFAIK they're all
involved in the current UTF-8 patches.


 I have read some old posts about this theme and source codes of mc, too.

I recommend reading the following two threads. Especially because I also
wrote my detailed opinion in both threads and I don't want to re-type them
:-))) so imagine they're #included here.

Proposal for simplification (2005 Sep-Oct) is (amongst others) about
possibly dropping support for one of ncurses and slang. If, after some
investigations, you think that dropping these would make your work much
easier than probably this is the way to go.

Request for discussion - how to make MC unicode capable (2007 Feb-Mar)
contains lots of useful ideas.

Please also see my UTF-8 related patches at
https://svn.uhulinux.hu/packages/dev/mc/patches/


The most important goal I think is to get work accepted in mainstream mc.
This means we need clean code that is well-designed, modularized, easy to
understand, easy to verify, easy to modify/improve/fix. And of course that
works correctly :)


I think the first step should be to decide which scripts to support (or plan
future support for). This should probably include testing commonly used
terminal emulators what they do at certain circumstances. Here's what I
mean:

- Handling single-width characters is trivial.

- Handling double-width (CJK) shouldn't be hard, but there are some tricky
  questions arising. E.g. what to do if only the left half of a double-width
  character is visible in the rightmost column during editing a file? What
  if wordwrap mode is on and it should continue in the next row? I don't
  think terminal emulators support wrapping CJK characters (and it would
  make no sense actually) so probably some special symbol (e.g. ») should
  be displayed at the end of the line if word wrapping is off, and if word
  wrapping is enabled then probably the whole new character should be
  wrapped to the next line. What if some CJK text (maybe a filename) needs
  to be printed in a smaller box, probably with a ~ in the middle, probably
  by cutting at its end...? I guess you'll need several helper functions
  similar to (but more complex than) my 00-70-utf8-common.patch.

- What to do with zero-width characters, including combining characters? 
  Very few terminal emulators support them correctly (e.g. plain old xterm).
  Should we address supporting them on these terminals? (Or at least design
  mc now so that it can be added easily later, without a complete rewrite?)

- What to do with BIDI issues (Right-To-Left writing)? I don't know if there
  are terminal emulators out there at all that support RTL. But maybe mc
  could reverse these strings on its own and send them out without sending
  LTR or RTL marks so that eventually the user sees them correctly. Needless
  to say, this would make editing a line or a file much trickier. Maybe you
  should study emacs/vim whether they support BIDI...

- How much support does ncurses or slang give to make these complicated
  things easier?

The current version of mc with utf8 patches works well with single-width
characters, but behaves quite bad with CJK. According to my experiences so
far, most of the terminal emulators and applications handle double-width
correctly, but other issues (zero-width, combining, bidi) still suffer from
plenty of bugs. So for me it would seem to be a wise decision to address
single and double wide characters, but not yet support other tricks. (Of
course by not supporting them I mean that mc still does something
reasonable in these cases, e.g. prints the Unicode value within  signs or
similar. It's not affordable if the screen gets completely damaged or
something out of mc's control happens.)


Some more random pieces of ideas you might found useful:

There's a stuff called gnulib. I have absolutely no info on it, except
that once I sent a bugreport to the findutils folks that case insensitive
UTF-8 matching didn't work, and later they reported they were able to fix it
due to an upgraded gnulib. MC with utf8 patches also suffer from such
problem, case insensitive search in the viewer only works for non-accented
letters. Probably gnulib provides a nice function that could solve it.

In order to be able to view or edit half-text half-binary files and fully
work on them, you'll need string searching and regexp matching functions
that perfectly tolerate invalid byte sequences, but still find matches
within the valid parts. Maybe you should take a look whether there's an
already existing solution that you can use. (Maybe glibc's regex stuff,
maybe pcre... I don't know whether these work correctly on mixed text/binary
strings.)

Currently mc with utf8 patches has a nasty bug that if a filename is invalid
utf8 and you 

Re: mc and utf8

[Egmont Koblinger]

On Wed, Apr 11, 2007 at 07:03:44PM +0200, Jindrich Novy wrote:

Hi,

 I have never claimed I'm the only original author of the UTF-8 patch.
 The misunderstanding [...]

No, that was clear to me, there's no misunderstanding. I knew the UTF-8
patch was a work of several people. I was just curious who Rostislav
referred to, because he (i.e. you) could also write to this list and so I
knew that yeah, _he_ is his supervisor :)


bye,

Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: [BUG+PATCH] Wrong name sort.

[Egmont Koblinger]

On Mon, Mar 05, 2007 at 07:49:06PM +0100, Martin Petricek wrote:

 I have files sorted by name, case insensitive sort. However, the
 sorting seems to be behaving strangely, as bunch of files that should
 be sorted before or after filter.cc and filter.h (not sure if . is
 before or after letters while sorting) got stuffed in the listing
 between these two files. Seems to me like dots are ignored when
 sorting at all,

Yes, this is how strcoll() behaves in many locales. You don't like it, but
others may.

 I think one extra test should be added there:
 if a.b is sorted between aa and ac, do not use strcoll
 See attached patch which does exactly that.

I don't think this kind of autodetection is the right way. Actually I think
this is a very wrong way.

If you think strcoll() behaves buggy for one particular language, go and fix
that locale, or set your LC_COLLATE variable to use some other locale for
sorting (e.g. export LC_COLLATE=C).

Perhaps it might make sense to have an option in mc where you can _manually_
choose between strcmp() and strcoll() (but hey, that's what LC_COLLATE is
for!), but doing such kind of autodetection is the worst I can imagine --
no-one would ever understand what and why mc does unless s/he looks at the
source. This behavior would be absolutely counterintuitive.



-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: maybe a bug in copy files

[Egmont Koblinger]

On Mon, Feb 26, 2007 at 08:38:37PM +0200, Pavel Tsekov wrote:

 Ok. Maybe we are talking about different issues. What I was talking
 about was that the current code in MC requires the chmod() that i've
 ressurected. From what I understand you was talking that if we change
 the code we may avoid the chmod() call at the end. Is this right ?

Yes, at least in the do not preserve permissions case we could avoid that
chmod, and hence have a simplercleaner code. I hope.


-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Request for discussion - how to make MC unicode capable

[Egmont Koblinger]

On Sat, Feb 24, 2007 at 02:57:44PM +0200, Pavel Tsekov wrote:

 I'd like to initiate a discussion on how to make MC
 unicode deal with multibyte character sets.

Hi,

Here are some of my thoughts:

- First of all, before doing any work, this is a must read for everyone:
  http://joelonsoftware.com/articles/Unicode.html
  One of the main points is: from the users' point of view, it absolutely
  doesn't matter what bytes there are, the only thing that matters is that
  the users should see every _letter_ correctly on the display. Byte
  sequences must always be converted accordingly. On the other hand, we'll
  see that it's often a must for mc to keep byte sequences unchanged. The
  other main point is: for _all_ the byte sequences, inside mc, in the
  config and history file, in the vfs interface, everywhere, you _must_ know
  in which character set the string stands there.

- Currently KDE has much more bugs with accented filenames than Gnome has.
  This is probably because they have a different philosophy. Gnome treats
  filenames as byte sequences (as every Unix does) and only converts them to
  characters for displaying purposes; while KDE treats them as character
  sequences (QString or something like that). Probably due to this, KDE has
  a lot of troubles, it is absolutely unable to correctly handle filenames
  that are invalid byte sequences according to the locale, and it often
  performs extra, erroneous conversions. So I think the right way is to
  internally _think_ in byte sequences, and only convert it to/from
  characters when displaying them or doing regexp matches and so on.

- Similar goes for file contents. Even in a UTF-8 environment, people want
  to display (read) and edit files with different encoding, and even if
  every text file used UTF-8 there would be other (non text) files too. We
  shouldn't drop support for editing binary files, hex editor mode and so
  on.

- When the author of the well-known text editor joe began to implement
  UTF-8 support, I helped him with advices and later with bug reports. (He
  managed to implement a working version 2 weeks after he first heard of
  UTF-8 :-)) The result is IMHO a very well designed editor and I'd prefer
  to see similar in mcview/mcedit. In order to help people immigrate from
  8-bit charset to UTF-8, and in order to be able to view older files, it's
  important to support different file encoding and terminal charset. For
  example, it should be possible to view a Latin-1 file inside a Latin-1 mc,
  to view an UTF-8 file in a Latin-1 mc (replacing non-representable
  characters with an inverted question mark or something like that), to view
  a Latin-1 file in an UTF-8 mc, and to view an UTF-8 file in an UTF-8 mc.

  - The terminal charset should be taken from nl_langinfo(CODESET) (that is,
the LANG, LC_CTYPE and LC_ALL variables) and (as opposed to vim) I do
believe that there should be _no_ way to override it in mc. No-one can
expect correct behavior from any terminal application if these variables
do not reflect the terminal's actual encoding, so it's the users' or
software vendors' job to set it correctly, there should be no reason why
anyone may want to fix it only in one particular application. MC is not
the place to fix it, and once it's fixed outside mc, mc should not
provide an option to mess it. (I have no experience with platforms that
lack locale support, in such platforms it might make sense to create a
terminal encoding option, the need for this could be detected by the
./configure script.)

  - The file encoding should probably default to the terminal encoding, but
should be easily altered in the viewer or editor (and in fact, some
auto-detection might be added, e.g. if the file is not valid UTF-8 then
automatically fall back to the locale's legacy charset, or automatically
assume UTF-8 if the file is valid. Joe does have two boolean options
whether to enable these two ways of auto-guessing file encoding.) This
setting alters the way the file's content is interpreted (displayed on
the screen, searched case insensitively etc.) and alters how the pressed
keys are inserted in the file, but does not alter the file itself (i.e. 
do not perform iconv on it). This way the editor remains completely
binary-safe. Obviously displaying the file requires conversion from the
file encoding to the terminal encoding; interpreting pressed keys
requires conversation in the reverse way).

- Currently mc with the UTF-8 patches have a bug: when you run it in UTF-8
  environment and copy a file whose name is invalid UTF-8 (copy means F5
  then Enter) then the file name is mangled: the invalid part (characters
  that are _shown_ as question marks) are replaced with literal question
  marks. Care should be taken to always _think_ in bytes and only convert to
  characters for displaying and similar purposes, so that the byte sequences
  always remain 

Re: Request for discussion - how to make MC unicode capable

[Egmont Koblinger]

On Sun, Feb 25, 2007 at 02:41:45PM +0100, Leonard den Ottolander wrote:
 Just a few thoughts:
 
 - Because multibyte is rather more memory hungry I think the user should
 still have the option to toggle the use of an 8bit path either in the
 interface or at compile time. This means where the UTF-8 patches replace
 paths we should preferably implement two paths.

Multibyte is memory hungry if you use UCS-4 internally, which I don't
recommend (e.g. viewing a 10MB log file would need 40MB of memory - this
would really be awful). But if you use Latin-1, UTF-8, whatever internally,
there's no problem. My proposal is to still store the original byte
sequences in memory, in this case memory consumption doesn't grow in the
8bit case.

On the other hand, separate execution paths should be avoided as much as
possible, I hope it's needless to explain why. Most of the glibc functions
and the wrappers we could write to them are perfectly able to handle every
charset, no matter if it's 8bit or UTF-8 or something else. E.g. if we
implement a general mbstrlen() that returns the number of Unicode entities,
and strwidth() that returns the with, they'll work both in UTF-8 and in
Latin-1. In Latin-1 they'll always return the same value, but it's not worth
branching the code just because of this and use separate code for the 8-bit
cases. Just write and test one piece of code: the general case that covers
both UTF-8 and the 8bit ones, and probably EUC_JP and others too.

 - I suppose a lot of the code of the UTF-8 patch can be reused, only we
 will need to add iconv() calls in the appropriate places. libiconv is
 already expected so not much trouble with the make files there. Iconv
 should only be used for the multibyte path, not the 8bit path. Using the
 multibyte path would still enable users to translate from one 8bit
 charset to another.

As said above, I think different paths should be avoided. As discussed in my
previous mail, the story is not so simple black and white (8-bit vs. utf8),
there are mixed scenarios as well (viewing an utf-8 file in a latin1
terminal or a latin1 file in an utf8 terminal etc...)

 - Unsupported character substitution character should be an ini option
 (and define some defaults for all/many character sets). (I'm not sure
 question mark is supported in all character sets.)

I don't think mc should support any non ASCII compatible (e.g. EBCDIC)
character sets. They'd make things much-much more complicated and would
result in a feature probably no-one would ever use. Question mark is
available in all other character sets.

I really don't care if the unsupported character (e.g. if mc wants to
display a kanji but is unable to do since the terminal is latin1) is
configurable or not (actually a hardcoded inverted question mark is fine for
me) -- but it's not an important issue at all.

If a UTF-8 terminal is used (which is now the case in most of the Linux
distributions, at least in every distribution that matters (in my eyes)),
then U+FFFD is the right character for invalid byte sequences, as well as it
could also be used (I think) to denote non-printable (!iswprint())
characters.

 - Users should be able to set character set per directory (mount). Of
 course there should be a system wide default taken from the environment
 (but also overridable).

No. MC should not try to fix what's incorrect even outside mc. For vfat-like
file systems, there's the iocharset= mount option. For Linux file systems,
there's no such option, so it really sucks if you have two file systems
using two different encodings, but if it bothers you, either use convmv() to
convert these files, or patch the kernel to support iocharset=... and
filesystemcharset=... mount option for Linux file systems that does this
conversion. If there's no way for you to see the filenames correctly
throughout your system with the echo or ls commands, it's not mc's job to
fix it.

I do believe there are many many things to do in mc with small developer
resources. I can't even see when mc will be able to properly support UTF-8
on systems that are properly set up. Based on the experiences of converting
a full distro from Latin-2 to UTF-8, I must say that mc is the only
important software where UTF-8 would be necessary but the mainstream version
completely lacks it. It is quite urgent to do something with it.
Unfortunately neither I can investigate much time in it. Let's try to do no
more than supporting properly set up systems. Let's not try to provide
workarounds for system misconfigurations and such.

I believe that if you see different filename encodings on your system then
your system is not probably set up. Go and fix it _there_ and leave mc's
developers alone. Having various encodings _inside_ the text files is a
different issue however, mc should deal with it...

And, by the way, is there any reason not to trust in environment variables
and provide a way to override them? Yet again it's a system configuration
issue: if your env vars are 

Re: maybe a bug in copy files

[Egmont Koblinger]

On Thu, Feb 22, 2007 at 05:44:39PM +0200, Pavel Tsekov wrote:

 Here it is:
 
 http://mail.gnome.org/archives/mc-devel/2006-June/msg00063.html
 
 Shall we discuss how to create the file in a secure manner
 and avoid the call to mc_chmod() ?

I think we're talking about two separate issues.

One is how to safely create a file (without race condition) so that we
really create _that_ file and not another one via a new symlink. The answer
is O_EXCL.

The other issue is how to create the file with the right permissions so that
we don't leak information. I guess I proposed a cleaner solution for this
than the current one.

I can't see any correlation between these two issues.


-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: maybe a bug in copy files

[Egmont Koblinger]

Hi,

 [...] As it can be
 seen the patch posted by Andrew calls chmod() on the target
 file only if preserve attributes is set. However, it has to
 be called in both cases since the destination file is created
 with mode 600 initially due to security concerns - more info
 can be found in file.c .

I think this is overcomplicated... open() does not create the file with the
permission taken from its third argument, it masks it with umask. So
currently the file is not created with mode 600, but with mode (600 
^umask).

What's wrong with the following simple solution?

When creating the file, pass the permissions of the old file to the open()
call. This way it will have no more permissions than the original file, and
no more permission than umask suggests.

When copying is finished, call chmod() only if preserve attributes is set.



-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

[bug #18767] Panel sort order: fallback to name

[Egmont Koblinger]

Follow-up Comment #4, bug #18767 (project mc):

Thanks for the patch.

I know about ls -U, but I think the audience of ls and mc might be a
little bit different. For the ls command it might be considered as a
filesystem debug option, or an option that can speed up scripts where the
order isn't important and there are a lot of files in a directory, or ls is
invoked many times. MC is rather a user-oriented, interactive application
with much more overhead (e.g. always stat()s all the files) which implies
that a little bit of extra overhead (sorting) is not a big issue, and it's
definitely faster if mc sorts the filenames than if the user finds the
requested file in an unsorted list. And I don't think anyone interested in
the filesystem order would use mc, they'd use ls. Anyway, it's not an
important issue at all, I was just interested in others' opinions. Of course
I don't mind if this option remains there, even though I can't see use of
it.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18767

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #18766] Not re-sorted at panel swap

[Egmont Koblinger]

Follow-up Comment #2, bug #18766 (project mc):

Okay, now I understand the design. But then IMHO the right behaviour would be
to re-sort the panels at swap, so that mc is consistent with itself (a ^R
doesn't change anything), and ^U is usable not only to very quickly show some
other file attributes but also to very quickly change to a different sorting
method.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18766

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #18766] Not re-sorted at panel swap

[Egmont Koblinger]

URL:
  http://savannah.gnu.org/bugs/?18766

 Summary: Not re-sorted at panel swap
 Project: GNU Midnight Commander
Submitted by: egmont
Submitted on: Friday 01/12/2007 at 14:40
Category: None
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: current (CVS or snapshot)
Operating System: GNU/Linux

___

Details:

If you use different sort orders on the two panels and press ^U to swap the
panels, the file lists are not updated. E.g. left panel is set to sort by
name, right panel is set to sort by date. Swap the two panels, the left one
will have the entries sorted by date, and the right one will list them
alphabetically. However, the sort settings of these two panels are not
swapped. Once you press ^R, that panel is re-sorted according to the current
rules.

I think that either the panels should be automatically re-sorted when
swapping, or maybe the config of the two panels should be swapped too (but I
don't really like this latter idea).





___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18766

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #18767] Panel sort order: fallback to name

[Egmont Koblinger]

URL:
  http://savannah.gnu.org/bugs/?18767

 Summary: Panel sort order: fallback to name
 Project: GNU Midnight Commander
Submitted by: egmont
Submitted on: Friday 01/12/2007 at 14:49
Category: None
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: current (CVS or snapshot)
Operating System: GNU/Linux

___

Details:

When sorting by a property that can be the same for different files (e.g.
file size), files having the same value are sorted strangely.

When you just change the sorting method from name to e.g. size, files of the
same size remain sorted by name. If you change directory, or simply press ^R
to reload the panel, these files will be sorted randomly (in fact I guess in
file system order). So a simple ^R changes the order, even though nothing
changed on the file system. This is quite strange, and IMHO not the expected
behavior.

IMHO sorting should always fallback to name, when their size/date/whatever is
the same.

PS. Does the Unsorted (file system order) option has any meaning in
practice? I don't think so.





___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18767

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #18695] tab completion vs. spaces and escaping

[Egmont Koblinger]

URL:
  http://savannah.gnu.org/bugs/?18695

 Summary: tab completion vs. spaces and escaping
 Project: GNU Midnight Commander
Submitted by: egmont
Submitted on: Friday 01/05/2007 at 13:07
Category: None
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: current (CVS or snapshot)
Operating System: GNU/Linux

___

Details:

Tab completion (Alt+Tab or Escape+Tab, I'll refer to these simply as Tab)
works exactly the same way in the command line and in dialog boxes (such as
copy/move file). The function complete() in src/complete.c only takes a
widget as its input and performs the completion.

This approach is wrong, since the dialog boxes and the command line have
different word splitting and escaping rules, they cannot be treated the same
way. Currently they both have bugs. (I found these while trying to tidy up my
mp3s, where lots of file and directory names contain spaces.)

In the file copy and similar dialogs, filenames are typed as pure strings
without any kind of escaping, and a text entry only takes one filename.
However, splitting at spaces is still performed. Suppose I have a directory
named /tmp/a bcde. I press F5/F6 on a file, and type /tmp/a and then Tab,
it completes to /tmp/a bcde. This is okay. But if I type /tmp/a bc and
press Tab now, it completes to the files in the current directory whose name
begins with bc, due to the splitting at the space. Similarly, if I already
have /tmp/a bcde/ in the edit field, it won't complete to subdirectories or
files of this directory. In this case the whole content of the field should be
treated as one, not being split at spaces.

In the command line, splitting at spaces is okay, however, we would need some
escaping and unescaping too, which doesn't happen. (Note: Esc followed by
Enter correctly escapes the filename when it puts it into the cmdline.)
Example: type ls /tmp/a and then Tab, you'll have ls /tmp/a bcdefgh/ in
the command line, which clearly won't list the contents of that directory due
to the unescaped space character. Another example: type ls /tmp/a\ b and hit
Tab, it won't complete to ls /tmp/a\ bcde/, but it should.

I understand that it is beyond the scope of mc to perform a full shell syntax
parsing (single and double quotes, nesting them etc.). This doesn't even
happen when Esc Enter is pressed: backslashes are inserted even between
quotes, but I'm fine with that. However, mc should produce proper escaping
when inserting spaces or other special chars as a result of completion, and
should be able to parse the backslash escaping it created (or the user typed)
when doing further completion.

Obviously the current design of the complete() function to take only a widget
is not okay (unless there's some room in the widget to store splitting and
escaping rules). There are two main possible solutions I can see, but
probably they'd eventually lead to basically the same code.

1) modify complete() so that it receives information on word splitting and
escaping, so that it becomes more complex and probably more buggy and harder
to maintain, but solves everything we need.

2) remove the word splitting code from complete(), so that it becomes simpler
and perfect for the file copy/move widgets. Slightly modify its interface to
take and return string and cursor positions instead of widget. Then make the
command line editor split at unescaped spaces, unescape the resulted word,
call complete() on this temporary string, escape the result of completion and
put back in the command line.

Finally, we should check how the internal cd command handles its arguments.
Currently it seems to do a lot of heuristics. For example, if I type cd
ab (four backslashes) then it tries to change to the directory called
ab (four backslashes) but if there's no such directory, it changes to
a\\b (two backslashes). This seems to be terrible, and leads to bugs, e.g.
if the cursor is on a\\b and I type cd  followed by a Tab, I get the
command cd ab and hence it'll change to ab which is not the
desired directory. I'd remove all the heuristics and perform the usual
command line unescaping, just as if it was an external command.





___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18695

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !

[Egmont Koblinger]

Follow-up Comment #6, bug #3836 (project mc):

Some time ago dpkg had a bug: when it removed a package that contained a
symlink to /dev/null, it chmod'ed /dev/null to 000. The problem was that it
did a chmod() instead of lchmod(), or stat() instead of lstat() or something
like that on the file to be removed.

Obviously if mc changed /dev/null to 600 for everyone, we would all know
about it and it would be already fixed. On the other hand I have no reason to
doubt the reporter.

So I guess that the bug might be that mc (or maybe its wrapper script)
chmod's something to 600, and this something (a temp file maybe) happens to
be a symlink to /dev/null on the reporter's system due to some special setup
or env var or special wrapper script or something like that...


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?3836

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: yet another utf8 patch: fix completion

[Egmont Koblinger]

Hi,

 Just a question related to 00-84-utf8-complete.patch. Why do you replace
 if (SLsmg_Is_Unicode) with if (1) in the implementation of
 mbstrnlen() ?

I just applied the previous patches and then cloned mbstrnlen() from
mbstrlen(). This modification comes from patch nr. 00-75. As far as I
remember, mc processes the --help switch before initializing slang, but we
already need a properly working mbstrlen() here to have the 2nd column of
the row +number displayed in the right place, if the translation of the
string +number contains accents. (The least important issue any of these
utf8 patches addresses :-)) Since mbstrnlen() is not used at this time, it's
perfectly okay to have if (SLsmg_Is_Unicode) there. Probably a better
approach would be to initialize slang at the very start and have both
functions begin with if (SLsmg_Is_Unicode).

 Will it work when mc is compiled with UTF-8 patches and
 ran with non-UTF-8 locale?

I guess it will, but I haven't tested. IIRC I once tested it with --help and
it worked. I think mbrtowc() and friends work correctly when converting
between arbitrary non-UTF-8 locale and wchar. ... OK, now I did a quick test
of tab completion in latin2 and it seems to work correctly.

Please note that I also modify mbstrlen() in patch nr. 00-82, and this one
also affects my implementation of mbstrnlen().

By the way, it seemed to me that we wouldn't need mbstrnlen(), since when we
call it, we actually always pass it the actual length of the string. If it
is the case, a simple mbstrlen() would have done it; but I just couldn't get
sure this is the case; and I didn't want to use a different approach than
the original code did.



-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

[bug #18689] Config checkboxes not acting on mouse click

[Egmont Koblinger]

URL:
  http://savannah.gnu.org/bugs/?18689

 Summary: Config checkboxes not acting on mouse click
 Project: GNU Midnight Commander
Submitted by: egmont
Submitted on: Thursday 01/04/2007 at 18:52
Category: None
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: current (CVS or snapshot)
Operating System: GNU/Linux

___

Details:

Under Options/Configuration and Options/Layout, checkbox or radiobutton
options that precede the currently focused widget are not clickable with
mouse, these mouse clicks are simply ignored.

Example: open the Options/Configuration dialog, click on the checkbox of the
last option (safe deLete), then click on any other option with your mouse,
this second click will have no effect. You have to use the keyboard or close
this dialog and open again to change these options.

Tested with 4.6.1 and with 2007-01-04-16 snapshot, both on Linux console
(gpm) and in gnome-terminal.





___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18689

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

yet another utf8 patch: fix completion

[Egmont Koblinger]

Hi,

Especially to the maintainers of the UTF-8 patches: I've created another
patch, this time to fix Alt+Tab (or Escape then TAB) completion when the
command line or filename or whatever you type already contains some accented
characters. The problem is caused by the UI widget telling the cursor
position in characters, while the functions in complete.c expect them to
refer to bytes.

This new patch can be found at the usual places:

  https://svn.uhulinux.hu/packages/2.0/mc/patches/
  https://svn.uhulinux.hu/packages/dev/mc/patches/

and is called 00-84-utf8-complete.patch. As usual, unfortunately, length
and width are not clearly distinguished, so it's unlikely to work
correctly with double-width characters. To be applied on the top of the
previous utf8 patches in numerical order (though it doesn't depend on all of
them).

The 2.0 directory contains patches of the UHU-Linux 2.0 distribution,
which is already released. This means that contents of this directory is
hardly changing (though I've just put this patch here and released an update
package). These patches apply to mainstream mc 4.6.1 release and will never
be ported to newer versions of mc. The dev directory contains the patches
of our current development version. Currently there's only one small
difference (one extra utf8 patch here) but the contents of this directory is
more likely to change at any time. (Check for the file ../version to see
which mc version these patches apply to if you're reading this letter much
later than I send it.)



bye,

Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

invalid utf8 filenames mangled

[Egmont Koblinger]

Hi,

A quite important note to the maintainers of the UTF-8 patches:

When you use mc with the UTF-8 patches in UTF-8 mode, and copy or move a
file whose name is not valid UTF-8 by pressing F5/F6 on it or selecting it
with Insert and then doing F5/F5 on it, its filename gets mangled, invalid
UTF-8 characters are replaced with literal question marks.

If these files occur somewhere deeper (inside a directory that you asked mc
to copy/move) then the name correctly stays the same.

I guess it's a quite nasty bug and should be addressed...


-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

[bug #17822] consecutive resize events not handled correctly

[Egmont Koblinger]

Follow-up Comment #5, bug #17822 (project mc):

Please commit it if it seems to be okay for you (I've been using mc 4.6.1
with this patch for a month, and found no side effects, while it makes mc
much better when resizing the terminal). But please don't yet close this
bugreport to remind us that a proper fix is still needed. This patch only
makes it much better, but still there's a small chance for the bug to appear.
Until we have a proper fix, it's good to apply a temporary hack to heavily
decrease the chance for the bug.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17822

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: File has hard-links. Detach before saving?

[Egmont Koblinger]

 Any other opinions?

I think the main question is what the main purpose of hardlinks is.

Is it to (1) save disk space for files that actually happen to be the same
at this very moment, but live separate lives?

Or is it to be (2) a way to have one file accessible by more names, so that
they live the same life?

I think the general right answer is (2), and having two large source trees
and diffing them is an exception. When doing so, you do not explicitely want
hard links, this is just an easy way for saving 50% disk space and making
diff run faster. For the case of diff this approach is not the best
possible in theory, but we don't have better in practice. The running time
could be drastically decreased if diff had an option to assume to files are
the same if their size and modification time is the same. For the disk usage
part, IMHO the operating system kernels and file systems should support an
option to copy a whole file using copy-on-write techniques (similar to the
one used in memory management when forking a process) so that it's
completely transparent to the applications and the file is only physically
copied when someone modifies it.

So my vote goes for not detaching hard links by default.


-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

[bug #17823] hint changed when the window is resized

[Egmont Koblinger]

URL:
  http://savannah.gnu.org/bugs/?17823

 Summary: hint changed when the window is resized
 Project: GNU Midnight Commander
Submitted by: egmont
Submitted on: Friday 09/22/2006 at 13:08
Category: Screen output
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.6.1
Operating System: GNU/Linux

___

Details:

When resizing the terminal, mc chooses another hint (tip) to display (it
seems that at most once per second). This looks soo silly when I slowly
resize the window to a very different size :-)






___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17823

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[bug #17269] localized headers in .mc/history

[Egmont Koblinger]

Follow-up Comment #4, bug #17269 (project mc):

Localizing an already localized string definitely shows wrong design.
Theoretically it can lead to false strings appearing on the screen (if the
first translated string happens to be the same as an English string used
somewhere else in mc). It's quite unlikely for this bug to ever occur, but
still it's better to avoid it by good design. It'd be bad if the person first
hitting this bug would have to choose different wording or if he had to fix mc
in this respect.

(Theoretically :-)) each function has a documented interface of what the
meaning of its arguments are, and this documentation should state for all
strings whether they are localized or not.

You say: this may not be the best solution since the programmer must know
that it should call nice_cd () with N_() instead of _(). I think this
approach is wrong. Every programmer wishing to use an already implemented
function should first check the docs or the comments in the code to see what
this function expects and then use it accordingly. If there's no docs stating
whether the argument to nice_cd should be localized or not then _this_ is a
bug in mc. If there are docs, however, then there's nothing you can do
against wrong usage and it's not your problem anymore.

(BTW it starts resembling the usually-misunderstood Hungarian notation by
Simonyi, see:
http://www.joelonsoftware.com/articles/Wrong.html
for the right explanation. If strings are always stored in variables whose
name begins with a prefix stating whether it's already localized, to be
localized, or non-translateable, then these kinds of bugs are less likely to
occur.)

About your first suggestion: it avoids translating an already translated
string, hence it should really be done.

About your second suggestion: it could make the config file look the same
even if for some reason the English UI string is modified. Hence it is a nice
move, too.

So, I recommend making both changes :-)


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17269

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

Re: patch for viewing DjVu files

[Egmont Koblinger]

On Fri, Sep 08, 2006 at 07:40:48PM +0300, Pavel Tsekov wrote:

  Open=if [ $DESKTOP_SESSION = kde ]; then (nohup kdvi %f ); else 
  (nohup djview %f ); fi
 
  No problem about using kdvi with me, but why nohup? No entry in
  mc.ext.in currently has it.
 
 Does everyone agree ?

nohup redirects output to nohup.out. Even thought it does it in append
mode, it may ruin my file that I used for other purpose.

We should check if another utility (e.g. setsid) which doesn't modify my
files is suitable instead.


-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: incorrect hex number in editor

[Egmont Koblinger]

On Tue, Sep 05, 2006 at 09:09:01AM +0300, Nerijus Baliunas wrote:

 I updated to 4.6.1a-26.fc5 and the problem is still here.

   attached file is 0xC3 0xBC 0xC5 0xAB (you can check with
   any hex editor or mc viewer in hex mode), but editor
   shows it (in the last column of the first line) as
   0x106 0xBC 0xC5 0xAB.
   
   Latest mc from FC5 (2006-06-30-18).

Fedora is using mc with the UTF-8 patches, and provides a full UTF-8
environment, right?

Then the file you described above should display as 2 characters, a
LATIN SMALL LETTER U WITH DIAERESIS
followed by a
LATIN SMALL LETTER U WITH MACRON

Hence the expected hex codes in the upper right corner of mcedit are
0xFC and 0x16B. This is different from what you expect, and different from
what you see, too.

mcedit is a text editor, whereas the word text nowadays usually refers to
UTF-8 encoding. Hence with the UTF-8 mc patches it is no longer a binary/hex
editor.

Or am I wrong?


-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: incorrect hex number in editor

[Egmont Koblinger]

On Tue, Sep 05, 2006 at 01:33:17PM +0300, Nerijus Baliunas wrote:

 But it should either show correct hex codes or correct UTF-8 letters, which it
 does not.

Yes, perfectly right.

 BTW, I am not using UTF-8 locale.

Now I'm playing with my mc (not Fedora, but most likely nearly the same
UTF-8 patches) in non-UTF-8 mode.

With the hu_HU locale (iso-8859-2) I get: 0x102, 0x17A, 0x139, 0x164.
With en_US the hex codes displayed are: 0xC3 0xBC 0xC5 0xAB.
The later one is perfect, the first one is faulty.
With C locale you get: 0xFFEC3, 0xFFEBC, 0xFFEC5, 0xFFEAB.

So you're right, there's a bug somewhere in the UTF-8 patch, and its
behaviour depends on the exact locale. What locale do you have? Does it work
perfectly for you with an iso-8859-1 locale?


-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: incorrect hex number in editor

[Egmont Koblinger]

 With the hu_HU locale (iso-8859-2) I get: 0x102, 0x17A, 0x139, 0x164.
 With en_US the hex codes displayed are: 0xC3 0xBC 0xC5 0xAB.

Okay, got it: these are the Unicode codes of the symbols that are actually
displayed. In other words: the byte over which your cursor stands is
converted from the current locale to UCS and this value is displayed.

I guess that the reason is the following: The current method could be simply
implemented with one single codebase without branches that works for all
locales. (Take the byte(s) which form the symbol you're standing over,
convert from the current locale to UCS4 and display this code).

The behaviour you'd expect would need different code for the two cases:
detect whether the locale is 8-bit or not, do the conversion if it's not,
but don't convert if it is 8-bit. It'd be tougher and less straight-forward
and less logical from a programmer's view. However, this might be the
behavior an average user prefers.

I'll take a quick look at the code to see if I can patch it.


-- 
Egmont
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: incorrect hex number in editor [patch]

[Egmont Koblinger]

Here you are. Apply it after the big utf8 patch.


-- 
Egmont
diff -Naur mc-4.6.1.orig/edit/editdraw.c mc-4.6.1/edit/editdraw.c
--- mc-4.6.1.orig/edit/editdraw.c   2006-09-05 13:14:51.0 +0200
+++ mc-4.6.1/edit/editdraw.c2006-09-05 13:42:50.0 +0200
@@ -57,12 +57,22 @@
  */
 if (edit-curs1  edit-last_byte) {
 mc_wchar_t cur_byte = edit_get_byte (edit, edit-curs1);
+mc_wchar_t cur_byte2 = cur_byte;
 #ifndef UTF8
g_snprintf (byte_str, sizeof (byte_str), %c %3d 0x%02X,
is_printable (cur_byte) ? cur_byte : '.',
 #else /* UTF8 */
+/* In 8-bit locales show the byte itself instead of its Unicode value 
*/
+if (MB_CUR_MAX == 1) {
+unsigned char cur_8bit_byte;
+mbstate_t mbs;
+memset (mbs, 0, sizeof (mbs));
+if (wcrtomb(cur_8bit_byte, cur_byte, mbs) == 1) {
+cur_byte = cur_8bit_byte;
+}
+}
 g_snprintf (byte_str, sizeof(byte_str), %lc %3d 0x%02X,
-iswprint(cur_byte) ? cur_byte : '.',
+iswprint(cur_byte2) ? cur_byte2 : '.',
 #endif /* UTF8 */
 (int) cur_byte,
 (unsigned) cur_byte);
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

[bug #17268] Shift+Enter weirdness

[Egmont Koblinger]

Follow-up Comment #4, bug #17268 (project mc):

Okay, just for reference, I attach a better fix, this time it fixes the UTF-8
patches. Additional comment explaining what and why it does are on the top of
the patch file. I'll send it to the mailing list, too.

___

Additional Item Attachment:

File name: 00-82-utf8-shift-enter.patch   Size:1 KB
fix for the utf-8 patches
http://savannah.gnu.org/bugs/download.php?file_id=10458

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?func=detailitemitem_id=17268

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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