jupyter/ipython-components#32

BUG: it creates a new input area on every click of the filter button:

It should prohibit tags with commas, and possibly also tags with spaces:

What is the filter supposed to do? For me, it does nothing at all.

Oooh, this is super cool! I have a few more comments...

• Suggestions seem to show up behind the text of the cell below (this only seems to happen with code cells, I think?):

• The filter also does nothing for me.
• If there are multiple cells with the same tag, the tag shows up twice in suggestions:

pinging also @juhasch, who I think will be very interested and maybe use some of these machinery in his extensions...

IMHO, the tagging where you have to type on each cell is not practical, I would have a main interface where you can edit the global list of tag, and then just a checkbox for the tag you want to add/remove. a bit like the github UI. But it's just an idea.

Wow thanks for the quick review guys. I've just pushed a fix for the tag filter and fixes for the other comments.

@minrk :

Why does this toolbar have a unique signature for register?

I changed it so it looks like the others now.

BUG: it creates a new input area on every click of the filter button:

Fixed

It should prohibit tags with commas, and possibly also tags with spaces:

Okay, I added a function that prohibits space characters and commas.

What is the filter supposed to do? For me, it does nothing at all.

It was broken after a rebase, it should be fixed now. You should be able to type a cell filtering expression. Pressing return will execute your filter. Filter expressions support and, or, not, and parenthesis. cell.cell_type is treated as a tag too, so you can also filter by cell type. i.e. not difficult and code will show code cells that don't have a difficult tag.

@jhamrick :

Suggestions seem to show up behind the text of the cell below (this only seems to happen with code cells, I think?):

Fixed

If there are multiple cells with the same tag, the tag shows up twice in suggestions:

Fixed

Temporarily broken because I rebased the components branch on top of master which has CM 4. I'll have to rebase this on top of @Carreau 's CM PR. I'll ping back when this is done.

I decided against rebasing on top of @Carreau 's CM4 PR for now, so this is no longer broken. Test away :)

@jhamrick I think you accidentally put your comment in the accompanying compents PR instead of here. I'll respond here:

After you click the filter button, it expands; if you click it again, it collapses, and then can't be expaned again.

Can you try again with the latest ( 86d4f91 ) ? I can't replicate this. Are any errors printing to the JS console?

If you start typing in the cell tags area and then click out of the area (or press tab), the tag doesn't get rendered. My expectation is that anything typed into the tags area should become a tag if focus leaves the tags area?

I'm not sure bootstrap-tags supports this, but I could probably add something so on blur the current text gets added as a tag.

Is the idea with filtering to be just visual

It was intended to be just visual, but you bring up a good point. It may make sense to modify run all so only cells that are display != 'none' get ran. @jasongrout opinion?

If the cursor is in the cell tags area and you press up/down, it does not cause the next/previous cell to be selected (which is what I would have expected). It seems the only way to get out of the tags area via the keyboard is to press "tab", which will move you into the text of the cell if it's a code cell, or to the tags area of the next cell. So if you wanted to go to a previous cell, you would have to do n tabs, escape, then n ups = 2n + 1 key presses, or use the mouse.

This is something I will add a handler for manually.

Another question: Should the filter be persist through download as? If so, it should probably be in a separate PR which would add nbconvert support for cherry picking.

