Re: questions about features

Hello and welcome.
 
> I'm new to this file manager, and I quite like it. Especially nice is
> the way it incorporates the command line and the output pane. No other
> graphical file managers do anything like it, and as I result I'm still
> stuck with mc in console. However emelfm2 looks like I may be able to
> switch to it eventually.

> There are lots of small and not so small features and interface
> improvements that need to be added. Some of them I can do and want to
> do myself. I looked at the code and at first sight, it's very clean
> and well commented, which I liked too.
 
> However to begin contributing to the project, I would like to get a
> better idea of its plans for future development. Some critical missing
> pieces I certainly cannot do myself. Here are, in my opinion, the most
> immediate needs (in fact, some of them may be already addressed -
> please forgive me if I missed something obvious in exploring the
> program):

> - The ability to enter archives in the panel, and
> view/copy/move/rename files in them as you would do with normal files.
> Right now pressing Enter just lists the files in the output pane.

That's because the default configuration is set to do that. Easily changed.

There is a plugin that sort-of replicates what you want, by unpacking the 
archive into a temp directory, and going there, and offering to 
delete/leave/repack when you depart.

See comment below, about vfs.

> - An FTP plugin.

There is a severe aversion to supporting yet another application-specific, 
incompatible, vfs mechanism. When the folks posting about vfs at 
freedesktop.org finish their work on D-VFS, we'll look at this matter again.

The e2 sourcecode includes flags where attention is needed to support vfs, but 
(without wanting to get too technical) at present it's not possible to upddate 
the filelists properly in all usage cases, if such updates are threaded (and 
they'd need to be, to support sometimes very-slow updates from e.g. a remote 
site).

> - A command to search files recursively based on name or content,
> ideally going into archives and using different encodings. The current
> F3 command is not that. There's some "find" plugin in the source, but
> it's not listed in the list of plugins after installation - is that
> what F3 does?

The find plugin allows detailed searching, but not inside archives (it's really 
just a glossy front end to the shell 'find' command). I would have thought that 
the find plugin is on the default plugins menu, but if not, edit the plugins 
config to make it so.

> IF these features are implemented, here are some changes that I would
> like to see, and probably implement myself:
 
> - File coloring in the panel based on file types (you already have a
> nice system of file types, so why not use it for coloring too?). The
> current ability of using different

In the filelists we distinguish, by colour, 6 broad categories of item. That 
seems a reasonable compromise between ease-of-use and speed (which is a 
priority, I work with dirs that contain up to 2,000 items, and I know that some 
e2 users have slow hardware). There is currently no infrastructure (and in 
particular, fast infrastructure) in e2 for distinguishing items in finer detail 
e.g. mime-type.

> - The ability to change background color everywhere (at least in the
> panels and output pane and viewer) - I love black background

Background color is intentionally not set by e2. It should match the installed 
gtk theme. Tell us if if does not.

> - Panel listing modes with more than one column for names

To show what ?

> - A way to select files in the current panel based on a mask, which mc
> does on pressing gray + or gray -

Use the filters that are provided in the respective file-panes' filter menus.

> - A file.edit action for opening external editor (different from
> file.open)

There's an 'edit with' dialog associated with e.g. *.c. Custom commands and 
custom filetypes can readily be created.

> - Incremental search in viewer

Not sure what this is ...
BTW, the search functionality in the released viewer is buggy, I've just 
updated it today.

> - Switching source encoding in the viewer

You mean source code ? Or character encoding ?

> - Syntax coloring in the viewer (using colorer library?)

The internal viewer is deliberately simple. There is a config option to use an 
external viewer for more sophisticated purposes.

> - Lots of new keyboard shortcuts, including Lynx-like directory motion

Feel free to develop and apply your own (well, to v.0.1.5 there was a bug 
preventing addition of more bindings). But there's no evident clamour to make 
any such things default. Has been a little bit of recent talk about vi bindings.

BTW, a tool (stand-alone or plugin) to parse and update config files, e.g. to 
change keybindings, filetypes etc etc, all in one go would be great !

> And my final question is, what is this project's policy and general
> attitude towards patches and contributions?

Fixes always welcome, of course. Anything substantially increasing application 
(as distinct from plugins) size would need to be justified. In fact I'm on the 
lookout for things that can reasonably be removed (we do not aim to to all 
things for all (wo)men, there are lots of other good tools out there).

To now, code committed only by me or tooar. Never been any request for other 
arrangements, but I'm sure something can be worked out.

 How do you grant commit
> access? If you need credentials, I'm one of the core developers for
> Inkscape (http://inkscape.org).

Hope this doesn't all sound too negative and hard, but is intended to inform.

Regards
Tom


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: