emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: map-file-lines


From: Ted Zlatanov
Subject: Re: map-file-lines
Date: Wed, 04 Feb 2009 09:38:08 -0600
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)

On Wed, 04 Feb 2009 02:04:32 -0500 Richard M Stallman <address@hidden> wrote: 

RMS> Here's an idea for a UI for editing big files.  First you run M-x grep on
RMS> the file, and display the matches for whatever regexp.  In the *grep*
RMS> buffer you specify a region, which is a way of choosing two matches,
RMS> the ones whose entries contain point and mark.  Then you give a command to 
edit
RMS> the file from one of the matches to the other.  It marks these matches
RMS> (and the lines containing them) as read-only so that you can't
RMS> spoil the correspondance with the file.  Thus, you can always save this
RMS> partial-file buffer.

RMS> The beginning and end of the *grep* buffer can be used to specify
RMS> that the portion to edit starts or ends at bof or eof.

RMS> It would be easy to adapt this to variants such as
RMS> (1) using hexl-mode to visit the file,
RMS> (2) using methods other than grep to subdivide the file,
RMS> (3) providing more friendly front ends to grep.

This is essentially mapping byte offsets to line positions, with extra
calculations.  As Stefan suggested, it's better to just use byte
offsets.  Your approach requires a lot of tracking of the grep lines,
whereas just using byte offsets requires remembering the two current
offsets and nothing else.  

Otherwise I think your suggestions are similar to mine: set up a special
mode where the buffer is a window[1] into the file instead of the whole
file, and create special commands to move the window back and forth.

Saving would only save the buffer contents; the window won't be moveable
until changes are saved (another approach is to remember modifications
outside the window, but that gets hairy with undo).

Ted

[1] I know "window" has meaning in Emacs already, but I can't think of a
better term.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]