help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: simple editor required


From: lawrence mitchell
Subject: Re: simple editor required
Date: Sat, 07 Jun 2003 12:19:44 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50

Paul Edwards wrote:

[...]

> I don't know that that is true.  An editor that doesn't allow
> you to stay at a particular level is not an editor, it is not
> suitable for programming in any language.
> Alignment of text under text is very very basic.  I don't mind
> if the behaviour changes when I break the pattern, but I do
> mind if the behaviour changes line by line.  No programmer has
> to hit space/tab 20 times at the beginning of every line in
> order to line up code.

I still don't quite understand this.  When I use Emacs, in, say,
C Mode, typing normally lines things up.  Pressing return adds a
newline and indents the current line, and the only thing that
changes indentation is if I forget a close ";", or add an open
or close brace ("{" or "}").  But perhaps I misunderstand your
needs.

[...] Summary of wants.

> 1. text to be lined up, line by line, suitable for any programming
> language, no matter what file extension I am using.  IIRC, all I needed
> to do on old emacs versions was inhibit the site file, either via a
> command-line option or .emacs file, can't remember, either is
> acceptable, and the junk wouldn't get loaded.

> 2. Block-marking not to be destroyed by ctrl-f and esc-g.  Xemacs
> 20.4 has a you-beaut highlighting of the block, which is great, but
> I'd trade it any day for the ability to do a find/goto to position to
> end of block.  Like emacs 20.7.1.  And like the last time I used a
> version of xemacs, IIRC.  I don't know why some people think it
> is appropriate to forget the marker, seems pretty basic to me, but
> besides, other emacs (like 20.7.1) don't forget the marker.

So, you don't want transient-mark-mode?  I don't believe that it
is turned on by default.  Certainly, without any kind of
customisations (emacs -q --no-site-file), when setting the mark,
and then moving away, the mark is not lost.  However, in this
mode, you cannot see what part of the text is marked.

Note that if you use transient-mark-mode (or zmacs-regions in
XEmacs), you can swap point and mark around by doing C-x C-x.


> 3. DEL to delete.  Just like xemacs 20.4 with appropriate .emacs
> entry.

If I understand your needs correctly, this .emacs is probably
close to what you want:

;; turn off all major-mode associations
(setq auto-mode-alist nil)
(setq interpreter-mode-alist nil)

;; Make return indent to the current level
(global-set-key (kbd "RET") #'newline-and-indent)
;; Make tab insert a tab, always
;; If you want tabs to be converted into spaces, you
;; will need to untabify files on saving.  But many people don't
;; like this.
(global-set-key (kbd "TAB") #'self-insert-command)

;; Make the DEL key work the same as C-d (and not like backspace)
(global-set-key (kbd "<delete>") #'delete-char)

;;; end

[...]

> Someone has suggested putting:
> (setq kill-whole-line nil)

> to get around this problem.  I didn't have to do that in other
> versions of emacs, it was the basic standard consistent
> behaviour.

kill-whole-line is nil by default, and has been since it was
first introduced in Emacs in 1993.  So, if it isn't for you, the
site file must be changing it.
The command line option to inhibit site-file loading is
"--no-site-file".

[...]

> I consider these to be extremely basic things that should be provided
> out-of-the-box with all emacs versions without having to create an
> enormous .emacs file, tailored for every version of emacs, to suppress
> every quirk that emacs introduces *by default* in every incarnation.
> I am shocked that the basics don't remain consistent.

Is there any particular need that you need a new Emacs version.
If, like you say, Emacs 20.7 works fine for you, and you have no
need of the new features in Emacs 21, why not stick with Emacs
20?  Or, use micro-emacs everywhere, after all, it's not an
overly large install.

-- 
lawrence mitchell <wence@gmx.li>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]