🚀 go-pugleaf

In article <786@stag.UUCP> trb@stag.UUCP ( Todd Burkey ) writes:

:This is a request for comments on an editor which will soon be released
:for public abuse. I hope to release the sources to comp.sources.unix
	Great!  The  overall description  of capabilities looks like the
	kind of stuff I'd love to have around.

:also has some relational capabilities. These allow the user to associate
:lines in their source files with sections of their documentation files
:and vice-versa. And both folding and relations are incorporated in such a
:fashion that they don't impact the original text files in any way.
	Try  to do this as generally as possible - users will  always
	try to use  a system in  ways  the  author never dreamed of,
	and if things are straight-forward and general it helps a lot.

:So what doesn't FOLDED do? Well, the first release will not have an UNDO
:feature. The trash can will have to do. It also is dual mode, something

	While I find modes easy  to use, they  seem  to be hard for
	people to learn (especially non-programmers, who you may not
	care about, but who will use your  editor if it's friendly.)
	(On the other  hand, UNDO is much  easier in modes. In either
	case, make the trash can big and  easy to rummage around in,
	and make sure *everything*  goes  in it (e.g. overwritten
	characters, indents, ..)

	If you  do need modes,  make  sure to indicate the  mode in
	big letters somewhere  on  the  screen so users know what's
	happening.  Similarly, Lotus/MSWord-like menus may be  boring,
	but they make it easy to just use.  And try to make cursor
	motion accessible from insert mode as well as command-mode.

	There are two obvious approaches to modelessness - either
	always be in command-like mode (the emacs approach where  "a" 
	is merely a command  to stick an "a" into the  text), or
	alternatively  to always be  in insert-like mode, with
	commands recognizable because they start with  "\" or  come
	from  function  keys (=> probably start with  ESC.)

:The first release also won't have any key binding capability. I still
:haven't decided upon the best approach to handle user-defined key maps.
	Key binding can  be very useful  for you, the developer, so
	you can  try things out without yet another round of compile-run.
	If you  don't provide it, and you do try to avoid having
	separate insert and command modes, think  really hard about
	how this affects things like arrow-and-function keys  on
	commonly available terminals.


: [ boxes, rectangles, quarter-planes, horizontal scroll ]
	Yay!  These are nice to have.
:Also, FOLDED does not retain tab characters. ... replaced with white space 

	Booo! This is *EVIL*!  If I put in a tab character, I want a
	tab character, and I will refuse to use any program  that
	thinks I wanted spaces instead!  Especially one that  trashes
	tabs on  input.  I realize this makes editing rectangles
	tougher, but tabs are reality, especially for us troff/tbl users.
	When I put in a tab  character, *I mean TAB!*.
	Similarly, make sure you can  support characters with the  8th
	bit on (i.e. non-ASCII) - for many  people, these are real
	characters!  Even \0,  if you can - then the editor can  hack
	binary files.

	You may  want to make some arbitrary definition  about what
	tabs mean, but leave the characters there. If you *must*
	do something obscure with them, here's a suggestion:
	Instead of using your trick of deleting initial white space
	and keeping an indent-int, leave the characters there, use
	the int to keep track of where  it indented to, and  also keep
	a flag that says whether there are non-initial tabs on the  line.
	If there aren't any (except initials), you can do things
	fast&easy, but if there are tabs, the user just waits while
	you count over from the left.  You get your speed, I get my
	tabs, and you  only write 25% more  code :-)

	If you really *must* trash  tabs on input, here's an alternative:
	fill it  out with  spaces, but  use a tab instead of a space
	as the  last character, and treat tabs as width-1 internally.
	At least then  the  tab  characters are still there, and those
	of use who want to move tbl-columns as rectangles can  be  only
	confused instead of totally confused.  It's still evil, but
	it's compassionate  evil:-).

: No line-wrap
	Shouldn't be too hard to add, and it makes editing  text much
	easier - but be careful not to have it break things the  way
	vi's line-wrap does (try  doing  a "p" at the  end of a line!)
	If you  do stick with  modes, you may want to  have wrap only
	work in insert mode, and  provide a command to explicitly
	rewrap hunks of text in command mode.

:The first release of FOLDED has been tested on BSD4.2/3 (Suns, Symetric,
:and Apollo), SYSVR3 (ETA-10), and the ATARI ST. It is being ported by
		     ^^^^^^^
     Hey, if you've gotta use  System V,  might  as well start out big!

: FOLDING 

:Worried that folding will change your source code? Don't worry, the
:act of folding doesn't affect the edited file at all...even when saved.
	Great!   However, what happens if  someone edits the program file
	with  emacs in between  FOLDED runs?   Do  you try to recover
	(unlikely), warn  the  user (asking whether to discard the
	fold-control-file), or  just assume  it's right, causing
	random folds to show up?

:In summary, folding is fully heirarchical (i.e. a fold can contain any number
:of folds), it is smart (it can fold based on programming logic blocks and
:indentation level), and it is retained from one edit session to the next.


:RELATING:
	There are a lot of parallels to hypertext work here - you
	should look  into it if you haven't yet.  

:A second relationship type is that of line relations.  These are basically
:invisible links that relate a line in one buffer to a line in another buffer.
	Try  not to be too literally line-oriented - if you can put
	marks at arbitrary points  in the file, and maintain them
	across formatting changes,  it makes them a lot  more useful.
	Also, what happens if two buffers are different views of the
	same file?  

:Since I added relations very late in the development of the editor, I have a
:feeling that this area will see the most improvement over the next year. I've
:already decided that I need a few more commands to do things like 'move'
:and 'view' relationships.


:EDITING COMMANDS:

	One of the  things vi does  right (mostly) is maintaining
	orthogonality between  actions and objects:  aN  object is
	just a cursor-motion, and the way  to do something is  to
	specify the verb (e.g. delete) and the motion.  Unlike emacs,
	this means you don't have totally different  commands to
	delete words, sentences, {}groups, ()groups, lines, ..., and
	you  have a lot more flexibility about  creating new
	object-types (such as  FOLDS!).
-- 
# Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
# also found at 201-271-4712 tarpon.att.com!wcs