# 'Legacy' argument compatibility

**URL:** <https://discourse.asciinema.org/t/legacy-argument-compatibility/130>\
**Category:** Ideas\
**Created:** [November 2, 2018, 6:22am UTC](https://discourse.asciinema.org/t/legacy-argument-compatibility/130 "2018-11-02T06:22:32Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![oldfart](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.asciinema.org/oldfart/32/28_2.png) [@oldfart](https://discourse.asciinema.org/u/oldfart)\
**Post date:** [November 2, 2018, 6:22am UTC](https://discourse.asciinema.org/t/legacy-argument-compatibility/130/1 "2018-11-02T06:22:32Z")

</div>

Hey,

The first versions used to use `-w` as a toggle for - what make senses to me, ‘wait’. Per example…

```auto
asciinema rec -t 'Some title' -w1
```

The new versions use ` -i ` (i would assume for ‘interval’… right…) which totally make sense.

```auto
asciinema rec -t 'Some title' -i1
```

Question is, is there a particular reason for switching from W to I and if it ain’t a major thing… how about re-introducing the W as a legacy compatibility thingny while, of course, keeping the I strong.

It,ll sound stupid but… i always get tricked into using -w SECONDS instead of the newer way.

What do you think? @ku1ik

---

<div class="post-metadata">

**Author:** ![ku1ik](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.asciinema.org/ku1ik/32/171_2.png) [@ku1ik](https://discourse.asciinema.org/u/ku1ik)\
**Post date:** [December 1, 2018, 12:56pm UTC](https://discourse.asciinema.org/t/legacy-argument-compatibility/130/2 "2018-12-01T12:56:29Z")

</div>

When preparing 2.0 I was thinking about changes to some args (since 2.0 was a major release, where it could be justified to introduce backwards incompat changes). This was one of them, and at that time I thought it’s about “idle time limiting”, not “specifying wait time”… What the does the latter mean? 😉 I’m still not 100% happy about naming of this option, but I think `-i/--idle-time-limit` is good enough.

One of the potential things I’d like to work on (not immediately, but maybe in the near future), is to allow overriding the terminal “window size”. You would pass width+height to `asciinema rec` and it would report these dimensions to the program that’s recorded (shell, vim, man, less). That could be useful to record asciicasts of (forced) size 80x24 in your 140x50 fullscreen terminal, that can be properly replayed in web player at 80x24. Why am I mentionting this? I thought about using args `-w 80 -h 24` with `rec` command.

`-w 80` would be taken then. But, after writing the above I’m not sure it’s good idea to reuse `-w` for different thing, and using `-h` for something different than display help message is also questionable… Also, it probably makes more sense to have single new arg for forced terminal size, accepting tuple `80x24` or `80,24`.

---

<div class="post-metadata">

**Author:** ![oldfart](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.asciinema.org/oldfart/32/28_2.png) [@oldfart](https://discourse.asciinema.org/u/oldfart)\
**Post date:** [February 10, 2019, 8:35am UTC](https://discourse.asciinema.org/t/legacy-argument-compatibility/130/3 "2019-02-10T08:35:26Z")

</div>

agreed with the combined args

uppercase arguments would solve the issue, allowing for ‘-w’ to be reinstated for compat (altho this is probably only for me at this point)

-W / -H

i had more to suggest about this but can’t think of it at the moment