[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs programming question
Re: Emacs programming question
Fri, 05 Oct 2012 14:52:10 +0530
Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)
Jambunathan K <firstname.lastname@example.org> 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
> One or more of the above things should suffice to accomplish the task at
You can also look at this wikemacs page.
It should provide a good starting point for futher exploration.
> Evan Driscoll <email@example.com> writes:
>> 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
>> 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.
>> 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
>> 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
>> 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.