acme(4) - Plan 9 from User Space

From 78e51a8c6678b6e3dff3d619aa786669f531f4bc Mon Sep 17 00:00:00 2001 From: rsc Date: Fri, 14 Jan 2005 03:45:44 +0000 Subject: checkpoint --- man/man4/acme.html | 268 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 268 insertions(+) create mode 100644 man/man4/acme.html (limited to 'man/man4/acme.html') diff --git a/man/man4/acme.html b/man/man4/acme.html new file mode 100644 index 00000000..ac310c13 --- /dev/null +++ b/man/man4/acme.html @@ -0,0 +1,268 @@ + +acme(4) - Plan 9 from User Space + + + + +

ACME(4) ACME(4) +

+
+

NAME
+ +
+ + acme – control files for text windows
+ +
+

SYNOPSIS
+ +
+ + acme [ −f varfont ] [ −F fixfont ] [ file ... ]
+ +
+

DESCRIPTION
+ +
+ + The text window system acme(1) serves a variety of files for reading, + writing, and controlling windows. Some of them are virtual versions + of system files for dealing with the virtual console; others control + operations of acme itself. When a command is run under acme, a + directory holding these files is posted as the 9P + service acme (using 9pserve(4)). +
+ + Some of these files supply virtual versions of services available + from the underlying environment, in particular the character terminal + files in Plan 9’s cons(3). (Unlike in Plan 9’s rio(1), each command + under acme sees the same set of files; there is not a distinct + /dev/cons for each window.) Other files are unique to + acme.
+ acmeis a subdirectory used by win (see acme(1)) as a mount point + for the acme files associated with the window in which win is + running. It has no specific function under acme itself.
+ consis the standard and diagnostic output file for all commands + run under acme. (Input for commands is redirected to /dev/null.) + Text written to cons appears in a window labeled dir/+Errors, + where dir is the directory in which the command was run. The window + is created if necessary, but not until text is + +
+ + actually written.
+ +
+ consctl + +
+ + Is an empty unwritable file present only for compatibility; there + is no way to turn off ‘echo’, for example, under acme.
+ +
+ index + +
+ + holds a sequence of lines of text, one per window. Each line has + 5 decimal numbers, each formatted in 11 characters plus a blank--the + window ID; number of characters (runes) in the tag; number of + characters in the body; a 1 if the window is a directory, 0 otherwise; + and a 1 if the window is modified, 0 + otherwise--followed by the tag up to a newline if present. Thus + at character position 5x12 starts the name of the window. If a + file has multiple zeroxed windows open, only the most recently + used will appear in the index file.
+ +
+ label + +
+ + is an empty file, writable without effect, present only for compatibility + with rio.
+ +
+ new   A directory analogous to the numbered directories (q.v.). Accessing + any file in new creates a new window. Thus to cause text to appear + in a new window, write it to /dev/new/body. For more control, + open /dev/new/ctl and use the interface described below. +
+ + +
+ + Each acme window has associated a directory numbered by its ID. + Window IDs are chosen sequentially and may be discovered by the + ID command, by reading the ctl file, or indirectly through the + index file. The files in the numbered directories are as follows.
+ addrmay be written with any textual address (line number, regular + expression, etc.), in the format understood by button 3 but without + the initial colon, including compound addresses, to set the address + for text accessed through the data file. When read, it returns + the value of the address that would next be read or + +
+ + written through the data file, in the format #m,#n where m and + n are character (not byte) offsets. If m and n are identical, + the format is just #m. Thus a regular expression may be evaluated + by writing it to addr and reading it back. The addr address has + no effect on the user’s selection of text. + +
+ bodyholds contents of the window body. It may be read at any byte + offset. Text written to body is always appended; the file offset + is ignored.
+ ctl   may be read to recover the five numbers as held in the index + file, described above, plus two more fields: the width of the + window in pixels and the name of the font used in the window. + Text messages may be written to ctl to affect the window. Each + message is terminated by a newline and multiple messages + +
+ + may be sent in a single write.
+ +
+ + addr=dot     Set the addr address to that of the user’s selected text + in the window.
+ clean        Mark the window clean as though it has just been written.
+ dirty        Mark the window dirty, the opposite of clean.
+ cleartag     Remove all text in the tag after the vertical bar.
+ del          Equivalent to the Del interactive command.
+ delete       Equivalent to the Delete interactive command.
+ dot=addr     Set the user’s selected text in the window to the text + addressed by the addr address.
+ dump commandSet the command string to recreate the window from + a dump file.
+ dumpdir directory
+ Set the directory in which to run the command to recreate the + window from a dump file.
+ get          Equivalent to the Get interactive command with no arguments; + accepts no arguments.
+ limit=addr   When the ctl file is first opened, regular expression + context searches in addr addresses examine the whole file; this + message restricts subsequent searches to the current addr address.
+ mark         Cancel nomark, returning the window to the usual state wherein + each modification to the body must be undone individually.
+ name name     Set the name of the window to name.
+ nomark       Turn off automatic ‘marking’ of changes, so a set of related + changes may be undone in a single Undo interactive command.
+ noscroll     Turn off automatic ‘scrolling’ of the window to show text + written to the body.
+ put          Equivalent to the Put interactive command with no arguments; + accepts no arguments.
+ scroll       Cancel a noscroll message, returning the window to the default + state wherein each write to the body file causes the window to + ‘scroll’ to display the new text.
+ show         Guarantee at least some of the selected text is visible on + the display.
+ +
+ +
+ datais used in conjunction with addr for random access to the + contents of the body. The file offset is ignored when writing + the data file; instead the location of the data to be read or + written is determined by the state of the addr file. Text, which + must contain only whole characters (no ‘partial runes’), written + to + +
+ + data replaces the characters addressed by the addr file and sets + the address to the null string at the end of the written text. + A read from data returns as many whole characters as the read + count will permit starting at the beginning of the addr address + (the end of the address has no effect) and sets the + address to the null string at the end of the returned characters.
+ +
+ event + +
+ + When a window’s event file is open, changes to the window occur + as always but the actions are also reported as messages to the + reader of the file. Also, user actions with buttons 2 and 3 (other + than chorded Cut and Paste, which behave normally) have no immediate + effect on the window; it is expected that + the program reading the event file will interpret them. The messages + have a fixed format: a character indicating the origin or cause + of the action, a character indicating the type of the action, + four free-format blank-terminated decimal numbers, optional text, + and a newline. The first and second numbers are + the character addresses of the action, the third is a flag, and + the final is a count of the characters in the optional text, which + may itself contain newlines. The origin characters are E for writes + to the body or tag file, F for actions through the window’s other + files, K for the keyboard, and M for the mouse. The + type characters are D for text deleted from the body, d for text + deleted from the tag, I for text inserted to the body, i for text + inserted to the tag, L for a button 3 action in the body, l for + a button 3 action in the tag, X for a button 2 action in the body, + and x for a button 2 action in the tag. + If the relevant text has less than 256 characters, it is included + in the message; otherwise it is elided, the fourth number is 0, + and the program must read it from the data file if needed. No + text is sent on a D or d message.
+ For D, d, I, and i the flag is always zero. For X and x, the flag + is a bitwise OR (reported decimally) of the following: 1 if the + text indicated is recognized as an acme built-in command; 2 if + the text indicated is a null string that has a non-null expansion; + if so, another complete message will follow describing the + expansion exactly as if it had been indicated explicitly (its + flag will always be 0); 8 if the command has an extra (chorded) + argument; if so, two more complete messages will follow reporting + the argument (with all numbers 0 except the character count) and + where it originated, in the form of a fully-qualified + button 3 style address.
+ For L and l, the flag is the bitwise OR of the following: 1 if + acme can interpret the action without loading a new file; 2 if + a second (post-expansion) message follows, analogous to that with + X messages; 4 if the text is a file or window name (perhaps with + address) rather than plain literal text. + For messages with the 1 bit on in the flag, writing the message + back to the event file, but with the flag, count, and text omitted, + will cause the action to be applied to the file exactly as it + would have been if the event file had not been open.
+ +
+ tag   holds contents of the window tag. It may be read at any byte + offset. Text written to tag is always appended; the file offset + is ignored.
+ +
+

SOURCE
+ +
+ + /usr/local/plan9/src/cmd/acme + +
+

SEE ALSO
+ +
+ + rio(1), acme(1)
+ +
+ +

+ + +

		+
	+ + + +

+ + -- cgit v1.2.3