I've applied this to OpenBSD now, thanks!
On Thu, Apr 16, 2015 at 09:59:49PM -0500, J Raynor wrote:
> > I like this, don't see any other problems so far.
>
> I applied your patch and looked it over. I don't see any problems, either.
-
> I like this, don't see any other problems so far.
I applied your patch and looked it over. I don't see any problems, either.
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in a
Couple of fixes. BCE is a FLAG not a STRING, and we need to check with
tty_term_flag not tty_term_has (so it wasn't actually making use of BCE
at all even if the terminal supported it). Also don't use the pane
colours for the borders.
I like this, don't see any other problems so far.
Index: cmd-
On Sun, Apr 12, 2015 at 07:25:43PM -0500, J Raynor wrote:
> This line in the patch for tmux.1 looks wrong:
>
> +.Fl P ).
>
> I think there has to be a space between the parenthesis and the
> period. Without it, the parenthesis gets treated as a flag and a dash
> is put before it.
Whoops, yes, I
This line in the patch for tmux.1 looks wrong:
+.Fl P ).
I think there has to be a space between the parenthesis and the
period. Without it, the parenthesis gets treated as a flag and a dash
is put before it.
If -g or -P is passed to selectp, other flags are ignored. Is that
the intended behav
On Sat, Apr 11, 2015 at 12:57:00AM -0500, J Raynor wrote:
> > On thing that occurred to me now is that display-panes uses a
> > target-client but this diff makes it need a target-pane sometimes which
> > is an issue for hooks command parsing. Not sure if we can workaround it
> > easily enough with
> On thing that occurred to me now is that display-panes uses a
> target-client but this diff makes it need a target-pane sometimes which
> is an issue for hooks command parsing. Not sure if we can workaround it
> easily enough with extra flags for hooks or if we should try to find a
> different co
Hi
This looks good. I've made a few changes, notably adding a tty_draw_pane
wrapper around tty_draw_line since it is mostly called with wp->screen.
Also I think there is no reason -g and -P can't be used together.
We'll need both these diffs together or it won't work in tmux itself so
I've put t
Ok thanks. I will look at these diffs (or any new ones if you've sent
them) again after OpenBSD unlocks which I guess will probably be a few
weeks.
On Mon, Feb 23, 2015 at 10:33:51PM -0600, J Raynor wrote:
> I've attached a patch that adds the BCE functionality I did before.
> It's more concise
I've attached a patch that adds the BCE functionality I did before.
It's more concise this time. You have to apply the other patch first,
the one that does pane colors for bce terminals.
As for the other stuff, I misunderstood what you were referring to. I
thought you were looking for a differen
On Sun, Feb 22, 2015 at 01:45:38AM -0600, J Raynor wrote:
> > You can try to make tmux itself support BCE ... or add BCE support
> > back on top of this like you had before.
>
> I don't know how to make tmux support terminals without BCE besides
> what I already did. Can you give me some detail f
> You can try to make tmux itself support BCE ... or add BCE support
> back on top of this like you had before.
I don't know how to make tmux support terminals without BCE besides
what I already did. Can you give me some detail for what you mean by
"make tmux itself support BCE"?
---
This looks good now, thanks, although I will need to find some time to
play with it a bit. We still have the question of terminals without
BCE. You can try to make tmux itself support BCE if you like which would
be nice and have a bit of overlap with this diff, or add BCE support
back on top of thi
I've attached a new patch. This patch:
* Adds Thomas's fix for pane selection via the mouse
* Gets rid of nflags in cmd_display_panes_exec
* Fixes the usage of memcpy in window.c
* Leaves tty_reset unchanged
* Has the tty_cmd_* functions call tty_attributes instead of tty_reset
* Includes u
Sorry. I looked at your larger patch, but the brief summary of the
other one (update window on mouse-select-pane) seemed unrelated, like
it was for something else you were working on, so I didn't look at it.
But I've seen it now, and I'll add it to the next patch.
On Thu, Feb 19, 2015 at 3:36 P
On Thu, Feb 19, 2015 at 12:21:37PM -0600, J Raynor wrote:
> I checked back over the emails for my patch, but I don't see any
> mention of mouse events. Was there a discussion off list? If so,
> I'll need to know what else you've found wrong. I can't fix it if I
> don't know about it.
I mentione
I checked back over the emails for my patch, but I don't see any
mention of mouse events. Was there a discussion off list? If so,
I'll need to know what else you've found wrong. I can't fix it if I
don't know about it.
> It's _still_ missing a fix in server-client. See the following:
>
>
> dif
screen_redraw_window implies status and borders, so can remove those.
On Thu, Feb 19, 2015 at 08:27:57AM +, Thomas Adam wrote:
> On Thu, Feb 19, 2015 at 01:49:14AM -0600, J Raynor wrote:
> > I've attached a new patch. There are 2 new window options,
> > window-style and window-active-style,
This looks pretty good.
tty_reset is not right. I've had another look and I don't think you need
to change the function itself, just the tty_cmd_* calls.
There are three reasons to call tty_reset:
1) It is called by, for example, tty_cmd_insertline, to set the colours
and attributes to OUR pa
On Thu, Feb 19, 2015 at 01:49:14AM -0600, J Raynor wrote:
> I've attached a new patch. There are 2 new window options,
> window-style and window-active-style, that allow you to set the
> window's color and the window's active pane color. The display-panes
> command can still be used to set an exp
I've attached a new patch. There are 2 new window options,
window-style and window-active-style, that allow you to set the
window's color and the window's active pane color. The display-panes
command can still be used to set an explicit pane color with -P.
tty_attributes now takes a window pane
On Mon, Feb 16, 2015 at 12:26:44AM -0600, J Raynor wrote:
> > Yes panes should always have colours. If the pane is set to 8, it uses
> > the window, if the window is 8, it uses the default. It isn't necessary
> > to have a way to set the pane directly to default, we don't have that
> > for any othe
> Yes panes should always have colours. If the pane is set to 8, it uses
> the window, if the window is 8, it uses the default. It isn't necessary
> to have a way to set the pane directly to default, we don't have that
> for any other style - it always follows the hierarchy (like eg the status
> li
On Sat, Feb 14, 2015 at 03:50:11PM -0600, J Raynor wrote:
> > - I don't think you need to allocate the gc with malloc, just put it
> > inside the wp directly and initialize it to grid_default_cell.
>
> I do need to allocate it with malloc. If I don't, it's always there
> (not NULL), so it'll al
> - I don't think you need to allocate the gc with malloc, just put it
> inside the wp directly and initialize it to grid_default_cell.
I do need to allocate it with malloc. If I don't, it's always there
(not NULL), so it'll always have some value. That makes it impossible
to tell what to do w
Almost all of the tty_reset will need to become tty_attributes for BCE
anyway so probably best to see where you are after that before worrying
too much about this anyway...
On Sat, Feb 14, 2015 at 09:36:16AM +, Nicholas Marriott wrote:
> Well, it's complicated a bit because tty_attributes cal
Well, it's complicated a bit because tty_attributes calls tty_reset.
So perhaps it is better to check it in two places - tty_attributes and
tty_reset. tty_reset can send SETAB/SETAF after SGR0 if either fg or bg
is not 8.
Or the call to tty_reset in tty_attributes could become a different
functio
In fact, since you will need to change tty_reset to call
tty_attributes(&grid_default_cell) instead of sending SGR0, you will
only need to check the default colours in tty_attributes itself.
On Sat, Feb 14, 2015 at 09:16:35AM +, Nicholas Marriott wrote:
> I was thinking that you do this in tt
I was thinking that you do this in tty_open:
if (!tty_term_has(tty->term, TTYC_BCE)
tty->flags |= TTY_NOBCE;
And use that instead of calling tty_term_has all the time. But actually
it probably makes little difference, just using tty_term_has is probably
fine.
As far as th
I've attached a new patch for pane colors. You use the display-panes
command to set the colors now, and the color changes take place in
tty_reset.
There's no bce stuff in this patch.
For bce, you mentioned a TTY_NOBCE flag. Could you give a little more
detail about what you're looking for? Whe
Hi
Looks like the right idea - please break the BCE stuff out into a
separate diff and we can check it separately. I suggest adding a flag
TTY_NOBCE rather than looking up TTYC_BCE every time.
Also I don't want a new command, so this will need to be a flag (or two:
one for fg, one for for bg) on
> I've taken a very quick look at this over lunch, and have put additional
> fixes/suggestions on top of your patch. The branch is here:
>
> https://github.com/ThomasAdam/tmux/commits/jr/pane-colours
>
> Have a look, tell me what you think. The cleanups are pretty trivial, but
> reduces some of t
> This will not work as it is on terminals which do not support BCE. To
> make it do so you will pretty much have to make tmux support BCE :-).
Ok, it now works on systems that don't support BCE. I've attached a new patch.
diff --git a/cmd-display-panes.c b/cmd-display-panes.c
index 9ce8971..150b
> But might make tmux flicker quite a bit over SSH or on slower terminals.
I don't think it'll cause flicker. Tmux tries to limit how much needs
to be written to the terminal. I did a quick login test with trickle,
setting upload/download speeds to 1K, 2K, 8K, and 16K. I don't see
any flickerin
I was able to reproduce the problem. If you start tmux with the -2
flag, does the problem go away?
I've attached a new patch that fixes this problem without having to
pass the -2 flag.
On Wed, Feb 11, 2015 at 4:54 AM, Thomas Sattler
wrote:
> Am 11.02.2015 um 07:57 schrieb J Raynor:
>> Also, wh
This will not work as it is on terminals which do not support BCE. To
make it do so you will pretty much have to make tmux support BCE :-).
On Wed, Feb 11, 2015 at 12:57:22AM -0600, J Raynor wrote:
> I???ve attached a patch that allows you to set the foreground and
> background color for a pane.
I'm typically a lurker on this list, but this is something I'm
definitely excited to see get added!
--
John Krueger
On Wed, Feb 11, 2015, at 08:31 AM, Thomas Adam wrote:
> On Wed, Feb 11, 2015 at 12:57:22AM -0600, J Raynor wrote:
> > I’ve attached a patch that allows you to set the foreground
On Wed, Feb 11, 2015 at 12:57:22AM -0600, J Raynor wrote:
> I’ve attached a patch that allows you to set the foreground and
> background color for a pane. The way it works is that, when tmux
> writes to the screen, if it would have written with the terminal’s
> default color, but you’ve set the pa
Am 11.02.2015 um 07:57 schrieb J Raynor:
> Also, when you set the background color with this patch,
> it changes the background for the whole pane, and not
> just for the parts of the pane that have text on them
This seems not to be true when using colors like #c0c0c0
(I tested with latest tmux
On Wed, Feb 11, 2015 at 12:57:22AM -0600, J Raynor wrote:
> I’ve attached a patch that allows you to set the foreground and
> background color for a pane. The way it works is that, when tmux
> writes to the screen, if it would have written with the terminal’s
> default color, but you’ve set the pa
40 matches
Mail list logo
