* Re: Emacs: a 21st century text-editor
[not found] <mailman.3038.1110313983.32256.bug-gnu-emacs@gnu.org>
@ 2005-03-08 20:42 ` Ulrich Hobelmann
2005-03-09 5:22 ` Gaetan Leurent
2005-03-09 9:32 ` Mathias Dahl
2005-03-15 0:07 ` Alan Mackenzie
2 siblings, 1 reply; 8+ messages in thread
From: Ulrich Hobelmann @ 2005-03-08 20:42 UTC (permalink / raw)
Christopher G D Tipper wrote:
> 1 Text-wrapping. Text wrapping is a limitation, and it would be nice
> to scroll past the edge of the screen. This is particularly acute in
> my case editing XSLT scripts where line-breaks become a
> presentational issue. Sometimes I actually need to compose documents
> with 250 columns, and I don't appreciate emacs telling me otherwise.
Do you mean that you want a horizontal scrollbar, or are you just (like
me) annoyed by those arrows left and right when a line is long?
BTW, emacs people: take a look at how Apple TextEdit handles long lines;
that's more like in a word processor, but if you type up or down, you
move in screen lines, even though it's just one line in the file.
> 3 Tabbed buffers. Open buffers should be easily visible in a tabbed
> layout below the menu, in the manner of XEmacs. A proper history
> list would help here so that documents are persistent across
> sessions.
That would be nice. Having everything mostly available in a text buffer
is somewhat antiquated. Similarly something like Cmd-left/right (or
Ctrl-left on Windows/Linux) would be nice for switching between Tabs.
> 4 File Dialogs. I use dlgopen.el on Windows, which gets rid of the
> most serious interface issue of all, the lack of modern file
> dialogs. It wouldn't be rocket-science to adapt the interface to
> support this. XEmacs file dialogs are unusable IMHO.
I use drag-and-drop to put files into emacs sometimes (on the Mac), but
having it recognize standard open/close keymappings would be nice too,
as would be dialogs.
> 5 Paste replaces edit. This idea that when I paste I end up with both
> the replacement text and the old text does not belong in the modern
> idiom. This is a real versioning issue when the replacement text
> scrolls past the bottom of the screen. I think this is just an
> old-fashioned feature that never got updated.
And make mark and backspace delete the marked text.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Emacs: a 21st century text-editor
[not found] <mailman.3038.1110313983.32256.bug-gnu-emacs@gnu.org>
2005-03-08 20:42 ` Ulrich Hobelmann
@ 2005-03-09 9:32 ` Mathias Dahl
2005-03-10 20:01 ` Gian Uberto Lauri
2005-03-15 0:07 ` Alan Mackenzie
2 siblings, 1 reply; 8+ messages in thread
From: Mathias Dahl @ 2005-03-09 9:32 UTC (permalink / raw)
"Christopher G D Tipper" <chris.tipper@gmail.com> writes:
> It just seems to be stuck in the 20th century with no sign of any
> attempt at modernisation.
Although I agree somewhat I think you are a bit unfair. Lately it has
got some nie-looking tool bar, the file dialog when accessed from the
menu bar is quite good (at least on Windows), etc.
> 1 Text-wrapping. Text wrapping is a limitation, and it would be nice
> to scroll past the edge of the screen. This is particularly acute in
> my case editing XSLT scripts where line-breaks become a
> presentational issue. Sometimes I actually need to compose documents
> with 250 columns, and I don't appreciate emacs telling me otherwise.
Have you tried Ctrl-PgDown and Ctrl-PgUp? Works quite well. I too miss
a horizontal scroll bar sometimes though.
> 2 Shell open. Emacs really ought to be able recognise when the shell
> is requesting it to open a file. Gnu-client should be unnecessary in
> a modern application.
I agree with this and I really do not understand why it should be that
hard to "feel" if an Emacs instance is allready running, and opening
the file in that. But I am no low-level programmer, so I would not
know about technical limitations here.
> 3 Tabbed buffers. Open buffers should be easily visible in a tabbed
> layout below the menu, in the manner of XEmacs. A proper history
> list would help here so that documents are persistent across
> sessions.
Personally, that tab-bar would be so crowded that the tabs would not
do any good. I tend to have many files and buffers open, especially
since emacs is more than a text editor for me (reading news, mail,
todolists, calendar etc etc). Btw, have you tried out tabbar.el? I
don't like it, but you might.
Persistent files though sessions is solved in many ways (desktop.el is
built in in emacs).
> 4 File Dialogs. I use dlgopen.el on Windows, which gets rid of the
> most serious interface issue of all, the lack of modern file
> dialogs. It wouldn't be rocket-science to adapt the interface to
> support this. XEmacs file dialogs are unusable IMHO.
On Windows, File -> Open File... works for me. I like to open the
files using the minibuffer though.
> 5 Paste replaces edit. This idea that when I paste I end up with
> both the replacement text and the old text does not belong in the
> modern idiom. This is a real versioning issue when the replacement
> text scrolls past the bottom of the screen. I think this is just an
> old-fashioned feature that never got updated.
I used to like this. I used pc-selection-mode and
delete-selection-mode, which you will probably like, but nowadays I
have turned all that off. I do not even use transient-mark-mode. I
have got used to do C-SPC (set-mark-command), move the cursor to the
end of the region I want to operate on, and to C-w, M-w, delete-region
(which I have mapped to C-c d). And I like it. For deleting words or
lines, I use M-d, C-k etc.
Basically I see where you are coming from, but by being a bit flexible
and accepting some "old quirks" (which seems to be really thought
through when you get used to it), I like it the way it works. Just
because something is not familiar does not meen that it is bad.
IMHO, of course... :)
/Mathias
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Emacs: a 21st century text-editor
2005-03-09 9:32 ` Mathias Dahl
@ 2005-03-10 20:01 ` Gian Uberto Lauri
2005-03-11 20:28 ` Richard Stallman
0 siblings, 1 reply; 8+ messages in thread
From: Gian Uberto Lauri @ 2005-03-10 20:01 UTC (permalink / raw)
Cc: gnu-emacs-bug
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4446 bytes --]
My 0.002ÂŽ¤ (the 0 count is right). I apologize for the delay.
>>>>> "MD" == Mathias Dahl <brakjoller@gmail.com> writes:
MD> "Christopher G D Tipper" <chris.tipper@gmail.com> writes:
>> It just seems to be stuck in the 20th century with no sign of any
>> attempt at modernisation.
No "modern" program has the flexibility of Emacs. No modern editor is
as good as Emacs. No modern editor is ready to do my work for me,
Emacs does it often.
MD> Although I agree somewhat I think you are a bit unfair. Lately it
MD> has got some nie-looking tool bar, the file dialog when accessed
MD> from the menu bar is quite good (at least on Windows), etc.
It's good under Mac OS X, Linux when compiled wiht GTK and so on.
(uh oh, the toolbar is cool looking, but I keep it disabled).
>> 1 Text-wrapping. Text wrapping is a limitation, and it would be
>> nice to scroll past the edge of the screen. This is particularly
>> acute in my case editing XSLT scripts where line-breaks become a
>> presentational issue. Sometimes I actually need to compose
>> documents with 250 columns, and I don't appreciate emacs telling me
>> otherwise.
MD> Have you tried Ctrl-PgDown and Ctrl-PgUp? Works quite well. I too
MD> miss a horizontal scroll bar sometimes though.
Hmmmm... Even not using Ctrl-PgDown and Ctrl-PgUp I rarely feel the
need of this when i set sqlplus line to 30000 characters and shot a
sixty fields query (of course, sqlplus is controlled by emacs and its
output goes in an Emacs buffer).
With code... I feel that whenever you have to scroll past the edge of
the screen there's something wrong either in your code or in the
language design... Anyway I can deal with these situations disabling
the text wrapping and using word or line moving commands. IMHO of
course.
>> 2 Shell open. Emacs really ought to be able recognise when the
>> shell is requesting it to open a file. Gnu-client should be
>> unnecessary in a modern application.
MD> I agree with this and I really do not understand why it should be
MD> that hard to "feel" if an Emacs instance is allready running, and
MD> opening the file in that. But I am no low-level programmer, so I
MD> would not know about technical limitations here.
Emacs is the shell.
gnuclient or emacsclient are still a very good solution since they are
useful in al broader range of situations.
They can help you with the clicky thing, but they are useful in many
other situations, especially when you call anc Emacs function from
OUTSIDE emacs, not only to invoke an existing emacs from the shell.
>> 3 Tabbed buffers. Open buffers should be easily visible in a tabbed
>> layout below the menu, in the manner of XEmacs. A proper history
>> list would help here so that documents are persistent across
>> sessions.
MD> Personally, that tab-bar would be so crowded that the tabs would
MD> not do any good. I tend to have many files and buffers open,
MD> especially since emacs is more than a text editor for me (reading
MD> news, mail, todolists, calendar etc etc). Btw, have you tried out
MD> tabbar.el? I don't like it, but you might.
I agree 100%
>> 4 File Dialogs. I use dlgopen.el on Windows, which gets rid of the
>> most serious interface issue of all, the lack of modern file
>> dialogs. It wouldn't be rocket-science to adapt the interface to
>> support this. XEmacs file dialogs are unusable IMHO.
MD> On Windows, File -> Open File... works for me. I like to open the
MD> files using the minibuffer though.
Again. it works on Mac OS X, Linux (at least if compiled with GTK)
MD> Basically I see where you are coming from, but by being a bit
MD> flexible and accepting some "old quirks" (which seems to be really
MD> thought through when you get used to it), I like it the way it
MD> works. Just because something is not familiar does not meen that
MD> it is bad.
MD> IMHO, of course... :)
Not just your opinion. I did a talk to our local FSUG, a simple
introduction explaining how Emacs was born, how it was designed and so
on. While workind on this talk I realized (mostly thanks to a Usenet
post) that keybindings are choosen in a very smart way that considers
how often you use them. CUA standard is ludicrous when compared to
the wisdom behind Emacs keybinding choice.
--
/\ ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
//--\ | | \| | Integralista GNUslamico
\/ e coltivatore diretto di software
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Emacs: a 21st century text-editor
[not found] <mailman.3038.1110313983.32256.bug-gnu-emacs@gnu.org>
2005-03-08 20:42 ` Ulrich Hobelmann
2005-03-09 9:32 ` Mathias Dahl
@ 2005-03-15 0:07 ` Alan Mackenzie
2 siblings, 0 replies; 8+ messages in thread
From: Alan Mackenzie @ 2005-03-15 0:07 UTC (permalink / raw)
Christopher G D Tipper <chris.tipper@gmail.com> wrote on Tue, 08 Mar 2005
20:04:02 -0000:
> Emacs: a 21st century text-editor
> I have been using emacs for over a year now, and value its power and
> flexibility. However, I cannot get used to some idiosyncrasies ....
Congratulations on spelling that word correctly! I'll bet you can write
"supersede", too. ;-)
> .... of its behaviour which seem to me to be artifacts of its heritage,
> rather than components of a piece of modern software. What I am talking
> about is nothing to do with any superficial features, such as the
> complex interface nor its architecture. It just seems to be stuck in
> the 20th century with no sign of any attempt at modernisation.
Hmmm. Not all answers to that are polite. Possibly the best is that
Emacs doesn't follow fashion, it follows functionality. Not everything
modern in user interface design is good, not by a long chalk. Not
everything that is good for a casual user is good for a power user.
Emacs is optimised for power users.
> 1 Text-wrapping. Text wrapping is a limitation, and it would be nice
> to scroll past the edge of the screen. This is particularly acute in
> my case editing XSLT scripts where line-breaks become a
> presentational issue. Sometimes I actually need to compose documents
> with 250 columns, and I don't appreciate emacs telling me otherwise.
I think you mean it would be nice to be _able_ to set up to scroll past
the edge of the screen. Some people prefer long lines to wrap on the
display (i.e. without newlines), some prefer auto-filling (i.e. with
newlines). There's various settings you can set for this.
> 2 Shell open. Emacs really ought to be able recognise when the shell
> is requesting it to open a file. Gnu-client should be unnecessary in
> a modern application.
> 3 Tabbed buffers. Open buffers should be easily visible in a tabbed
> layout below the menu, in the manner of XEmacs.
Again, this is personal taste. Such a feature would be of no help to me,
and I strongly dislike such distractions on my screen. But I agree that
such a feature as an option would be a good thing.
> A proper history list would help here so that documents are
> persistent across sessions.
What do you mean by a "history list", and what does "proper" mean.
desktop.el does a not too bad job.
> 4 File Dialogs. I use dlgopen.el on Windows, which gets rid of the
> most serious interface issue of all, the lack of modern file
> dialogs. It wouldn't be rocket-science to adapt the interface to
> support this. XEmacs file dialogs are unusable IMHO.
Why is that a serious interface issue? How are modern file dialogues
better? Too me, dialog boxes are like explosions in my face, so I
disable them as much as possible. What's wrong with what Emacs currently
offers?
> 5 Paste replaces edit.
"edit"?
> This idea that when I paste I end up with both the replacement text
> and the old text does not belong in the modern idiom.
What do you mean by "the old text" when pasting? Do you mean that you
want to mark some text, then replace it with some other text with a
single key-sequence? How is this better than deleting text then yanking
other text? It seems to me more a matter of personal taste. Many
"modern" proprietary programs drive me to distraction in that moving the
cursor to a field on the screen marks its contents in such a way that
pressing any key within reach of the home position deletes the entire
field. As for "not belonging in the modern idiom", I thank my deity and
RMS (not necessarily in that order ;-) that Emacs retains tried and
tested old stuff.
> This is a real versioning issue ...
What do you mean by "versioning issue"?
> ... when the replacement text scrolls past the bottom of the screen. I
> think this is just an old-fashioned feature that never got updated.
The thing is, there are _lots_ of different ways people work. What is so
obviously the Right Thing to you is absolute purgatory for others (like
me). I use Emacs, by choice, on a 134 x 41 character console screen
rather than a GUI, so as to avoid mice, dialog boxes, menus, scroll-bars,
as well as not having to mess with fonts and so on. The solution is to
provide enough different ways of working so that everybody can find their
optimum setup. I have a feeling that Emacs can be customized nearer to
what you want than you've so far found out.
> Best wishes,
> Christopher Tipper
And to yourself, Sir!
--
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
^ permalink raw reply [flat|nested] 8+ messages in thread