Re: removing the obsolete gnome (gmc) support?



> I've never understood why was it good to hack mc to hell to get the gmc
> thing, especially after trying gmc. Writing such thing from scratch must
> have been simpler...

I don't know, I'm not Miguel.

> > Of course, a lot of stuff was moved to the TODO file.  We also have a bug
>
> I've read it. I'll come up soon with my own TODO, probably a stripped down
> version of yours, with things i'm interested to work on.

Sounds good.

> > tracking system and a patch manager on savannah.gnu.org.  There are still
> > serious problems in the code, such as an unsafe rewriting of the config
> > files without locking and doing backups.
>
> ah, the config system...
> i usually run several instances of mcedit on tty1..tty9, editing various
> source files (yes i know i should use some multifile-capable IDE but i
> like mcedit) and if i change something (indenting, tab size etc) in one
> mcedit then it will be saved and new mcedit instances will have that values
> set as default. It's really annoying... Imho there should be something like
> 'Ok for this instance' and 'Save as default setting' choices at the
> preferences/settings panels.

I'm talking about data corruption because of interrupted writes.

Anyway, your problem can be solved by integrating settings for the editor
with all other settings, using "OK" and "Save" consistently and
implementing a more fine-grained "auto save setup".

The editor is now developed independently of Cooledit, although the syntax
rules are kept (almost) compatible for now.

> > There is a lot of work to be done.  4.6.0 is just the beginning.
>
> Sure. I've find this in TODO:
>
> * Internal terminal - no more console saving.
>
> Imho it's one of the most important issues/problems of mc.
> I'm use dto norton/volkov comamnder under dos, and far under win32,
> they behave the same way when panels are visible and when they are hidden.
> In opposite, mc is tricky: if panels are enabled, then you're in mc's line
> editor, with mc hotkeys working. When panels disabled: you're in raw shell,
> no mc keys or things available. Even the command history in panels on/off
> mode is independent...

I think you are expecting too much.  I simply wanted to make console
saving work on all systems, not just on Linux and xterm (and SCO, but that
code it most likely rotten).

Of course, we could do all that is mc manages the terminal for the
subshell itself, but that would be separate tasks.

> The question is that how to solve this duality. Or is it planned at all?
> The first thing came in to my mind is the approach used by Volkov
> commander: You're always in the commandline editor, even if panels
> disabled.

That would be wrong.  The shell prompt is much more powerful.  Maybe as an
option.

> Also, I like your idea of builtin terminal emulation.
> Btw, it would be nice if it could run commands in new tty. Some utils, for
> example fte, ht or biew supports raw keys (to utilize shift+control+Fx
> etc combinations) but they don't work when executed from mc. It's boring to
> exit mc whenever i want to run biew on a file...
> It should be optional, and is useful only for local console use.

Just write a separate utility for that.  Maybe there is one already.

Or try using XFree86.  Reading modifiers from X doesn't require the
"top-level" shell, not to mention that you could open separate windows.

> Ok i'll try to avoid forking :)
> But I will (have to do) if we can't agree on some important change later,
> since getting the issues solved is more important for me than waiting years
> for some api change or end of code freeze :)

I hope that the time between releases will decrease.  However, the high
requirements for the code quality will remain in force.

> > It's quite natural, actually.  GNU Midnight Commander doesn't have major
> > competitors in the free software world.
>
> yes. many of my friends said "mc is buggy, mc sucks, but no alternatives so
> i'm using it". I hope i can help changing this opinion.

I also hope that you would be helpful, especially with the first two items
("buggy" and "sucks") :-)

-- 
Regards,
Pavel Roskin



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]