Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
I just noticed the following: on my system, my browser cannot find in an Lab page the strings of characters of the form “Definition ” etc. that are generated by the formal Definition-environments.
To see what I mean, go to the Sandbox and make your browser search for the string “Definition 1”. Do you land in the definition or in the theorem?
I just noticed this when somebody pointed out to me a typo in some definition 49 on some long page. It’s tedious to find. Or is it just my system?
It's not just you! But if I search for ‘Definition.’ (note the period), then I find it; the ‘1’ and the spaces are just ignored.
Thanks, Toby, for the feeback.
Yes, it’s only the number that is not found, but that’s what makes it hard to jump to one definition among order of them if interspersed are a comparable number of Propositions and Remarks etc.
but that’s what makes it hard to jump to one definition among order of them
Because of this reason I think it is not native to make wiki pages or web pages in general that long. This habit is probably a heritage from the times of linear texts. Also I learned that is is advantageous to give structure elements descriptive identifiers.
The reason for the search behaviour is because the number is inserted at a later stage in the rendering process than the rest of the text (theorem/definition numbering is done by CSS - this has some advantages, but also the odd disadvantage as we’ve found before). I don’t know why, but it would appear that browsers search the text before this insertion takes place. If you search for “Definition. This is the first numbered definition.” on Sandbox then you’ll see that the “1” isn’t included in the search. Ditto if you cut-and-paste.
I’ve asked on a StackExchange site to see if there’s a way to reconfigure this. But I’m not hopeful.
it is not native to make wiki pages or web pages in general that long.
Maybe, I am not sure. I thought about this quite a bit and the case is maybe not that clearcut.
But one thing that is clear is this:
writing a single long page involves work, clearly. But writing the same content on separate interlinked pages drastically increases the amount of editorial work, further. Not only does each separate page now need its own preamble, its own References or pointers to references, but also now creating pointers to some definition/theorem etc. becomes much more tedious.
On the other hand, the other trouble of course is that the instiki software fiercely punishes long pages. The time it takes to save a page grows immensely as soon as the page is longer than an average newspaper article. I have developed ways to deal with this. I write pieces of code in separate pages. Then when I need to brew a coffee or go to the bathroom or make a phone call, I put them into the big page and ask instiki to save it. And minutes later it’s already done! ;-)
But one thing that is clear is this:
What you say is essentially, that instiki is not good in linking specific elements from one page to specific points in another one. Also there is no reference environment which could be associated to more than one page. - I agree with this (maybe for the latter problem one can use the include command) and I also think that instiki and markdown are not the ideal solution for our purposes.
Nevertheless, if I edit insiki-pages or just look there for a piece of source code without a preferred editor it takes some time to find the right position in the source code. So I think it has also for editorial purposes disadvantages to make extreme long pages.
Nevertheless, if I edit insiki-pages or just look there for a piece of source code without a preferred editor it takes some time to find the right position in the source code. So I think it has also for editorial purposes disadvantages to make extreme long pages.
Did you write a bunch of extreme long pages? When I did, I found it easier to edit in one single file. If there is a lot of material, you have to search anyway. But in one single file I can at least make full use of the browser’s seach capability. If the material is spread over many separate pages, I have to search for the right page myself. At some point this becomes quite impractical.
Ideal (for me, at least) would be a software that would read in source code for one single big page and automatically then produce separate pages for each section, and possibly subsection, and so on, automatically introducing all the cross-linking that this requires.
1 to 8 of 8