[feature request] Organize pages with tags

[Jaap Karssenberg]

Bug report to track tag support in zim.

Goal is to allow a different non-hierarchical view on the data. Tags will look the same like tags used in the task manager, e.g. ”@foo” will add the tag “foo” to the text where it appears. Tags will be inline in the text, so they are included when you cut-paste a section of text to another page etc. Most functionality will be from having an alternative side pane view showing the pages sorted by tag.

[Jaap Karssenberg (jaap.karssenberg)]

Added bug #528313 as duplicate. This bug requests to have color highlighting in the side pane. Need some config to associate tags with colors.

[Fabian Stanke (fmos)]

Since this is the one main feature I would really love to see in Zim myself to make it the perfect note taking app, I'll attack this next.

[dagurasu (dagurasu15)]

Great. This idea seemed mostly DOA when asked in Bug #492486 . One point, the OP for this bug asked for non-hierachical tags. That's fine if he doesn't want to build a hierarchy of tags, but the feature would be more useful if it DID allow hierarchical tags like
[personal:finance:WAMU]

With a hierarchical side bar view. Like, wikidpad, but better (it only allows two levels).

I again repeat the request to (optionally) squeeze the white space and/or fonts too in the side panel. Especially if more things are added, like the tags, Zim just doesn't fit enough stuff over there.

Here's an idea, what if the tags are just a special type of link? LIke the user is on a page about [[travel]] and inserts a tag for [[food:mexican]]. Automatically (not like now) the page [tags:food:mexican] is created with a link in it to [[travel]]. For that matter just making all links automatically create blank pages(if not existing) half solves the problem but still requires the uncomfortable use of looking for backlinks. The only extra bit needed is that for some special links recognized as tags.. a forward link gets placed in that page and these special links are separated in the side view (under tags). These special links could be recognized by a different markup or simply by [[tags:food:mexican]], where the top level "tags" triggers the extra behavior.

[Fabian Stanke (fmos)]

@dagurasu
I don't believe a hierarchy is what you want when using tags. I would rather orientate towards the behaviour of Zotero (a Firefox plugin for bibliography management): Make the tag list filtered such that when you select a tag (or keyword for that matter), the tag list is filtered to tags that are found on pages which already contain the selected tag. This is in fact much more natural to unstructured meta-information that tags are and even embraces your use-case. Instead of browsing a tree, you filter the taglist at each level.

Of course one is always free to implement a pseudo-hierarchy by tag name convention, although I admit, this may look rather ugly.

[Jaap Karssenberg (jaap.karssenberg)]

On Mon, Aug 30, 2010 at 7:11 AM, dagurasu <email address hidden> wrote:
... 8< ...
> Here's an idea, what if the tags are just a special type of link?  LIke
> the user is on a page about [[travel]] and inserts a tag for
> [[food:mexican]].  Automatically (not like now) the page
> [tags:food:mexican] is created with a link in it to [[travel]].   For
> that matter just making all links automatically create blank pages(if
> not existing) half solves the problem but still requires the
> uncomfortable use of looking for backlinks.  The only extra bit needed
> is that for some special links recognized as tags.. a forward link gets
> placed in that page and these special links are separated in the side
> view (under tags).  These special links could  be recognized by a
> different markup or simply by [[tags:food:mexican]], where the top level
> "tags" triggers the extra behavior.

The main reason that tags are not yet implemented is that I really
wanted to implement them as special links. However I found there are a
number of subtleties where tags differ from links, which made it hard
to do. And hard things easily get postponed. My current view is that
tags should be more like a property than like a link, they codify
keywords to index the pages, not necessarily relations between pages.
For example when moving a page links need to be updated but tags don't
change. Instead of indexing tags in the same table as links we better
put them in a separate index table. This makes things much easier.

Another objection against using links for tags is that you would have
the discipline to start every tag-link with ":tags:". Notice the
starting ":" which is necessary because you might have a local page
called "tags" as well. This makes is bothersome to type tags like
this. I would prefer a wiki syntax like "@foo" for the tag "foo".
(Some people seem to prefer "#foo", but this may conflict with a
future use of link anchors.)

Regards,

Jaap

[dagurasu (dagurasu15)]

