Re: Another neat Eclipse'ism

[Paul Michael Reilly]

Stefan Monnier wrote:
> > > > While I try to do most of my editing from Emacs, occasionally I will
> > > > find myself using the Eclipse Java editor.  One of the more convenient
> > > > niceties, in the absence of auto-fill-mode, is having the print-margin
> > > > displayed.  This is a useful feature in its own right, i.e. show a 1
> > > > pixel background line in Emacs where the right margin is set.
> > > > Needless to say, I have not a clue how to implement it.
> > > Not 100% the same but there is column-marker-mode available (search the
> > > emacswiki).  It will highlight a given column iff the line is at least
> > > that long.
> > FWIW, column-marker.el is pretty cool but it pales by comparison to the
> > approach used in Eclipse.   The Eclipse solution is barely noticeable
> > whereas the Emacs highlighting solution is very much in your face. If truth
> > be told I like the merged notion of having multiple such column indicators
> > that can be tailored by width and face.  I have a strong hunch they will
> > need to be implemented at the C level.  I wonder how to do that ... and if
> > this is an itch I want to scratch right about now ...
>
> All the Elisp-level approaches are just hacks.  You might be able to get
> reasonably far at the Elisp level, depending on your tolerance to pain.
>
> But one question remains: for what is this meant?  If it's for
> `fill-column', then there's a problem with variable-width fonts since
> in that case fill-column has a variable pixel position.

Good question and very good point.  And this is where I get kind of
stuck in moving any further.  The answer to the question, if it is
one, may ramble but I'll try.  And the point about variable width
fonts means that the solution is by necessity either limited to
fixed-width fonts (more likely) or fairly complex.

About six months ago I started a Java, Eclipse based, project inside a
very loose organization --- little or no standards and a lot of ugly
existing code to fix/enhance or otherwise grok.  I also started using
a pair of 1920x1200 resolution monitors.  My preference is to keep the
width of code lines around 80 characters so that if and when they are
ever printed they look reasonable and to minimize the need to scroll.
That put me in a minority of one.  Most of the existing code seemed to
have been written by people who felt that entire methods should
consist of a single line of code ... well a slight exaggeration but it
makes the point.  Fixing this code in Emacs is a piece of cake between
C-x = and auto fill mode but in Eclipse it was a pain until I
discovered the existence of the print margin facility.  When using
Eclipse it serves as a constant and gentle reminder (mostly because it
is only 1 pixel wide and does not alter the existing text) of where
the (mostly imaginary) boundary is.

Because of the large monitors I started to keep a full screen instance
of Emacs running split vertically.  It was doing this that keyed off
the desire to have that low intensity margin indication.  With such a
large amount of screen real estate it is "nice" to know where the
boundary is but hardly necessary.

Then I read about column-marker.el where it mentions that some
languages with fixed column constraints, like Fortran, still are used.
This is where multiple, variable (pixel) width, faceable column
indicators make even more sense.  But useful enough to want to start
hacking at the graphics level?  I've another hunch that the solution
is platform dependent.  Certainly toolkit dependent which makes it a
lot of work for not a lot of bang.  In Eclipse it is easier because of
SWT.  If a solution was doable in a day or so with not a lot of risk
about breaking other code it might be worth pursuing.  I'm guessing
this is not the case.

So in a nutshell, my interest is less associated with fill-column and 
more closely related to showing grid-lines in a table or print margins 
in wysiwyg editor.

I think the solution for variable width fonts has to be distance based
and not so much a particular column number, i.e. more complicated
already.

> Personally, I use a much simpler solution: I use my right window border
> as "vertical column".  It has worked for as long as I remember (even
> under xterm) and it saves screen real estate.

This has the consequence of either having text off screen or folded
with ugly fringe arrows.  Both are past my pain threshold.  But I'll
confess that at one point I did think of using this solution.  It
certainly does work.

Thanks,

-pmr