Tags:
create new tag
, view all tags
Just collecting some "snippets" from other pages (notably the Info... pages) to get them out of the way there and start collecting them in one place.

See:

Contents

Aside

An aside I've made (or planned to make more than once (deleted from Info... before first "publish"):

This page is specifically not ready for "publication" (even on WikiLearn). I've been working on it offline, and it's time to do some significant editing (i.e., cutting). I feel much more comfortable about that kind of thing when previous versions are under RCS control, then, in a certain sense, I am less likely (??) to lose anything "permanently", making me feel freer to cut things. (Well, since you now know how to use RCS on your own computer, why not just put this under RCS control at home? Hmm, maybe someday, but the whole offline editing business leads to duplication of information in two different locations (and all the associated problems, including the desire to keep it up-to-date in both locations). For now (as I have been so far), I prefer to keep WikiLearn / twiki.org / SourceForge as the canonical location for the material. I trust it is still being backed up, both by SourceForge and by twiki.org.

Notes

from some comments on the "first" Info... page (actually deleted before the first "publication" on WikiLearn

Hmm, another aside. Why do I put garbage (digressions) like some of what's on this page on a page like this in the first place. (I have an answer, but the better question to ask is:) What do I need in the way of infrastructure, work habits, or whatever to avoid so many of these digressions?

Part of the problem is clearly my own laziness, and maybe all of it is, but:

  • I think of these things while I'm writing a page like this, and they are either somewhat relevant to this page (sometimes even in the sense of providing an excuse for the poor quality / organization of the page)
  • Finding another place to put them creates some problems:
    • Where to put them
    • How to make sure I get back to the main thing (the document I'm working on), and with a minimum of wasted "restart" effort
    • How to find those digressions again (easily) if I want to add to them, confirm that they already exist, or to find their WikiName so I can refer to them again in another document — brings to mind the joke by number joke / story, maybe I need to be able to rant by number. wink

Some related (contributing) problems:

  • The slowness of WikiLearn / twiki.org / SourceForge — it's just too slow to find other WikiLearn pages, taking anywhere from 10 seconds to minutes to hours
    • Excacerbated by my unreliable (inconsistent) dial up connection
  • I've tried (am trying) an offline plain text askSam for Linux as a supplement to WikiLearn, but
    • It almost becomes an alternate — there is no easy / automatic way to "publish" the stuff in the offline thingie to the on-line WikiLearn
    • The offline thingie is becoming cumbersome as it gets bigger (it is primarily one big plaintext file, maintained in Nedit, using search, "my" collapsible outlining macros, sort, and similar. Because it is so cumbersome, I'm using it for quick scratchpad notes, but when I go to write a "dedicated" page like this, I start a new file (in Nedit, with the same capabilities)

Things I've tried:

  • Maintaining lots of open browser windows (tabs) so that I can leave "relevant" WikiLearn pages open for quick access. Still, I have to anticipate what pages those are, and I don't like to leave them open for editing (and opening for editing takes the 10 seconds to minutes to hours thing), partly for fear of a crash (or just a browser crash — happened often in Mozilla, IIRC, I've only had one in konqueror, and it might have been an EBKAC).
  • askSam for Linux — problems mentioned above

What I'd like to have:

  • Something that is as fast and easy to access different records as askSam was (is?) on dos / Windows, but that also allows easy publishing on line. (Well, askSam does have a means (now) for (easily?) publishing to the web (maybe for as many as the last 5 to 8 years??). Does it allow / support collaboration? How?

Other things to try:

  • A (much) bigger monitor and/or a multihead setup so I can keep more pieces of information visible at the same time?
  • Print more things, and get back to my old "file in piles" system (which worked quite well for me) (although a personal secretary would have been nicer wink (Oh, no, another aside: Why didn't I have a personal secretary, and why did, e.g., Mr. Big have one? Subject for another rant in which I could argue that my work was more important to the organization (I was getting actual projects done, he was "managing" me (and others like me), arguably a personal secretary for me would have resulted in a bigger incremental payoff to the organization. (Well, maybe I should have made that case at the time. But, I was in a dying industry. Were some of our jobs were almost welfare / featherbedding? I didn't think mine was ;-), but ...)

Some other acronyms I want to use:

  • IMOW: In My Own Words
  • TTM: Talking To Myself
  • DNP: Do Not Publish

See, I'd want to "instantly" switch to the page that lists my "personal" acronyms, "instantly" confirm that I've already defined it, or instantly create the definition, "instantly" return here, "instantly" insert a reference to that acronym, and then resume my writing here. It just doesn't work with on line TWiki, nor, so far, with askSam for Linux. Maybe I have to go back to pencil and paper (maybe I never should have attempted to get away from pencil and paper?)?

And even if they (the acronyms) were all on one page, I'd like to be able to (what's the phrase on TWiki, I want to be able to refer to them individually, related to "granularity" — I guess I want information (addressing) granularity at something less than a page (like purple numberes, etc.) — could / should there be a new TWiki syntax to refer to an individual paragraph on a page? (Well, there is already the ability to refer to a <something (#Section_Name)> if it is predefined, and headings have those automatically predefined. Hmm, I forget, can I refer to them in a (T)Wiki name like Acronym#IMOW_Second _Word (or PersonalAcronym#IMOW_Second _Word?

Yes, but the "#" and "_" make the link look ugly, leading to the desire to label the link. It would be nicer to have a "prettier" (more wiki like??) link without the need for a label. Can I brainstorm? Well, how about:

  • Acronym#IMOW_Second _Word automatically rendering as IMOWSecondWord, or Acronym#IMOWSecondWord
  • Maybe with some character other than "#"? Would it be confusing if I used "." or ":", probably, as they are already defined. But, maybe not — does it really matter (a lot) if I don't know where the link is until I follow it? Well, in an ideal world, maybe not, but on TWiki (with my dial up connection especially) a link to another page is much more costly (timewise) than a link to elsewhere on the same page.
  • Even better if Acronym#IMOW_Second _Word automatically rendered as IMOW Second Word, or Acronym# IMOW Second Word
  • Even better if I could write the link as Acronym#IMOW Second Word and have it rendered as IMOW Second Word, or Acronym# IMOW Second Word (the "_" is a real pain to type)

It would also be nice to have a way to specify on a global and individual basis whether the rendered link should include the TWiki, web, page, and anchor or some subset. (If I didn't use the <noautolink> option, I'd have some control over displaying the web or not by choosing the WikiName or double square bracket syntax, but:

  • I want to use the <noautolink>
  • Depending on the context, sometimes I (or someone else) might like to display just the anchor, the page and anchor, the web, page, and anchor, or the (T)Wiki, web, page, and anchor. (Hmm, with all this, doesn't TWiki already have fine grained addressing as some others are advocating? Yes, but it's not quite as convenient or "scalable" (not the right word) as some (including me) might like. (The switch from WikiWords for pages to "underbarred" words for anchors is one aspect of the thing I don't like and am trying to describe as not scalable. Not orthogonal isn't quite the right phrase either.)
  • I could imagine the context automatically determining the form of rendering (render an anchor on the same page with just the anchor name) an anchor in the same web with just the page and anchor name, ..., and that might work quite well, but I'd still advocate (at least initially) a simple way to override that behavior. Maybe, when you specify a link like TWiki: Wikilearn. AskSam For Linux Dev# Some Anchor, allow for example a number immediately after (or between?) the first brackets, the number indicating how much of the link to render (and varying based on whether the link includes an anchor or not). For example:
    • [3[TWiki: Wikilearn. AskSam For Linux Dev# Some Anchor]] would render as Wikilearn. AskSam For Linux Dev# Some Anchor, but, if there were no anchor, [3[TWiki: Wikilearn. AskSam For Linux Dev]] would render as TWiki: Wikilearn. AskSam For Linux Dev. I.e., the number would represent the number of "elements" of the link rendered, counting from the right. (I agree that's potentially confusing, suggest something better!)

Aside: The 32 character limit also makes the thing a pain — is there an alternate to that? Can I brainstorm?

  • Could it be just a flexible requirement, like enough characters to make the reference unique on this page?
  • Hmm, before I think too much about this, I need to remember the problem with non-unique headings (where two headings are identical except for the higher level headings) (I (and others) have written stuff elsewhere on TWiki about the problem. IIRC, a particular example of the problem is on a page like ~Codev.DataStorageforMultiLevelTWikiWebs (I'll do a search some time wink ).
  • < stopped here to change topics again>

Another problem to be considered with thinking of anchors as the answer to fine grained "access" to TWiki is the lack of features like automatic renaming — if you rename a TWiki page (using the provided tools), the links are (optionally) automatically fixed. If you rename a heading / anchor, any links to that anchor are broken. How can that be solved? Maybe:

  • Manually created anchors are easy, just don't change the name (they are not displayed anyway).
  • Automatic anchors (for headings) are the problem. I can think of two potential approaches (not sure I want to write them both down wink ):
    • After the first save (or at some other event), make the anchor name for each heading a part of the file (i.e., make the anchors visible when editing) (ahha, I suspect the anchors for headings are never saved as part of the file, but instead looked for on the fly when a reference must be followed hmmm, that might affect the approach to this, but let me finish these thought before digressing some more) — by making the anchors visible, the writer now has control, he can choose to keep them the same if he modifies (or relocates) the heading. I guess I'd like to see the anchor consist of "meaningful" ASCII text, instead of some hard to "recognize" 32 bit number. If we adopt an approach like this, I'd suspect that the "system" on first save of a heading without an anchor, should create one. (This would also work if the writer wanted to delete the old anchor name from a heading for some reason — he simply deletes it and the system assigns a new anchor on the next save.
    • Similar to above, but the system doesn't create anchors for headings, the author does. Ideally, a simple syntax is available, to over simplify, maybe something like:

   * [[A: My Anchor]] A heading

I could elaborate (can't I always), but I want to switch gears to thinking about how the idea of looking for heading anchors on the fly impacts the discussion:

Hmm, or, the idea of hierarchical anchors for headings (a different digression??):

Hierarchical anchors:

Should (could) anchors for headings somehow incorporate the hierarchy.

What I'm trying to think about is this. One of the problems of anchors for headings at this time is that duplicates are not allowed (or more accurately, don't allow links to work properly). For example, in a page structured like this:

   * One Main Heading
      * Subheading
   * Another Main Heading
      * Subheading

Any attempt (short of manually adding an explicit anchor) to link to the second "Subheading" will not work, the link will "resolve" to the first "Subheading".

One resolution could be that described somewhere above — if the automatically applied "system" anchors were visible to the author on subsequent edits (after a save), he could revise the second anchor to make it unique (and my intent would be that the table of contents would use that manually revised anchor (because, among other reasons, when I link to a heading, I often get the link by right clicking on the ToC entry and copying the link).

Another resolution (but I don't even want to mention it because it could often be very cumbersome) could be to have anchors of the form #Another_Main_Heading__Subheading (just to temporarily invent a (lousy) syntax), i.e., the anchor to a subheading includes the (hierarchical) "path" to the desired subheading. (If it's not clear yet, the anchor to the first subheading would be #One_Main_Heading__Subheading and the link to the second subheading would be #Another_Main_Heading__Subheading.)

Could we make that any better by somehow avoiding the actual names of the heading but instead basing the anchor on the structure? For example, make and anchor like #L12_L21 be to the second subheading (interpret that as:

  • "L12": the second L1 (Level 1) heading
  • "L21": the first L2 heading (under the second L1 heading).
To clarify, I hopw, the anchor to the first "Subheading" would be #L11_L21 and the anchor to the second "Subheading" would be #L12_L21

Commment: The above is possible, but it seems even more cumbersome than the previous approach (#Another_Main_Heading__Subheading), partially because, presumably we'd want to change the anchors (automatically) if we rearranged the outline (hierarchy of the headings).

Of the three (?) approaches discussed so far, I think (so far) I like the idea of the system automatically generating a human readable anchor on first save, and displaying those for the author on subsequent edits, so he can modify (or delete, to allow the system to generate a new anchor on next save).

I haven't yet explicitly talked (or thought) about the idea that TWiki might generate and search for the heading anchors on the fly. Maybe I'll have to look for the "generated" HTML of a few pages (i.e., view source) with headings, some with, some without a ToC.

Signing off for now.

Contributors

  • () RandyKramer - 17 Dec 2003
  • If you edit this page: add your name here; move this to the next line; and if you've used a comment marker (your initials in parenthesis), include it before your WikiName.

Revision Comment

  • %DATE% —

Page Ratings

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2003-12-23 - RandyKramer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look