all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
To: Sean Ochoa <wakiewakie@gmail.com>
Cc: bug-gnu-emacs@gnu.org
Subject: Re: What about "The Modernization of Emacs"?
Date: Thu, 20 Dec 2007 23:44:52 +0100	[thread overview]
Message-ID: <476AF064.4020900@gmail.com> (raw)
In-Reply-To: <811554110712200713m35204f96x136ebcc393984682@mail.gmail.com>

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




  reply	other threads:[~2007-12-20 22:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-20 15:13 What about "The Modernization of Emacs"? Sean Ochoa
2007-12-20 22:44 ` Lennart Borgman (gmail) [this message]
2007-12-21  9:21   ` David Reitter
2007-12-21 19:49   ` Richard Stallman
2007-12-21 16:21 ` Eli Zaretskii
2007-12-21 16:33 ` Shawn Boyette ☠

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=476AF064.4020900@gmail.com \
    --to=lennart.borgman@gmail.com \
    --cc=bug-gnu-emacs@gnu.org \
    --cc=wakiewakie@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.