Ok I see Moser's point about crss searching meta-data. I tend to like to build some fixed structture and that's why I want tags in a wiki,.. which isn't naturally structured. But this might about do the same thing just without the visual tree apeal that helps organize my brain. Also as you click more tags the choices should narrow down to only relevant remaining ones. I have some concern that the top level(containing everything) just gets too big though. Too many first choices to visualy scan. You then always have to access your brain first and either type or scan a long list. But everyone works diferently.

@jaap yes I thought about conflict with a local tags page and tedium of typing even just tag: let alone :tags:. Yes it's best if using links if the page is named cleverly. Of course it's possible to have @foo alias to :tags:foo with write permissions and the auto linking behavior and still re-use your link structure.

Yes I see the point that moving a page changes links and that's messier than needed for tags, OTH, you already have all the coding for changing back-links when pages moves don't you? So ugly or not... it's already done. Just seemed like it might be a simple way to shoe-horn it in with minimal effort.

Anyway, you're the coder on this one and obviously I can't fully appreciate all the subtleties without digging through the code myslef. Beggers can't be choosers or back-seat drivers. I'm glad it's gaining interest though.

[dagurasu (dagurasu15)]

BTW in principle I think you can have all that. You do the shoe horn, have @ alias to :tags:, use the existing viewer. Then later you write a new viewer, possibly even eliminating the actual wiki pages. You can also have the hierarchy allowed by the link system but still allow meta cross searching on anything between to colons in your future super-duper viewer system. The markup of the tags themselves never needs to change, so you can re-write viewers anytime you want. Just a thought.

[dagurasu (dagurasu15)]

One last point.. in wikidpad.. when you click a tag it takes you not just to the page, but to right part of the page. That's nice. It seems like that doesn't fit in the standard link viewer idea though.

[Fabian Stanke (fmos)]

On 09/01/2010 06:55 AM, dagurasu wrote:
> Also as you click more tags the choices should narrow down to only
> relevant remaining ones.

Absolutely!

> I have some concern that the top level(containing everything) just
> gets too big though. Too many first choices to visualy scan.

I'm aware of this problem, but we could partly eliminate it by allowing
to (optionally) sort the tags by frequency. This should list "root" tags
first if the "tree" is more or less balanced.

Also it is vaguely planned to combine the current tree-view behavior
with tag filtering, e.g. by showing sub-pages of tagged pages. It might
be useful to do the opposite direction also, i.e. filtering tags to the
sub-tree when a selection in the standard tree-view is made. That would
also help fixing the above problem.

[Fabian Stanke (fmos)]

After a longer period of infrequent commits from my side, the tagging now meets the minimum requirements as stated on the Wiki. I plan to continue improving the source, but also try and add a few optional features.

[Jaap Karssenberg (jaap.karssenberg)]

On Thu, Dec 9, 2010 at 10:08 AM, Fabian Moser <email address hidden> wrote:
> After a longer period of infrequent commits from my side, the tagging
> now meets the minimum requirements as stated on the Wiki. I plan to
> continue improving the source, but also try and add a few optional
> features.

Probably good to put up a package for this branch on the website and
announce to the mailing list. THat way you get feedback from early
adopters and testers.

-- Jaap

[Jaap Karssenberg (jaap.karssenberg)]

@Fabian: latest revision of trunk now has a standardized way to add
widgets to the sidepane. You can e.g. use
"ui.mainwindow.add_tab(title, widget, LEFT_PANE)". When merging from
trunk you will need to update to this interface.

[Fabian Stanke (fmos)]

@Jaap: Thanks for the notification! I'll update my branch ASAP. I'll also look into the preview-packaging you proposed.

[Fabian Stanke (fmos)]

@Jaap: I've merged the main branch and updated the widget registration according to your suggestion. How (i.e. in which form) should I provide a "package" for the website. Easiest would be re-packaging a special source package e.g. "zim-0.49-tags0.tar.gz" which I could send you. I didn't manage to build a .deb on Fedora, but I don't think anyone would want to install this into system locations anyway. What do you think?

[Jaap Karssenberg (jaap.karssenberg)]

On Sat, Jan 8, 2011 at 8:11 PM, Fabian Moser <email address hidden> wrote:
> @Jaap: I've merged the main branch and updated the widget registration
> according to your suggestion. How (i.e. in which form) should I provide
> a "package" for the website. Easiest would be re-packaging a special
> source package e.g. "zim-0.49-tags0.tar.gz" which I could send you. I
> didn't manage to build a .deb on Fedora, but I don't think anyone would
> want to install this into system locations anyway. What do you think?