@jdfreder it looks like Travis is breaking on the submodule. I think you need to push your branch in components to the ipython/ipython-components repo (don't merge, just git push ipython tagging), so that Travis can see it.

@jdfreder it looks like Travis is breaking on the submodule. I think you need to push your branch in components to the ipython/ipython-components repo (don't merge, just git push ipython tagging), so that Travis can see it.

Ah I was wondering why I say branches != 'master' in that repo, that explains why...

Oops! Sorry about that.

The error with the filtering box does still seem to occur on 86d4f91 :

From the js console, it looks like it's still throwing the same TypeError on line 206 of maintoolbar.js that I mentioned before (it's happening within the jquery merge function).

ok looking now...

@jhamrick I fixed the bug and made it so blur triggers the typed text to add a tag (this fixes the problem you mentioned regarding tab). I didn't modify the up/down behavior because it appears to be coupled with the suggestions box. I'm not sure what the correct up/down behavior should be other than how it behaves now.

I love the feature. For a widget, we used bootstrap-tagsinput rather than bootstrap-tags. We found it more flexible, it has more contributors and stars on GitHub. The main advantage was the ability to have custom complex logic for the validation of the tag, using a lookup in a dataset, or multiple datasets.

For convenience, I would find it nice if it was the one used and loaded with IPython, and you might also prefer it because of its larger adoption.

Let's look at this option

Sent from my iPhone

On Oct 21, 2014, at 6:48 AM, Sylvain Corlay notifications@github.com wrote:

I love the feature. For a widget, we used bootstrap-tagsinput rather than bootstrap-tags. We found it more flexible, it has more contributors and stars on GitHub. The main advantage was the ability to have custom complex logic for the validation of the tag, using a lookup in a dataset, or multiple datasets.

For convenience, I would find it nice if it was the one used and loaded with IPython, and you might also prefer it because of its larger adoption.

—
Reply to this email directly or view it on GitHub.

There are many different usage cases that this targets. In a sense tags are
a way of providing a entire set of commonly asked for features such as the
ability to change how a notebook looks in different contexts. I definitely
think that a tagging and filtering UI should be in ipython core.

In terms of the particular library that is used, I think that it is worth
looking at different ones.

While I agree with some of the points that @Carreau has made about the UI,
I think there are more problems with the checkbox approach:

• The amount of visual noise this approach creates is = N*M where N is the
  number of cells and M is the total number of tags on the page.
• As the number of tags in a notebook gets large, the checkbox UI becomes
  extremely painful - this is true even if individual cell only has a few
  active tags.
• The label+checkbox takes up more space than the existing tag UI
• It is really distracting to look at all of the tags on all of the cells.

On Tue, Oct 21, 2014 at 7:40 AM, Brian Granger ellisonbg@gmail.com wrote:

Let's look at this option

Sent from my iPhone

On Oct 21, 2014, at 6:48 AM, Sylvain Corlay notifications@github.com
wrote:

I love the feature. For a widget, we used bootstrap-tagsinput rather than
bootstrap-tags. We found it more flexible, it has more contributors and
stars on GitHub. The main advantage was the ability to have custom complex
logic for the validation of the tag, using a lookup in a dataset, or
multiple datasets.

For convenience, I would find it nice if it was the one used and loaded
with IPython, and you might also prefer it because of its larger adoption.

—
Reply to this email directly or view it on GitHub
#6638 (comment).

Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

I am fine with & and | being used in addition to and and or.

On Tue, Oct 21, 2014 at 10:41 AM, Brian Granger ellisonbg@gmail.com wrote:

There are many different usage cases that this targets. In a sense tags
are a way of providing a entire set of commonly asked for features such as
the ability to change how a notebook looks in different contexts. I
definitely think that a tagging and filtering UI should be in ipython core.

In terms of the particular library that is used, I think that it is worth
looking at different ones.

While I agree with some of the points that @Carreau has made about the UI,
I think there are more problems with the checkbox approach:

• The amount of visual noise this approach creates is = N*M where N is the
  number of cells and M is the total number of tags on the page.
• As the number of tags in a notebook gets large, the checkbox UI becomes
  extremely painful - this is true even if individual cell only has a few
  active tags.
• The label+checkbox takes up more space than the existing tag UI
• It is really distracting to look at all of the tags on all of the cells.

On Tue, Oct 21, 2014 at 7:40 AM, Brian Granger ellisonbg@gmail.com
wrote:

Let's look at this option

Sent from my iPhone

On Oct 21, 2014, at 6:48 AM, Sylvain Corlay notifications@github.com
wrote:

I love the feature. For a widget, we used bootstrap-tagsinput rather
than bootstrap-tags. We found it more flexible, it has more contributors
and stars on GitHub. The main advantage was the ability to have custom
complex logic for the validation of the tag, using a lookup in a dataset,
or multiple datasets.

For convenience, I would find it nice if it was the one used and loaded
with IPython, and you might also prefer it because of its larger adoption.

—
Reply to this email directly or view it on GitHub
#6638 (comment).

Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

Hey all,

I'm going to open another PR trying bootstrap-tagsinput. I'll ping back when I do so.

I don't say that checkbox is perfect, but people will be mostly adding tags and remove them occasionally.
UI is good at the opposite.

Le's imagine something more evolved, Taking john example aboveI just edited cell "A" from
code|asdf to code|asdf|has, commas, etc I'm thus likely to want o add has, commas, etc to other cell.

I propose that the UI of all the "others" cell of the notebook turn into something like the following, n which clicking on the + of the ghost has, commas, etc of the cell does actually add the tag to the cell.

These "ghost proposed tags" could be limited to the 3 last entered tags in the last minute or so.
Cause I really find typing to tag cell really annoying, especially by the fact that it's relatively difficult to do purely in keyboard and you have to reach the mouse.

@Carreau I like the ghost tags idea, I'll play around with it to see if it's easy enough to implement.

Inactive for more than a month, and we decided that for 3.0 if we do something it would be API only.
Closing.

@jasongrout @SylvainCorlay and all, I will implement this as an extension and ping back.

Drat! I was looking forward to this being something we could rely on for people to tag materials for nbviewer. Guess I'd just refer them to the extension?

👍 for porting this to Jupyter.

Any chance of reviving this PR?

Yes, this week is our dev meeting, this is one of the subject we are discussing.

Bump; it would still be great to have this ported.