[comp.emacs] Sections in Gnu Emacs Buffers?

dayoung@hplabsz.HPL.HP.COM (Doug A. Young) (01/27/89)

I have an application for which I need to be able to break a Gnu buffer into
multple sections. Although the buffer should act like a normal buffer in most 
respects, I need to be able to do certain things on a sectional basis: Add a 
section, delete a section, set read-only mode on a section, go to a section,
collapse or expand a section, and so on. A few operations that normally are 
associated with buffers also need to be moved to sections. For example, I need
to keep a modified flag for each section, rather than the whole buffer. I'm
told that some other emacses have this capability (zemacs ?) although I've 
never used  one that does.

So, my question: Before I embark on what may well be a major hack to Gnu emacs,
has anyone done this already or tried to? Can anyone give me some info on emacs
versions that support this capability that would help me keep from completely
reinventing the wheel?

Doug Young  (dayoung@hplabs.hp.com)
HP Labs

beede@pavo.SRC.Honeywell.COM (Michael Beede) (01/29/89)

It seems that the same effect (separating buffers into sections with
per-section variables, it would be simpler to allow windows to exist
without modelines.  Then a stack of windows each showing a different
buffer would represent the "sections" you need, and the contents could
be collected correctly when the buffer was saved (or whenever you
needed them).  There may even be a way to specify a modelineless
window, but I suspect it calls for modification of the display code.

This might be simple and useful enough that it could make it into the
GNU distribution, while I don't see section-local variables doing that
(possibly I am too foolish to see their obvious appeal, though).
---
Mike Beede -- Secure Computing Technology Center MN55-7282
Honeywell Systems & Research Center              (612) 782-7147
2855 Anthony Lane South - Suite 130
Minneapolis MN                                   beede@src.honeywell.com

liberte@m.cs.uiuc.edu (01/30/89)

Stallman and I have just now been discussing interval-local
variables.  If we can figure out how to do it, he wants to add it
to Emacs.  A buffer would be divided into a sequence of disjoint
intervals, and each interval has a set of variables local to it,
analogous to buffer-local variables.  The interval boundaries would
be automatically adjusted by Emacs as text is changed.

Nothing is definite yet, so if you have any ideas, get them out now.
What kinds of things would you use intervals for?

Dan LaLiberte
uiucdcs!liberte
liberte@cs.uiuc.edu
liberte%a.cs.uiuc.edu@uiucvmd.bitnet

spolsky-joel@CS.YALE.EDU (Joel Spolsky) (02/06/89)

In article <4300032@m.cs.uiuc.edu> liberte@m.cs.uiuc.edu writes:
>
>Stallman and I have just now been discussing interval-local
>variables.  If we can figure out how to do it, he wants to add it
>to Emacs.  A buffer would be divided into a sequence of disjoint
>intervals, and each interval has a set of variables local to it,
>analogous to buffer-local variables.  The interval boundaries would
>be automatically adjusted by Emacs as text is changed.
>
>Nothing is definite yet, so if you have any ideas, get them out now.
>What kinds of things would you use intervals for?

If the overhead was low enough, this might be a way to implement
proper formatting, such as bold mode, underline mode, etc, like in PC-
style word processors. You could have interval-local variables for
character-format, paragraph-format, font, and so on. Then you'd have
to find a way to display them...

+----------------+----------------------------------------------------------+
|  Joel Spolsky  | bitnet: spolsky@yalecs.bitnet     uucp: ...!yale!spolsky |
|                | internet: spolsky@cs.yale.edu     voicenet: 203-436-1483 |
+----------------+----------------------------------------------------------+
                                                      #include <disclaimer.h>

jrferro@athena.mit.edu (Jon R Ferro) (02/07/89)

>>What kinds of things would you use intervals for?

Is this the right idea?:
The first thing that pops into mind would be to have intervals
automagically set off by comment delimiters, so that I wouldn't have to
think about how to fool C-mode into letting me edit my block comments
the way I like:

...
[C-mode: TAB means indent-current-line]
...
}

/*
**  [Pseudo-Text-Fill-mode with interval variable fill-prefix = "** "]
**  [TAB means tab-to-tab-stop]
** ...
*/

[Back in C-mode]
...


This usage implies some sort of automatic interval-creation mechanism
similar to abbrevs (NOT like the explicit ruler insertion of MacWrite).

I don't know enough about the theoretical operation of major modes to
know if changing to a "pseudo" mode in an interval would be best handled
by actually calling the mode function or just changing all the mode and
keymap variables in the interval.

Another good example is the editing of yacc input files for which emacs
(correctly) use c-mode in the sections which are actually C code, but
where c-mode rather gets in your way during the editing of the grammar
rules. (This would be better handled by something much more
text-mode-ish)

