Re: Emacs programming question

[Jambunathan K <kjambunathan@gmail.com>]

Jambunathan K <kjambunathan@gmail.com> writes:

> Consult the Elisp manual:
>
> Look at buffer-* APIs that convert a buffer to a string.
>     (info "(elisp) Buffer Contents")
>
> Look at with with-*-buffer APIs in
>     (info "(elisp) Current Buffer")
>
> You can also look at text properties that hide portions of text.  
>     (info "(elisp) Invisible Text")
>
> Or you just want to narrow to a region.
>     (info "(elisp) Narrowing")
>
> Or you want some sort of composition (Search for compose etc in the
> manuals)
>
> One or more of the above things should suffice to accomplish the task at
> hand.


You can also look at this wikemacs page.
    http://wikemacs.org/wiki/Emacs_Lisp_Cheat_Sheet

It should provide a good starting point for futher exploration.

>
> Evan Driscoll <driscoll@cs.wisc.edu> writes:
>
>> Hi,
>>
>> 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.
>>
>> 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.)
>>
>> 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.
>>
>> Evan
>>
>>
>>
>>
>> What I want to do:
>>
>> 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.)
>>
>> 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".
>>
>> I want some functions (perhaps a whole mode?) that will load a trace
>> file in emacs and do the following:
>>
>> 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.)
>>
>> 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.
>>
>> 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.")
>>
>> 4. If the user selects a file/line in the stack trace buffer, open the
>> corresponding file and navigate to that line.
>>
>> 5. Ideally, add some styling to the data buffer to show where the
>> chunk boundaries are, e.g. alternate between two different faces.
>>
>>

--