virtual space?

virtual space?

[Michael Durland]

Is there a way to tell emacs to allow the cursor to move anywhere in a
window?  By default, the cursor seems to be restricted to only move where
there is actually text in the open file.  This is a common option in other
editors.

Thanks,
Mike

Re: virtual space?

[Sudarshan S. Chawathe]

"Michael Durland" <mdurland@ix.netcom.com> writes:

> Is there a way to tell emacs to allow the cursor to move anywhere in a
> window?  By default, the cursor seems to be restricted to only move where
> there is actually text in the open file.  This is a common option in other
> editors.

M-x picture-mode

Re: virtual space?

[Michael Durland]

"Sudarshan S. Chawathe" <chaw@cs.umd.edu> wrote in message
news:m3oewcki9r.fsf@Buckbeak.cs.umd.edu...
>
> "Michael Durland" <mdurland@ix.netcom.com> writes:
>
> > Is there a way to tell emacs to allow the cursor to move anywhere in a
> > window?  By default, the cursor seems to be restricted to only move
where
> > there is actually text in the open file.  This is a common option in
other
> > editors.
>
> M-x picture-mode
>
I tried picure-mode, but that seems to insert tabs into the file as soon as
the cursor is moved into empty space.  I don't want to modify the file, I
just want to be able to move the cursor anywhere.  Only if I start typing in
that empty space, then I do want it to fill the empty space with tabs and/or
spaces.

Re: virtual space?

[Björn Lindström]

"Michael Durland" <mdurland@ix.netcom.com> writes:

> I tried picure-mode, but that seems to insert tabs into the file as
> soon as the cursor is moved into empty space.  I don't want to modify
> the file, I just want to be able to move the cursor anywhere.  Only if
> I start typing in that empty space, then I do want it to fill the
> empty space with tabs and/or spaces.

Why would you want to move the cursor somewhere if you don't plan to
edit anything there?

-- 
Björn Lindström <bkhl@elektrubadur.se>
http://bkhl.elektrubadur.se/

Re: virtual space?

[Michael Durland]

> > I tried picure-mode, but that seems to insert tabs into the file as
> > soon as the cursor is moved into empty space.  I don't want to modify
> > the file, I just want to be able to move the cursor anywhere.  Only if
> > I start typing in that empty space, then I do want it to fill the
> > empty space with tabs and/or spaces.
>
> Why would you want to move the cursor somewhere if you don't plan to
> edit anything there?

Having the cursor move to somewhere where I didn't tell it to go is
annoying.  For example, imagine holding down the up or down arrow key to
move some distance in a file, like from the bottom of a window to somewhere
in the middle.  The cursor should move directly up the column it started in.
But emacs doesn't do that.  The cursor jumps around all over the place.  It
is very distracting.  Regardless of where typing actually occurs, the cursor
shouldn't move except exactly where it's told to go.  If I tell it to go up,
it should go up one line and not change columns.  Period.

I researched this a little more and indeed this is not something that can be
changed in emacs.  Furthermore, I found posts in newsgroups asking for this
feature going back to at least 1998, 5 years.  Every good editor I've ever
used has virtual space.  I find it hard to believe that the most well
known/respected best editor on the planet can't do it.  Can someone please
point me to how to submit a wishlist request for the next version of emacs?
I really want to learn this great editor, but stuff like this is
frustrating.  When I need to work on UNIX where I don't have my trusty TSE
Pro, I was hoping I could customize emacs to do what I need.  But it just
lacks key features.  e.g. virtual space and popup windows being the ones I
can't live without.  Emacs windows and frames do not cut it for popup
windows.  On this note, I saw another post requesting popup windows as well,
e.g. in order to implement something akin to the C++ class member
autocompletion popups of many editors.  I read this can be somewhat faked
with the new tooltip concept, but it is not a complete solution. *sigh*

Re: virtual space?

[Dan Anderson]

	You know it's interesting; virtual space as I think I understand it
would probably break a lot of macros people like me have collected. 
(Granted it could be thrown in its own mode -- thus reducing the
likelihood of breakage).  So I suppose this "problem" could be construed
as a feature.

	But even so, just to run a quick check I opened up vi.  Vi did not use
