Multiple columns for quick tags

[HydraheadHunter]

I like quick tags, but I don't like having so many bundles that I have to scroll through my bundles to find the specific tag I need, and I find I only really use ever the first four tag bundles on the list because scrolling down is effort and I've the object permanance of a rabid goldfish. Reducing the amount of scrolling necessary to use the feature extensively would make the feature much more usable to me such that I could add more tag bundles than I'm currently using because as stands I know I won't use most of the bundles I create.

My suggestion then, is to add some options to the quick tags settings that can make arrange it more like a table or soundboard that you look at rather than a list you scroll through.

Three simple options that'd achieve this would be:

1. [Force no-scroll] a boolean which when activated says "no matter how many options are in a column make the menu as long as necessary to show them without a scroll bar."
2. [Number of column] an int which determines how many columns there are and then distributes the list as evenly as possible among N columns
3. [Maximum column length] an int which caps the number of bundles in a column. When all columns have M items in them, a new column is started.

The more granular implimentation I'd love to see in a perfect world would be individual bundle address

[Bundle address] is a string formated "X,Y" given to each bundle in addition to its name and tags; the system takes bundles and puts them at that address in the table. If multiple bundles have the same address, that conflict is resolved by putting them into a secondary dropdown menu. Bundle Address could potentially be implimented with "X,Y,Z,W..." formating such that the drop-down menus are themselves tables.

I'd be happy with either as I think either implimentation of columns would make the feature more user-friendly for me to use in mind of having just a lot of bundles.

[marcustyphoon]

Somewhat related: #867; #792. This is a novel way to solve the "too many tags" problem, though! Personal thoughts:

[Force no-scroll] a boolean which when activated says "no matter how many options are in a column make the menu as long as necessary to show them without a scroll bar."

I would just make the increased height option instead of this; the user can set it to 1000 or whatever and effectively get this functionality.

[Number of column] an int which determines how many columns there are and then distributes the list as evenly as possible among N columns
[Maximum column length] an int which caps the number of bundles in a column. When all columns have M items in them, a new column is started.

Of these two I would probably lean toward "number of columns," I think.

[Bundle address] is a string formated "X,Y" given to each bundle in addition to its name and tags; the system takes bundles and puts them at that address in the table. If multiple bundles have the same address, that conflict is resolved by putting them into a secondary dropdown menu. Bundle Address could potentially be implimented with "X,Y,Z,W..." formating such that the drop-down menus are themselves tables.

If we were going to this level of granularity (unlikely, I think, but fun), I would probably search for something that's more user friendly but even more complicated to code. For example, it's possible (albeit pretty convoluted as far as I know) to code drag and drop rearrange in javascript.

Ultimately I think something like folders would be simpler to understand and used more, but now it sounds kind of neat to attempt :D

[HydraheadHunter]

I played around in the code a bit (struggling the entire time because no offense to everyone whose worked on this and is obviously much ... more well practiced than me about it, reading other people's code is hell no matter how good it is) and did manage to find the area in the css to change how many tags it can show at once, so that's cranked all the way up to a billion (hyperbole) on my personal version of the extension, so the no scroll boolean isn't a needed thing and just a part of the thought process.

I too lean towards preferring number of columns, although it has a problem where you may find you need to adjust it more often than maximum column length which is a much more set it and forget style of variable.

I do see you're point about user friendliness wit going towards granularity; if you're gonna allow that much user control, might as well put the effort into making it as easy for the user to play around within the rules as possible; but, as a wierdo who liked linear algebra, I'm much more at home with lists of numbers that when parsed make the code do the thing.

I'd love folders too except they run into the object permanence of a rabid goldfish problem where if I can't see what's inside them i won't remember to use what's inside them. The dropdown menu to solve address conflicts also has this problem, but it's something I suggest more as a solution to the inevitably of imperfect user input, since nothing survives contact with the userbase if the answer is "just don't do that," rather than as a featured part of the implementation that I'd personally be likely to use.

[HydraheadHunter]

I do want to clarify though, upon having played around in the code and realizing the distinction exists, I meant this to be about the quick tags as they appear in the quick reblog menu specifically, though applying it to the quick tags menus would be nice too.