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
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 pane’s default color option, then
it’ll use that color instead. Doi
41 matches
Mail list logo