virtual space.  Neither does my word processor.  So I'm trying to figure
out how it could possibly be so ubiquitous.

	I suppose if you really wanted to you could hire a poor unemployed
programmer to create these things for you, and then share it with the
community.  If you really want it that bad.

	But perhaps this just shows that not all tools are useful for
everyone.  Some people love vi, and hate emacs.  (Although they will
forever burn in hell for straying from the path of the One True
Editor).  That's fine.  It's preference.

	Use the editor that suits you.  If you want an IDE with a nice GUI,
emacs may not be for you.  If you enjoy all the features many of us do,
and don't really care about GUIs, Emacs may be for you.

</2 Cents>

Dan

Re: virtual space?

[Eli Zaretskii]

> From: "Michael Durland" <mdurland@ix.netcom.com>
> Newsgroups: gnu.emacs.help
> Date: Tue, 21 Oct 2003 01:52:28 GMT
> 
> I find it hard to believe that the most well known/respected best
> editor on the planet can't do it.

Perhaps because it's much easier to get used to Emacs's behavior wrt
cursor movement than to implement the feature you want.

> Can someone please point me to how to submit a wishlist request for
> the next version of emacs?

Please write to emacs-devel@gnu.org.

> I really want to learn this great editor, but stuff like this is
> frustrating.  When I need to work on UNIX where I don't have my trusty TSE
> Pro, I was hoping I could customize emacs to do what I need.  But it just
> lacks key features.  e.g. virtual space and popup windows being the ones I
> can't live without.

Can you explain why do you need the popup windows so badly (and what
do you mean by that, exactly)?  You gave one example, but is that
really all there is to it?

> Emacs windows and frames do not cut it for popup
> windows.  On this note, I saw another post requesting popup windows as well,
> e.g. in order to implement something akin to the C++ class member
> autocompletion popups of many editors.  I read this can be somewhat faked
> with the new tooltip concept, but it is not a complete solution. *sigh*

Emacs has an optional feature to cause it pop up a new frame
(``window'' in your parlance) to display comlpetion results.  See the
documentation of the variable `special-display-buffer-names'.  Why
isn't this sufficient?

Re: virtual space?

[Barman Brakjoller]

> > Why would you want to move the cursor somewhere if you don't plan to
> > edit anything there?
> 
> Having the cursor move to somewhere where I didn't tell it to go is
> annoying.  For example, imagine holding down the up or down arrow key to
> move some distance in a file, like from the bottom of a window to somewhere
> in the middle.  The cursor should move directly up the column it started in.
> But emacs doesn't do that.

I agree with you and I disagree with you:

1. I am annoyed with all people that answers "M-x picture-mode" to
this question all the time, when they clearly (yes, I really believe
that) see that in most cases picture-mode is not what the person
wants.

2. I understand that you are frustrated by the cursor jumping around,
I can see your point from a GUI/user experience point of view. But as
someone here said, are there any "real" benefits from this virtual
cursor? If there were I would expect that someone actually implemented
it in emacs. What do you want to *do* in that virtual place?

Hmm, come to think of it, I can actually find a valid use for it.
Imagine this text in a buffer:

blah blah blah
blah blah<-buffer ends here

If you have the buffer text above, it is *impossible* to copy a
rectangle with  all the content of the buffer without needing to add
extra spaces at the end of the last line to get the cursor to the same
column as the third "blah" on the first line. Right? Having a virtual
cursor would solve the problem.

Anyway, this is no big problem for *me*.

/Mathias

Re: virtual space?

[Stefan Monnier]

> Hmm, come to think of it, I can actually find a valid use for it.
> Imagine this text in a buffer:

> blah blah blah
> blah blah<-buffer ends here

> If you have the buffer text above, it is *impossible* to copy a
> rectangle with  all the content of the buffer without needing to add
> extra spaces at the end of the last line to get the cursor to the same
> column as the third "blah" on the first line. Right?

Of course you can: place point at beginning of second line press C-SPC,
then press C-p C-e to go to the end of first line and C-x r k to kill
the rectangle.

But your point does hold in the following case:

blabla
blablabla
blabla

> Having a virtual cursor would solve the problem.

There are two other ways to solve the problem:
- use SPC instead of C-f (if you also use transient-mark-mode, this will
  turn off the mark, so you'll need to hit C-x C-x when done to reactivate
  it).
- use CUA, which has a very good support for rectangles, including special
  commands to highlight/grow/shrink/shift the currently selected rectangle,
  and which inserts spaces as needed, just like picture-mode.

> Anyway, this is no big problem for *me*.

Neither is it for me.  At first, it would seem like it'd be very difficult
to implement, but now that I think about it, I believe it can be done purely
in elisp: When going "past the last char" of a line, just add an overlay at
the end of the line with an `after-string' property of "     ".  At least
here (Emacs-CVS), it seems to move the cursor according to the number of
spaces you've put, so you can place the cursor where you want on screen
without modifying the buffer text.  The tricky part will be to make the
other commands work correctly by replacing the overlay with actual spaces
before doing an insertion.


        Stefan

