home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 638 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.2 KB
  1. Date: Mon, 13 Jun 94 22:50:00 +0200
  2. Message-Id: <2dfcd951@daggskim.ct.se>
  3. From: bo.leuf@daggskim.ct.se (Bo Leuf)
  4. Subject: Re: blocks (was Control A)
  5. To: gem-list@world.std.com
  6. Precedence: bulk
  7.  
  8.  
  9.  
  10. Christian Nieber wrote...
  11.  > [...munch...]
  12.  > In papyrus I solved the text loss danger like this:
  13.  > When the whole text is marked via mark all/CTRL A, a flag is set that
  14.  > the block is non-overwriteable. Delete works (after all there is still
  15.  > Undo), but when the user tries to overwrite it, the block is deselected
  16.  > and the typing ends up at the beginning of the document.
  17.  
  18. This brings up an interesting characteristic of marked blocks, which may be a
  19. bit off-topic, but does directly impinge on the question of user "safety" and
  20. choice of modified/unmodified shortcuts (the Control A thread), so I wish to at
  21. least mention it here.
  22.  
  23. I've noticed in a few Atari text applications the very common, nay almost
  24. ubiquious PC (Windows) behaviour of marked blocks being treated as automatic
  25. delete when typing something new. E.g. where we in a GEM form text-edit use ESC
  26. to clear the line of existing text, the Windows user doubleclicks if not
  27. already marked (by selecting/TABing to) and types something new. In the extreme
  28. case practically the entire text in a document can be marked and vanish on the
  29. press of any key.
  30.  
  31. I quite honestly don't know if I'm entirely confortable with this behaviour,
  32. but a lot of software tends in this direction. I will admit that this is often
  33. convenient, but at times dangerous (such as unexpected no recovery, especially
  34. since one doesn't always see a marked block (off screen) which may have been
  35. marked by accident (doubleclick giving an end-block marker).
  36.  
  37. Christian has obviously opted for the contrary direction of disallowing
  38. overwrite in this sense, and in fact going a bit stronger by not allowing any
  39. modification within the block at all.
  40.  
  41. However, is the Windows-like "delete a block when typing something new",
  42. something we need to consider when dealing with this group of shortcuts? Or
  43. should we in general recommend that a block can only be deleted explicitly,
  44. preferably with a Ctrl-Delete?
  45.  
  46.  (illegible signature) Bo Leuf
  47.  - Email: bo.leuf@daggskim.ct.se
  48.  
  49.  
  50.  
  51.  
  52.