Emacs programming question

Emacs programming question

[Evan Driscoll]

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.

Re: Emacs programming question

[Jambunathan K]

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.

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.
>
>

-- 

Re: Emacs programming question

[Jambunathan K]

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.
>>
>>

-- 

RE: Emacs programming question

[Doug Lewan]

Evan,

Indirect buffers may be worth looking at. (Or maybe not. The text is the same, 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. 

There's a parent buffer and its affiliated buffers. The affiliates know about 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 Erwin 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 hold detailed design information: a table's schema, all the tables containing a certain column, a list of tables matching a certain regular expression, etc.

Your application seems to want similar kinds of relationships.

,Doug

> -----Original Message-----
> From: help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org
> [mailto:help-gnu-emacs-bounces+dougl=shubertticketing.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
> 
> 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.

Re: Emacs programming question

[Pascal J. Bourguignon]

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.

There are a lot of modes that don't display the literal data.

hexl-mode
forms-mode
etc


As I see it, you have two solutions:

- when you switch to your mode, you can create a new "editing" buffer,
  where the user will give commands, and those commands will update the
  file buffer.

- you can also "parse" the buffer contents and put it in some data
  structures (kept in buffer local variables), and then show in the
  buffer any view of that data you want.  Editing commands will update
  the data structure.  Saving will unparse it into a text file.


There are more variants.  The forms-mode for example, actually use the
forms file to build a meta data structure in the forms buffer, and
actually opens another data file to be edited thru the forms buffer.


> 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.)

Indeed, you would define your own commands and key bindings to edit the
data anyways.


> [… some specs …]

Indeed, you can program anything (that's computable).

emacs lisp is a general algorithmic programming language: you can write
any program with it.  As a bonus, you have a big library for text
editing and a lot of libraries for various other things.  Don't let the
libraries obscure your view that emacs lisp is just a programming
language. You have your specifications.  Write the program.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.