GNU emacs 22 goes into pretest [LWN.net]

GNU emacs 22 goes into pretest

Posted Oct 29, 2006 18:21 UTC (Sun) by dh (subscriber, #153) [Link] (6 responses)

Well, Emacs...

I've never understood what's so great about this program. Ok, I used it
myself for long times for C and Java program editing, for TeX editing and
for editing in general. And most things worked. But it was awkward.

I never understood how this thing was supposed to be configured. Ok,
Scheme. I learned Scheme during my studies. I was rather good in
programming Scheme. But has anyone anywhen tried to learn Emacs
configuration in Scheme from the documentation? I failed miserably. Ok,
somehow I managed to reconfigure the key assignment - but I always felt
that I did it wrong. And I never succeeded in any further customization. I
simply did not understand why AucTeX or that Java extension/mode sometimes
worked and sometimes did not.

I started moving away from Emacs as my Java editor back in 2002. Trying
JEdit and Netbeans I finally found Eclipse. Geez, was I happy! Not only
that it did what I expected it to do, I also understood how I could
configure it to do these things the way I wanted. I did not miss that
Emacs thing for a second. Same with kate for the TeX sources and OOo for
the rest.

Back in 1995, I heard RMS' key note at the Linux Kongress in Berlin,
Germany. Two details of that speech come to my mind: (a) He accused SGML
to be a "facist language" (which I found rather problematic, especially
regarding the location) and (b) he claimed that Emacs will become similar
to Word within the next years. I do not remember the exact schedule he had
in mind, but if things had happened the way he announced, we would have a
Word-like Emacs for some years these days.

Even back then I thought: "My friend, how do you want to make 'Emacs as
Word' as long as not even the menus look as people expect them for a
graphical application." At least until late 2002, there was no change in
the general menu machinery and I doubt that anything has changed since
then. Things like the announcement of "Antinews" show me, that Emacs is as
geeky as it used to be. Unfortunately, the user base has changed
drastically during the last ten years and this has not increased the
percentage of geeks.

Emacs great times are over. With or without a version 22.

Ciao, Dirk

GNU emacs 22 goes into pretest

Posted Oct 29, 2006 18:45 UTC (Sun) by smoogen (subscriber, #97) [Link]

Well if it doesnt work for you, it doesnt work for you. Each brain is programmed differently, and there is no way to get a non-Emacs brain to understand Emacs. Nothing wrong with that.. but it doesn't make an editor better or worse than another (or why people who have vi/emacs/eclipse wars dont understand the problem.)

A) Emacs uses lisp not scheme. They are somewhat similar but different. Emacs was written on systems long ago that used lisp as their main language.

B) Trying to get RMS to understand other editors is like trying to get your mind to understand emacs. Its not going to work. And with his glacial pace of making things perfect.. I expect Emacs-Word to exist in 2251.

GNU emacs 22 goes into pretest

