Re: minor ctrl+w bug
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Thu, 26 Aug 2010 17:13:03 +1000
On Wed, 25 Aug 2010 21:34:40 +0300
Liviu Andronic <landronimirc@xxxxxxxxx> wrote:
> On Tue, Aug 24, 2010 at 2:08 AM, <tpgww@xxxxxxxxxxx> wrote:
> > Liviu, the top line of output-pane displayed text remains the top line of
> > displayed text after expanding or contracting that pane. This approach is
> > equally-arbitrary to retaining the bottom displayed line, but slightly less
> > onerous to implement.
> >
> A similar case where the top-line approach seems unwarranted is when:
> - generate some output (and stay at teh bottom)
> - with the mouse increase teh size of the output pane and then restore
> to the original size
>
> You will note that restoring the size doesn't restore the original
> screen (that is, the text that was originally displayed). This looks
> confusing.
I suspect that we all would prefer that output-pane resizing worked as you
describe, in effect as if stacked, independent, windows were being partially
[un]covered. However instead, we actually need to log some position(s) in the
output textview widget, and after resize, ensure that such positions are still
visible. Which positions ?
Terminal emulators do not all work the same, though they tend to be biassed
toward retaining the bottom-displayed position. Perhaps this is a bit due to
their heritage, with most attention to last-printed stuff.
But if you're showing the top of the displayed text before resizing ? If you're
showing the top of the displayed text for a particular command before resizing
? If you're showing somewhere else in the middle of the displayed text before
resizing ? If you're showing the bottom of the displayed text before resizing,
the points you're making are definitely valid.
What if your example (above) is varied to include some additional output
between size increase and size decrease, making any pre-increase positions
irrelevant ?
Although unlikely, what if the user's layout is such that the output pane is at
the top of the application window ?
I'm sure that some fancier algorithm could be applied to handle all the
possibilities, but sofar it hasn't seemed worth the overhead.
Thoughts please. Does anyone feel strongly about this stuff ?
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:
