An option to lock (and specify by keyboard) the height of the command input box.

I've been told to run this in an immediate window:

SetOption ("auto_resize_command_window", 1)
SetOption ("auto_resize_minimum_lines", 1)
SetOption ("auto_resize_maximum_lines", 1)

It works quite nicely, but it would be awesome if we could just click somewhere (or mark an option) to lock the output/input separator and then be able to freely click and (try to) drag it without moving it.

It would also be awesome if we could specify its height by keyboard, just like it happens when we use the immediate commands above. After all, of what use is a command input that is composed of "fractions" of lines? I'd risk saying (at least almost) everybody tries to achieve an integer number of lines by dragging the separator with the mouse. An option to specify the number of lines (and to have MUSHclient calculate the correct height for us based on input font and size settings) would rock.

Who told you to run that? And why? It's a bit silly. Given the lack of context, though, you probably want just SetOption("auto_resize_command_window", 0)




Can you show a screenshot of this actually happening?



Anything you can do with the immediate window you can also do with the script prefix on the input line. http://www.gammon.com.au/scripts/doc.php?dialog=IDD_PREFS_P17

Putting it simple, I'd like a command input box whose height is going to stay "locked" just like Windows' taskbar.

I can freely drag Windows' taskbar's border up and down to set its "height" to 1, 2, 3 or more "lines" of icons. If I lock the taskbar, however, it will no longer respond to attempts of being dragged. Even the change of the mouse cursor to that icon with two arrows, one up and one down, which indicates a draggable border, is gone.

I'd like the command input box to behave similary when "locked". It won't allow me to mess with it until I unlock it back.

As a plus - I'm a bit OCD - I'd like to be able to tell MUSHclient how many lines I'd like the box to accomodate, with not one unecessary additional pixel. I would type, say, "2" and MUSHclient, knowing that the font face and size I'm using makes letters be, say, 20 pixels tall, would set the command input box height to, say, 46 (40 from two 20 pixel tall lines with a 2 pixel padding between them), and, most importantly, keep it locked that way, not allowing me to change it with my mouse.

If you turn auto-resizing off, then the command bar height stays what you put it at.

I don't know about "locking" it - are you worried you will accidentally click on that little dividing line with the mouse, and then move it somewhere that you don't want?

Exactly. :)

This is already the existing behavior. I'm not sure what exactly you're asking for.

Put the bar in auto size mode with
SetOption("auto_resize_command_window", 1)

Make it exactly 2 lines with
SetOption("auto_resize_minimum_lines", 2)
SetOption("auto_resize_maximum_lines", 2)

Type anything in the bar and it will set to 2 lines. Drag it bigger, and then type anything in the bar and it will reset to 2 lines. Drag it smaller, and then type anything in the bar and it will reset to 2 lines.

If you want to do it from the command line, either use the script prefix and the commands directly or set up an alias or an accelerator.

It isn't "locked" if I'm able to drag it. :)

Like I said, the "auto resize" thing works very nicely.



I'm just suggesting an option to actually "lock" it. By "lock" I mean to make it so its state (the command input bar's height, in this case) cannot be changed (dragged).

Ok, but so what? Type anything and it goes back to the size you set.


But why? If it always goes back to the size you set, then the drag doesn't actually affect anything.

In my email program if I accidentally make some part of the screen wider than I want, I just have to put it back. I don't think many programs "lock" GUI elements.

It might be just me then. I end up dragging the input box a bit quite often when I go click in it (to set focus) in order to start typing. Since none of you experience that and this hasn't been suggested before, maybe it would really be an unnecessary addition after all.

There is also a small issue that I've seen happen at least three times. When I have two worlds open and both use the auto resize trick, sometimes I will (accidentaly) drag the box taller and, upon typing, have MUSHclient drag it back down for me. When I CTRL+TAB to the other world, the other world's input box is suddenly brought higher (to the same height as I accidentaly dragged the previous world's box to). I type something and the auto resize kicks in and does its work. Then as I CTRL+TAB again, in order to go back to the first world, the first world's input box (which had its size "fixed" by autoresize) is bigger once again (with the same height as was set by the initial drag), as if auto resize weren't "saving" the input box size. Then in order to make it "save", I have to first type something for auto resize to "correct" the height, then click the separator, as if I wanted to drag it, but without actually moving the mouse, and only then I can go back to CTRL+TABing and both worlds will show me the input bar at the auto resized/correct size. It seems as if only the mouse dragging/clicking is capable of saving the height of the input box.

MUSHclient would not be any less awesome without this "locking" feature. This was meant to be a very simple and humble suggestion since my ignorant mind thought it was quick and easy to implement (I know, I know, that is blasphemy sometimes, I know a tiny bit of coding). I'm already feeling bad just for making Nick have to read all of this because I know he has way more important things to take care of. :P

TL/DR: Let's pretend I didn't suggest this at all. But it would be nice if autoresize saved across CTRL+TABing of worlds.

There are two methods of setting the focus to the input bar which you may not be aware of. Neither involves using the mouse.

• Press Tab
• Press Esc

If you use one of those your problems should just go away. :)