Sounds good. I you send me the package I will upload it and you can do the
mailing list announcement.

-- Jaap

[Anton Zayats (anton-zayats)]

Hi Fabian, Jaap,

What's the status of this? I'm happy to try this and report on bugs/usability.

[Fabian Stanke (fmos)]

Hi Anton,

Thanks for the poll ;) I've recently implemented a tag cloud widget. I'll make another snapshot testing/tryout "release" today after some more testing from my side. Also I plan to create a very brief screencast to get feedback also from non-experimenters.

[Fabian Stanke (fmos)]

I have put together an updated preview "zim-0.50-tags1" which can be downloaded at http://www.zim-wiki.org/wiki/doku.php?id=supporting_tags
As you can see on the TODO list (same page), it includes almost all targeted features.
I would be very glad to receive feedback on the user interface and of course bug reports, if you locate one of these nasty beasts.

[Anton Zayats (anton-zayats)]

Hi Fabian,

I've spend some time playing with it. Honestly, this makes Zim twice more lovely for tag junkies. Thanks for a great job!
These are my observations:

Tags view:
1) If the page and a subpage has the same tag, the subpage will appear twice under the tag. Confusing, but not critical.
2) Drag and drop in the tags tab doesn't work as advertised. With dragging and dropping I did the structure that doesn't not exist in index, tags are not added anywhere on the page. Personally, I don't think that drag'n'drop is needed here.

Tag Cloud: Fantastic! I just love tag buttons you can switch on and off and filtering is instant. I don't have much notes, although.
Two wishes here:
1) Can it be a plain list of pages, not a tree? To my taste it will make this view simpler, cleaner and more efficient
2) If no tag is selected I expect to see no pages. But this is a matter of taste.
A bug: I see not only the trees, but all the pages as well (I think this is the same as in tags view). Especially confusing when no tag is selected.

General: may be use other color to distinguish links from tags (when I see blue text in zim I want to click on it). But this is not important at all.
Also I noticed a kind of "drag'n'drop" event in a tree (Index tab) while writing some text on a page. I observed this a few times, but not sure what triggered this drag'n'drop.

[Anton Zayats (anton-zayats)]

A few screens to describe my observations.

[Anton Zayats (anton-zayats)]

the second one - the page is under tag, but this tag doesn't exist on the page. This was done via drag'n'drop of the page.

[Fabian Stanke (fmos)]

Hi Anton,

Am 03.03.2011 22:09, schrieb Anton Zayats:
> I've spend some time playing with it.

Thanks for the "in-depth" review/testing/feedback!

> Tags view: 1) If the page and a subpage has the same tag, the
> subpage will appear twice under the tag. Confusing, but not
> critical.

This, as most other things you mention, is intended behaviour I'm
afraid. Note the phrase "pages can appear multiple times in the tree" in
the TODO list on the Wiki page. Of course the intention is IMO nowhere
near frozen and we can discuss and change it. (see bottom)

> 2) Drag and drop in the tags tab doesn't work as advertised. With
> dragging and dropping I did the structure that doesn't not exist in
> index, tags are not added anywhere on the page. Personally, I don't
> think that drag'n'drop is needed here.

Thank you for pointing that out. Drag and drop behaviour is somehow
underspecified on the wiki page IMO, but I had a discussion with Jaap on
the topic earlier and will go over that again and update the wiki. Then
I will be able to correct either the implementation or the "advertising".

> Tag Cloud: Fantastic! I just love tag buttons you can switch on and
> off and filtering is instant.

Me too! ;)

> Two wishes here: 1) Can it be a plain list of pages, not a tree? To
> my taste it will make this view simpler, cleaner and more efficient

As long as you don't expand the nodes, a tree is a list. Also I think it
can be useful that way, because if you use subpages, they will be
somehow related to the parent and thus kind-of inherit the tags from it
as well.

> 2) If no tag is selected I expect to see no pages. But this is a
> matter of taste.

If you look at it from the filtering standpoint, you expect:
no filter - all pages. I don't see how showing nothing would improve
usability here.

> A bug: I see not only the trees, but all the pages
> as well (I think this is the same as in tags view). Especially
> confusing when no tag is selected.

As discussed above, this is not really a bug but intentional. (see bottom)

