🚀 go-pugleaf

hofmann@cs.uiuc.edu (hofmann) writes:

      IMHO, I think that formating the the text is a bad idea because then you
   move away from the "just text" nature of un*x files and toward the extremely
   program-dependant (and nonportable, and more difficult to transmit) format of
   PCs such as the Macintosh.

I don't agree.  It would certainly be a bad idea to have "universal"
formatting, such as Word uses -- where every data file must contain
specific formatting information in order for the editor to be able to
handle it.  But that was never in the cards anyway.

It would be extremely useful for Emacs to provide support for
developing major modes capable of doing formatting based on the
contents of a file.  Ideally (I don't expect this to actually happen),
one would be able to construct an Emacs *Word* mode that would read
Word files, edit them in WYSIWYG fashion with Word functionality (on
systems with X-Windows), and output properly formatted Word files.

Less ambitiously, C mode could be rewritten to display comments in an
italic font and function headers in bold; LaTeX mode could display
formatting commands in a different color, etc.  Extensibility and
customizability are the important things.

	-- Bill

In article <BILL.92Jun24132115@cortex.nsma.arizona.edu>, bill@nsma.arizona.edu (Bill Skaggs) writes:
> It would be extremely useful for Emacs to provide support for
> developing major modes capable of doing formatting based on the
> contents of a file. 

This is possible with Epoch currently, it would just be _very_
painful.

> Less ambitiously, C mode could be rewritten to display comments in an
> italic font and function headers in bold; LaTeX mode could display
> formatting commands in a different color, etc.

This already exists and is in use. In fact, I think that there are
several independent packages to do this. I know we built one in house
and there is at least one NIH package (which, to be honest, works
better).

I was at the Emacs BOF at the X conference a couple of years ago and
this very same topic came up (surprise!) and lead to a somewhat
rancorous debate that settled nothing. The same two camps arose
(embedded controls vs. pure text). Of course, the _real_ solution is a
better file system that allows you have parallel "data segments" in a
file (ala multiples files but grouped together by the OS and easily
handled as a unit by things such as cp). Barring this, I personally
favor the Epoch (pure text) solution as it is backwards compatible.
Too many other programs depend on a pure text stream.

-- 
Alan M. Carroll          "Weren't there yams involved, too?" - J. Ockerbloom
Epoch Development Team   
Urbana Il.               "I hate shopping with the reality-impaired" - Susan

OK, I have been watching this discussion for a while, and I just have one
question: What (other than being slightly clumsy) is wrong with using
the existing emacs local variables mechanism, together with temporary
highlighting to, in effect, create permanent highlighting.

A local variable could either hold a (probably large) alist of information
about the formating of various regions, or it could simply point to
another file where that information is held.

Another local variable spec could install a write file hook which updates
the list of highlighted regions when the file is written.

Not very elegant, perhaps, but it seems like it would work, could be done
with a little elisp code (once it is possible to have "temporary"
highlighting in buffers), and would use only mechanisms which already exist
in emacs.

Just wondering...
--
======================================================================
domain: tahorsley@csd.harris.com       USMail: Tom Horsley
  uucp: ...!uunet!hcx1!tahorsley               511 Kingbird Circle
                                               Delray Beach, FL  33444
+==== Censorship is the only form of Obscenity ======================+
|     (Wait, I forgot government tobacco subsidies...)               |
+====================================================================+

In article <TOM.92Jun25080511@amber.ssd.csd.harris.com> tom@ssd.csd.harris.com (Tom Horsley) wrote:
>
> OK, I have been watching this discussion for a while, and I just have one
> question: What (other than being slightly clumsy) is wrong with using
> the existing emacs local variables mechanism, together with temporary
> highlighting to, in effect, create permanent highlighting.

Basically, because you want acceptable behavior on the degenerate case of
a multi-megabyte file with lots and lots of font changes.  To do this, you
need something more sophisticated than an alist of endpoints.

Also, markers can't be involved, because the time that insertions take
goes up linearly with the number of markers in the buffer.  (A substantial
reimplementation of markers would fix this, but would be pretty much the
same amount of work as a decent implementation of "regions" (whatever
you're calling them).  We've considered making markers be implemented as
zero-length regions because of this.)

In article <9206242107.AA01431@hugo.lucid> jla@lucid.com (Joseph Arceneaux) wrote:
> 
> The idea is that there is a fundamental distinction between buffer
> text and its properties (e.g., italics), and visual indicators such as
> highlighting selected text, or the the gdb arrow, or marker glyphs
> pointing to various buffer positions.  The text and its properties are
> persistent entities which exist after emacs has finished, while
> overlays such as highlighting are temporary indicators having more to
> do with editing operations.
> 
> This distinction is completely separate from the implementation
> mechanisms, which could be the same.

My take on the whole "properties of the text" versus "visual overlays" thing
is that yes, there is a difference, but it's not a significant enough one to
warrant a distinct implementation for the two.  Both need to have equally
good performance characteristics.

Another thing that I think is worth noting is that, as far as I know, there
aren't any word processors that actually attach "font" information to
characters.  Now I'm not exactly a word processor guru, so maybe I've just
led a sheltered life; I'm sure someone will come up with a counter-example
if this isn't true, but all the word processors I've ever seen behave as if
they use the "overlay" style of formatting while editing, and then put that
information into the file (in whatever encoding) when the file is written.
At least, this is the impression they give from their behavior.

For example: suppose there was a boldface word in the middle of otherwise
plain text.  If you moved the insertion point into the middle of that word
and typed a character, that character would be inserted in boldface in every
word processor I've seen.  The "fonts attached to characters" model would
suggest that it should be inserted in whatever the current "global" font was.
That it is inserted in bold suggests to me that there is a "bold region" in
the buffer, -not- that this particular set of characters, which just happen
to be consecutive, have the "bold" bit set on them.

	-- Jamie

PS: It's true that Zmacs attached font bits to characters, but there were
    enough silly things about the way Zmacs dealt with fonts that it really
    wasn't much of a "word processor."  It certainly wasn't WYSIWYG by any
    stretch of the imagination.

I while back a posted a "folding mode" to gnu.emacs.sources.  One of the
features I would very much like to see in a future Emacs is temporary
formatting, because sometimes it is nice to be able to edit something
that doesn't look like the low-level text underlying it.  With reference
to a folding mode, the lisp code decides where text formatting should go
when Emacs reads a file (in the form of hidden regions of text), as
opposed to having it as part of the file itself (and in fact changes the
view, which I would like to do without modifying the text of the file).
Emacs already has a simple capability for hiding some text by narrowing,
and a slightly more destructive technique for selective-display.

Similar ideas apply to other program-specified formatting, such as
colours in a C program, or highlighted menus in an Info buffer.  Those
things ought not to be stored as part of the text, although where they
are placed at edit time is determined by the text, as interpreted by the
lisp code that looks at it.

I would much rather see a facility wherby the text displayed in a
particular window is determined by some lisp structure, which holds
something like a list, whose elements each refers to a region of text
from an arbitrary buffer, and some property information.  Then
information from several buffers could be displayed.  I think this would
be most useful for displaying bits of text from a buffer, and a little
more text from a temporary buffer, so for example Emacs could display
some dynamic, informative symbols in a document being word-processed,
but which are not truly part of the text.  Would that really be so
difficult to implement?

Jamie
--
Wibble.