~arivigo/scalc-devel

3 2

History Bug + New Feature

Details
Message ID
<CCT0A9TRA15P.1SUFOJL9DY209@shire>
DKIM signature
pass
Download raw message
Hey,

With 0.3.0 out I've tested out the (wonderful!) new history features and
noticed what I think is a bug and a feature I'd like to see. Nothing
urgent, just some more eventual improvements :D

## Bug

Given the following input: 1<return>2<return><up>

We correctly get "2" from history

However, if instead of pressing <up> we first type some input, say "3",
then press <up>, we incorrectly get "1" from history, after which
pressing <down> indeed gives us "2" and once more gives us a blank
prompt again.

## New Feature

In summary: "Current input should be continuously saved to history"

Right now, entering some input, then pressing <up> followed by <down>
returns us to an empty prompt. Instead, as done in terminals, I think it
should restore the existing partial input.

Thanks,
Steven
Details
Message ID
<20210714173848.gg3qgglclbzoicoq@arch>
In-Reply-To
<CCT0A9TRA15P.1SUFOJL9DY209@shire> (view parent)
DKIM signature
pass
Download raw message
On Wed, Jul 14, 2021 at 12:33:11PM -0400, Steven Guikal wrote:
> Hey,
> 
> With 0.3.0 out I've tested out the (wonderful!) new history features and
> noticed what I think is a bug and a feature I'd like to see. Nothing
> urgent, just some more eventual improvements :D

Thank you! Glad you're liking scalc! :D

> ## Bug

First, let's address this. This isn't a bug. It isn't a feature either,
before you ask :P

> Given the following input: 1<return>2<return><up>
> 
> We correctly get "2" from history
> 
> However, if instead of pressing <up> we first type some input, say "3",
> then press <up>, we incorrectly get "1" from history, after which
> pressing <down> indeed gives us "2" and once more gives us a blank
> prompt again.

OK, this was a deliberate decision by me when I implemented sline.c,
because I thought it made more sense to have it this way. Also, 
memory-wise it makes things easier.

> ## New Feature
> 
> In summary: "Current input should be continuously saved to history"
> 
> Right now, entering some input, then pressing <up> followed by <down>
> returns us to an empty prompt. Instead, as done in terminals, I think it
> should restore the existing partial input.
 
But, I've been playing around with different prompt-based programs and
you're right: every single one of them behaves exactly as you propose.

Of course scalc could behave in any arbitrary way. The fact that other
behave in way A and scalc behaves in way B doesn't really mean 
anything... but I totally see users being confused by this sui generis
way of doing things. (That's why this isn't a bug properly speaking...
it's just different... a bit way too different!)

So... I'm adding this to the tracker as a feature ticket! Thank you so
much for your thoughtful proposal! If you want to kick in with some
code, please do so!

> Thanks,
> Steven

Thanks to you! :D

-- 
Ariadna Vigo
Web: <https://ariadnavigo.xyz>
PGP: 0xA3B1324836A669BD
Details
Message ID
<CCT1WHF9QB8T.34IQ8M0LC2KVK@shire>
In-Reply-To
<20210714173848.gg3qgglclbzoicoq@arch> (view parent)
DKIM signature
pass
Download raw message
On Wed Jul 14, 2021 at 1:38 PM EDT, Ariadna Vigo wrote:
> > Given the following input: 1<return>2<return><up>
> > 
> > We correctly get "2" from history
> > 
> > However, if instead of pressing <up> we first type some input, say "3",
> > then press <up>, we incorrectly get "1" from history, after which
> > pressing <down> indeed gives us "2" and once more gives us a blank
> > prompt again.
>
> OK, this was a deliberate decision by me when I implemented sline.c,
> because I thought it made more sense to have it this way. Also, 
> memory-wise it makes things easier.

Yep that's fair, though I personally don't quite understand the
rationale (beyond the easier memory handling). Why would beginning a new
command instead of leaving the prompt blank make history skip a single
entry?

> > ## New Feature
> > 
> > In summary: "Current input should be continuously saved to history"
> > 
> > Right now, entering some input, then pressing <up> followed by <down>
> > returns us to an empty prompt. Instead, as done in terminals, I think it
> > should restore the existing partial input.
>  
> But, I've been playing around with different prompt-based programs and
> you're right: every single one of them behaves exactly as you propose.
>
> Of course scalc could behave in any arbitrary way. The fact that other
> behave in way A and scalc behaves in way B doesn't really mean 
> anything... but I totally see users being confused by this sui generis
> way of doing things. (That's why this isn't a bug properly speaking...
> it's just different... a bit way too different!)

Just to make sure we're on the same page, I figured these were two
separate things. Are you saying what I call a bug and then the feature
are one in the same?

> So... I'm adding this to the tracker as a feature ticket! Thank you so
> much for your thoughtful proposal! If you want to kick in with some
> code, please do so!

Awesome, thanks! I'm a bit busy with other work at the moment but will
see if I can contribute some time in the future.

> > Thanks,
> > Steven
>
> Thanks to you! :D

Thanks for the detailed reply :^)
Details
Message ID
<20210714193433.mseuhkrcovox5h77@arch>
In-Reply-To
<CCT1WHF9QB8T.34IQ8M0LC2KVK@shire> (view parent)
DKIM signature
pass
Download raw message
On Wed, Jul 14, 2021 at 01:49:12PM -0400, Steven Guikal wrote:
> Yep that's fair, though I personally don't quite understand the
> rationale (beyond the easier memory handling). Why would beginning a new
> command instead of leaving the prompt blank make history skip a single
> entry?

Looking backwards, it was a terrible idea!

> Just to make sure we're on the same page, I figured these were two
> separate things. Are you saying what I call a bug and then the feature
> are one in the same?

This is becoming a bit philosophical. What is a bug? Is it an insect?
Is it a misplaced byte? /jk

This is probably me, but I call bugs things that give an objectively
wrong behavior as a result. Apart from crashes that render the program
useless, if the documentation said A but the program did B, that's a
bug. Or if the history feature returned the entries in disorder. For me
it's key that the expected behavior is defined *internally* to the
project's way of doing things.

A difference with behavior that is common in *other* programs is hardly 
a bug for me. If a program used Alt+Shift+O for copying instead of the 
more common Ctrl+C, is that a bug? I don't think so. It's probably a 
poor design decision (like mine was), but not a bug.

It's probably a gray area, though.

So I consider this a proposal to improve upon a feature but not because
the current feature works incorrectly... but just that scalc can do
way better by adhering to what everyone else is doing. That was my
point in my last email... Probably explained it badly.

But again, this is philosophy... the goal now is to make scalc better!
\o/
 
> Awesome, thanks! I'm a bit busy with other work at the moment but will
> see if I can contribute some time in the future.

Don't worry! I have some ideas already on how to implement this, but I
think I will take it a bit slow. Feel free to jump in, of course :)

xoxo,

-- 
Ariadna Vigo
Web: <https://ariadnavigo.xyz>
PGP: 0xA3B1324836A669BD
Reply to thread Export thread (mbox)