home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / alt / galactic / 748 < prev    next >
Encoding:
Internet Message Format  |  1992-11-16  |  4.9 KB
  1. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!agate!doc.ic.ac.uk!uknet!keele!nott-cs!dpg
  2. From: dpg@cs.nott.ac.uk (Dave `geek' Gymer)
  3. Newsgroups: alt.galactic-guide
  4. Subject: Re: HyperTextish stuff
  5. Message-ID: <1992Nov16.094621.12334@cs.nott.ac.uk>
  6. Date: 16 Nov 92 09:46:21 GMT
  7. References: <1992Nov11.223716.6341@primerd.prime.com>
  8. Reply-To: dpg@cs.nott.ac.uk (Dave Gymer)
  9. Distribution: alt
  10. Organization: Association of Slack Producing Geeks
  11. Lines: 92
  12.  
  13. In article <1992Nov11.223716.6341@primerd.prime.com> jasonp@sunbabe.Prime.COM (Jason Pascucci) writes:
  14. >I'm looking for a point-and-click/scroll kind of index, as well as a search,
  15. >basically. 
  16.  
  17. I think TUG! 2 should have something like this, although the exact
  18. details of the interface haven't been worked out yet (one reason why a
  19. post like yours is useful).  TUG! 0.22 allowed you to look at a list of
  20. all the index entries, and then pick one from there; effectively doing
  21. the same job, just with the added inconvenience of having to type the
  22. article number of the entry of interest (for which the TAB completion
  23. doesn't help much).
  24.  
  25. >The help a program can give you is immessurable. Picture:
  26. >You are browsing through an entry on Good Drinks, and you
  27. >have a great idea for an article on Gin's I have known. *click*,
  28. >up comes the window with skeleton, you type your entry, add in some
  29. >cross references, hopefully also a point-and-click operation, and
  30. >*click* you send it off. Simple. No tapdancing required. 
  31.                                   ^^^^^^^^^^^^^^^^^^^^^^
  32.  
  33. What you've just asked for requires a complete text editor to be built
  34. into the browser.  Either it's gonna be a really crummy editor, or this
  35. is going to bloat the browser beyond sensible limits.  The only way
  36. round I can see is to let you select xrefs either before or after you do
  37. the editing; this might actually be a Good Thing, since you could then
  38. update xrefs to other articles on the fly.  Thoughts, anyone?
  39.  
  40. >No, I think the lack of a easy way to submit articles, which should
  41. >be very closely tied into the browser, is the reason. That, and
  42. >that many people unsubscribed to this newsgroup because it was
  43. >quickly turning into a abortion.
  44.  
  45. I remain skeptical about this.  Would you be happier if the editors were
  46. to accept entries in any format, and agree to add the headers
  47. themselves?  (Fear not, Paul and Steve, I'm suggesting for a minute that
  48. you actually do this!)
  49.  
  50. >When (not now) you can present
  51. >a concerted and integrated front, then you can post to all the various 
  52. >newsgroups (rec.lit, alt.sex, whatever) about this, and you will get
  53. >some response.
  54.  
  55. alt.sex, huh?  Hmm, wonder what sort of entries we'd get from there...
  56.  
  57. >>[Notes about binary distributions and autoconf deleted.]
  58. >1) Yes I am. You have to compile it for about a half-dozen platforms,
  59. >which IS NOT A BIG DEAL. Take a look at the netrek example. It's been
  60. >done, and is fairly reasonable to maintain.
  61.  
  62. Which half-dozen?  I could start trying to list all the different UNIX
  63. platforms that people might want to compile TUG! 2 on, but, I think
  64. you'll agree, it comes to rather more than 6.  Or 10.  Or 20.  Hell, if
  65. my 386 running Linux can't run binaries from other 386 Unices, why
  66. should I expect to provide binaries for more than a handful of the more
  67. common Unices?
  68.  
  69. If you want to volunteer to provide binaries for you particular flavors
  70. of UNIX, fine, but don't expect me or anyone else to compile up a
  71. browser on any system that someone wants it on, it just isn't practical,
  72. or desirable, given that TUG! is covered by the GNU GPL.
  73.  
  74. >2) Gnu Autoconf is a real abortion in and of itself, and while I don't
  75. >think you shouldn't use it, include a 'normal' Makefile. You shouldn't
  76. >be doing *that* many funny implementation-specific things, if you are,
  77. >then you are clearly doing something fairly major wrong. (I, personally,
  78. >prefer the Imake/xmkmf idiom for dealing with similar things. But
  79. >you are only assured to have it on an X platform.)
  80.  
  81. Have you known _any_ piece of non-trivial UNIX software that compiled on
  82. both BSD and SysV with no source changes?  Nope, me neither; the variety
  83. of Unices is quite alarming!
  84.  
  85. What have you got against Autoconf?  It's not exactly difficult to edit
  86. a Makefile.in into a Makefile even if you can't run a configure script
  87. (and I can't think why you shouldn't be able to).
  88.  
  89. Imake is nice if you've got X (I finally got it installed on my PC under
  90. Linux a coupla weeks ago), but it doesn't solve all portability issues,
  91. just, in general, X-related ones.
  92.  
  93. >>[Stuff about finding a DOS box deleted.]
  94. >Wrongo, BeetleBreath. [...]
  95.  
  96. Ouch!  `BeetleBreath'!  Now that hurts!  :-)
  97. -- 
  98. `Grave' Dave Gymer
  99. Life is like a grapefruit.
  100. -- 
  101. `Grave' Dave Gymer | Hanlon's Razor: "Never attribute to malice that which
  102. 42 St Mary's Park  | can be adequately explained by stupidity." Finagle's
  103. Louth, Lincs       | Law: "The perversity of the universe tends towards a
  104. LN11 0EF, England  | maximum." (Quoted from the jargon file. Thanks ESR!)
  105.