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