Hello Rainer,
Am 12.12.2016 um 17:26 schrieb Dr Rainer Woitok: > Wolfgang, > > On Monday, 2016-12-12 08:35:43 +0100, [email protected] wrote: > >> ... >> https://bitbucket.org/maproom/qmapshack/wiki/playground/AxAdvIndex_Test >> ... >> * The section name is not included in the link. Having this name in >> the link an awful layout comes up (everything underlined). > I see what you are referring to. However, this only happens when you > look at the file locally, and perhaps even only when you're using Fire- > fox. If you really go to the URL you've mentioned above, there's no un- > derlining at all. Obviously different browsers are using different ways to format a link. I'm using Firefox. And when I use the offline HTML variant of the manual then there is the underline problem as well as with the local MD file. > We could use a more prominent separator, even " ," rather than just "," > at each line's end would help, though not much because a comma just IS > tiny. A semicolon " ;" would be a little bit better, but really only a > little bit. I could live with " ~" or even " <>" (looks like a diamond > sign in my browser) between the clickable section names. > > If you insist in including non-clickable section names in parentheses > following the link, you could use "~" or "<>" as link text for ALL links > (the link text really doesn't matter, after all). > > But what you'll really HAVE to do is to weed out duplicate sub-indices: > > Activity > color (Assign colors to track activities), track (Assign colors to > track activities) > > Data organization > data items (Organization of QMapShack data), databases (Organization > of QMapShack data), group in database (Organization of QMapShack > data), lost & found (Organization of QMapShack data), projects > (Organization of QMapShack data), qms files (Organization of > QMapShack data), workspace (Organization of QMapShack data) At this point it is getting clear that there are different ideas about the construction of an index: Look at a computer science book with an Index. There quite often you have the following picture: There is a keyword (an important topic) and below this keyword there are several "attributes" or "details" to this keyword. This is what I'm calling "index" (keyword") and subindex ("attribute", "detail"). Next to the subindex/attribute/detail there is one or several page references where the user can find information about the (index, subindex) pair. No section header of the book is mentioned in the index and only in rare cases a section header may appear as index or subindex. Section headers can be found in the table of contents. Instead of the page number a wiki page has to use a link which points to a certain page (ore even more precisely to a "subpage" - this is not in the discussion). Thus in a book there is: Index - subindex1: 13, 27 - subindex2: 13, 48 which translates in my understanding in the Wiki to Index - subindex1.link13, subindex1.link27 subindex2.link13, subindex2.link48 Of course, the order of the entries should be the order of the (index, subindex) pairs (this is not in the discussion). There are up to now 2 discussed implementations of this structure: Index - [subindex1](link13), [subindex1](link27) (here I mean MD links, subindex1 is clickable! (Manual page)) and Index - [subindex1](link13) (link13_section_header), ... (second (..) text string outside or inside the link, playground page) I am convinced that the subindex part is a "must" (as well as the hierarchical structure of index - subindex). There are obvious disadvantages of both variants mentioned already in the previous discussions: In the first variant there is the "Routino, Routino" problem and only the link caption makes it clear that the links go to different pages/sections. The subindex appears several times after the index term. In the second variant there is the subindex1(link13),..., subindex2(link13) problem - the same section headers appear several times after the index term. It is difficult for me to get precisely your idea of the index. Can it be that you propose to have something like Index - link13, link27? Then either the subindex is lost and instead of Activity, color and Activity, track (meaning of course: color of activity, activity of a track - but this is the way an index in a book is read) there is only Activity link1, link2, link3 which I wouldn't do or the pair (Activity, color) appears (maybe with some reformulation) as index itself and then there is (Activity, color) link1, link2 (possible reformulation: Activity, color of) (Activity, track) link1, link3 (no reformulation) The last variant is technically no problem (at least in the comma-separated form "Index, subindex"). It increases simply the list of terms in the definition list used. >> ... >> * I don't succeed to insert newlines with indentation in the term > description of the defintion list. Thus, all subindex entries are in > 1 line. > > Personally, I would prefer leaving this as is. Simply let the browser > wrap long lines. But if you think otherwise, this could be of help: > > https://michelf.ca/projects/php-markdown/extra/#def-list > >> * There is still the ..., Routino (section1), Routino (section2),... >> situation. > This would be automatically solved by either of my suggestions above. > > Sincerely, > Rainer > I hope that this explanation helps to come to a clearer understanding of the mutual positions about a possible structure of the QMS index so that we can reach a common solution soon. Regards WolfgangTh ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
