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

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

perceived input method inconsistencies


From: Jonas Järneström
Subject: perceived input method inconsistencies
Date: Wed, 22 Jun 2005 15:28:22 +0200

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the address@hidden mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.3.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2004-04-07 on raven, modified by Debian
configured using `configure '--build=i386-linux' '--host=i386-linux' 
'--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' 
'--localstatedir=/var/lib' '--infodir=/usr/share/info' 
'--mandir=/usr/share/man' '--with-pop=yes' '--with-x=yes' 
'--with-x-toolkit=athena' 'CFLAGS=-DDEBIAN -g -O2' 'build_alias=i386-linux' 
'host_alias=i386-linux''
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: sv_SE
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Yo guys!

There seem to be 2 general promting methods in GnuEmacs for commands
requiring additional arguments:

a) the traditional: command input by keybinding prompts for argument
input in the minibuffer.

b) the graphic: command input by meny prompts for argument input
in a pop-up window. (note: my interpretation of observed reality,
not described in the "GNU Emacs manual" V21)

However, the b-method seems slightly inconsistent. The pop-up window
prompt comes up only for y/n type of confirmations, not for
longer strings of input like filenames or search strings. But this
seems to depend on the platform used. On Emacs 21 on Windows-2000
that I use, a file selection windows comes up when opening a file
with the mouse, whereas on this platform, i386-linux with Emacs 21,
the minibuffer is still used.

Why does the behavior differ between these platforms? Is it
because my Linux copy is badly configured localy, or doesnt the X
toolkit supply the necessary interface component to the file
system, the way Windows-2000 does?

And what is the intended general graphic behavior? Is it as I
described it above, or in some other way? In any way I cant find
any statement describing this in the manual. If indeed lacking, it
would be nice to have it explicitly stated, since its not obvious
how the mouse input method is supposed to work, compared to the
traditional alphanumeric input method. As mentioned below, these
items can easily cause confusion for Emacs neophytes.

I have interviewed a bunch of computer science students here in
Stockholm about their attitude and experience of Emacs over 2
years time, and their criticism is massive about the fact that the
open file menu command use the minibuffer for argument input. 

My interpretation of this criticism is that it derives from the
fact that the Emacs standard for graphic interface clashes heavily
with the Windows standard, which nearly all students were
previously accustomed to. Do you have any comments on this?

One student even reported that the behavior of the open-file
command was inconsistent over time, i.e. that the 2 prompting
methods were used randomly. My interpretation of this is 2
possibilities:

a) Either he has switched between the Linux and Windows platforms,
using Emacs 21 on both (and as I mentioned above, they seem to
behave differently)

b) Or else he hasnt realised that the promting method depends on
the command input method, and that he has switched between input
methods without realising that they elicit different prompting
methods.

Do you have any comments on this?

Quick response is greatly appreciated.  (I'm writing a usability
study on Emacs which is already overdue :-(
Thanks!






reply via email to

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