Hi
Applied now, although I don't see a need for a default key binding to
paste a named buffer so I left that out - it's easy for people to bind
it themselves. Also I'm iffy on whether we really need a key to append
to a buffer in copy mode. If we do I think I'd rather it was a separate
prompt (so
yes you're right, changed that too
On Fri, May 09, 2014 at 10:09:42AM -0500, J Raynor wrote:
> > Only need to change paste_cmp_times, paste_(get|free)_top and remove the
> > RB_INSERT and REMOVE from paste_rename:
>
> I think paste_set needs to be modified as well. When it replaces a
> buffer,
> Only need to change paste_cmp_times, paste_(get|free)_top and remove the
> RB_INSERT and REMOVE from paste_rename:
I think paste_set needs to be modified as well. When it replaces a
buffer, it frees the old one and mallocs a new one. The new one needs
to have pb->order set to paste_next_order+
Hi
Yes, I think making it always ordered by time with both automatically
and explicitly named buffers mixed together will be fine - if anyone
comes up with a serious need to make delete-buffer skip !automatic then
we can consider a flag at that point. So effectively it's back to a
stack again :-).
Do you mean order everything by time when displaying the buffers in
buffer-list and buffer-choose? Or do you mean order everything by
time in all cases, so that paste_get_top refers to the most recent
buffer, even if it is !automatic?
If it's the former, that sounds fine. If it's the latter, tha
I've attached a new patch which drops the buffer_stickiness format and
includes changes to the man page.
On Thu, May 1, 2014 at 5:33 PM, Nicholas Marriott
wrote:
> Hi
>
> This looks good thanks, but I'd lose the buffer_stickiness format and just add
> buffer_name.
>
> (Even if we want it flag fo
Hi
This looks good thanks, but I'd lose the buffer_stickiness format and just add
buffer_name.
(Even if we want it flag formats should be 0 or 1 so that the #{?,}
conditional works.)
Also this is going to need some manpage changes.
On Thu, Apr 24, 2014 at 07:37:19PM -0500, J Raynor wrote:
> I
I've attached a new patch. It's the patch you just recently sent with
the following modifications:
1. buffer-limit isn't passed to paste_set. paste_add is the only
paste function that needs it now, and it'll look it up itself.
2. The length and character restrictions for buffer names have been
> Yes I think we could do the same with buffer-limit now it is global too.
Ok, I'll do that.
> I think let's not limit the length or charset of names for now, if someone
> sets it to something silly it'll be a display issue only and their own fault
> anyway.
Ok, I'll remove the restrictions.
>
27;ll be a display issue only and their own fault anyway.
Did you see my comments about -s and -u?
Cheers
Original message
From: J Raynor
Date: 24/04/2014 19:05 (GMT+00:00)
To: Nicholas Marriott
Cc: tmux-users@lists.sourceforge.net
Subject: Re: patch for named buffers
I ke
I kept passing in global_buffers since that's what the existing code
did, and I thought there might be a reason (planned future
functionality?), so I kept it. But it makes sense to not pass it in
if you don't expect other paste_stores. But why not do the same with
buffer-limit? paste_add can loo
Here's updated diff.
I renamed the compare funcs and make some other minor tweaks but didn't
change the sticky/unsticky bits.
Why do you limit the buffer names to 16 characters? 16 characters is too
short, but why limit them at all?
Also not certain about limiting them to printables, seems like
I've attached a new patch for named buffers. There's no longer a
paste stack. There's a name-tree which stores all the buffers, and a
time-tree which just stores unsticky buffers. The time-tree only
needs to store unsticky buffers since they're the only ones which can
be age
I'd say (2), we never want to automatically destroy buffers which the
user has explicitly named, let them do that.
On Fri, Apr 18, 2014 at 06:34:58PM -0500, J Raynor wrote:
> Your proposed implementation looks fine to me. I have a question about this:
>
> > - buffer-limit is only applied to !st
Your proposed implementation looks fine to me. I have a question about this:
> - buffer-limit is only applied to !sticky buffers
Which of these did you mean?
1. Buffer-limit limits the total number of buffers (the sum of sticky
and non-sticky), but only non-sticky buffers get aged away.
2. B
Hi
Thanks for this, but I'm not sure about the approach.
I don't like having separate named and non-named stacks, I definitely
think we only need one data structure - unnamed buffers should be the
same as named but with some automatically-generated generic name like
"buffer0101".
TBH if we have
I've attached a patch which implements named buffers.
Commands that take a buffer arg, like save-buffer and paste-buffer,
have been modified so that -b can take a number or a name. So, you
can do "setb -b myBuf someData".
buffer-limit applies to both the paste stack and the named buffers.
So if
17 matches
Mail list logo