As was mentioned before, interval-local variables would also give a
mechanism for marking off blocks to be displayed bold, underlined, or
\narrower like the MacWrite or TeX commands they would emulate, but I
don't think pushing emacs towards WYSIWYGness should be the reason for
this work, or a good thing at all.

P.S. How would interval boundaries be displayed in the file? Would one
(a) have to find the boundaries via mark-current-interval or
narrow-to-interval and then go back to editing, or (b) would there be a
command like display-current-interval which would invert the current
interval's text until either the next keypress or until the next call to
undisplay-current-interval, or (c) permanent visible markers in the
text?  (My opinion: Both (a) and (b) should be available. (c) loses big.)

Would it even be necessary to display the boundaries of the interval if
the mode-line had some indication of what interval or set of interval
variables is active at the point? If the interval mechanism works as
transparently as the buffer/window mechanism, I can picture never
worrying about it.

Sounds like a very intriguing puzzle and a likely addition to emacs.
Hope these comments help.

--Jon

Jon Ferro
MIT Mathematics
jrferro@athena.mit.edu

steiner@topaz.rutgers.edu (Dave Steiner) (02/08/89)

In article <4300032@m.cs.uiuc.edu> liberte@m.cs.uiuc.edu writes:

>Stallman and I have just now been discussing interval-local
>variables.
>
>What kinds of things would you use intervals for?

I've always wanted to use something like this for being in a different
mode when you are editing the headers in mail mode.  If your To: field
gets too long and you have auto-fill on in mail-mode it auto fills but
doesn't put a TAB or something in front of the line and then sendmail
gets confused.  The solution always looked too messy to try something.

ds
-- 

arpa: Steiner@TOPAZ.RUTGERS.EDU
uucp: ...{ames, cbosgd, harvard, moss}!rutgers!topaz.rutgers.edu!steiner

mrd@sun.soe.clarkson.edu (Michael DeCorte) (02/10/89)

>What kinds of things would you use intervals for?

It would make it possible to write a web mode or in my case c-web.

