Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

irc.look.pv_buffer=merge_all sometimes fails #216

Open
oakkitten opened this Issue Sep 25, 2014 · 15 comments

Comments

Projects
None yet
3 participants
@oakkitten
Copy link

oakkitten commented Sep 25, 2014

at times opening a new private buffer when i have another open private buffer doesn't make them merged. often the new buffer will shift the old buffer down and take its place (i guess it's getting its position from /layout store).

i'm pretty sure the problem's been here since 0.x. perhaps related to #215?

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Sep 26, 2014

The irc options for buffer positions are incompatible with layout, you should use either only layout, or irc options without a layout stored.
This is not a bug for me.

@oakkitten

This comment has been minimized.

Copy link
Author

oakkitten commented Sep 26, 2014

what are these "irc options for buffer positions"?

most of the time these options work just fine together.

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Sep 26, 2014

I meant these options:

irc.look.new_channel_position
irc.look.new_pv_position
irc.look.pv_buffer
irc.look.server_buffer

They are in most cases incompatible with a layout, because the position in layout and chose by irc plugin can be different.

@oakkitten

This comment has been minimized.

Copy link
Author

oakkitten commented Sep 26, 2014

how about making irc options have higher precedence?
like, if irc.look.new_channel_position is anything other than none, then obey it, but if it's none, do whatever layout suggests. same for independent value of pv_buffer/server_buffer

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Sep 26, 2014

Currently, the layout has higher priority. So if you use a layout, the irc options are ignored.

@oakkitten

This comment has been minimized.

Copy link
Author

oakkitten commented Sep 26, 2014

i see. then, i suggest it reversed.
either that or the fact should present in help (hopefully clearly enough)

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Sep 27, 2014

But it does not make sense to force a buffer move after the layout has been applied. The goal of layout is to save the number for a buffer, so that you are sure a given buffer will always have the same number. Allowing irc plugin (or anything else) to move the buffer after layout will break layout.
Or maybe you would want to save only some buffers in layout and not all?
Or another solution, just don't use layout at all if you don't want to save buffer numbers.

@oakkitten

This comment has been minimized.

Copy link
Author

oakkitten commented Sep 27, 2014

uh. that's why i'm suggesting the thing reversed?
don't move buffer after the layout has been applied, move it before you attempt to use layout.
logic goes like this

  • opened new private buffer
  • is irc.look.pv_buffer merge_all?
    • no, it's independent. well then let's look at irc.look.new_pv_position
      • it's none. so. options don't give us any directons. use layout
      • it's next. place next
    • yes, it's merge_all. do we have another private buffer open?
      • no. again, check out irc.look.new_pv_position
        • none. use layout and merge
        • near_server. find the last window of server x
          • found? place next and merge
          • not found? use layout and merge
      • yes. merge

by use layout i understand retreive number from layout or, if not present, put last
want to only use layout? set these setting to none/independent

currently, i can end up having TWO buffers with merged private buffers. it might seem logical from the perspective of developer, but from user's perspective the options are simply broken.

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Sep 27, 2014

The problem is that layout is managed by core and not irc plugin at all.
So currently when irc opens a buffer (with weechat_buffer_new), the layout is used immediately, even before irc can do things on buffer (like change the name/properties, and move/merge the buffer).

The only think I could do is to completely disable the layout when irc opens a buffer, if some irc options are affecting the position of this buffer (merged, or position).

@flashcode flashcode added enhancement and removed bug labels Sep 27, 2014

@oakkitten

This comment has been minimized.

Copy link
Author

oakkitten commented Sep 27, 2014

position = -1;
if (buffer.plugin == IRC_PLUGIN)
    position = irc_plugin.get_position(buffer);
if (postion < 0)
    position = core.layout.get_position(buffer);
if (position < 0)
    position = buffers.length + 1;

or maybe make layout aware of the "hierarchy" of buffers and move those settings away from irc plugin and into the core

@Shawn-Smith

This comment has been minimized.

Copy link
Contributor

Shawn-Smith commented Oct 8, 2014

The irc options for buffer positions are incompatible with layout, you should use either only layout, or irc options without a layout stored.

Is there a way to configure the connect-order for servers with the auto-connect option set to 'on'?

Currently I use /layout to ensure that my server buffers are in the correct order when starting Weechat, but the irc.look.* settings to order my channels.

I can effectively order the channels the way I want to by using irc.server.<server>.autojoin and having irc.look.new_channel_position set to near_server, however I didn't know the two options weren't compatible, so having an option to configure server-load-order would be needed for me to stop using /layout all together.

I'm guessing that servers are autoconnected to in the order they were added using the /server add, so a command to re-order the servers listed in the /server output would probably work.

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Oct 8, 2014

The problem with order of connection is that the autojoined channels are done after the connection and the time to connect is not the same for all servers.
So just an order of connection would work only if you have independent server buffers and irc.look.new_channel_position set to near_server.

If server buffers are merged, then the only choice would be to wait for the join of all auto-joined channels, then connect to the second server. Which is hard to do because the connection to server may fail, and then the next server would never be connected.

Or, even another solution, do a "fake" join of autojoined channels, ie just open buffers, but empty, waiting for the future join, which would auto use the buffer if it exists.

@Shawn-Smith

This comment has been minimized.

Copy link
Contributor

Shawn-Smith commented Oct 8, 2014

So just an order of connection would work only if you have independent server buffers and irc.look.new_channel_position set to near_server.

This would work for my case then. Am I right in assuming servers are connected to in the order they appear in the /server output?

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Oct 8, 2014

Yes the order displayed in /server output is the order of servers in memory, and the order in irc.conf. So I think servers are connected in this order.
Then we just need a way to reorder them (no need of extra option).

@flashcode flashcode removed the waiting info label Nov 8, 2014

@flashcode flashcode added this to the 1.1 milestone Dec 14, 2014

@flashcode flashcode self-assigned this Dec 14, 2014

@flashcode flashcode closed this in 624083f Dec 14, 2014

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Dec 14, 2014

The commit fixed one solution proposed in the latest comments, but it does not fix the initial problem, so I reopen the issue.

@flashcode flashcode reopened this Dec 14, 2014

@flashcode flashcode removed this from the 1.1 milestone Dec 21, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.