Another neat Eclipse'ism

Another neat Eclipse'ism

[Paul Michael Reilly]

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.

-pmr

Re: Another neat Eclipse'ism

[David Hansen]

On Thu, 19 Jun 2008 03:58:25 -0400 Paul Michael Reilly 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.

David

RE: Another neat Eclipse'ism

[Drew Adams]

> > 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.

Yes, see this page:
http://www.emacswiki.org/cgi-bin/wiki/HighlightCurrentColumn

It also links to other pages that deal with this.

Re: Another neat Eclipse'ism

[Paul Michael Reilly]

David Hansen wrote:
> On Thu, 19 Jun 2008 03:58:25 -0400 Paul Michael Reilly 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 ...

-pmr

Re: Another neat Eclipse'ism

[Stefan Monnier]

>>> 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.

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.


        Stefan

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

Re: Another neat Eclipse'ism

[Lennart Borgman (gmail)]

Paul Michael Reilly wrote:
> 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.

Did you read

   http://www.emacswiki.org/cgi-bin/wiki/EightyColumnRule

Especially lineker.el at the bottom of the page might interest you. It 
will show which lines are too long (or gets too long) and it also lets 
you jump between them.

Re: Another neat Eclipse'ism

[Stefan Monnier]

> 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

Since the 80-columns rule has nothing to do with screen size but with
the human brain, maybe you can find some relevant software-engineering
principles (probably alongside cyclomatic complexity or something ;-).
It might allow you to make a stronger case.

>> 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.

That's OK: 99% of those cases need to be fixed, so I fix them.
The remaining cases where a long line is a better choice than the
alternatives are sufficiently rare that it's a non-issue.

> Both are past my pain threshold.

That's the intention: it compels you to fix the buggers.


        Stefan

RE: Another neat Eclipse'ism

[Drew Adams]

> > On Thu, 19 Jun 2008 03:58:25 -0400 Paul Michael Reilly 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.

Again:
http://www.emacswiki.org/cgi-bin/wiki/HighlightCurrentColumn

Some of the other aids are less in-your-face than col-highlight.el. Some are
"barely noticeable".

Re: Another neat Eclipse'ism

[Paul Michael Reilly]

Drew Adams wrote:
>>> On Thu, 19 Jun 2008 03:58:25 -0400 Paul Michael Reilly 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.
> 
> Again:
> http://www.emacswiki.org/cgi-bin/wiki/HighlightCurrentColumn
> 
> Some of the other aids are less in-your-face than col-highlight.el. Some are
> "barely noticeable".

Agreed.  In particular, vline mode with a suitable face is a reasonable 
solution.

-pmr

Re: Another neat Eclipse'ism

[Lennart Borgman (gmail)]

Paul Michael Reilly wrote:
> Drew Adams wrote:
>>>> On Thu, 19 Jun 2008 03:58:25 -0400 Paul Michael Reilly 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.
>>
>> Again:
>> http://www.emacswiki.org/cgi-bin/wiki/HighlightCurrentColumn
>>
>> Some of the other aids are less in-your-face than col-highlight.el. 
>> Some are
>> "barely noticeable".
> 
> Agreed.  In particular, vline mode with a suitable face is a reasonable 
> solution.


It looks very good IMO but unfortunately it sometimes hit bugs in Emacs 
display engine. See the Emacs Devel archives.

RE: Another neat Eclipse'ism

[Drew Adams]

> > Again:
> > http://www.emacswiki.org/cgi-bin/wiki/HighlightCurrentColumn
> > 
> > Some of the other aids are less in-your-face than 
> > col-highlight.el. Some are "barely noticeable".
> 
> Agreed.  In particular, vline mode with a suitable face is a 
> reasonable solution.

1. col-highlight.el *uses* vline.el. (It used to use column-marker.el.)

What applies to the face for vline.el applies also to the face for
col-highlight.el. See option `col-highlight-vline-face-flag', which lets you
choose between `col-highlight-face' and `vline-face'.

2. FWIW, http://www.emacswiki.org/cgi-bin/wiki/ModeLinePosition is perhaps even
less noticeable. It highlights the column in the mode line when greater than
some limit.

BTW, a year ago, Richard asked that this be installed in Emacs, but I can't see
that it was. If it was, what is the user-definable column limit variable?

[2007-06-24: Thread "mode line: 1) indicate region size, if active; 2) highlight
column # if > limit".]

3. If you are trying to shorten particularly long lines in code, you might also
be interested in this:
http://www.emacswiki.org/cgi-bin/wiki/FindLongLines#goto-longest-line

This is particularly handy to use with Isearch. isearch+.el binds
`goto-longest-line' to `C-end': `C-s C-end C-end C-end...'
http://www.emacswiki.org/cgi-bin/wiki/IsearchPlus