Re: virtual space?

[Michael Durland]

"Stefan Monnier" <monnier@iro.umontreal.ca> wrote in message
news:jwv65ii8wwd.fsf-monnier+gnu.emacs.help@vor.iro.umontreal.ca...
> > Having a virtual cursor would solve the problem.
>
>
> Neither is it for me.  At first, it would seem like it'd be very difficult
> to implement, but now that I think about it, I believe it can be done
purely
> in elisp: When going "past the last char" of a line, just add an overlay
at
> the end of the line with an `after-string' property of "     ".  At least
> here (Emacs-CVS), it seems to move the cursor according to the number of
> spaces you've put, so you can place the cursor where you want on screen
> without modifying the buffer text.  The tricky part will be to make the
> other commands work correctly by replacing the overlay with actual spaces
> before doing an insertion.
>

This sounds cool!  So is it possible to implement a virtual cursor entirely
as an overlay?  I'm imagining that the real cursor would have to be hidden,
but always follow the virtual cursor where there is text.  Where there isn't
text, the virtual cursor would travel away from the real cursor.  Then when
the virtual cursor got back on to real text, they would sync up again.  If
text was inserted at the virtual cursor, yes whitespace would need to be
added to pad the real cursor out to the virtual cursor, but this is
expected.  I know a little about overlays, but not enough to write one from
scratch.  I'm learning.  Any guidance down this path would be appreciated.

Thanks,
Mike

Re: virtual space?

[Michael Durland]

"Eli Zaretskii" <eliz@elta.co.il> wrote in message
news:mailman.2047.1066715377.21628.help-gnu-emacs@gnu.org...
>
> Emacs has an optional feature to cause it pop up a new frame
> (``window'' in your parlance) to display comlpetion results.  See the
> documentation of the variable `special-display-buffer-names'.  Why
> isn't this sufficient?
>

Is there a way to show these spawned special frames without an actual
"frame" around them?  That is, just the window contents with no title bar,
no resizing border, etc.  Just the actual contents inside the frame?  That
way it could appear on top of the existing frame and have the appearance
that it is part of the same frame.  I found how to specify some properties
of the frame, like position and size, but I didn't figure out how to specify
system properties like what "style" the spawned frame has.  Another example
where this is useful is to have a virtual ruler that floats around over the
text.  This can be used to measure how wide strings are.  I have found this
feature useful in the past.  With a real frame, the "frame stuff" gets in
the way of the actual contents, which in this case would be numbers with
tick marks as periods.  Maybe this particular example could be done with an
overlay.  I'll see if I can look into that.

Thanks

Re: virtual space?

[Eli Zaretskii]

