Re: symlink copy/move behaviour
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Mon, 18 Sep 2006 21:11:17 -0400
On Sun, 17 Sep 2006 17:32:54 -0700 (PDT)
Felix <thetrivialstuff@xxxxxxxxxxx> wrote:
> I messed up a significant portion of my filesystem by assuming that
> emelfm2 would copy/move symlinks as symlinks (it instead descended into
> them as directories, which caused enormous problems when it hit one that
> linked to its parent directory).
Thanks for the report, Felix.
Copying links is supposed to work more or less as you expected (actually, a new
link is created with the same target as the one in the original link), and it
does work as such when simply copying selected link(s). There is a bug when
copying directories, which causes a link to a directory to be treated as the
link's target. Readily fixed. If anyone can't wait until the next release, let
me know and I'll post a patch.
> .. I almost prefer [original emelfm] actually, for
> the following reasons:
> - I find the autocomplete behaviour in the directory lines very
> annoying, because it frequently results in things like
> "/mntnt/driverive/directoryectory--dammit!"
> (I'm often still looking at the output pane or the directory panes when
> changing dirs, so I won't notice when the autocomplete has fired)
> and
> "/m<tab>--k why didn't that work? oh, right--nt/<tab>--huh? oh,
> right...--"
Same here. For a while, I found it annoying. But that passed. Quite like when
using the the address input in any gtk file-chooser, or thunar, or nautilus.
> - it's a lot harder to drag things unintentionally (this happens to me
> in emelfm2 a lot because I somehow associate full row selection hilights
> with "no dragging possible" and icon/filename-only selection hilights
> with "this is a draggable user interface" -- midnight commander,
> xplorer2, 2xexplorer, directory opus, emelfm1, ws_ftp, windows explorer,
> mac OS finder, etc. all encourage this kind of thinking or have settings
> that cater to it)
As far as I can see, DnD does not work in emelfm, its item-selection mechanism
interferes with gtk processes. Highlighting less than the whole of a line is
only useful if you can guarantee that the highlighted part is visible - but in
emelFM2 any column may be hidden or scrolled off the window. Can't comment on
the other managers.
> - right clicking multiple items and clicking info creates a barrage of
> info windows.
One at a time, in order of selected items. To abort the sequence, if so
desired, there is typically a dialog-window close box, you can always do an
<Esc> key-press or activate the Stop button or its corresponding mnemonic key
...
admittedly emelfm1 also has this problem, but somehow I'm
> not tempted to press the info button there... maybe because my brain
> goes "this is old software, remember the properties dialogue didn't work
> yet" in there, and "ok, they should've fixed that by *now*" in the new
> one? (I expect some kind of summary for all the items; if I select 50
> files I expect to have to deal with one window, not 50.)
> )
Do you need to be told basic, lowest-common-denominator, stuff about multiple
items ?
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:
