/join -h switch
/part -h switch
The usefulness of these switches partly depends on other behavior changes suggested for the [recent] list and [channels] favorites list as suggested separately and also described below.
--
/join -h #channel would allow Joining a channel without adding the channel to the [recent] history or moving it to the top of the [recent] list if it's already there.
/part -h #channel would Part the channel and then remove it from the [recent] history list. If the suggestion of being able to edit the [recent] list is granted, then /part -h could also be scripted as a channel-menu popup, and a limited amount of the /join -h behavior could be scripted, except for a race condition between autojoin adding things to the list that /join -h was trying to prevent. An optional behavior for /part -h could be to remove a #channelname from [recent] history even if you're not in it.
These would also work more effectively if the other suggestion post goes into effect - that adding/updating the [recent] list not be done when the join is caused by autojoining from Favorites list, or from "rejoin on connect", or "rejoin when kicked", in order to expand the usefulness of the [recent] list without expanding it.
--
From observation, it looks like the [recent] list works by adding/moving each channel join to the top of the list each time the channel is joined, and it limits each network to having max 20 spots on the list. If there's a combined max total for the entire list, I've not encountered it yet.
So the only time something gets dropped from history is when there's already 20 spots taken by that same network when you join a channel not already in history, which makes the lowest channel for that network get dropped, not necessarily something near the last item in the entire list.
This also means that if you join some network and you then join a channel there, but then never visit that network again, it doesn't look like there's a way for a network having gained N channels on the [recent] list to ever have that count decreased without zapping the entire list from /tools/favorites/history/clear
--
Joins added to the [recent] list or bumped to the top of the list include those generated by being autojoined from the favorites list, plus those generated by tools/options/irc/ "rejoin on connect" in combination with "keep channels open on disconnect", and those generated by "rejoin when kicked".
It is useful to add to the [recent] list for joins due to checking the box for "autojoin when invited", but I'm not so sure if there's a need to add/bump-up channels in the [recent] list if the join is caused by the above 3 situations.
Most of the usefulness of the channel history would be for channels you manually joined or from "auto join on invite".
If the user wanted to find channel history for the channels in their autojoin list, they could be found in the favorites manager from where they autojoined them. If the channel is listed in Favorites without having 'autojoin' checked, then yes it's fine to add it to the [recent] list.
If the join is happening due to the window being kept open during disconnect/reconnect it shouldn't need to be updated/bumped-up since it's not really a manual join.
--
A example situation where the current behavior fails:
Assume someone always autojoins 21 channels on a network. This fills up that network's quota of 20 on the [recent] list, and the first of the autojoin channels get pushed out, and no manual joins ever survive the next reconnect to that network.
If they autojoin 15 channels, the top 15 spot get churned each time they reconnect, and there's only 5 spots left for everything else.
If they're in 20 channels and have both boxes checked 'rejoin on connect' and 'keep channels open' in Options/IRC - if they then manually join a 21st channel which adds it to the top of their [recent] list and then /part it, the next time they reconnect to the network, that 21st channel gets pushed off the [recent] list by the 20 channels they're already inside that get rejoined on connect simply because the #window was open - even if the Favorites list doesn't have the autojoin box enabled.
It seems more useful for the [recent] list to not be updated due to something that rejoins a #window that's already open.
If the favorites-autojoins and rejoin-on-connect/kick stopped being added to history, that avoid the autojoins filling up that network's quota of 20, which makes the [recent] list more useful without enlarging the network quota based on how many autojoins it has.
--
If the Favorites List and "keep channels open" continued the existing behavior of adding/updating the [recent] list, "join -h" would allow several workarounds which could produce the same effect.
One workaround would be for someone to script their own autojoin script that uses join -h to keep the autojoins from filling up the [recent] list.
The other workaround would be to continue using the favorites list, but uncheck the manager's main window box "enable join on connect". They could then have their autojoin script parse the favorites list near ON CONNECT looking for channels at the current network who have the 'join on connect' box, and the script could then use /join -h against them all.
If the "rejoin on connect" option continued to bump channels to the top of the list when they rejoined a kept-open channel window, both workarounds would also need to uncheck the 'rejoin on connect' box while continuing to have "keep channels open" checked, and then during ON CONNECT have their script look for open #windows needing to be rejoined with /join -h