Posted Oct 29, 2006 18:57 UTC (Sun) by iabervon (subscriber, #722) [Link] (4 responses)

I've been forced to drop every editor I've tried in the past decade, because I copy and move text with the kill ring. Every other editor I've used has either not supported ^K the way I expect or (worse) not supported ^Y.

GNU emacs 22 goes into pretest

Posted Oct 29, 2006 23:39 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

Or has not supported C-u C-SPC. How anyone can work without the ability to
navigate back to `significant points I was at last' is quite beyond me.

Plus, of course, there's the customizability. How anyone can have laboured
under the misapprehension that Emacs is customized via Scheme is beyond
me, when the user's guide says otherwise, the manual *named*
emacs-lisp-intro says otherwise, and the entire damn manual named `elisp'
says otherwise... well. The fault is not in the manual but in the person
who had his brain turned off when he read it, I fear. :/

significant point

Posted Oct 30, 2006 11:46 UTC (Mon) by man_ls (guest, #15091) [Link]

How anyone can work without the ability to navigate back to `significant points I was at last' is quite beyond me.

Eclipse has that, and with two handy arrows; three in fact, with an additional "last edit point". I'm using lyx for an article right now, and I miss this feature big time.

GNU emacs 22 goes into pretest

Posted Oct 31, 2006 13:30 UTC (Tue) by tcabot (subscriber, #6656) [Link]

C-u C-SPC! I like emacs because even though I've been using it for a few years I still learn something every time people talk about it. Thanks for the tip, nix.

GNU emacs 22 goes into pretest

Posted Nov 1, 2006 8:02 UTC (Wed) by jasonspiro (guest, #38047) [Link]

You reminded me: Does Vim have any kill-ring-like feature, or can one be added by Vim scripting? Such a thing would be great to have.

Debian packages

Posted Oct 29, 2006 19:41 UTC (Sun) by rfrancoise (subscriber, #15508) [Link]

Debian unstable users can just `apt-get install emacs-snapshot-gtk' to get it.
For other Debian/Ubuntu releases, see http://emacswiki.org/cgi-bin/wiki/EmacsCvsAndDebian

GNU emacs 22 goes into pretest

Posted Oct 29, 2006 22:54 UTC (Sun) by moxfyre (guest, #13847) [Link] (2 responses)

So... I'm confused. Is Emacs 22 actually a GTK app? Or does it just look like one?

Is there a good page with screenshots and a bullet-point feature list?

GNU emacs 22 goes into pretest

Posted Oct 29, 2006 23:51 UTC (Sun) by jeroen (guest, #12372) [Link]

Yes, you can compile Emacs 22 with GTK2 support.

GNU emacs 22 goes into pretest

Posted Oct 30, 2006 1:16 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link]

Well, for reasonably exponential values of "page" there is
http://www.emacswiki.org/cgi-bin/wiki

Emacs is dead?

Posted Oct 30, 2006 1:05 UTC (Mon) by alessandro.russo (guest, #6471) [Link] (1 responses)

I found some interesting comments here:

http://dmy999.com/article/2/eclipse-and-the-death-of-emacs

Ciao

Ale

No, just misunderstood

Posted Oct 30, 2006 3:15 UTC (Mon) by wjhenney (guest, #11768) [Link]

Interesting, perhaps, but not particularly well-informed, judging by comments like "The biggest weakness of Emacs is its [sic] lack of structural understanding of code." He doesn't seem to know about semantic and ECB, for instance. I'm not saying that these are better than Eclipse (I've never seriously used either), but it is not true that source parsing and IDE-like features are not available for emacs.

Fanning the flames...

Posted Oct 30, 2006 12:00 UTC (Mon) by jonth (guest, #4008) [Link] (25 responses)

Whilst I am, in most respects, a fully committed member of the GNU-Linux/OSS fanboy club, my one weakness is over a good text editor/IDE. I've tried at least ten different open source editors and never been able to live with any of them for any great length of time. In the end, I can't face the loss of productivity I suffer when I try to use the alternatives. I find the current crop of choices sufficiently deficient that I'm prepared to put my money where my mouth is and buy a proprietary editor (SlickEdit).

If you're interested, my #1 functionality requirement (I have lots of others, but this is the main one) is good tag support: I want to be able to select a set of files organised in an arbitrary structure (Kdevelop & Eclipse, take note) and then to be able to select a symbol with a mouse and be shown all places it's referenced and where it is defined. I want this to happen in whatever language I happen to be using (currently C/C++ Perl and Python). You'd be amazed how many editors don't provide this functionality, even for one language.

Fanning the flames...

Posted Oct 30, 2006 13:13 UTC (Mon) by nix (subscriber, #2304) [Link] (8 responses)

Both the Emacsen have done this for, oh, decades. Look up 'tags' in the manual.

(Were they the first editors off the Lisp Machine to implement tagging? I'd not be surprised, but I don't know...)

Fanning the flames...

Posted Oct 30, 2006 15:06 UTC (Mon) by jonth (guest, #4008) [Link] (7 responses)

Well, only if you create the etags file and keep it up to date. Can anyone spot the race condition there? Really, I shouldn't have craft a makefule to do this and remember to update it when I save the file - the editor should just "know" that it's a sensible thing to do just from the file type.

The closest I've seen to an editor doing this correctly is Geany, which seems to do this automatically for all currently open files. But I don't want all 2000 files in my project open at the same time - just the ones I'm interested in right now. (Geany looks really promising - with VCS integration and project support, it would tick enough of the boxes for me to leave SlickEdit behind - and I really would like to do that.)

<rant>

I've lost count of the number of times I've been told "but <substitute your favourite editor here> already supports that" for any particular feature. The point is that this sort of functionality should "just work." I want to program my computer, not my editor!

This sort of thing used to be common in the Linux world generally, but the user-friendliness focus of distros like Ubuntu, Linspire, Xandros has had a hugely positive effect on how easy it is to get a Linux computer going with the minimum amount of unnecessary configuration. Most packages now come with sensible default settings that "just work." How I wish that editor development has followed the same path towards developer-friendliness. Just as an example, I've just opened emacs21 in Debian and attempted to set it up to use a smaller font - 5 minutes later, I'm still trying to work out how to change anything in the configuration file. Compare with gvim: this took about 10 seconds to do. Not that gvim's perfect - it's just an example.

I know, I know - I'm just a stupid newbie who doesn't grok the mystical power of Lisp or the beauty of vi's command processing state machine. The thing is, there are plenty of us stupid newbies with >20 years of computing experience who never had to experience computing in the 1970s and have no wish to start now.

</rant>,

cheers,

Jonth

Fanning the flames...

Posted Oct 30, 2006 15:29 UTC (Mon) by sdalley (subscriber, #18550) [Link]

(bursts into spontaneous applause)

Fanning the flames...

Posted Oct 30, 2006 16:21 UTC (Mon) by nix (subscriber, #2304) [Link] (5 responses)

the editor should just "know" that it's a sensible thing to do just from the file type.

How can it tell which files in the filesystem constitute a project that should be scanned for tags? I guess you have to tell it... hm, and if you assume that the top of the tree is the highest directory directly above you towards / which contains either a makefile or a configure.[ac/in], giving priority to the latter if it's found, then I guess you *could* automate most of this. I feel an emacs-mode hacking-session coming on...

Fanning the flames...

Posted Oct 30, 2006 18:27 UTC (Mon) by khim (subscriber, #9252) [Link] (4 responses)

hm, and if you assume that the top of the tree is the highest directory directly above you towards / which contains either a makefile or a configure.[ac/in], giving priority to the latter if it's found, then I guess you *could* automate most of this

No will do. Remember: "I shouldn't have craft a makefule to do this and remember to update it when I save the file". Basically editor should just magically understand that this and that file is part of the project (and these 10GB of files can become part of project - so it's probably good ides to iclude them as well), no matter where it sits (if tags from qt are not supported in qt project then it'll not be very helpfull)... May be easier to write the editor which will just write programs for you ?

Fanning the flames...

Posted Oct 30, 2006 20:07 UTC (Mon) by NAR (subscriber, #1313) [Link] (3 responses)

Basically editor should just magically understand that this and that file is part of the project

I definitely disagree with you - an editor should have no concept about projects. What you need is an IDE, which is a quite different beast than an editor. Both vim and emacs have a number of extensions (modes, plugins, etc.) that give them IDE-like functionality, but they are not an IDE, they are still editors that can be used to e.g. change configuration files even if the user logged in through a VT100 terminal(emulator).

By the way, you've had an interesting comment: and then to be able to select a symbol with a mouse. I believe it's a serious design fault if a feature is only available with mouse, because it's just takes way too much time to grab for the mouse, then move my hand back to the keyboard. I've had a couple of collagues using Visual SlickEdit and it was painful to watch them working, they were so slow. Going to an already opened other file took ages (about 5-10 clicks, depending how far the other file was in the directory hierarchy), while in vim its a simple :b <part-of-filename><TAB> command...

Bye,NAR

Fanning the flames...

Posted Oct 30, 2006 22:50 UTC (Mon) by jonth (guest, #4008) [Link] (1 responses)

OK, I'll bite!

I don't want to get into the religious "my editor is better than yours" war - suffice it to say that your friends don't know how to drive SlickEdit, or just prefer to use a mouse rather than a keyboard.

However, on the IDE point, I think I agree with you. I do want an IDE - I think that an IDE is the natural evolution of what a text editor should be. If I want a _really_ simple console based editor to edit simple configuration files, then I use aee, or nano, or if there's nothing else, vi. But if I need to do some real programming, then I use the tool that gives me the most leverage of my meagre talents.

Anyway, where do you draw the line? Is emacs an editor or an IDE? I'd argue that any editor that can be configured as a chess client is straying quite far from its core competency ;-)

As I said in my first post, I do revisit this issue frequently. I really would like to let go of the only proprietary software I use at work and home. I had hopes for kdevelop at one time, and these days Geany seem my best hope. But I honestly can't accept that any of the OSS editors currently available fit my needs as well as SlickEdit, and I willingly spend my own money on that opinion.

One last thing: I have frequently witnessed full blown arguments about how much better emacs is than vi (or vice-versa) and find it amazing to see the blindness to the alternatives, even in the OSS world, that this seems to engender. These people really should understand that they don't hold a monopoly on good ideas. There are tools out there that do some things better. A bit of embrace and extend might be a good idea in this case!

cheers,

Jonathan

Fanning the flames...

Posted Oct 31, 2006 12:23 UTC (Tue) by NAR (subscriber, #1313) [Link]

Is emacs an editor or an IDE? I'd argue that any editor that can be configured as a chess client is straying quite far from its core competency ;-)

I believe that emacs (and vim too) are just editors that happen to have their own programming languages, so they can be extended with IDE-like features. I don't know much about emacs, but e.g. in vim if I open a C++ file, vim doesn't have a clue about the type of the variable under the cursor. Using tags I could go to the place where the variable is defined (so when I need to get the type, I usually can get it fast), but it's not that simple because of the namespaces, classes, etc. there can be many variables with the same name in the tags file. On the other hand an IDE could parse the C++ sources and could know what's the actual namespace and could find the appropriate definition.

Bye,NAR

Fanning the flames...

Posted Oct 31, 2006 0:25 UTC (Tue) by nix (subscriber, #2304) [Link]

I think under some circumstances we could hunt down a `probable project
root' with reasonable certainty. The thing to do is to hunt downwards from
the root, directly towards the current directory, checking each directory
in turn (/, /usr, /usr/local, /usr/local/src, /usr/local/src/foo-1.95,
etc), looking first for configure.{ac,in} and then for (GNU)?[mM]akefile*.
The first such you find is probably at the project root.

This is easy to implement: I'll get around to it soon, or someone else
will :)

Fanning the flames...

Posted Oct 30, 2006 18:44 UTC (Mon) by mikov (guest, #33179) [Link] (15 responses)

For me the number one feature, that as far as I know only one editor on Linux supports (http://savannah.nongnu.org/projects/ww-tedit), is "virtual space". To be able to move the cursor beyond the end of the line horizontally as well as vertically. Not having that strikes me as absurdly primitive in a screen-oriented editor (as opposed to "ed"). Eclipse doesn't support it either.

Fanning the flames...

Posted Oct 30, 2006 20:04 UTC (Mon) by donbarry (guest, #10485) [Link] (7 responses)

Can you say "picture-mode" ?

I knew you could.

It's been in emacs since at least the late 80's.

Fanning the flames...

Posted Oct 30, 2006 20:29 UTC (Mon) by mikov (guest, #33179) [Link] (6 responses)

I am sorry, but picture-mode is completely unusable for editing source
code. Have you tried it ? :-) I don't want to edit ASCII art, I want to be
able to move my cursor in a logical fashion.

Look at these two lines:
line1
line2

On line1 I can position my cursor at column 20. On line2 I can't. Why ??
Because line1 has lots of spaces added. Since I can't see the spaces, why
should I be restricted from positioning my cursor anywhere I want ? I
should be able to press down arrow from column 20 on line1 and start
typing on column 20 on line2. The editor can insert the necessary spaces
automatically - it isn't rocket science :-)

This is not theoretical. Imagine this scenario:

long long long long long long long BUG1 more text.
foo
longer longer longer longer longer BUG2 more text.

After fixing BUG1 I intuitively press the down arrow to move towards BUG2
and fix it too. Surprise - the cursor disappears and moves far to the left
by 'foo' at column 4. Why ?? What dark magic is restricting the cursor
from some areas of the screen ??

No matter, I press the down arrow again. At this time different editors
choose to do different things:

- Some keep the cursor cursor at column 4, so I have to move it all the
way to BUG2 again. Total and utter cr*p.

- Others try to be smart and move the cursor to BUG2 because they remember
the old position. Of course that is completely illogical - why should
moving the cursor DOWN from column 4 on line 2 result in positioning it at
column 20 on line 3 ??

The only logical behavior is to allow free movement of the cursor in all
directions and automatically insert spaces when necessary. Many editors
under DOS used to do that - it is actually the simplest to implement.

I like the springy version, I can 'feel' the shape of the file.

Posted Oct 31, 2006 0:20 UTC (Tue) by xoddam (subscriber, #2322) [Link] (5 responses)

The annoying things about putting the cursor in an arbitrary column are
that (a) it gives you no way of knowing what white space there is after
the end of the visible text on a line and (b) you can accidentally
introduce said whitespace by an unintended keystroke without even being
aware of it.

I'm sure there are ways of being able to keep the cursor in one column
while still letting you "feel" the shape of the lines in the file -- you
could show two cursors, for instance, so you know the column you want to
be in even if it doesn't exist, or you can use faint glyphs to indicate
spaces and tabs -- but those things are annoying too.

I'm sure that, for most values of $EDITOR, there's a way to configure it
to do just what you want it to do. Just don't expect other people to
like it :-)

But why ?

Posted Oct 31, 2006 3:37 UTC (Tue) by mikov (guest, #33179) [Link] (4 responses)

Why would you care if you have spaces at the end of the line ? They for
sure don't matter in most programming languages. A setting to
trim spaces at end of line automatically is the most reasonable solution.
Relying on something that you can't see is very bad design anyway.
Thinking about the "shape of the line" is not what you need to be doing
when programming. (Well, unless you are writing a makefile, but that
clearly was a terrible design mistake in make).

I think that whether most people like "virtual space" or not is not as
clear cut as you'd think (depending on your background). There are many
programmers coming from the DOS & Windows world that prefer the behavior I
am describing. Most of these people think that both 'vi' and 'Emacs' are
terrible text editors. I am not terribly fond of them either - I like
selecting text with shift+arrows, for example :-)

Of course I don't kid myself that I can convince anyone that it is better
(it is equally futile to participate in the TAB vs SPACE wars :-) -
ultimately for things like this habit trumps logic. That applies to me
too, of course.

But why ?

Posted Oct 31, 2006 10:16 UTC (Tue) by fooker (guest, #14834) [Link] (2 responses)

Why would you care if you have spaces at the end of the line?

Off the top of my head:

I'd like to move from the end of line to the beginning of the next line.
I'd like to add text to the end of line.
I'd like to join two consecutive lines.
I'd like to see differences between two revisions of a file.

Each scenario is pretty common when programming, and having extra whitespace inserted randomly at the end of line by the editor is Bad Thing(tm) in each case (how does a program know when whitespace at the end of line matters and when it doesn't).

Relying on something that you can't see is very bad design anyway.

Like having whitespace appearing magically at the end of line?

Thinking about the "shape of the line" is not what you need to be doing when programming. (Well, unless you are writing a makefile, but that clearly was a terrible design mistake in make).

Yes, indeed. So terrible that Guido van Rossum copied the mistake to Python. The "shape of the line" is very important when programming in any language. That's why we indent our code and group related functionality by adding empty lines.

The only legitimate reason for having magic whitespace is writing a program in Befunge (but that also can be done just as easily by using picture-mode).

But why ?

Posted Oct 31, 2006 16:04 UTC (Tue) by mikov (guest, #33179) [Link] (1 responses)

You don't seem to understand my point at all. I don't want to start a
religious war- as I said, it is as much about habit as it is
about logic. I however have the advantage of having extensively used both
ways of editing. I am replying not show that you are wrong, but to explain
my position and hopefully to prove that it is at least as valid. It is
certainly more logical.

> I'd like to move from the end of line to the beginning of the next
line.
>I'd like to add text to the end of line.
>I'd like to join two consecutive lines.

I agree this is a valid reason. This is what the 'end' key is for, but if
you feel that you may have to press it too often (not in my experience,
but I am subjective), then this mode of editing is not convenient for you.

>I'd like to see differences between two revisions of a file.

As I said (and you obviously ignored), editors have the option to remove
the invisible spaces at the end of a line automatically. This option
should be on at all times when editing software in any programming
language that I know.

> Each scenario is pretty common when programming, and having extra
whitespace inserted randomly at the end of line by the editor is Bad
Thing(tm) in each case (how does a program know when whitespace at the end
of line matters and when it doesn't).

Space is not inserted randomly. Why would it be inserted
randomly ?? I believe I addressed the other points too.

>Like having whitespace appearing magically at the end of line?

You keep repeating that, but it is simply not true. The _only_ way for
more spaces to appear is if you press a _non-space_ character somewhere
after the physical end of the line. Spaces are inserted between the end of
the line and the character your pressed. Is that so hard to understand ?
How else could it be ?

You seem overly concerned with spaces - they are ignored by all
programming languages (including Python), for god's sake. Also, they are
invisible. You should not have to think about them at all.

> Yes, indeed. So terrible that Guido van Rossum copied the mistake to
Python. The "shape of the line" is very important when programming in any
language. That's why we indent our code and group related functionality by
adding empty lines.

I feel silly when saying this, since it is obvious, but Python cares about
spaces _at the beginning of the line_. The spaces at the end of a line,
even if they are not automatically removed (which they are!), are
completely and totally irrelevant in all programing languages. This has
absolutely nothing to do with indentation.

Empty lines have nothing to do with it either - an empty line is equally
as empty if it has spaces.

Editors should not violate the principle of least surprise

Posted Oct 31, 2006 23:54 UTC (Tue) by xoddam (subscriber, #2322) [Link]

> The spaces at the end of a line ... are completely and totally
> irrelevant in all programing languages.

> Empty lines have nothing to do with it either - an empty line
> is equally as empty if it has spaces.

True for most programming languages, yes. But whitespace
differences are significant in revision control systems,
with good reason.

Editors should never, ever make a change to a file without
being explicitly instructed to do so and making the change
visible to the user (so users can correct their own mistakes).

If your editor enforces a hard-and-fast rule that spaces at the
end of the line should always be removed, then as long as you
only ever use that editor, it sticks to this principle. But if
you edit a file which, for whatever random unreasonable reason,
contains spaces at the end of a line, that editor will change
something you can't see. And if, as is sometimes the case for
the most esoteric reasons (hey, I never *chose* to use autotools,
I just inherited the build system!) trailing whitespace is
actually required -- why then your editor breaks not only the
principle of least surprise, but also your program.

But why ?

Posted Nov 1, 2006 2:15 UTC (Wed) by ibukanov (subscriber, #3942) [Link]

> There are many programmers coming from the DOS & Windows world that prefer the behavior I am describing.

That is very true. When after 5 years of Turbo/Borland Pascal/C for Dos/Windows I started to use Unix/Linux, I spent some time trying to configure editors for that virtual space behaviour with no success. I even tried to create an Emacs mode for that. But then I gave up after realizing how non-trivial it would be and just started to ignore those cursor jumps during vertical movements. But sometimes they still annoy me after almost 10 years of using Emacs.

I guess this is really some cultural difference.

vim does it...

Posted Oct 31, 2006 12:26 UTC (Tue) by niner (guest, #26151) [Link] (3 responses)

'virtualedit' 've'      string  (default "")
                        global
        A comma separated list of these words:
            block       Allow virtual editing in Visual block mode.
            insert      Allow virtual editing in Insert mode.
            all         Allow virtual editing in all modes.
Virtual editing means that the cursor can be positioned where there is no
actual character.  This can be halfway into a Tab or beyond the end of the
line. Useful for selecting a rectangle in Visual mode and editing a table.

So a simple :set ve=all will get you what you want. Put it in your ~/.vimrc to have it always set.

vim does it...

Posted Oct 31, 2006 15:36 UTC (Tue) by mikov (guest, #33179) [Link] (2 responses)

Thanks! That is close to want I want. It doesn't quite work in my version
of Vim (6.3) - moving the cursor is fine, but if I insert a character at
column 20 and press down arrow, the cursor still moves to the end of the
next line. I suppose this is a bug.

vim does it...

Posted Oct 31, 2006 18:30 UTC (Tue) by niner (guest, #26151) [Link] (1 responses)

Have the same behavior in 6.4.6
It only is after typing something. If I move the cursor one to the left after typing and pressing down it moves down. If not, it goes to the end of the line below. But if I press up and down again it's just one position down. Weird.

This could be because vim remembers the position in the line one moved to. In non-virtual mode if you press down and the next line is shorter, the cursor moves to that line's end. If the next after that is longer again, it moves to the position it were. This nice feature is the reason why I usually don't need virtual mode. But it could be handy for drawing ASCII art ;)

vim does it...

Posted Oct 31, 2006 18:52 UTC (Tue) by mikov (guest, #33179) [Link]

>This could be because vim remembers the position in the line one moved
to. In non-virtual mode if you press down and the next line is shorter,
the cursor moves to that line's end. If the next after that is longer
again, it moves to the position it were. This nice feature is the reason
why I usually don't need virtual mode.

But don't you find it just a little bit confusing, theoretically
speaking ? It remembers the position in the "longer" line and tries to
keep as close to it as it can. But for how long - what if you move the
cursor horizontally, or type something? Then it doesn't remember it
anymore. But what if you undo the operation ? You see, the desired
behavior is not obvious and I have noticed that editors have subtle
differences and are not entirely consistent in implementing it.

We can start adding improvements like remembering the position in the last
100 or 1000 lines, and a timeout after which we flush the remembered
position, etc. Ultimately, the logical conclusion leads to "virtual
space".

This is just pet peeve of mine, of course. I am speaking only
theoretically. I don't want to offend anyone or to claim that virtual
space is actually more convenient for editing source. Only that it seems
more logical theoretically.

Fanning the flames...

Posted Oct 31, 2006 15:58 UTC (Tue) by rfunk (subscriber, #4054) [Link] (1 responses)

I've been programming Unix for 15 years, and have read your comments in
this thread, but I still have no idea why you would want/need the feature
you're describing.

Fanning the flames...

Posted Oct 31, 2006 16:21 UTC (Tue) by mikov (guest, #33179) [Link]

This allows more consistent movement around the file. Pressing a down arrow should move the cursor vertically, not horizontally - it is the only logical and consistent way. I believe I demonstrated why the alternative behavior is illogical. There are two options that I have seen in editors:

After down/up arrow position the cursor at the beginning of the line. This is obviously inconvenient.
After down/up arrow, attempt to position the cursor as close as possible to the position it had when it began moving vertically, which may have been several lines up/down. This behavior is even difficult to explain!

Why is it inconsistent?

Depending on what you did before that, the down arrow will do a different thing. Try to define this behavior precisely, and you will understand what I mean.
Depending on whether a line already has spaces or not (which are invisible!), you are either allowed to be at certain position or not. Since you can't see that there are spaces, this is a completely arbitrary restriction.

By contrast, virtual space is crystal clear. Vertical arrows move the cursor vertically. The 'end' key moves you to the physical end of the line, when you need to go there. Space is inserted as needed if you start typing beyond the end of line.

I don't expect people to convert. It is silly to change one's habits in something as important as using an editor. I just expect them to understand that it is a valid way and even hopefully concede that it is somewhat more logical.

Fanning the flames...

Posted Nov 1, 2006 9:49 UTC (Wed) by man_ls (guest, #15091) [Link]

Ah the ironies of life... The first time I started Emacs (don't know which version) I found that I could click beyond the actual line into "virtual space". It was so 80'ish... couldn't figure out how to turn that off and went back to vim. Never tried again.

When I go from a long line to a short one, I want my cursor to jump between lines so I can see the context! Eclipse is not perfect, but it works well IMHO. By the way, you might want to lend them some help with bug 21000 ("Allow positioning of the cursor beyond line end option").

GNU emacs 22 goes into protest

Posted Oct 30, 2006 13:55 UTC (Mon) by lefty.crupps (guest, #41388) [Link] (4 responses)

I first read the headline as "GNU emacs 22 goes into protest" and my first thought was, "oh oh RMS is at it again, trying to shoot the FSF in the foot by dividing our community..."

It looks like we survived this round however ;)

GNU emacs 22 goes into protest

Posted Oct 30, 2006 15:59 UTC (Mon) by sbergman27 (guest, #10767) [Link] (3 responses)

"""
I first read the headline as "GNU emacs 22 goes into protest" and my first thought was, "oh oh RMS is at it again, trying to shoot the FSF in the foot by dividing our community..."
"""

I hear you. But where have you been for the last 30 years? Richard began his quest to divide the community in 1975, and I still say vi is better.

GNU emacs 22 goes into protest

Posted Oct 30, 2006 22:52 UTC (Mon) by ncm (guest, #165) [Link] (2 responses)

Better for what? Certainly Vi is more efficient in number of keystrokes consumed in day-to-day editing. But for that, Emacs users have [... drum roll ...] viper-mode! Yes, all the goodness of Vi within Emacs proper. All the Emacs commands still work, in Vi's insert mode, because the command sets are -- amazingly -- nearly disjoint.

Some people would say that's the worst of both worlds. It would be hard to argue with them, but I use viper-mode anyway.

GNU emacs 22 goes into protest

Posted Oct 31, 2006 9:46 UTC (Tue) by fooker (guest, #14834) [Link] (1 responses)

Some people would say that's the worst of both worlds

Heh, yeah. An editor that takes ages to load and is practically impossible for a beginner to use ;-). Imagine, whatever button you press, something unpleasant and unexpected happens.

PS. I'm a devoted vim user

GNU emacs 22 goes into protest

Posted Oct 31, 2006 16:08 UTC (Tue) by cyd (guest, #4153) [Link]

> An editor that takes ages to load

Time to upgrade from that crusty ol' 486. Emacs starts up pretty much instantaneously on modern machines.

From:		Chong Yidong <cyd-AT-stupidchicken.com>
To:		emacs-devel-AT-gnu.org
Subject:		Pretest
Date:		Fri, 27 Oct 2006 13:59:36 -0400

GNU emacs 22 goes into pretest

what's new: the antinews

GNU emacs 22 goes into pretest

GNU emacs 22 goes into pretest

GNU emacs 22 goes into pretest

GNU emacs 22 goes into pretest

significant point

GNU emacs 22 goes into pretest

GNU emacs 22 goes into pretest

Debian packages

GNU emacs 22 goes into pretest

GNU emacs 22 goes into pretest

GNU emacs 22 goes into pretest

Emacs is dead?

No, just misunderstood

Fanning the flames...

Fanning the flames...

Fanning the flames...

Fanning the flames...

Fanning the flames...

Fanning the flames...

Fanning the flames...

Fanning the flames...

Fanning the flames...

Fanning the flames...

Fanning the flames...

Fanning the flames...

Fanning the flames...

I like the springy version, I can 'feel' the shape of the file.

But why ?

But why ?

But why ?

Editors should not violate the principle of least surprise

But why ?

vim does it...

vim does it...

vim does it...

vim does it...

Fanning the flames...

Fanning the flames...

Fanning the flames...

GNU emacs 22 goes into protest

GNU emacs 22 goes into protest

GNU emacs 22 goes into protest

GNU emacs 22 goes into protest

GNU emacs 22 goes into protest