> General: may be use other color to distinguish links from tags (when
> I see blue text in zim I want to click on it). But this is not
> important at all.

I think, that's a good idea. I will do that.

> Also I noticed a kind of "drag'n'drop" event in a
> tree (Index tab) while writing some text on a page. I observed this
> a few times, but not sure what triggered this drag'n'drop.

That sounds like the only real bug here. Do you have details (running
zim --no-daemon -D in a console)

On the matter of what to show, I see three options:

a) The current state i.e. list all pages and include their sub-pages
below them. If parent and child contain the same tag, the child is
listed twice, once below the parent and once at the top level.

b) List only i.e. no sub-pages

c) Tree only (this applies only to the cloud): Show the full tree if no
filter is applied and hide leaves that don't contain the filter tags as
soon as filtering is applied. I.e. hiding sub-pages of tagged pages, but
showing their parents, even if they don't contain the tags.

IMO, option b) is just a matter of a) after pressing "\" to collapse all
and option c) is counter-int...

[Jaap Karssenberg (jaap.karssenberg)]

On Fri, Mar 4, 2011 at 9:48 AM, Fabian Moser <email address hidden>wrote:

> On the matter of what to show, I see three options:
>
> a) The current state i.e. list all pages and include their sub-pages
> below them. If parent and child contain the same tag, the child is
> listed twice, once below the parent and once at the top level.
>
> b) List only i.e. no sub-pages
>
> c) Tree only (this applies only to the cloud): Show the full tree if no
> filter is applied and hide leaves that don't contain the filter tags as
> soon as filtering is applied. I.e. hiding sub-pages of tagged pages, but
> showing their parents, even if they don't contain the tags.
>
> IMO, option b) is just a matter of a) after pressing "\" to collapse all
> and option c) is counter-intuitive, since I'm usually more interested in
> sub-pages of a tagged page than in the parent (I often re-factor too
> large pages into sup-pages and believe that a common behaviour).
>
> So my vote unsurprisingly goes to a), but if you disagree, speak up and
> convince me :)
>

Alternative would be to create a preference for this kind of thing. In
general I try to avoi putting in to much preferences, but they are useful if
there are different usage patterns of.

-- Jaap

[Fabian Stanke (fmos)]

Am 04.03.2011 10:26, schrieb Jaap Karssenberg:
> Alternative would be to create a preference for this kind of thing. In
> general I try to avoi putting in to much preferences, but they are useful if
> there are different usage patterns of.

True. Since that would be part of the Tag plugins which have no
preferences as of yet anyway, it shouldn't be too confusing.
The Tag tree plugin could provide options a) and b) only.

Cheers,
Fabian

[Jaap Karssenberg (jaap.karssenberg)]

On Fri, Mar 4, 2011 at 10:44 AM, Fabian Moser <email address hidden>wrote:

> Am 04.03.2011 10:26, schrieb Jaap Karssenberg:
> > Alternative would be to create a preference for this kind of thing. In
> > general I try to avoi putting in to much preferences, but they are useful
> if
> > there are different usage patterns of.
>
> True. Since that would be part of the Tag plugins which have no
> preferences as of yet anyway, it shouldn't be too confusing.
> The Tag tree plugin could provide options a) and b) only.
>

After playing around I find the tag cloud with buttons really genius. But I
have many redundant entries in the tree. E.g. my calendar namespace has many
pages called "01", "02", "03" etc. Now in the tag cload pane without any
selection the tree is basically unusable due to a huge list of these
numbered pages.

May I suggest a view where without any selection in the tag cloud the normal
page index tree is shown. However when selecting some tag the tree is shown
with the pages containing this tag as top nodes (still including all
children).

If children that contain the same tag should be shown double as a top node
can be a matter of discussion.

By having the default go back to the normal index I can really imagine the
tag cloud pane replace the index pane as default view for me.

ANother suggestion is to combine the "tag tree" and "tag cloud" plugins in a
single plugin, with preference setting to show the tag tree, the tag cloud
or both. But feel free to decide differently.

-- Jaap

[Jaap Karssenberg (jaap.karssenberg)]

Maybe going even further the tags tree and tag cloud views could be
combined. Essentially show a pane with the tag cloud on the top (optional
with preference) and tree below. Default the tree shows full index and
behaves like tree in current tag cloud pane. However add a toggle to "sort
be tag" which switches the tree view to the tree view that is now in the tag
tree pane. This toggle could be a checkbox at the bottom of the pane or in
the context menu of the treeview.