For those of you who aren't familiar with web it is a way of writing
"literate" programs.  (not this isn't ai).  Basically you mix pascal
code in with TeX code.  Running foo.web through tangle.web generates
foo.c which is compilable by your favorite c compiler.  Running
foo.web through weave.web generates foo.tex which after being TeX'ed
will be the prettiest program you have ever seen.  

here is an example of web.
------------------------------------------------------------
@* Basic input routines.
For the purposes of this program, a |byte| is an unsigned eight-bit quantity,
and an |ASCII_code| is an integer between @'40 and @'177. Such ASCII codes
correspond to one-character constants like \.{"A"} in \.{WEB} language.

@<Types...@>=
@!byte=0..255; {unsigned eight-bit quantity}
@!ASCII_code=@'40..@'177; {standard ASCII code numbers}
------------------------------------------------------------
The top part is TeX code while the bottom part is sort of pascal.  I
haven't the faitest idea how to make a major mode for this but might
(probably not really) with regions in a buffer.



--

Michael DeCorte // (315)265-2439 // P.O. Box 652, Potsdam, NY 13676
Internet: mrd@sun.soe.clarkson.edu  // Bitnet:   mrd@clutx.bitnet        
---------------------------------------------------------------------------
Clarkson Archive Server // commands = help, index, send, path
archive-server@sun.soe.clarkson.edu
archive-server%sun.soe.clarkson.edu@omnigate.bitnet
dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server
---------------------------------------------------------------------------

mdt@s1.sys.uea.ac.uk (M.D. Templeton GEC ) (02/13/89)

Can anyone mail or repost the improvement to lpr/print to make it print
the whole buffer??

PLEASE DO. I will be eternally greatful (grateful?).

		The Druid.

ceb@ethz.UUCP (Charles Buckley) (02/14/89)

In article <49769@yale-celray.yale.UUCP> spolsky-joel@CS.YALE.EDU (Joel Spolsky) writes:
   In article <4300032@m.cs.uiuc.edu> liberte@m.cs.uiuc.edu writes:

   >Stallman and I have just now been discussing interval-local
   >variables.  If we can figure out how to do it, he wants to add it
   >to Emacs.
   If the overhead was low enough, this might be a way to implement
   proper formatting, such as bold mode, underline mode, etc,

   Then you'd have to find a way to display them...

While you're at it, how about simply having a hook to display the text
between the point and the mark in inverse-video, or standout mode, as
the jargoneurs would say?  I started in on this once, but had decided
that this was a job for someone who knew the C-code when duty called
me back to my work.

This feature is implemented on the Symbolics machines Zmacs, and is
enormously useful.  Shouldn't be hard to implement either.

Ram-Ashwin@cs.yale.edu (Ashwin Ram) (02/15/89)

In article <779@ethz.UUCP>, ceb@ethz.UUCP (Charles Buckley) writes:
> In article <49769@yale-celray.yale.UUCP> spolsky-joel@CS.YALE.EDU (Joel Spolsky) writes:
>    In article <4300032@m.cs.uiuc.edu> liberte@m.cs.uiuc.edu writes:
>    >Stallman and I have just now been discussing interval-local
>    >variables.  If we can figure out how to do it, he wants to add it
>    >to Emacs.
>
>    If the overhead was low enough, this might be a way to implement
>    proper formatting, such as bold mode, underline mode, etc,
> 
> While you're at it, how about simply having a hook to display the text
> between the point and the mark in inverse-video, or standout mode, as
> the jargoneurs would say?

This comes up time and again.  I agree that something like this is needed.
However, I would not like the text between mark and point to be in
inverse-video all the time because the mark is used for different purposes in
Emacs.  For example, when you M-> to the end of the file, Emacs leaves a mark
at your previous position.  In fact, in most buffers, there is always a mark
somewhere, and you don't want half your screen to always be in inverse-video.

On the other hand, inverse-video is very useful when you're selecting regions
to cut and paste, or to pass to a process, or whatever.  The problem here is
that the same mark is used for this purpose too.

I can think of a few solutions to this (some of these are used in different
editors):

 - commands that automatically drop a mark (e.g., M->) don't turn on
   inverse-video; explicitly set marks (using set-mark-command) do

 - a separate command for selecting regions (i.e., separation of the "mark
   this spot" function and "select this region" function)

 - two mark commands (or a prefix argument to set-mark-command which turns on
   inverse video until the next "region" operation)

 - always turn inverse video on when a mark is set, but turn it off when the
   next "region" command is executed (i.e., excluding cursor movement
   commands).  This way inverse video will normally be off, but it will
   temporarily be on while you're selecting a region

 - a command to toggle inverse video for the region.  This way you can hit a
   key when you want the region to be highlighted

What I'm trying to say is that this is more than a matter of adding a
"standout mode" -- there is also the issue of what the best design is.

My personal preference is as follows (a combination of the above):

 - automatic marks (e.g., M->) do not turn on inverse video
 - set-mark-command turns on inverse video
 - any region operation (C-w, case change, etc.) turns off inverse video
 - a command to toggle inverse video in case you explicitly want to turn it
   off or on for a given situation

Of course, one could provide more than one method and have a user-settable
variable to allow him to select which one he wants to use.

-- Ashwin.

jgy@opus.ATT.COM (John Young) (02/16/89)

In article <50744@yale-celray.yale.UUCP>, Ram-Ashwin@cs.yale.edu (Ashwin Ram) writes:
> In article <779@ethz.UUCP>, ceb@ethz.UUCP (Charles Buckley) writes:
> > In article <49769@yale-celray.yale.UUCP> spolsky-joel@CS.YALE.EDU (Joel Spolsky) writes:
> >    In article <4300032@m.cs.uiuc.edu> liberte@m.cs.uiuc.edu writes:
> >    >Stallman and I have just now been discussing interval-local
> >    >variables.  If we can figure out how to do it, he wants to add it
> >    >to Emacs.
> >
> >    If the overhead was low enough, this might be a way to implement
> >    proper formatting, such as bold mode, underline mode, etc,
> > 
> > While you're at it, how about simply having a hook to display the text
> > between the point and the mark in inverse-video, or standout mode, as
> > the jargoneurs would say?

While you're at that, how about adding hooks/variables so that different
highlighting capabilities can be used, such as inverse video for the
mode-line, underline for the region between point and mark, etc..

If multiple intervals and or regions become a reality does this mean
a function "highlight-regexp" could be written to "mark" all occurances
of "regexp" so that whenever they are displayed they are highlighted.

One of the purposes of intervals seems to be to make providing "forms"
with various "field types" and input checking a reality, if this is
true it should also be possible to "highlight" these fields.
Enough rambling!

pierson@mist (Dan Pierson) (02/16/89)

In article <50744@yale-celray.yale.UUCP>, Ram-Ashwin@cs (Ashwin Ram) writes:
>On the other hand, inverse-video is very useful when you're selecting regions

Two levels of standout mode are even more useful.  For example, in the
Xerox lispm's SEdit, the seleted region is inverse videod and the
previously selected region is underlined.  This (plus the obvious
commands) makes it very easy to swap two non-contiguous sections of
text or code.

When the time (now?) comes to finally teach Emacs to handle standout
displays, it would be a mistake to design in a restriction to only a
single level.
-- 
                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@encore.com

barnett@vdsvax.steinmetz.ge.com (Bruce Barnett) (02/17/89)

In article <4919@xenna.Encore.COM>, pierson@mist (Dan Pierson) writes:
>Two levels of standout mode are even more useful.

How about four? Six? Sun's TextEdit model has four stand out modes:

	Reverse Video Black 	=> primary selection
	Reverse Video Grey 	=> primary selection, marked for delete
	Underline		=> secondary selection
	Underline + Grey 	=> secondary selection, marked for delete

Maybe have standout be color selectable?

I have also seen NeWS windows draw a bounding box around selections marked.

Please, no arguments about whether these are the Right Thing to Do.
If GNUemacs had several stand-out modes, we could customize it
to do whatever we like as individuals.

--
	Bruce G. Barnett 	barnett@ge-crd.ARPA, barnett@steinmetz.ge.com
				uunet!steinmetz!barnett

ceb@ethz.UUCP (Charles Buckley) (02/19/89)

In article <50744@yale-celray.yale.UUCP> Ram-Ashwin@cs.yale.edu (Ashwin Ram) writes:

   In article <779@ethz.UUCP>, ceb@ethz.UUCP (Charles Buckley) writes:
   > While you're at it, how about simply having a hook to display the text
   > between the point and the mark in inverse-video, or standout mode, as
   > the jargoneurs would say?

   This comes up time and again.  I agree that something like this is needed.
   However, I would not like the text between mark and point to be in
   inverse-video all the time because the mark is used for different purposes in
   Emacs.  For example, when you M-> to the end of the file, Emacs leaves a mark
   at your previous position.

Excuse me that I  did not tell the whole story.  Yes, using  the
simple  scheme of always inverting the field between the point and
mark can lead to what hardened users  of EMACS might  find as an
unacceptably cluttered display at times.  However, the system from
which I took my cue (the Symbolics Zmacs editor) also provides an
escape from this which is much  simpler than the essentially
batch-mode heuristics you suggest,which is that any buffer modifying
command causes this inversionto be turned off.  

I like  this for its simplicity - I don't necessarily recommend doing
it this way.  Probably two keystroke commands, so you don't get beeped
at about a read-only buffer when all you wanted to do is do an
insertion and then undo it to turn off things, would be optimal.

Point remains:  All this is kitchen work, to be grown by users as they
like: only thing missing is an entry point into the speed-sensitive C
code to enable this inversion, probably a special variable or
something.  What happens afterward is `peoples choice'.

calm@calm.applicon.UUCP (02/22/89)

ethz.UUCP!ceb writes:
> ... spolsky-joel@CS.YALE.EDU (Joel Spolsky) writes:
>    ... liberte@m.cs.uiuc.edu writes:
> 
>    >Stallman and I have just now been discussing interval-local
>    >variables.  If we can figure out how to do it, he wants to add it
>    >to Emacs.
>    If the overhead was low enough, this might be a way to implement
>    proper formatting, such as bold mode, underline mode, etc,
> 
>    Then you'd have to find a way to display them...
> 
> While you're at it, how about simply having a hook to display the text
> between the point and the mark in inverse-video, or standout mode, as
                                    ^^^^^^^^^^^^^     ^^^^^^^^^^^^^
> the jargoneurs would say?  ...


   One should not presume that they're necessarily always the same.  My
preferred highlight rendition would be a bold style.  Particularly in an
emacstool window with more than one emacs window, where the mode-lines
that separate them are rendered in inverse-video.  Some terminals are
capable of more than one style of highlighting (SGR escape sequence,
accessible from TERMINFO or TERMCAP).  If a desired highlight treatment
(set in .emacs) is unavailable for a given display, the default could be
to use the basic standout mode.  Emacstool (on Sun's) should consult
~/.defaults for the user's /Tty/Bold_style preferrence. 

   Ashwin Ram's thoughtful comments about WHEN to highlight the region
are well taken.  Such a feature would be WONDERFUL! When selecting a
region, I frequently bounce the cursor around with `C-x C-x' to help
visualize the selection.  Unnecessary if it's highlighted and the
highlight is cleared after processing the region with a command. 

   Two occasions when I would particularly like to see this kind of
highlighting are:
   display of matching delimiters (instead of doing the cursor bounce)
   current match in searches and query-replace

--
Fred Calm      calm@applicon.com
               Schlumberger CAD/CAM, 829 Middlesex Tpke, Billerica, MA 01821
	       
 Is something VIOLENT going to happen to a GARBAGE CAN?
                   -- Zippy