> From: "Michael Durland" <mdurland@ix.netcom.com>
> Newsgroups: gnu.emacs.help
> Date: Wed, 22 Oct 2003 01:26:00 GMT
> >
> > Emacs has an optional feature to cause it pop up a new frame
> > (``window'' in your parlance) to display comlpetion results.  See the
> > documentation of the variable `special-display-buffer-names'.  Why
> > isn't this sufficient?
> 
> Is there a way to show these spawned special frames without an actual
> "frame" around them?  That is, just the window contents with no title bar,
> no resizing border, etc.  Just the actual contents inside the frame?

I don't understand why is this an issue (can you explain?), but it
sounds like the default Emacs behavior, whereby the possible
completions are shown in a window in the same frame, should satisfy
your needs, since there's no new frame borders involved.  What am I
missing?

> That way it could appear on top of the existing frame and have the
> appearance that it is part of the same frame.

A separate window popped by Emacs by default in the same frame is, in
fact, part of the same frame.  What's wrong with that?

> I found how to specify some properties
> of the frame, like position and size, but I didn't figure out how to specify
> system properties like what "style" the spawned frame has.

What do you mean by the frame's ``style''?

> Another example where this is useful is to have a virtual ruler that
> floats around over the text.  This can be used to measure how wide
> strings are.

You can easily find out the length of a string in Emacs without any
ruler.

> I have found this feature useful in the past.

Any other useful applications of the ruler, besides string length?

> With a real frame, the "frame stuff" gets in the way of the actual
> contents, which in this case would be numbers with tick marks as
> periods.

It is possible, at least in principle, to have frames without borders
(that's how Emacs creates tooltips, a.k.a. ``balloon help''), if that
is important, although I don't think you can do that now in Emacs.

Re: virtual space?

[Kevin Rodgers]

Eli Zaretskii wrote:

>>From: "Michael Durland" <mdurland@ix.netcom.com>
>>Newsgroups: gnu.emacs.help
>>Date: Wed, 22 Oct 2003 01:26:00 GMT
>>
>>>Emacs has an optional feature to cause it pop up a new frame
>>>(``window'' in your parlance) to display comlpetion results.  See the
>>>documentation of the variable `special-display-buffer-names'.  Why
>>>isn't this sufficient?
>>
>>Is there a way to show these spawned special frames without an actual
>>"frame" around them?  That is, just the window contents with no title bar,
>>no resizing border, etc.  Just the actual contents inside the frame?
>
> 
> I don't understand why is this an issue (can you explain?), but it
> sounds like the default Emacs behavior, whereby the possible
> completions are shown in a window in the same frame, should satisfy
> your needs, since there's no new frame borders involved.  What am I
> missing?


He liked your suggestion to display the *Completions* buffer in its own
frame, via special-display-buffer-names.  But he wants it displayed
without any window manager decorations.

>>That way it could appear on top of the existing frame and have the
>>appearance that it is part of the same frame.
> 
> A separate window popped by Emacs by default in the same frame is, in
> fact, part of the same frame.  What's wrong with that?

He wants the buffer/window to have a separate (special) frame.


>>I found how to specify some properties
>>of the frame, like position and size, but I didn't figure out how to specify
>>system properties like what "style" the spawned frame has.
> 
> What do you mean by the frame's ``style''?

I think he wants a new frame property (e.g. window-manager-decorations) that he
could specify in special-display-frame-alist.

...


