From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Doug Lewan Newsgroups: gmane.emacs.help Subject: RE: Emacs programming question Date: Fri, 5 Oct 2012 12:54:46 +0000 Message-ID: <155DEC68569B714B86C2C7075F5EDA982693D2FE@DAKIYA1.pegasus.local> References: <506E51AB.6020204@cs.wisc.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1349441660 6568 80.91.229.3 (5 Oct 2012 12:54:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Oct 2012 12:54:20 +0000 (UTC) To: Evan Driscoll , "help-gnu-emacs@gnu.org" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Oct 05 14:54:26 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TK7Q7-0003rD-Tk for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Oct 2012 14:54:24 +0200 Original-Received: from localhost ([::1]:43142 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK7Q2-00076h-0A for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Oct 2012 08:54:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK7Pr-00075j-I8 for help-gnu-emacs@gnu.org; Fri, 05 Oct 2012 08:54:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TK7Pl-0002vZ-IR for help-gnu-emacs@gnu.org; Fri, 05 Oct 2012 08:54:07 -0400 Original-Received: from [207.246.209.200] (port=41502 helo=webmail.shubertorg.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK7Pl-0002um-EB for help-gnu-emacs@gnu.org; Fri, 05 Oct 2012 08:54:01 -0400 Original-Received: from dakiya1.pegasus.local ([::1]) by DAKIYA1.pegasus.local ([::1]) with mapi id 14.01.0339.001; Fri, 5 Oct 2012 08:54:47 -0400 Thread-Topic: Emacs programming question Thread-Index: AQHNor1VkFl1XsJj/kK8qHXQVUtx/5eqqCGw In-Reply-To: <506E51AB.6020204@cs.wisc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.21.202] X-detected-operating-system: by eggs.gnu.org: Windows XP/2000 (RFC1323+, w+, tstamp-) X-Received-From: 207.246.209.200 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:87080 Archived-At: Evan, Indirect buffers may be worth looking at. (Or maybe not. The text is the sa= me, but you can do different processing on it.) In a different direction: I've needed to do similar things several times and I created the idea of an= affiliated buffer.=20 There's a parent buffer and its affiliated buffers. The affiliates know abo= ut the parent, and the parent knows all of its affiliates. So, commands in = the affiliates can affect the parent, and commands in the parent can affect= any of the affiliates. The most common application has been with employers who have lost their Erw= in licenses for database design. (This seems to be surprisingly easy to do.= ) The parent buffer can hold a list of table names while the affiliates hol= d detailed design information: a table's schema, all the tables containing = a certain column, a list of tables matching a certain regular expression, e= tc. Your application seems to want similar kinds of relationships. ,Doug > -----Original Message----- > From: help-gnu-emacs-bounces+dougl=3Dshubertticketing.com@gnu.org > [mailto:help-gnu-emacs-bounces+dougl=3Dshubertticketing.com@gnu.org] On > Behalf Of Evan Driscoll > Sent: Thursday, 2012 October 04 23:19 > To: help-gnu-emacs@gnu.org > Subject: Emacs programming question >=20 > Hi, >=20 > I want to write an emacs mode to display a particular type of file. > However, the way I'd like to display the file isn't the literal text > contents in the file, but rather a (text) rendering of parts of the > information contained within. Unfortunately, I don't know any modes > that > do something comparable; the closest ones I can think of are what you > get if you load an image. As a postscript I've included a fairly wordy > description of what I'm trying to do to set some context; It's step (2) > in that description that I foresee the most problems with. >=20 > What I want is something to the effect of opening the file normally but > then (1) saving the contents of the buffer into a lisp variable, (2) > clearing the buffer, (3) inserting into the buffer some computed > contents from step (1). (Fortunately, I can set the buffer to read-only > for my purposes and I don't have to worry about user edits to it.) >=20 > The programming reference talks about functions for visiting a file and > also inserting the contents of a file into a buffer without visiting it > (insert-file-contents), but neither of these are what I want, really. >=20 > Evan >=20 >=20 >=20 >=20 > What I want to do: >=20 > Before starting, let me say that I'm not so interested in catching lots > of edge cases; something that will work for the common case is good > enough. (In case it's not clear from the following, this is going to be > a debugging aid to help trace back incorrect output to the point in the > code that created it. And don't say that point may not be where a > write(2) call is actually finally made because of buffering, because I > know, and if that's a problem in practice I'll fix it. :-) But the > emacs > part can remain unchanged.) >=20 > I have a program which will run another program under ptrace and each > time it makes a write(2) system call, will record information > consisting > of (1) the size of the write, (2) the target "file" name (could be > /dev/pts/blah), (3) the offset in that file (or that it is appended if > the file is unseekable), (4) a stack trace of the program (file/line, > via debugging information). In addition, assume the actual data of the > write is available either in a separate file or in the trace file. (I'm > flexible on this point, and can pick whichever makes things easier. I > think that may mean putting the data into the trace file.) Call the > information for each write(2) call a "chunk". >=20 > I want some functions (perhaps a whole mode?) that will load a trace > file in emacs and do the following: >=20 > 1. Let the user choose a file of interest, and ignore the parts of the > trace not pertaining to that file. (If it would make things simpler, I > could preprocess the trace to extract the information for each file > separately.) >=20 > 2. Reconstruct the final state of that file, displaying it to the user > in the "data" buffer. If the trace file and file contents are loaded > separately this is just loading the file. If the data is in the trace > file itself, this will mean looking at the data for each chunk and > putting the data at the appropriate place in the buffer. Set that > buffer > read-only. >=20 > 3. Open a new buffer in another window. As the user moves the point > around that buffer, find the chunk that corresponds to the (last) time > the byte under the point was written. Grab the stack trace from that > chunk, and display it in this other buffer. (Call it the "stack trace > buffer.") >=20 > 4. If the user selects a file/line in the stack trace buffer, open the > corresponding file and navigate to that line. >=20 > 5. Ideally, add some styling to the data buffer to show where the chunk > boundaries are, e.g. alternate between two different faces.