This would allow using both methods to find pages by tag in union. So make a
selection in the tag cloud and then get a tree with remaining tags as top
levels.

Tag labels in pages can be made clickable (like links). Clicking a tag would
toggle the corresponding button in the tag cloud (if the tag cloud is shown)
and result in a selection for that tag.

Just my brainstorm ideas. Must say I'm really impressed by what is in
already :)

[Fabian Stanke (fmos)]

Am 05.03.2011 11:40, schrieb Jaap Karssenberg:
> After playing around I find the tag cloud with buttons really
> genius.

Thanks for your feedback and thanks for the compliment, but although I
don't know if they themselves copied it from somewhere, the credits for
"geniusness" really go to the Zotero [1] developers. Of course, the
implementation wasn't that trivial either ;) There is still the
filter-while-type interaction with the cloud missing, which is a
must-have for huge clouds.

> But I have many redundant entries in the tree. E.g. my calendar
> namespace has many pages called "01", "02", "03" etc. Now in the tag
> cload pane without any selection the tree is basically unusable due
> to a huge list of these numbered pages.
>
> May I suggest a view where without any selection in the tag cloud the
> normal page index tree is shown. However when selecting some tag the
> tree is shown with the pages containing this tag as top nodes (still
> including all children).

I agree, that is good idea.

> If children that contain the same tag should be shown double as a top
> node can be a matter of discussion.

(or configuration)

> By having the default go back to the normal index I can really
> imagine the tag cloud pane replace the index pane as default view for
> me.

True, no more switching tabs, cool!

> ANother suggestion is to combine the "tag tree" and "tag cloud"
> plugins in a single plugin, with preference setting to show the tag
> tree, the tag cloud or both. But feel free to decide differently.

(see answer to your next e-mail)

Cheers,
Fabian

[1] http://www.zotero.org/

[Fabian Stanke (fmos)]

Am 05.03.2011 11:51, schrieb Jaap Karssenberg:
> Maybe going even further the tags tree and tag cloud views could be
> combined. Essentially show a pane with the tag cloud on the top (optional
> with preference) and tree below. Default the tree shows full index and
> behaves like tree in current tag cloud pane. However add a toggle to "sort
> be tag" which switches the tree view to the tree view that is now in the tag
> tree pane. This toggle could be a checkbox at the bottom of the pane or in
> the context menu of the treeview.
>
> This would allow using both methods to find pages by tag in union. So make a
> selection in the tag cloud and then get a tree with remaining tags as top
> levels.

I like your ideas! I'd rather go for the context menu, since I would
like to avoid more GUI elements and most of the time you will be using
either one of the two modes I believe.

> Tag labels in pages can be made clickable (like links). Clicking a tag would
> toggle the corresponding button in the tag cloud (if the tag cloud is shown)
> and result in a selection for that tag.

This is also a good idea. However I would like to precise that
_toggling_ a tag would be great, however _untoggling_ wouldn't be such a
good idea I think. Just a feeling though and I can't justify before
trying out.

> Just my brainstorm ideas. Must say I'm really impressed by what is in
> already :)

I'm glad you like it. With all the new ideas, plenty of room for
improvement and no real bugs up to know as far as I can see. Nice!

Cheers,
Fabian

[joede (joerg-desch)]

I haven't had the spare time to try this release, so I'm late with my question. Sorry.

I've downloaded the archive above and tried to install it with the following call:
$ mkdir translations
$ python setup.py install --prefix=/home/jd/local

The given prefix is the path where I install all my "test installations". Nevertheless, the regular zim package is still installed on my system!

Starting /home/jd/local/bin/zim works fine, but I can't see any difference to the regular package. Any hint?

So I started to install it on an older laptop I've prepared with a Ubuntu Karmic release. Here it comes up with an error. zim couldn't fint the module zim.

I' no python developer, so could you give me a hint please? Thanks.

[Jaap Karssenberg (jaap.karssenberg)]

On Mon, Mar 7, 2011 at 5:03 PM, joede <email address hidden> wrote:
... 8< ...

> Starting /home/jd/local/bin/zim works fine, but I can't see any
> difference to the regular package. Any hint?
>

There should be two new plugins, one for the tag list and one for the tag
cloud. You need to enable these before you see much change.