>>With a real frame, the "frame stuff" gets in the way of the actual
>>contents, which in this case would be numbers with tick marks as
>>periods.
>>
> 
> It is possible, at least in principle, to have frames without borders
> (that's how Emacs creates tooltips, a.k.a. ``balloon help''), if that
> is important, although I don't think you can do that now in Emacs.

Exactly -- but why not?


-- 
Kevin Rodgers

Re: virtual space?

[Eli Zaretskii]

> From: Kevin Rodgers <ihs_4664@yahoo.com>
> Newsgroups: gnu.emacs.help
> Date: Wed, 22 Oct 2003 09:55:02 -0600
> > 
> > I don't understand why is this an issue (can you explain?), but it
> > sounds like the default Emacs behavior, whereby the possible
> > completions are shown in a window in the same frame, should satisfy
> > your needs, since there's no new frame borders involved.  What am I
> > missing?
> 
> 
> He liked your suggestion to display the *Completions* buffer in its own
> frame, via special-display-buffer-names.

I understood that.

>  But he wants it displayed without any window manager decorations.

I understood that, too, but didn't understand _why_ he wants that, and
asked for explanations.

> > A separate window popped by Emacs by default in the same frame is, in
> > fact, part of the same frame.  What's wrong with that?
> 
> He wants the buffer/window to have a separate (special) frame.

I understood that, but didn't understand why.

> > It is possible, at least in principle, to have frames without borders
> > (that's how Emacs creates tooltips, a.k.a. ``balloon help''), if that
> > is important, although I don't think you can do that now in Emacs.
> 
> Exactly -- but why not?

Because no one has coded it, I guess.  See x_create_tip_frame for how
it is done; someone needs to add similar code to the function
x-create-frame which is used to create all the other frames on
graphics displays.

Re: virtual space?

[Kai Grossjohann]

"Eli Zaretskii" <eliz@elta.co.il> writes:

>>  But he wants it displayed without any window manager decorations.
>
> I understood that, too, but didn't understand _why_ he wants that, and
> asked for explanations.

The completion popups of Eclipse look a lot like tool-tips and they
are displayed near point.  Maybe that's what he wants.

I think having the completions displayed near point has some value --
on a big display your eyes would otherwise have to travel a lot.

On the other hand, displaying a popup near point for less eye travel
makes sense only if the popup is small.  And to make it so, it needs
to either contain few characters, or a small font.  I find that popups
with few characters are unreadable, due to the scrolling involved, and
popups with a small font are also unreadable.

Yeah, that might be what I dislike about the Eclipse tooltip-like
completion popups.  They are too damnes tiny!

Kai

Re: virtual space?

[Stefan Monnier]

> I don't understand why is this an issue (can you explain?), but it
> sounds like the default Emacs behavior, whereby the possible
> completions are shown in a window in the same frame, should satisfy
> your needs, since there's no new frame borders involved.  What am I
> missing?

He's thinking of something like the mini completion window that pops up
right underneath the text you're editing (the only place where I've
experienced that first hand is in mozilla where I type the URL).
It's like the offspring of a tooltip and a completion buffer.

For such functionality I think that x-show-tip is just sufficient.


        Stefan

Re: virtual space?

[Kai Grossjohann]

"Michael Durland" <mdurland@ix.netcom.com> writes:

> Having the cursor move to somewhere where I didn't tell it to go is
> annoying.  For example, imagine holding down the up or down arrow key to
> move some distance in a file, like from the bottom of a window to somewhere
> in the middle.  The cursor should move directly up the column it started in.
> But emacs doesn't do that.  The cursor jumps around all over the place.  It
> is very distracting.  Regardless of where typing actually occurs, the cursor
> shouldn't move except exactly where it's told to go.  If I tell it to go up,
> it should go up one line and not change columns.  Period.

That's really interesting.  It never occurred to me that somebody
would want to have the cursor in a spot where there is no character in
the file.  Just goes to show how people are different and have
different expectations.

FWIW, exiting picture-mode removes trailing spaces on lines.  That's
intended to remove the spaces it added itself, but of course that
feature has its own problems -- it could remove spaces that were there
before.

Hm.  I think you could kind of fake things by doing something similar
to picture mode.  But instead of just adding whitespace to the end of
the line, you mark the whitespace with a special text property.  Then,
when the cursor leaves the line, you can remove the whitespace again.
Or you remove the whitespace on saving the buffer.

Another piece of data is that the cursor remembers the column it likes
to be in.  That is, if you're on column 27 and move across a line with
less characters into a line with more than 27 characters, then the
cursor will still be in column 27 in the long line.  It will just be
towards the left in the short line.

Yet another piece of data is the track-eol variable.  I set it to
true.  It's way cool.  But I think it's kind of the opposite behavior
of what you want 8-)

> I researched this a little more and indeed this is not something
> that can be changed in emacs.

Hah!  Few things are impossible here ;-)  Just a SMOP...

> But it just lacks key features.  e.g. virtual space and popup
> windows being the ones I can't live without.  Emacs windows and
> frames do not cut it for popup windows.  On this note, I saw another
> post requesting popup windows as well, e.g. in order to implement
> something akin to the C++ class member autocompletion popups of many
> editors.  I read this can be somewhat faked with the new tooltip
> concept, but it is not a complete solution. *sigh*

I've always found them popup thingies to be a kind of a pain in the
neck.  At the moment I use Eclipse for Java coding, and it uses
tooltip-like popup windows for completion.  The Eclipse implementation
is quite good, but I'm still not convinced...

Emacs just opens a new window for completion.  Type C-x C-f TAB TAB to
see that window in action.  Maybe with much wailing and gnashing of
teeth, you can get used to these windows.

(What Emacs calls a window is probably different from what everybody
else calls a window.  Type C-x 2 and now you have two windows.)

Kai