rio consctl behaviour

rio consctl behaviour

[umbraticus]

from rio(4):
> consctl controls interpretation of console input.  Writing
> strings to it sets these modes: rawon turns on raw
> mode; rawoff turns off raw mode; holdon turns on
> hold mode; holdoff turns off hold mode.  Closing the
> file makes the window revert to default state (raw
> off, hold off).

I am wondering if there is a reason for the behaviour described in the
last sentence.  It seems like it would be convenient to be able to
just echo holdon > /dev/consctl rather than do the dance in eg.
/rc/bin/hold to keep the fd open.  I have commented out
/sys/src/cmd/rio/xfid.c:328,335 in my local copy and nothing seems to
have broken...

umbraticus

Re: [9front] rio consctl behaviour

[Ethan Gardener]

On Tue, Jun 2, 2020, at 9:25 PM, umbraticus@prosimetrum.com wrote:
> from rio(4):
> > consctl controls interpretation of console input.  Writing
> > strings to it sets these modes: rawon turns on raw
> > mode; rawoff turns off raw mode; holdon turns on
> > hold mode; holdoff turns off hold mode.  Closing the
> > file makes the window revert to default state (raw
> > off, hold off).
> 
> I am wondering if there is a reason for the behaviour described in the
> last sentence.  It seems like it would be convenient to be able to
> just echo holdon > /dev/consctl rather than do the dance in eg.
> /rc/bin/hold to keep the fd open.  I have commented out
> /sys/src/cmd/rio/xfid.c:328,335 in my local copy and nothing seems to
> have broken...

There is a good reason applicable to raw mode. When a program exits, however it exits - crashes or whatever, you want the console restored to cooked mode. The way it is now is a simple way to do this, an open file will be closed by the OS if the program crashes. How reasonable it is to apply this same logic to hold mode is perhaps debateable.

I briefly thought failure to end hold mode would confuse users, but then I realised I only thought that because I'm used to 9pm, which has no color. ;) It doesn't indicate hold mode at all. This former lack of color might be why hold mode is tied to keeping the fd open. (9pm was ported in 2002.)

Re: [9front] rio consctl behaviour

[umbraticus]

Thanks, eekee. That makes sense re raw mode at least.
Any problem removing the hold stuff, then, given that,
as you say, you can easily tell if you're in hold mode?

umbraticus

Re: [9front] rio consctl behaviour

[hiro]

i agree that for hold this doesn't make sense, but no idea if it's
worth changing in case somebody's scripts break...

On 6/2/20, umbraticus@prosimetrum.com <umbraticus@prosimetrum.com> wrote:
> Thanks, eekee. That makes sense re raw mode at least.
> Any problem removing the hold stuff, then, given that,
> as you say, you can easily tell if you're in hold mode?
>
> umbraticus
>

Re: [9front] rio consctl behaviour

[Silas McCroskey]

I'm not sure going from one convention to two -- for the same file
endpoint -- is an improvement.

If we're leaving raw mode alone, I'd lean towards leaving hold mode
alone as well for that reason.

I don't see much issue with /rc/bin/hold, other than that it blanks
the file on-disk until you exit hold mode, which can lead to
surprising problems if you e.g. just close the window without exiting
hold mode. If your proposal would address that somehow, it might be
worth it, but otherwise I see this as a net drop in simplicity of
overall interface, for questionable gain.

- sam-d

On Tue, Jun 2, 2020 at 2:58 PM hiro <23hiro@gmail.com> wrote:
>
> i agree that for hold this doesn't make sense, but no idea if it's
> worth changing in case somebody's scripts break...
>
> On 6/2/20, umbraticus@prosimetrum.com <umbraticus@prosimetrum.com> wrote:
> > Thanks, eekee. That makes sense re raw mode at least.
> > Any problem removing the hold stuff, then, given that,
> > as you say, you can easily tell if you're in hold mode?
> >
> > umbraticus
> >

Re: [9front] rio consctl behaviour

[umbraticus]

On Wed Jun  3 10:50:41 NZS 2020, inkswinc@gmail.com wrote:
> I'm not sure going from one convention to two -- for the same file
> endpoint -- is an improvement.

Fair enough.  /bin/hold is fine but for a more complicated script
having to wrap the whole thing just to have it start in hold mode
seems awkward.  I can do this instead, I guess:
	unicode -x 1b > /dev/kbdin

umbraticus

Re: [9front] rio consctl behaviour

[hiro]

> I don't see much issue with /rc/bin/hold, other than that it blanks
> the file on-disk until you exit hold mode, which can lead to
> surprising problems if you e.g. just close the window without exiting
> hold mode.

what surprising problems are those? i'm not able to imagine right now

Re: [9front] rio consctl behaviour

[Silas McCroskey]

> > I don't see much issue with /rc/bin/hold, other than that it blanks
> > the file on-disk until you exit hold mode, which can lead to
> > surprising problems if you e.g. just close the window without exiting
> > hold mode.
>
> what surprising problems are those? i'm not able to imagine right now

/bin/hold an existing file with contents (not ones you care to keep),
then delete the window (or shut down, end your drawterm session,
whatever) without exiting hold mode.

The file will be left blank, because >path/to/file within the script
truncated it at the *start* of the process, rather than doing
truncate-and-write at the end. No way to retrieve the original other
than to pull it from dump.

I encountered this when I set up a "notes" window in each of my
sub-rios (most of which usually won't have edits in a given session)
and they kept getting lost on session close. I've switched to sam -d
for that (a better choice anyways) and haven't looked back.

Perhaps a more reasonable choice for hold would be to write to a temp
file path and then mv it after completion.

- sam-d