If you don't see the plugins, the /home/jd/local/bin/zim script is just
using the libraries of the regular version and failed to find the new ones,
see below.

So I started to install it on an older laptop I've prepared with a
> Ubuntu Karmic release. Here it comes up with an error. zim couldn't fint
> the module zim.
>

This means the library paths to your installation folder are not set, so the
script doesn't know where to find the library. You can fix this by setting
the PYTHONPATH environment variable poiting to the location where the
libraries ended up (so parent folder of zim/__init__.py).

Alternatively you can skip installing zim and run directly from the source
folder. This is by far the easiest for testing snapshots.

REgards,

Jaap

[Jaap Karssenberg (jaap.karssenberg)]

Patched merged in trunk

[Jaap Karssenberg (jaap.karssenberg)]

Released in zim 0.51

[avlas (avlas)]

Hi,

I discovered Zim very recently and like it so far! I use it to keep track of my notes related to research. One very useful think to this regards is tags, and I read above they try to be as in Zotero, something like keywords. One thing missing though (or perhaps it's me that I didn't find the way to do it yet) is to have tags that cover more than a single word. In Zotero when you introduce a new tag, you can write in it whatever you like, but in Zim it seems you have to introduce them with "@", which is fast and efficient, but the tag finishes when a whitespace is found.

Can somebody tell me if there is a way to have a tag like "my tag", or could you please consider to implement it otherwise?

Thanks

[Jaap Karssenberg (jaap.karssenberg)]

@avlas: in the future please ask general questions in the "questions"
section, or on the mailing list

To answer your question: tags in zim have to be a single word, but can
contain e.g. "_" to seperate parts. I feel tags by definition should be
short, so don't see support for tags containing whitespace as a must have.

On Sat, Jun 22, 2013 at 10:58 PM, avlas <email address hidden> wrote:

> Hi,
>
> I discovered Zim very recently and like it so far! I use it to keep
> track of my notes related to research. One very useful think to this
> regards is tags, and I read above they try to be as in Zotero, something
> like keywords. One thing missing though (or perhaps it's me that I
> didn't find the way to do it yet) is to have tags that cover more than a
> single word. In Zotero when you introduce a new tag, you can write in it
> whatever you like, but in Zim it seems you have to introduce them with
> "@", which is fast and efficient, but the tag finishes when a whitespace
> is found.
>
> Can somebody tell me if there is a way to have a tag like "my tag", or
> could you please consider to implement it otherwise?
>
> Thanks
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/575118
>
> Title:
> [feature request] Organize pages with tags
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/zim/+bug/575118/+subscriptions
>

[avlas (avlas)]

Ok, sorry for not opening a question.

I disagree, at least in research: keywords are most of the times composed of about two words or even more words (although you're right, the aim is to be as short as it can be). You can check usual keywords in scientific papers to see that, and in fact Zotero is taking this into account. One instance "selective attention": because "attention" is so broad concept that having a tag for it wouldn't make much sense. On the other hand, "selective attention", is a clearly defined and much more specific concept.

My request would be to have tags for keyword concepts instead of single words, as they frequently include more than a single word. But actually a person not interested in this could continue using single words for tags.

Am I the only one seeing how useful this would be?

Sorry again for the question thing

[Jaap Karssenberg (jaap.karssenberg)]

In that case you can still use "@selective_attention" which would make zim
consider it a single term.

For further discussion please follow up on mailing list, there also may be
more users there that have an opinion on this.

-- Jaap

On Mon, Jun 24, 2013 at 2:54 PM, avlas <email address hidden> wrote:

> Ok, sorry for not opening a question.
>
> I disagree, at least in research: keywords are most of the times
> composed of about two words or even more words (although you're right,
> the aim is to be as short as it can be). You can check usual keywords in
> scientific papers to see that, and in fact Zotero is taking this into
> account. One instance "selective attention": because "attention" is so
> broad concept that having a tag for it wouldn't make much sense. On the
> other hand, "selective attention", is a clearly defined and much more
> specific concept.
>
> My request would be to have tags for keyword concepts instead of single
> words, as they frequently include more than a single word. But actually
> a person not interested in this could continue using single words for
> tags.
>
> Am I the only one seeing how useful this would be?
>
> Sorry again for the question thing
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/575118
>
> Title:
> [feature request] Organize pages with tags
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/zim/+bug/575118/+subscriptions
>