Inner and outer sizes need to match, panes can't overlap, minimum sizes need to
be enforced and a parent has to have the right number of children. It would
probably be possible to check all of these.
-------- Original message --------
From: Felix Rosencrantz <f.rosencra...@gmail.com>
Date:29/11/2014 11:37 (GMT+01:00)
To: Nicholas Marriott <nicholas.marri...@gmail.com>
Cc: Steven Lu <stevenlu...@gmail.com>,tmux-users
<tmux-users@lists.sourceforge.net>,Thomas Adam <tho...@xteddy.org>
Subject: Re: Reverse-Engineering Layout Format
Do you think it would be hard to verify a custom layout in tmux as part of
parsing without a checksum? Like what kind of format could a user create that
would crash the server?
It seems like it would be possible to use syntax to make sure that the layout
is complete such as adding parenthesis around the complete layout format.
-FR
On Fri, Nov 28, 2014 at 11:58 AM, Nicholas Marriott
<nicholas.marri...@gmail.com> wrote:
The checksum is so that people don't make copy/paste errors or try to tweak the
layout manually and crash tmux.
-------- Original message --------
From: Steven Lu
Date:22/11/2014 10:20 (GMT+01:00)
To: Felix Rosencrantz
Cc: tmux-users ,Thomas Adam
Subject: Re: Reverse-Engineering Layout Format
I have not had a chance to dig into this code yet but I do agree that there is
a large amount of untapped potential in this functionality and that can only be
helped by making it easier to interface with.
I can see that a set of even not very intelligent layout mutating scripts
should be able to improve usable screen real-estate by a large factor, by
effectively blurring the line between panes and windows by just auto-expanding
the focused pane, letting unfocused panes get smaller but still remain visible.
It helps that all terminal programs I have used (with few exceptions, such as
man pages) are rather robust to resizing, because we would now be resizing on
pane changes!
Anyway, I think the simple fact that it's possible at all to do such
interfacing is 90% of the engineering work, so hats off to whoever decided to
put this capability into the design.
On Sat, Nov 22, 2014 at 3:10 AM Felix Rosencrantz <f.rosencra...@gmail.com>
wrote:
I've wondered why is the checksum needed? It seems like it would be easier for
tmux users to write simple tools to tweak a custom layout without the checksum
being there. As best I can tell from a comment in the code, it is a quick way
to check if a layout is valid. I'm not familiar enough with the format or its
issues, is checking the validity something that is hard to do from code without
the checksum?
It seems like it would be useful to have a simpler format, perhaps not as
flexible as the current format, but one that was easier to parse, and validate.
For example, one that just took pane_ids and used the same grouping via the
braces and brackets like the current custom layout to build the cells
structure, evenly distributing space among the child cells of a parent. Less
control of pane placement, but easier to create more complicated patterns than
the defaults.
-FR.
On Wed, Nov 19, 2014 at 10:24 AM, Steven Lu <stevenlu...@gmail.com> wrote:
Hi Thomas, thanks for the hint!
layout-custom.c reveals a lot of things, I am now imagining that if I can
properly replicate the computation of the layout string along with the checksum
then I'll actually be able to do processing independent of mutating the pane
sizes within tmux, so that i can e.g. resize a particular pane to make it
bigger and then apply that change in one fell swoop by feeding a brand new
layout string.
I just wanted to know if this is actually how you have designed the
"select-layout" command to work.
I was taking a quick look at the source code (just poking around on github) but
it's strange that I cannot find the actual declaration for "struct
layout_cell"...
On Sat Jul 27 2013 at 7:28:43 AM Thomas Adam <tho...@xteddy.org> wrote:
On 15 July 2013 23:06, Steven Lu <stevenlu...@gmail.com> wrote:
> 3: zsh (1 panes) [274x76] [layout cc63,274x76,0,0,6] @3
> 4: zsh (1 panes) [274x76] [layout cc65,274x76,0,0,8] @4
>
> I'm hoping someone in the know could give me some hints about how to parse
> this so that I can compute what the result would be to warp any pane to one
> of the directions.
You need to look in layout-custom.c
-- Thomas Adam
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
