What about "The Modernization of Emacs"?

What about "The Modernization of Emacs"?

[Sean Ochoa]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

What do the maintainers have to say about this article, "The Modernization
of Emacs" (http://xahlee.org/emacs/modernization.html)? I find myself in the
very same boat as he's describing.  Its a good thing that I have geeky
friends who already use emacs to show me the ropes.

 - Sean Ochoa

[-- Attachment #2: Type: text/html, Size: 383 bytes --]

Re: What about "The Modernization of Emacs"?

[Lennart Borgman (gmail)]

Sean Ochoa wrote:
> What do the maintainers have to say about this article, "The 
> Modernization of Emacs" (http://xahlee.org/emacs/modernization.html)? I 
> find myself in the very same boat as he's describing.  Its a good thing 
> that I have geeky friends who already use emacs to show me the ropes.
> 
>  - Sean Ochoa

Here are some comments:

;; Simple UI Changes
;;
;; * Have cua-mode on by default.

Maybe a simple way to turn on platform like features instead? There 
could be "platforms" like:

- Emacs default
- GNU/Linux
- w32

;; * Have Syntax Highlighting on by default.

It is from Emacs 22.

;; * Change the undo behavior so that there is a Undo and
;;   Redo.

I hardly notice (since I use Viper), but it sounds useful. Of course you 
can do redo with the undo command, but it is hard for a beginner. There 
is a undo-only command, why not also have a redo-only command?

;; * Get rid of the “*scratch*” buffer.

This has been discussed on the devel list. Please look at the discussion 
there.

;; * Make longlines-mode the default editor behavior for any
;;   file. (So that, the up arrow and down arrow keys moves
;;   the cursor by a visual line, not by line-return
;;   character.

I think this deserves some thought.

By default Emacs wraps long lines. This is not the same as 
longlines-mode. I think it would be useful to be able to use down/up 
arrows to move to the next/previous visual line. I believe this might be 
what beginners expect. (Maybe there is already such an option in Emacs?)

;; Documentation Changes (for the User Documentation of
;; Emacs (not Emacs Lisp Doc))
;;
;; * Change the terminology of “Meta key” to “Alt key”

I would say no. They are not the same. I do not use the Alt key for 
Emacs META key.

I would say make the explanation of this more visible instead. It is 
already mentioned in for example

   M-: (info "(emacs) Windows Keyboard")

but it could perhaps be in a section of its own since it is such an 
important detail.

;;   replace the abbreviations C-«key» and M-«key» by
;;   Ctrl+«key» and Alt+«key».

Why? Is that really so difficult for a beginner?

;; * Change the terminology of “kill” to “cut”, and “yank”
;;   to “paste”.

I would say yes (though many others surely disagree), but there are some 
difficulties with doing it. It is easy to change the names in the menus, 
but what should then be done with the command names (think mnemonics)? 
And backward compatibility? (Maybe this can be solved just by adding 
wrapper functions with new names like cut, copy, paste?)

;; * Change the terminology of keybinding to “keyboard
;;   shortcut”. Use the term keybinding or binding only in a
;;   technical context, such as in elisp documentation.

If you search through the Info manual (use C-s) you will find "keyboard 
shortcuts". That is useful. Rewriting the whole manual with a new 
terminology takes time.

;; * Reduce the use of the word “buffer”. Call it “opened
;;   file”, “unsaved document”, “tab”, “window”, as
;;   appropriate.

None of those names are really appropriate.

;; * Switch the terminology of Window and Frame so it is
;;   more standard. That is, emacs's notion of “Window”
;;   should be called Panes or Frames. While emacs's notion
;;   of “Frame” should be termed Window.

Mm. Perhaps many would wish that the terminology was different, but it 
is a lot of work to change it. I believe most developers will not find 
it worth that. There are many, many other things that can be done to 
evolve Emacs. (They are often quite a bit harder, but much more useful. 
Like bringing JDEE to a state comparable to Eclipse again (which would 
actually make it more useful than Eclipse perhaps). Or working on 
getting Semantics into Emacs with all the possibilities that would mean. 
Or ... - a lot of other things.)

Re: What about "The Modernization of Emacs"?

[David Reitter]

On 20 Dec 2007, at 22:44, Lennart Borgman (gmail) wrote:
>
> ;; * Make longlines-mode the default editor behavior for any
> ;;   file. (So that, the up arrow and down arrow keys moves
> ;;   the cursor by a visual line, not by line-return
> ;;   character.
>
> I think this deserves some thought.
>
> By default Emacs wraps long lines. This is not the same as longlines- 
> mode. I think it would be useful to be able to use down/up arrows to  
> move to the next/previous visual line. I believe this might be what  
> beginners expect. (Maybe there is already such an option in Emacs?)

Longlines mode is littered with problems. It fails to break lines  
correctly just when you need soft word wrapping most, i.e. for long  
prose texts  which are displayed with a variable width font, or where  
lines are shown in different font sizes (AUCTeX). Longlines fails to  
recognize comments, e.g., in LaTeX (this is a bug!). Because the line- 
number correspondence between files and buffer lines get lost, a lot  
of functions simply don't work any longer (this is a bug!), such as  
jumping to the place of errors in LaTeX files (compiler reports file  
lines, then jumps to buffer lines). I wrote some code to make  
`pdfsync' work with longlines in AUCTeX, but these things are really  
just hacks because the mode rightfully assumes that buffer line = file  
line.
Longlines also isn't recognized automatically when a text file with  
many long lines is loaded. The setting "use longlines for all text  
modes" is rather cumbersome.

Rather than going on with this rant, I'd like to point readers to a  
post by Fernando Pereira:

http://article.gmane.org/gmane.emacs.macintosh.osx/3524

Instigating change is good. But solving the problems is better. Write  
code!

Re: What about "The Modernization of Emacs"?

[Eli Zaretskii]

> Date: Thu, 20 Dec 2007 07:13:20 -0800
> From: "Sean Ochoa" <wakiewakie@gmail.com>
> 
> What do the maintainers have to say about this article, "The Modernization
> of Emacs" (http://xahlee.org/emacs/modernization.html)?

I think the author has an agenda (see his latest postings on
gnu.emacs.help) that makes his articles suspect of propaganda and
bias.

I also think that Emacs maintainers do care about keeping Emacs in
sync with modern UI and editing requirements, and recent Emacs
development shows that very clearly.  Rational suggestions for
improvements in these areas are welcome, of course (please post them
to emacs-devel@gnu.org, not here), but blindly accusing Emacs of being
stagnant in a Web page is a very inefficient way of achieving the goal
of talking Emacs maintainers into changing Emacs.

Re: What about "The Modernization of Emacs"?

[Shawn Boyette ☠]

I'm not a maintainer, but I'll tell you what I have to say anyway :)

I think that the article is fundamentally misguided, presuming that a
monoculture is a good thing, and further presuming that having to
learn how to use a tool is a *bad* thing. I could expand upon both
these points at length, but I'll leave that as an exercise for the
thoughtful reader :)

On Dec 20, 2007 10:13 AM, Sean Ochoa <wakiewakie@gmail.com> wrote:
> What do the maintainers have to say about this article, "The Modernization
> of Emacs" (http://xahlee.org/emacs/modernization.html)? I find myself in the
> very same boat as he's describing.  Its a good thing that I have geeky
> friends who already use emacs to show me the ropes.
>
>  - Sean Ochoa
>



-- 
Shawn Boyette
<sboyette@gmail.com>

Re: What about "The Modernization of Emacs"?

[Richard Stallman]

I am very much against making CUA mode the default.