Discussion:
GTK file selector
(too old to reply)
Jérôme Marant
2005-12-14 09:27:36 UTC
Permalink
Hi,

I usually prefer Emacs compiled with Athena widgets. Nonetheless,
I decided to give the GTK version a try, again.

I may be dumb but with the current GTK file selector, I did not find
any way to view dotfiles and dotdirectories. So, I was unable to
open my .emacs nor to enter my .emacs.d directory.

Also, there is no textarea where I could enter a filename manually.

Is there something to configure I missed?

Thanks.

--
Jérôme Marant
Aidan Kehoe
2005-12-14 14:06:29 UTC
Permalink
Post by Jérôme Marant
I usually prefer Emacs compiled with Athena widgets. Nonetheless,
I decided to give the GTK version a try, again.
I may be dumb but with the current GTK file selector, I did not find
any way to view dotfiles and dotdirectories. So, I was unable to
open my .emacs nor to enter my .emacs.d directory.
Also, there is no textarea where I could enter a filename manually.
If it’s GTK2, then you should be able to start typing a file name and have a
text field appear. You can use this text field to access dot files.
Post by Jérôme Marant
Is there something to configure I missed?
--
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.
Jérôme Marant
2005-12-14 14:38:38 UTC
Permalink
Post by Jérôme Marant
I usually prefer Emacs compiled with Athena widgets. Nonetheless,
I decided to give the GTK version a try, again.
I may be dumb but with the current GTK file selector, I did not find
any way to view dotfiles and dotdirectories. So, I was unable to
open my .emacs nor to enter my .emacs.d directory.
Also, there is no textarea where I could enter a filename manually.
If it’s GTK2, then you should be able to start typing a file name and have
a
text field appear. You can use this text field to access dot files.
It indeed opens a textarea but typing the dotfile does not seem to
make it being opened.

Someone just told me I have to right-click on the filelist to activate
hidden file displaying.

I'm ashamed I have to ask such simple questions but the previous file
selector was much more intuitive.

Thanks.

--
Jérôme Marant
Eli Zaretskii
2005-12-14 19:41:04 UTC
Permalink
Date: Wed, 14 Dec 2005 15:38:38 +0100
Someone just told me I have to right-click on the filelist to activate
hidden file displaying.
I'm ashamed I have to ask such simple questions but the previous file
selector was much more intuitive.
The file selector is something GTK people develop, Emacs just uses
it. So perhaps you should complain to the GTK developers.
Jérôme Marant
2005-12-14 20:33:28 UTC
Permalink
Post by Eli Zaretskii
Date: Wed, 14 Dec 2005 15:38:38 +0100
Someone just told me I have to right-click on the filelist to activate
hidden file displaying.
I'm ashamed I have to ask such simple questions but the previous file
selector was much more intuitive.
The file selector is something GTK people develop, Emacs just uses
it. So perhaps you should complain to the GTK developers.
Sure. I was just asking here if it was related to some configuration
option, which seems not to be.

Thanks.
--
Jérôme Marant
Jan Djärv
2005-12-14 20:00:25 UTC
Permalink
Post by Jérôme Marant
I'm ashamed I have to ask such simple questions but the previous file
selector was much more intuitive.
You are not alone in thinking that. The GTK 2 file chooser has always been
controversial, but it is quite like the Mac OSX one (functionality wise). The
problem is that features like this are more or less hidden to a user who don't
hang around mailing lists like this :-)

Jan D.
Jérôme Marant
2005-12-16 20:10:40 UTC
Permalink
Post by Jan Djärv
Post by Jérôme Marant
I'm ashamed I have to ask such simple questions but the previous file
selector was much more intuitive.
You are not alone in thinking that. The GTK 2 file chooser has always
been controversial, but it is quite like the Mac OSX one
(functionality wise). The problem is that features like this are more
or less hidden to a user who don't hang around mailing lists like this
:-)
BTW, I noticed that Firefox, which is linked against the same gtk version
as Emacs on my system, uses a different file selector. It looks like the
previous one, if I recall correctly. Is the old file selector still
around in the current gtk? Or maybe did they re-code it?

Regards,
--
Jérôme Marant
Jan Djärv
2005-12-16 20:16:26 UTC
Permalink
Post by Jérôme Marant
BTW, I noticed that Firefox, which is linked against the same gtk version
as Emacs on my system, uses a different file selector. It looks like the
previous one, if I recall correctly. Is the old file selector still
around in the current gtk? Or maybe did they re-code it?
The old one is still around. The new one can be extended with plugins and may
look quite different on, for example, a Suse distribution. But I don't know
what Firefox has done.

Jan D.
Jérôme Marant
2005-12-16 20:28:37 UTC
Permalink
Post by Jan Djärv
Post by Jérôme Marant
BTW, I noticed that Firefox, which is linked against the same gtk version
as Emacs on my system, uses a different file selector. It looks like the
previous one, if I recall correctly. Is the old file selector still
around in the current gtk? Or maybe did they re-code it?
The old one is still around. The new one can be extended with plugins
and may look quite different on, for example, a Suse distribution.
But I don't know what Firefox has done.
Thanks.
--
Jérôme Marant
Paul Pogonyshev
2005-12-16 22:00:34 UTC
Permalink
Post by Jérôme Marant
Post by Jan Djärv
Post by Jérôme Marant
I'm ashamed I have to ask such simple questions but the previous file
selector was much more intuitive.
You are not alone in thinking that. The GTK 2 file chooser has always
been controversial, but it is quite like the Mac OSX one
(functionality wise). The problem is that features like this are more
or less hidden to a user who don't hang around mailing lists like this
:-)
BTW, I noticed that Firefox, which is linked against the same gtk version
as Emacs on my system, uses a different file selector. It looks like the
previous one, if I recall correctly. Is the old file selector still
around in the current gtk? Or maybe did they re-code it?
No, it is a completely different file chooser (just checked, at least in
1.0), I guess it is the same in all/most Firefox variants, regardless of
backend. BTW, Firefox GUI, in my opinion, is generally much worse than
that of GNOME/GTK+ standards-conforming applications, e.g. font selection
is atrocious.

Old GTK+ file selector is deprecated but not removed (probably not until
GTK+ 3.0 or something), see GtkFileSelection widget.

I ranted on GTK+ mailing list about the new file chooser too. It was
pretty unusable in 2.4, but in 2.6 it is already quite good, though I
still like the old one a little better in terms of keyboard usability.
However, I agree with GTK+ developers that for a common user the new
file chooser is much more convenient and intuitive.

Paul
Mario Domenech Goulart
2005-12-14 15:25:51 UTC
Permalink
Hello Jérôme
Post by Jérôme Marant
I usually prefer Emacs compiled with Athena widgets. Nonetheless,
I decided to give the GTK version a try, again.
I may be dumb but with the current GTK file selector, I did not find
any way to view dotfiles and dotdirectories. So, I was unable to
open my .emacs nor to enter my .emacs.d directory.
Also, there is no textarea where I could enter a filename manually.
Is there something to configure I missed?
If you right-click the files listing at the GTK file selector, a popup
menu will be displayed. This menu has a "Show hidden files" item.

Best wishes,
Mario
Jérôme Marant
2005-12-14 20:30:54 UTC
Permalink
Post by Mario Domenech Goulart
Post by Jérôme Marant
I usually prefer Emacs compiled with Athena widgets. Nonetheless,
I decided to give the GTK version a try, again.
I may be dumb but with the current GTK file selector, I did not find
any way to view dotfiles and dotdirectories. So, I was unable to
open my .emacs nor to enter my .emacs.d directory.
Also, there is no textarea where I could enter a filename manually.
Is there something to configure I missed?
If you right-click the files listing at the GTK file selector, a popup
menu will be displayed. This menu has a "Show hidden files" item.
Yes, thanks. It used to be a visible checkbox and it was just fine
that way. I can't agree more with Linus Torvalds about where GNOME
is going.
--
Jérôme Marant
Reiner Steib
2005-12-14 16:18:38 UTC
Permalink
Post by Jérôme Marant
I may be dumb but with the current GTK file selector,
[ See http://thread.gmane.org/439E24E2.1070201%40gmx.net for a related
discussion ]
Post by Jérôme Marant
I did not find any way to view dotfiles and dotdirectories. So, I
was unable to open my .emacs nor to enter my .emacs.d directory.
mouse-3 in the file list area (or however it's called), opens a "Show
hidden files" checkbox.
Post by Jérôme Marant
Also, there is no textarea where I could enter a filename manually.
Ctrl-l
Post by Jérôme Marant
Is there something to configure I missed?
,----[ <f1> v use-file-dialog RET ]
| use-file-dialog is a variable defined in `C source code'.
| Its value is nil
|
| Documentation:
| *Non-nil means mouse commands use a file dialog to ask for files.
| This applies to commands from menus and tool bar buttons. The value
| of `use-dialog-box' takes precedence over this variable, so a file
| dialog is only used if both `use-dialog-box' and this variable are
| non-nil.
`----

Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
Jérôme Marant
2005-12-14 21:23:01 UTC
Permalink
Post by Reiner Steib
Post by Jérôme Marant
I may be dumb but with the current GTK file selector,
[ See http://thread.gmane.org/439E24E2.1070201%40gmx.net for a related
discussion ]
Yes, I think this is a very good illustration of what's being
discussed.
Post by Reiner Steib
Post by Jérôme Marant
I did not find any way to view dotfiles and dotdirectories. So, I
was unable to open my .emacs nor to enter my .emacs.d directory.
mouse-3 in the file list area (or however it's called), opens a "Show
hidden files" checkbox.
Thanks.
Post by Reiner Steib
Post by Jérôme Marant
Also, there is no textarea where I could enter a filename manually.
Ctrl-l
Ah. I'll have to read docs in order to use GTK dialogs now ;-P
Post by Reiner Steib
Post by Jérôme Marant
Is there something to configure I missed?
,----[ <f1> v use-file-dialog RET ]
| use-file-dialog is a variable defined in `C source code'.
| Its value is nil
|
| *Non-nil means mouse commands use a file dialog to ask for files.
| This applies to commands from menus and tool bar buttons. The value
| of `use-dialog-box' takes precedence over this variable, so a file
| dialog is only used if both `use-dialog-box' and this variable are
| non-nil.
`----
I think I can switch back to C-x C-f ;-)
--
Jérôme Marant
Emfox Zhou
2005-12-14 16:20:28 UTC
Permalink
Post by Jérôme Marant
Hi,
I usually prefer Emacs compiled with Athena widgets. Nonetheless,
I decided to give the GTK version a try, again.
I may be dumb but with the current GTK file selector, I did not find
any way to view dotfiles and dotdirectories. So, I was unable to
open my .emacs nor to enter my .emacs.d directory.
hello, have you tried to right click your mouse on the selector anywhere? :)
Post by Jérôme Marant
Also, there is no textarea where I could enter a filename manually.
Ctrl+L. also it could be called via right click of the mouse.
Post by Jérôme Marant
Is there something to configure I missed?
Thanks.
--
Jérôme Marant
Richard M. Stallman
2005-12-15 02:08:41 UTC
Permalink
I may be dumb but with the current GTK file selector, I did not find
any way to view dotfiles and dotdirectories. So, I was unable to
open my .emacs nor to enter my .emacs.d directory.

Also, there is no textarea where I could enter a filename manually.

I heard yesterday that the latest GTK file selector
is so limited that it is making lots of people unhappy.

I hope I get a chance to see it for myself soon
so that I can come to solid conclusions.

Someone suggested:

If it's GTK2, then you should be able to start typing a file name and have a
text field appear. You can use this text field to access dot files.

Does that work for you? If so, could you explain to me what it means?
Jérôme Marant
2005-12-16 20:05:40 UTC
Permalink
Post by Richard M. Stallman
If it's GTK2, then you should be able to start typing a file name and have a
text field appear. You can use this text field to access dot files.
Does that work for you? If so, could you explain to me what it means?
A text field appears but typing a dotfile name does not make the file
being loaded.

As many people explained, Ctrl-l is the right action for this.

Regards,
--
Jérôme Marant
Frank Schmitt
2005-12-14 15:28:14 UTC
Permalink
Post by Jérôme Marant
I usually prefer Emacs compiled with Athena widgets. Nonetheless,
I decided to give the GTK version a try, again.
I may be dumb but with the current GTK file selector, I did not find
any way to view dotfiles and dotdirectories. So, I was unable to
open my .emacs nor to enter my .emacs.d directory.
Also, there is no textarea where I could enter a filename manually.
Is there something to configure I missed?
No, just hit / in the dialog, this gives you a small window where you
can enter the path and filename. You can also use C-l to open the dialog
box.

Yes, this sucks like hell.
--
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.
Stephen Berman
2005-12-15 09:00:43 UTC
Permalink
Post by Frank Schmitt
Post by Jérôme Marant
I usually prefer Emacs compiled with Athena widgets. Nonetheless,
I decided to give the GTK version a try, again.
I may be dumb but with the current GTK file selector, I did not find
any way to view dotfiles and dotdirectories. So, I was unable to
open my .emacs nor to enter my .emacs.d directory.
Also, there is no textarea where I could enter a filename manually.
Is there something to configure I missed?
No, just hit / in the dialog, this gives you a small window where you
can enter the path and filename. You can also use C-l to open the dialog
box.
If you type any non-function or non-prefix key while the dialog is
foregrounded, it opens an even smaller text box with the value of the
key already inserted and the first entry in the current directory that
matches the value highlighted (as I just discovered by doing that on a
whim).

Steve Berman
Richard M. Stallman
2005-12-16 01:52:07 UTC
Permalink
Post by Frank Schmitt
No, just hit / in the dialog, this gives you a small window where you
can enter the path and filename. You can also use C-l to open the dialog
box.
If you type any non-function or non-prefix key while the dialog is
foregrounded, it opens an even smaller text box with the value of the
key already inserted and the first entry in the current directory that
matches the value highlighted (as I just discovered by doing that on a
whim).

These sound like reasonable features. What is missing is something to
give the user a clue to them.
Juri Linkov
2005-12-15 12:59:21 UTC
Permalink
Post by Frank Schmitt
Post by Jérôme Marant
Is there something to configure I missed?
No, just hit / in the dialog, this gives you a small window where you
can enter the path and filename. You can also use C-l to open the dialog
box.
Yes, this sucks like hell.
What an irony that the goal of Gnome developers was to design an easy-to-use
file dialog, and now no one can use it without hints acquired from others.

If there is some option that restores the old reasonable behavior in new
GTK2 dialogs, Emacs could set such an option by default.
--
Juri Linkov
http://www.jurta.org/emacs/
Aidan Kehoe
2005-12-15 15:52:34 UTC
Permalink
Post by Juri Linkov
Post by Frank Schmitt
Post by Jérôme Marant
Is there something to configure I missed?
No, just hit / in the dialog, this gives you a small window where you
can enter the path and filename. You can also use C-l to open the dialog
box.
Yes, this sucks like hell.
What an irony that the goal of Gnome developers was to design an easy-to-use
file dialog, and now no one can use it without hints acquired from others.
It’s an irony if you ignore that their goal was to design a dialog that was
easy to use for naive users. In 2005, naive users do not use any form of
emacs, in general, and even the experts are abandoning it today.
Post by Juri Linkov
If there is some option that restores the old reasonable behavior in new
GTK2 dialogs, Emacs could set such an option by default.
--
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.
Juri Linkov
2005-12-16 07:56:56 UTC
Permalink
Post by Aidan Kehoe
Post by Juri Linkov
What an irony that the goal of Gnome developers was to design an easy-to-use
file dialog, and now no one can use it without hints acquired from others.
It’s an irony if you ignore that their goal was to design a dialog that was
easy to use for naive users.
I doubt very much that removing useful features to make a simplistic UI
will persuade naive users to use the Gnome environment. So I still
don't understand what is the target audience of Gnome developers.
Post by Aidan Kehoe
In 2005, naive users do not use any form of emacs, in general,
By analogy with GTK2 dialog windows, removing features from Emacs
to make it similar to Notepad will make naive users happy :-)
Post by Aidan Kehoe
and even the experts are abandoning it today.
Why do they abandon it? And what do they prefer instead?
--
Juri Linkov
http://www.jurta.org/emacs/
Aidan Kehoe
2005-12-16 11:38:02 UTC
Permalink
Post by Juri Linkov
Post by Aidan Kehoe
Post by Juri Linkov
What an irony that the goal of Gnome developers was to design an
easy-to-use file dialog, and now no one can use it without hints
acquired from others.
It’s an irony if you ignore that their goal was to design a dialog that
was easy to use for naive users.
I doubt very much that removing useful features to make a simplistic UI
will persuade naive users to use the Gnome environment.
Making a UI that’s no more complicated than it needs to be may, and that’s
what they’ve done for the naïve user. They’ve made it more awkward for the
expert, but for mass-market software, the expert doesn’t matter.

However, I believe that the comparative advantage from Gnome’s new-found
simplicity won’t outweigh the endorsement from Linus for KDE; indeed, the
endorsement from Linus for one environment over the other might be the
impetus needed for KDE to pull ahead as the dominant desktop environment,
and finally having a standard desktop environment would be an excellent
thing.
Post by Juri Linkov
So I still don't understand what is the target audience of Gnome
developers.
Post by Aidan Kehoe
In 2005, naive users do not use any form of emacs, in general,
By analogy with GTK2 dialog windows, removing features from Emacs
to make it similar to Notepad will make naive users happy :-)
Do you not understand what the GTK2 people did? They didn’t remove features,
it’s just as possible to use the new dialog box in the same way as the old.
Less obvious for what experts want to do, but experts are experts, they’ll
figure it out.

And yes, making GNU Emacs behave more like a Win32 app, like Notepad, _will_
make naïve users happy. Look at the success of CUA-mode. Hang round with
Win32 users looking for an advanced editor, and they’ll go for Notepad++
long before GNU Emacs, because all their habits from Notepad work in
Notepad++, and not in emacs. Emacs is more featureful, but not enough to
overcome the pain of finding out what CUA-mode is and doing all the other
donkey-work to have the editor behave like what they’re used to.
Post by Juri Linkov
Post by Aidan Kehoe
and even the experts are abandoning it today.
Why do they abandon it? And what do they prefer instead?
They abandon it because of stagnant development, the design and
implementation clusterfuck that is Mule from the perspective of European
language users (search for ö not working again!) and minimal consideration
for GUI users in this age of 17" screens. Among other reasons.

Eclipse, VIM or Notepad++ seem to be what most of the power users I know who
chose an advanced editor recently are using.
--
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.
Juri Linkov
2005-12-16 12:49:00 UTC
Permalink
Post by Aidan Kehoe
Do you not understand what the GTK2 people did? They didn’t remove features,
it’s just as possible to use the new dialog box in the same way as the old.
The filename entry field (with available TAB completion like in Emacs) was
a very useful feature. Neither C-l nor a small text box that appears
after starting typing is an acceptable replacement.
Post by Aidan Kehoe
And yes, making GNU Emacs behave more like a Win32 app, like Notepad, _will_
make naïve users happy. Look at the success of CUA-mode.
CUA-mode doesn't disable useful Emacs features.
Post by Aidan Kehoe
Hang round with Win32 users looking for an advanced editor, and they’ll
go for Notepad++ long before GNU Emacs, because all their habits from
Notepad work in Notepad++, and not in emacs.
Notepad++ is not easier to use for naive users than Emacs.
Post by Aidan Kehoe
Emacs is more featureful, but not enough to overcome the pain of finding
out what CUA-mode is
The top-level menu item in the Options menu that enables CUA-mode
and its tooltip are self-descriptive enough.
Post by Aidan Kehoe
and doing all the other donkey-work to have the editor behave like what
they’re used to.
Experts can do this easily anyway.
Post by Aidan Kehoe
They abandon it because of stagnant development, the design and
implementation clusterfuck that is Mule from the perspective of European
language users (search for ö not working again!)
Not in the unicode-2 branch.
Post by Aidan Kehoe
and minimal consideration for GUI users in this age of 17"
screens. Among other reasons.
Eclipse, VIM or Notepad++ seem to be what most of the power users I know who
chose an advanced editor recently are using.
I don't think VIM belongs to the category of Notepad-like editors.
--
Juri Linkov
http://www.jurta.org/emacs/
Romain Francoise
2005-12-16 15:40:22 UTC
Permalink
Post by Juri Linkov
Post by Aidan Kehoe
They abandon it because of stagnant development, the design and
implementation clusterfuck that is Mule from the perspective of European
language users (search for ö not working again!)
Not in the unicode-2 branch.
This search bug should now be fixed in the trunk, too.
--
Romain Francoise <***@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
Kaloian Doganov
2005-12-17 10:44:59 UTC
Permalink
Post by Romain Francoise
Post by Juri Linkov
Post by Aidan Kehoe
They abandon it because of stagnant development, the design and
implementation clusterfuck that is Mule from the perspective of
European language users (search for ö not working again!)
Not in the unicode-2 branch.
This search bug should now be fixed in the trunk, too.
It is fixed indeed. I've just checked it out. Thank you, Romain.


--
Поздрави,
Калоян Доганов.
___________________________________________________________
Ако не отговарям на писмата Ви:
Romain Francoise
2005-12-17 15:16:17 UTC
Permalink
Post by Kaloian Doganov
It is fixed indeed. I've just checked it out.
Thanks for checking!
Post by Kaloian Doganov
Thank you, Romain.
To give credit where it's due: it was Kenichi Handa who fixed this bug,
not me.
--
Romain Francoise <***@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
Kim F. Storm
2005-12-16 16:27:47 UTC
Permalink
Post by Juri Linkov
Post by Aidan Kehoe
They abandon it because of stagnant development, the design and
implementation clusterfuck that is Mule from the perspective of European
language users (search for ö not working again!)
Not in the unicode-2 branch.
Which might enter pretest in 2010 or so...
--
Kim F. Storm <***@cua.dk> http://www.cua.dk
Chong Yidong
2005-12-16 20:54:56 UTC
Permalink
Post by Juri Linkov
Post by Aidan Kehoe
Emacs is more featureful, but not enough to overcome the pain of finding
out what CUA-mode is
The top-level menu item in the Options menu that enables CUA-mode
and its tooltip are self-descriptive enough.
Only in Emacs 22. Since we're discussing why people are abandoning
Emacs, we can't point to features that haven't been released (or may
never be released.)
Nick Roberts
2005-12-16 20:08:37 UTC
Permalink
Post by Aidan Kehoe
Post by Juri Linkov
Why do they abandon it? And what do they prefer instead?
They abandon it because of stagnant development, the design and
implementation clusterfuck that is Mule from the perspective of European
language users (search for ö not working again!) and minimal consideration
for GUI users in this age of 17" screens. Among other reasons.
Over the last three years that I've been contributing to Emacs, development
has been pretty active. Without doing market research, any notion that
people are abandoning Emacs can only be anecdotal. Perhaps you're bitter
that XEmacs does seemed to have slowed down, but please remember this
list is for contributing to Emacs development, not to knock it down.

Nick
David Kastrup
2005-12-16 22:23:28 UTC
Permalink
Post by Nick Roberts
Post by Aidan Kehoe
Post by Juri Linkov
Why do they abandon it? And what do they prefer instead?
They abandon it because of stagnant development, the design and
implementation clusterfuck that is Mule from the perspective of
European language users (search for ö not working again!) and
minimal consideration for GUI users in this age of 17"
screens. Among other reasons.
Over the last three years that I've been contributing to Emacs,
development has been pretty active.
Which would rather explain why people are abandoning it: those three
years of development have never been released.
Post by Nick Roberts
Without doing market research, any notion that people are abandoning
Emacs can only be anecdotal.
Debian by now has "emacs-snapshot" as a package. People _are_
abandoning released versions of Emacs, also because of problems in the
utf-8 department. CVS trunk is much better than anything that has
been released, but few system administrators will, even when tempted
to use it themselves, unleash an unreleased Emacs unto their users.
Post by Nick Roberts
Perhaps you're bitter that XEmacs does seemed to have slowed down,
but please remember this list is for contributing to Emacs
development, not to knock it down.
XEmacs at least sports more or less regular releases from their
increasingly stagnant development code base.

"Waiting for Emacs" would make for a scintillating piece of absurd
theater, with the particularly rememberable line "Code, pig!". I have
not yet figured out where XEmacs would come into play, though.


ESTRAGON:
Charming spot. (He turns, advances to front, halts facing
auditorium .) Inspiring prospects. (He turns to Vladimir.) Let's
release.


VLADIMIR:
We can't.


ESTRAGON:
Why not?

VLADIMIR:
We're waiting for Bugfixes.


ESTRAGON:
(despairingly). Ah! (Pause.) You're sure it was here?


VLADIMIR:
What?


ESTRAGON:
That we were to wait.


VLADIMIR:
He said from the trunk. (They look at the CVS tree.) Do you see any others?


ESTRAGON:
What is it?


VLADIMIR:
I don't know. A branch.


ESTRAGON:
Where are the commits?


VLADIMIR:
It must be dead.


ESTRAGON:
No more weeping.


VLADIMIR:
Or perhaps it's not the season.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Jérôme Marant
2005-12-16 23:23:19 UTC
Permalink
Post by David Kastrup
Post by Nick Roberts
Perhaps you're bitter that XEmacs does seemed to have slowed down,
but please remember this list is for contributing to Emacs
development, not to knock it down.
XEmacs at least sports more or less regular releases from their
increasingly stagnant development code base.
I think it could be fixed by making bugfix releases as I already
proposed many times (I also proposed to add myself as manpower
for such a purpose). So far, supporting the current released
version is not wanted, as far as I understood.

Also, I wonder if the modular design -- separating core and
modules -- makes it easier to release often. But, this does not
seem to be an open discussion.

Regards,
--
Jérôme Marant
David Kastrup
2005-12-16 23:38:10 UTC
Permalink
Post by Jérôme Marant
Post by David Kastrup
Post by Nick Roberts
Perhaps you're bitter that XEmacs does seemed to have slowed down,
but please remember this list is for contributing to Emacs
development, not to knock it down.
XEmacs at least sports more or less regular releases from their
increasingly stagnant development code base.
I think it could be fixed by making bugfix releases as I already
proposed many times (I also proposed to add myself as manpower for
such a purpose). So far, supporting the current released version is
not wanted, as far as I understood.
We have already too little manpower to support the coming release.
Post by Jérôme Marant
Also, I wonder if the modular design -- separating core and modules
-- makes it easier to release often.
One has to be aware that in the case of XEmacs, this is snake oil.
XEmacs' code base, while frequently released, has not yet even caught
up to Emacs-21.0 in core areas. The packages, while frequently
released, are often in a state of disarray and various levels of
outdatedness. XEmacs-21.5 is quite unstable. And so on. There is
the occasional package that is kept more up to date in that manner,
but the overall effect is not consistently convincing to me.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Jérôme Marant
2005-12-17 13:05:30 UTC
Permalink
Post by David Kastrup
Post by Jérôme Marant
I think it could be fixed by making bugfix releases as I already
proposed many times (I also proposed to add myself as manpower for
such a purpose). So far, supporting the current released version is
not wanted, as far as I understood.
We have already too little manpower to support the coming release.
Really? There are more than one hundred committers, according to
the Emacs page at Savannah.

Isn't it only a broadening the scope of features for the next release?
Post by David Kastrup
Post by Jérôme Marant
Also, I wonder if the modular design -- separating core and modules
-- makes it easier to release often.
One has to be aware that in the case of XEmacs, this is snake oil.
XEmacs' code base, while frequently released, has not yet even caught
up to Emacs-21.0 in core areas. The packages, while frequently
released, are often in a state of disarray and various levels of
outdatedness. XEmacs-21.5 is quite unstable. And so on. There is
the occasional package that is kept more up to date in that manner,
but the overall effect is not consistently convincing to me.
I'm not promoting anything but IMHO XEmacs did it right from the
very beginning by focusing on what users expect the most from, that
is user interface: toolbar (movable on the left and on the right
as well), buffer tabs, horizontal scrollbars, a gutter, rich
menu entries from where most UI options can be configured (I'm
not talking about "customize"), a package system.
I'd even say that there are enough features for most end users.
The only necessary improvement I can see is related to Unicode
support (which Emacs is doing quite right).

Catching-up with Emacs is only necessary because Emacs APIs do change,
are enriched, and mode authors who mostly use Emacs update their
software accordly.
--
Jérôme Marant
David Kastrup
2005-12-17 15:22:31 UTC
Permalink
Post by David Kastrup
Post by Jérôme Marant
I think it could be fixed by making bugfix releases as I already
proposed many times (I also proposed to add myself as manpower for
such a purpose). So far, supporting the current released version
is not wanted, as far as I understood.
We have already too little manpower to support the coming release.
Really? There are more than one hundred committers, according to the
Emacs page at Savannah.
Most of the work is done by very few people. Committers are basically
just people comfortable with CVS, who have signed the necessary
assignments and are expected not to do anything really bad too often.
However, that does not mean that you can rely on them doing useful
stuff all too frequently.
Post by David Kastrup
Post by Jérôme Marant
Also, I wonder if the modular design -- separating core and
modules -- makes it easier to release often.
One has to be aware that in the case of XEmacs, this is snake oil.
XEmacs' code base, while frequently released, has not yet even
caught up to Emacs-21.0 in core areas. The packages, while
frequently released, are often in a state of disarray and various
levels of outdatedness. XEmacs-21.5 is quite unstable. And so on.
There is the occasional package that is kept more up to date in
that manner, but the overall effect is not consistently convincing
to me.
I'm not promoting anything but IMHO XEmacs did it right from the
very beginning by focusing on what users expect the most from, that
But we are not talking about the user interface here. We are talking
a package system.
And as I said, the overall effect does not seem too convincing to me.
Many packages have not even caught up to the state of Emacs-21. I
actually had quite a bit of fallout with the XEmacs developers over
integrating AUCTeX as a package into XEmacs.
I'd even say that there are enough features for most end users.
But we are not talking about "features", but usability, both for users
and programmers. Whenever I have had contact with XEmacs, lot of the
stuff was unusable to me. Documentation and stuff of the features
tends to be so bad that it is hard to programmatically interface to
it. Those features just don't get used.

As an example: when working with preview-latex, it was found that
images displayed from a binary file format were garbled when dired was
loaded. This was analyzed and reported by a programmer in our project
who subsequently went silent. Several years later, nobody had
bothered fixing the stuff. I don't think it is fixed even now.

Now I think you will agree that displaying images are sort of a
feature for which XEmacs was renowned (this does not concern the
normal icons and toolbars who are read from a non-binary image
format), and dired is pretty basic.

And yet, nobody apparently used this functionality for years and
years. A lot of the stuff in XEmacs is like that: implemented, and
left unused because it has, maybe because of the roughness of APIs and
documentation, not been tied into any application in frequent use.

And the package system partly is a way not to feel bad about material
in various states of disarray. How many people actually use the
package system? It actually is likely to interfere with the package
systems of operating system distributions if you actually use it.

XEmacs has always had a much larger overlap between developers and
users. In contrast, Emacs has for a long time had a pretty closed
inner circle. As a result, Emacs development and maintainance has
turned out to care a lot more for users who neither are nor want to be
developers.

Of course, not releasing any of the work for such a long time is not a
good thing for the end user. But it does not look to me like a
package system would lead to a better situation.
The only necessary improvement I can see is related to Unicode
support (which Emacs is doing quite right).
Which is partly because people involved with it are actively using it.
With XEmacs, there is currently Ben Wing working in the background on
stuff that will at one time emerge while everybody is waiting with
bated breath, and it will not magically solve all problems.

The link between engineering and actual use in the real world is in my
opinion what is the strongest ailment of XEmacs. And I don't think
the package system is much of a help there. And getting more frequent
releases which still don't work well does not cut it, either.
Catching-up with Emacs is only necessary because Emacs APIs do
change, are enriched, and mode authors who mostly use Emacs update
their software accordly.
Sure, and your point was? We don't change Emacs just for fun, but to
improve it, for users as well as developers. And catching-up means
passing on those improvements.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Aidan Kehoe
2005-12-17 22:21:27 UTC
Permalink
My perception is that XEmacs’ main problems are manpower and GNU
compatibility, GNU Emacs’ main problem is management. GNU Emacs doesn’t lack
manpower or mailing list activity compared to say, Perl or GCC. That said --
Post by David Kastrup
Post by Jérôme Marant
I'm not promoting anything but IMHO XEmacs did it right from the
very beginning by focusing on what users expect the most from, that
But we are not talking about the user interface here. We are talking
Post by Jérôme Marant
a package system.
And as I said, the overall effect does not seem too convincing to me.
Many packages have not even caught up to the state of Emacs-21. I
actually had quite a bit of fallout with the XEmacs developers over
integrating AUCTeX as a package into XEmacs.
Your falling out out was an artifact of the details of our package system,
not of having a package system in itself. Our package system is too
centralised, and oriented towards XEmacs committers to easily accommodate
what you wanted to do. The package system does work better than the
monolithic alternative, users do see finished code quicker.
Post by David Kastrup
Post by Jérôme Marant
I'd even say that there are enough features for most end users.
But we are not talking about "features", but usability, both for users
and programmers. Whenever I have had contact with XEmacs, lot of the
stuff was unusable to me. Documentation and stuff of the features
tends to be so bad that it is hard to programmatically interface to
it. Those features just don't get used.
As an example: when working with preview-latex, it was found that
images displayed from a binary file format were garbled when dired was
loaded. This was analyzed and reported by a programmer in our project
who subsequently went silent. Several years later, nobody had
bothered fixing the stuff. I don't think it is fixed even now.
Yup. We lack manpower. I should be writing code and documentation now, not
this mail. But I’m not making a living from XEmacs, I’m doing what I do in
my spare time, so a certain amount of indulging whims is reasonable.
Post by David Kastrup
Now I think you will agree that displaying images are sort of a
feature for which XEmacs was renowned (this does not concern the
normal icons and toolbars who are read from a non-binary image
format), and dired is pretty basic.
And yet, nobody apparently used this functionality for years and
years. A lot of the stuff in XEmacs is like that: implemented, and
left unused because it has, maybe because of the roughness of APIs and
documentation, not been tied into any application in frequent use.
And maybe because anything implemented using the XEmacs-specific APIs will
never run on GNU Emacs, so coders tend to put off writing code to use a
feature until that feature makes it into GNU Emacs, at which point XEmacs
provides a compatibility API--the reverse is never true. Eminently rational
behaviour.

[...]
--
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.
David Kastrup
2005-12-18 00:38:33 UTC
Permalink
Post by Aidan Kehoe
Post by David Kastrup
And yet, nobody apparently used this functionality for years and
years. A lot of the stuff in XEmacs is like that: implemented,
and left unused because it has, maybe because of the roughness of
APIs and documentation, not been tied into any application in
frequent use.
And maybe because anything implemented using the XEmacs-specific
APIs will never run on GNU Emacs, so coders tend to put off writing
code to use a feature until that feature makes it into GNU Emacs, at
which point XEmacs provides a compatibility API--the reverse is
never true. Eminently rational behaviour.
I can only speak for myself. I tried using and working with images
when XEmacs was the only variant providing them. I failed. I was
completely unable to make heads or tails of the available
documentation. The whole details with specifiers and instantiators
and stuff like that was completely opaque. References in the manual
pointed you to other places in the manual, no examples were there,
terminology was not defined. In short: it was completely unusable
unless you were willing to get intimate with the code itself and find
out what this was supposed to be all about.

The preview-latex project basically lay dormant until Emacs acquired
image support. It became a matter of professional pride to make it
work under XEmacs, too, after it worked under Emacs already. After I
had in the past given several rants about the quality of
documentation, things were supposed to have improved. I tried several
times to get it to work, and failed. Some volunteer tried his hand,
and gave up. Finally I got a core developer from XEmacs interested in
the problem. It took him months to port this to XEmacs, partly
because XEmacs image code was still not documented usefully for all
but the people really into the XEmacs code base, partly because the
XEmacs image code was chock full of bugs. As well as the process
handling. Bugs I could not possibly have imagined, circumvented, or
reliably tracked down. Bugs in functionality that was claimed to have
been working for quite a few years.

preview-latex is an application that works with the purported strong
points of XEmacs. It would have been utterly impossible to get it to
work without the help of an internal XEmacs programmer who worked out
how to do stuff that was missing in the documentation, and who fixed
most of the bugs that were simply everywhere.

In contrast, the documentation of Emacs was comprehensible, and stuff
basically worked. There were redisplay errors: I think I sent at
least a dozen separate bug reports about them to Gerd Möllmann. But
those were locatable, and not of the "things crash" or "impossible to
figure out how this is supposed to work" variety. And the manual was
sufficient for finding out how things were supposed to work.

If things don't get ported to XEmacs until there is a compatibility
API, this can simply be because the native API is incomprehensible, if
it works at all.

Point the fingers all you want, but you are deluding yourself if you
imagine that the waning popularity of XEmacs among developers is just
a matter of religious beliefs.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Aidan Kehoe
2005-12-18 11:07:31 UTC
Permalink
[...] If things don't get ported to XEmacs until there is a compatibility
API, this can simply be because the native API is incomprehensible, if it
works at all.
Sure, but the GNU APIs, with their documentation and clarity, didn’t get
that way _ex nihilo._ I’m sure someone besides the original developer tried
to use them, failed, found out why, and fixed the problem.
Point the fingers all you want, but you are deluding yourself if you
imagine that the waning popularity of XEmacs among developers is just
a matter of religious beliefs.
I never imagined any such thing. The waning popularity of XEmacs among
developers is a result of the waning popularity of XEmacs among users, whose
roots are that Ben Wing hasn’t been coding like a dervish for most of a
decade, and that Stephen’s high quality standards for letting code in means
people who learn about the codebase from scratching an itch, are discouraged
when the code to do that isn’t integrated.

Anyway, back to doing something useful.
--
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.
Jérôme Marant
2005-12-18 12:56:14 UTC
Permalink
Post by David Kastrup
Post by Jérôme Marant
I'm not promoting anything but IMHO XEmacs did it right from the
very beginning by focusing on what users expect the most from, that
But we are not talking about the user interface here. We are talking
I'll explain later why I think it is indirectly relevant.
Post by David Kastrup
Post by Jérôme Marant
a package system.
And as I said, the overall effect does not seem too convincing to me.
Many packages have not even caught up to the state of Emacs-21. I
I've already been publicly accused of trying to undermine the Emacs
project when dealing this subject.
The situtation with Emacs would be different since it is the mainline,
so updated package would be painless for developers and users would
get bugfixes more quickly.
I think the problem with XEmacs is mostly due to the fact that adapting
modes that are written for Emacs is more and more difficult as mode
writers tend to use newer Emacs features.
Post by David Kastrup
actually had quite a bit of fallout with the XEmacs developers over
integrating AUCTeX as a package into XEmacs.
Quite loudly ;-)

[...]
Post by David Kastrup
Post by Jérôme Marant
The only necessary improvement I can see is related to Unicode
support (which Emacs is doing quite right).
Which is partly because people involved with it are actively using it.
With XEmacs, there is currently Ben Wing working in the background on
stuff that will at one time emerge while everybody is waiting with
bated breath, and it will not magically solve all problems.
The link between engineering and actual use in the real world is in my
opinion what is the strongest ailment of XEmacs. And I don't think
the package system is much of a help there. And getting more frequent
releases which still don't work well does not cut it, either.
I think the unicode support is out of the scope of the package system.
It is a core feature which requires a major release update.
Post by David Kastrup
Post by Jérôme Marant
Catching-up with Emacs is only necessary because Emacs APIs do
change, are enriched, and mode authors who mostly use Emacs update
their software accordly.
Sure, and your point was? We don't change Emacs just for fun, but to
improve it, for users as well as developers. And catching-up means
passing on those improvements.
OK, I'm going to explain my point. No offence meant.

For end users -- that is, people who use the text editor as a text
editor and are not spending time customizing the editor nor editing
the editor -- (and being myself an end user) there is not anything
really new to expect from Emacs 22. I used to fire it up many times
while working on emacs-snapshot, and did my usual work (coding in C,
Perl, Python, Make, Shell and so on) and I did not feel it was
different from Emacs 21.3, which provides just fine all what I need
these days. Of course, there is the GTK interface for the eye-candy
(to the detriment of performance) and better unicode support for
non-European countries. But for the average end users, I can say
there is not anything worth waiting 4+ years.

What I was saying with XEmacs is that they decided at the very
beginning to prodive UI features that users wants these days, such
as buffer tabs, rich menu entry avoiding the use of the ugly
"customize" as much as possible, a gutter, and so on, which is
just enough for the average end user these days. So, except from
the lack of unicode support, there is not much in the land of
improvement but bugfixes, for a _text editor_.
The package system could be just fine _iff_ packaged modes did not
come from the Emacs land.

Emacs still does not have the necessary features for competing with
bare text editors (I'm not talking about displaying images, reading
mail or chating with irc).

And let's be honest, Emacs is not going to provide any of the nice
features that Eclipse provides these days. And Eclipse is free, runs
with a free Java Platform, is extensible, and so on. Furthermore,
there is no more performance argument against Java since Eclipse
compiled with GCJ is pretty fast (congratulations to CGJ and GNU
Classpath people!).
--
Jérôme Marant
David Kastrup
2005-12-18 13:40:02 UTC
Permalink
Post by Jérôme Marant
Post by David Kastrup
But we are not talking about the user interface here. We are talking
I'll explain later why I think it is indirectly relevant.
Where?
Post by Jérôme Marant
Post by David Kastrup
Post by Jérôme Marant
a package system.
And as I said, the overall effect does not seem too convincing to me.
Many packages have not even caught up to the state of Emacs-21. I
I've already been publicly accused of trying to undermine the Emacs
project when dealing this subject.
The situtation with Emacs would be different since it is the
mainline,
And that's the whole point. There is no automatic "mainline" after a
fork with regard to developer involvement. And yet Emacs has regained
the "mainline" moniker in the eyes of some.
Post by Jérôme Marant
so updated package would be painless for developers and users would
get bugfixes more quickly.
You are presumably talking about a package system like XEmacs' in the
use of Emacs. It is wishful thinking to assume that its effects on
Emacs would be magically different than on XEmacs. A package system's
intent is to decrease the number of collisions between an abundance of
workers by organizing them into more independent departments with
separate release policies and timelines.

We don't have an abundance of workers. Neither does XEmacs. The
XEmacs package system is, in its current state, just overengineering.
Almost nobody uses anything except the Sumo collections, and it will
likely cause interference with operating system package systems if you
attempt actually using the XEmacs package system.
Post by Jérôme Marant
I think the problem with XEmacs is mostly due to the fact that
adapting modes that are written for Emacs is more and more difficult
as mode writers tend to use newer Emacs features.
But why is XEmacs dependent on adapting modes that are written for
Emacs? Because people choose Emacs as their first platform.
Post by Jérôme Marant
Post by David Kastrup
Sure, and your point was? We don't change Emacs just for fun, but
to improve it, for users as well as developers. And catching-up
means passing on those improvements.
OK, I'm going to explain my point. No offence meant.
For end users -- that is, people who use the text editor as a text
editor and are not spending time customizing the editor nor editing
the editor -- (and being myself an end user) there is not anything
really new to expect from Emacs 22.
Except for better syntax highlighting (enabled by default), better
filling, strikingly better handling of images, better scrolling,
working Unicode support including cut&paste between applications,
basic drag&drop support, automatical support of mouse wheels, working
image support on platforms beyond X11, mouse-induceable temporary
transient-mark-mode (this is a _very_ important improvement for the
average user), CUA-mode, tramp, Leim, a large number of included
documents like the Elisp programming manual and tutorial, a much
improved Gnus, a spreadsheet, a symbolic calculator and so forth and
so on.

Just type C-h C-n.
Post by Jérôme Marant
But for the average end users, I can say there is not anything worth
waiting 4+ years.
Beg to differ.
Post by Jérôme Marant
What I was saying with XEmacs is that they decided at the very
beginning to prodive UI features that users wants these days, such
as buffer tabs, rich menu entry avoiding the use of the ugly
"customize" as much as possible, a gutter, and so on, which is
just enough for the average end user these days. So, except from
the lack of unicode support, there is not much in the land of
improvement but bugfixes, for a _text editor_.
But there has been room for lots of improvement within Emacs. The
reason we are getting tense here about the release of Emacs-22 is not
because Emacs-22 would be just the same as Emacs-21. Maybe you
consider it similar in the core feature set, but core features alone
don't cut it. You don't get anywhere just by implementing some fancy
feature and then letting it rot away. It has to get tied into the
average person's work flow.
Post by Jérôme Marant
The package system could be just fine _iff_ packaged modes did not
come from the Emacs land.
So why do they come from the Emacs land? And if the package system is
just something important for dealing with packages coming "from Emacs
land", why would Emacs need one?
Post by Jérôme Marant
Emacs still does not have the necessary features for competing with
bare text editors (I'm not talking about displaying images, reading
mail or chating with irc).
Well, it fares pretty well considering that it is not able to
compete.
Post by Jérôme Marant
And let's be honest, Emacs is not going to provide any of the nice
features that Eclipse provides these days.
Well, that certainly would seem to work in both ways.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Stephen J. Turnbull
2005-12-18 17:37:24 UTC
Permalink
David> You are presumably talking about a package system like
David> XEmacs' in the use of Emacs. It is wishful thinking to
David> assume that its effects on Emacs would be magically
David> different than on XEmacs.

Exactly! They'd be similar, and similarly beneficial. IMHO YMMV.

Overall, your claims about the intent and usage of the XEmacs package
system are incorrect, although I'm willing to admit that some of them
bear a slight resemblence to AUCTeX reality. I would be happy to
support my counterclaim in an appropriate venue, but as far as I know
a package system has been vetoed, so emacs-devel isn't it. In the
meantime, I hope you will stop posting misinformation about XEmacs's
package system. It doesn't do Emacs any good.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
David Kastrup
2005-12-18 17:57:38 UTC
Permalink
Post by Stephen J. Turnbull
David> You are presumably talking about a package system like
David> XEmacs' in the use of Emacs. It is wishful thinking to
David> assume that its effects on Emacs would be magically
David> different than on XEmacs.
Exactly! They'd be similar, and similarly beneficial. IMHO YMMV.
Overall, your claims about the intent and usage of the XEmacs
package system are incorrect, although I'm willing to admit that
some of them bear a slight resemblence to AUCTeX reality. I would
be happy to support my counterclaim in an appropriate venue, but as
far as I know a package system has been vetoed, so emacs-devel isn't
it. In the meantime, I hope you will stop posting misinformation
about XEmacs's package system. It doesn't do Emacs any good.
It was not I who has brought the topic up on this list again, and I
don't think that anything can be gained by prohibiting Emacs
developers that actually have had contact with the XEmacs package
system to comment on the claims of XEmacs developers on the Emacs
developer list.

So just stop bringing up your claims here, and I won't feel compelled
to report my experiences in reply.

Simple as that. It is not like we don't have enough other stuff on
our hands.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Xavier Maillard
2005-12-18 20:37:07 UTC
Permalink
Post by David Kastrup
Post by Jérôme Marant
Catching-up with Emacs is only necessary because Emacs APIs do
change, are enriched, and mode authors who mostly use Emacs update
their software accordly.
Sure, and your point was? We don't change Emacs just for fun, but to
improve it, for users as well as developers. And catching-up means
passing on those improvements.
OK, I'm going to explain my point. No offence meant.

For end users -- that is, people who use the text editor as a text
editor and are not spending time customizing the editor nor editing
the editor -- (and being myself an end user) there is not anything
really new to expect from Emacs 22.

The main point is that GNU Emacs is not _just_ a text editor. GNU Emacs is
more and more stable, it will provide updates for many modes including gnus,
it will provide many new modes such as EMMS, it will provide bug fixes, ...

This is what a release should provide: enhancements, new features, stability
and bug fixes.

Emacs still does not have the necessary features for competing with
bare text editors (I'm not talking about displaying images, reading
mail or chating with irc).

Hum, I do not see what features you are talking. Emacs is by far the most
advanced text editor providing all the coolest features one can expect from
such a software.

And let's be honest, Emacs is not going to provide any of the nice
features that Eclipse provides these days.

Can you enumerate few of these nice features ?

Xavier
Miles Bader
2005-12-18 22:36:10 UTC
Permalink
Post by Jérôme Marant
And let's be honest, Emacs is not going to provide any of the nice
features that Eclipse provides these days.
Can you enumerate few of these nice features ?
Rounded widget corners.

:-)

-miles
--
"Suppose He doesn't give a shit? Suppose there is a God but He
just doesn't give a shit?" [George Carlin]
Stefan Monnier
2005-12-18 23:33:48 UTC
Permalink
Post by Miles Bader
Post by Jérôme Marant
And let's be honest, Emacs is not going to provide any of the nice
features that Eclipse provides these days.
Can you enumerate few of these nice features ?
Rounded widget corners.
In terms of features that I'd care about, so-called "intellisense"
(i.e. code completion that's sensitive to types) would be nice. We have it
for elisp, but not for most other languages. Supposedly CEDET and JDEE
provides the feature for some languages, but I've never really used them
because they tend to change many other unrelated parts of the behavior
of Emacs.


Stefan
Xavier Maillard
2005-12-19 14:07:44 UTC
Permalink
Post by Jérôme Marant
And let's be honest, Emacs is not going to provide any of the nice
features that Eclipse provides these days.
Can you enumerate few of these nice features ?
Rounded widget corners.

Erf ;-)

Xavier
Tom Tromey
2005-12-19 01:41:45 UTC
Permalink
Post by Jérôme Marant
And let's be honest, Emacs is not going to provide any of the nice
features that Eclipse provides these days.
Xavier> Can you enumerate few of these nice features ?

Refactoring. Incremental compilation. Type-sensitive completion.
(And other more minor compiler integration features.)

For ordinary java projects, no need to know how to build anything.

Better CVS UI (IMO anyway).

For Java the difference is enough that I've moved to Eclipse for my
daily Classpath hacking. For C/C++ ... Emacs' better editing features
still keep it in the lead.


There's no deep reason Emacs could not do all of these things, aside
from the amount of work involved.

Another approach to a similar end would be to replace the Eclipse
editor with Emacs.

Tom
Alfred M\. Szmidt
2005-12-19 02:26:11 UTC
Permalink
Incremental compilation.

For proper incremental compilation you need compiler support. make
style based compilation isn't really incremental, since you always
need to relink the whole program and keep the original object files
around (mixing object files from different compilers is also a bad
idea due to ABI changes and what not), and I suspect that eclispe uses
this, as does Emacs when one uses compilation-mode and GNU Make.

The only system I know of that had proper incremental compilation were
the Lisp Machines.
Tom Tromey
2005-12-19 05:33:15 UTC
Permalink
Tom> Incremental compilation.

Alfred> For proper incremental compilation you need compiler support.

Yes, I was just referring to Eclipse's Java support. Eclipse has a
built-in Java compiler.

The C/C++ support in Eclipse is less nice. It doesn't do incremental
compilation, though I think it does try to do incremental indexing.
(FWIW I once sent in a patch to Emacs to allow "kinda" incremental
updates to TAGS, but afaik it never went in.)

Tom
Miles Bader
2005-12-18 22:33:19 UTC
Permalink
Post by Jérôme Marant
And let's be honest, Emacs is not going to provide any of the nice
features that Eclipse provides these days. And Eclipse is free, runs
with a free Java Platform, is extensible, and so on.
I dunno; my experience with Eclipse is pretty underwhelming -- lots of
flashy widgets, and no doubt some powerful functions, but completely
infuriating to use. It seems to require that you buy into an entire
style of programming in order to use it at all (as opposed to Emacs,
which is "just" a text-editor, "just" a debugger interface, and "just" a
build invoker).

That is, Emacs just works with what you already have (or doesn't work
with it -- but if you were to extend Emacs to do so, you'd make Emacs
use existing tools), but Eclipse seems to say "change the way you work
to suit the development tools."

-miles
--
"An atheist doesn't have to be someone who thinks he has a proof that there
can't be a god. He only has to be someone who believes that the evidence
on the God question is at a similar level to the evidence on the werewolf
question." [John McCarthy]
Eli Zaretskii
2005-12-17 15:27:35 UTC
Permalink
Date: Sat, 17 Dec 2005 14:05:30 +0100
Post by David Kastrup
Post by Jérôme Marant
I think it could be fixed by making bugfix releases as I already
proposed many times (I also proposed to add myself as manpower for
such a purpose). So far, supporting the current released version is
not wanted, as far as I understood.
We have already too little manpower to support the coming release.
Really? There are more than one hundred committers, according to
the Emacs page at Savannah.
The number of active developers, whose are of interest is not limited
to a specific package, is much smaller.
Aidan Kehoe
2005-12-17 22:02:01 UTC
Permalink
I sent the below to Juri alone, and it bounced. To my surprise--strategies
of 친애하는 지도자 being criticised on emacs-devel? what?--people seem to
want to discuss the matter further here, so I’m sending it on.
Post by Juri Linkov
Post by Aidan Kehoe
Do you not understand what the GTK2 people did? They didn’t remove
features, it’s just as possible to use the new dialog box in the same
way as the old.
The filename entry field (with available TAB completion like in Emacs) was
a very useful feature. Neither C-l nor a small text box that appears
after starting typing is an acceptable replacement.
What the Gnome people have implemented is an acceptable replacement; it
gives the same functionality as the old but without its confusing features.
If you don’t accept that, then I’ve no confidence that you’ve ever used the
new file selection dialog.
Post by Juri Linkov
Post by Aidan Kehoe
And yes, making GNU Emacs behave more like a Win32 app, like Notepad,
_will_ make naïve users happy. Look at the success of CUA-mode.
CUA-mode doesn't disable useful Emacs features.
What on Earth gave you the idea that I suggested disabling useful features?
Post by Juri Linkov
Post by Aidan Kehoe
Hang round with Win32 users looking for an advanced editor, and they’ll
go for Notepad++ long before GNU Emacs, because all their habits from
Notepad work in Notepad++, and not in emacs.
Notepad++ is not easier to use for naive users than Emacs.
It’s much easier to use for a naïve Win32 user than is any emacs, and in
2005 the number of users who come to Emacs before encountering Win32 and
gaining some experience is infinitesimally small compared to the number with
previous Win32 experience.
Post by Juri Linkov
Post by Aidan Kehoe
Emacs is more featureful, but not enough to overcome the pain of finding
out what CUA-mode is
The top-level menu item in the Options menu that enables CUA-mode
and its tooltip are self-descriptive enough.
I disagree.
Post by Juri Linkov
Post by Aidan Kehoe
and doing all the other donkey-work to have the editor behave like what
they’re used to.
Experts can do this easily anyway.
And an editor that makes it unnecessary is still more attractive than one
where it must be done.
Post by Juri Linkov
Post by Aidan Kehoe
They abandon it because of stagnant development, the design and
implementation clusterfuck that is Mule from the perspective of European
language users (search for ö not working again!)
Not in the unicode-2 branch.
And? Emacs Multi-TTY has been stable for years, and there’s no sign of it
being integrated. Unicode-2 isn’t even stable yet.
Post by Juri Linkov
Post by Aidan Kehoe
and minimal consideration for GUI users in this age of 17"
screens. Among other reasons.
Eclipse, VIM or Notepad++ seem to be what most of the power users I
know who chose an advanced editor recently are using.
I don't think VIM belongs to the category of Notepad-like editors.
And? I do know some Unix power-users.
--
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.
Juri Linkov
2005-12-18 20:59:54 UTC
Permalink
Post by Aidan Kehoe
Post by Juri Linkov
The filename entry field (with available TAB completion like in Emacs) was
a very useful feature. Neither C-l nor a small text box that appears
after starting typing is an acceptable replacement.
What the Gnome people have implemented is an acceptable replacement; it
gives the same functionality as the old but without its confusing features.
These "confusing" features were very useful.
Post by Aidan Kehoe
If you don’t accept that, then I’ve no confidence that you’ve ever used the
new file selection dialog.
Of course, I've used the new file selection dialog in GTK applications
other than Emacs configured to use GTK. When I encountered the new
file selection dialog for the first time, I wasted my time searching on
the Web how to return a good old filename entry field. Fortunately,
many mailing lists were full of cursing at the new file dialog, so it
was easy to find information about C-l which is not intuitive.

The new file selection dialog is a failure of Gnome developers to design
an intuitive and convenient UI for beginners as well as for power users.
Post by Aidan Kehoe
Post by Juri Linkov
Post by Aidan Kehoe
And yes, making GNU Emacs behave more like a Win32 app, like Notepad,
_will_ make naïve users happy. Look at the success of CUA-mode.
CUA-mode doesn't disable useful Emacs features.
What on Earth gave you the idea that I suggested disabling useful features?
Removing the filename entry field was disabling a useful feature.
Post by Aidan Kehoe
Post by Juri Linkov
Post by Aidan Kehoe
Hang round with Win32 users looking for an advanced editor, and they’ll
go for Notepad++ long before GNU Emacs, because all their habits from
Notepad work in Notepad++, and not in emacs.
Notepad++ is not easier to use for naive users than Emacs.
It’s much easier to use for a naïve Win32 user than is any emacs, and in
2005 the number of users who come to Emacs before encountering Win32 and
gaining some experience is infinitesimally small compared to the number with
previous Win32 experience.
Could you elaborate a bit what makes it easier for naïve Windows users
to use than emacsen? A simple user interface? A familiar user interface?
Easy configuration? Something else?
Post by Aidan Kehoe
Post by Juri Linkov
Post by Aidan Kehoe
Emacs is more featureful, but not enough to overcome the pain of finding
out what CUA-mode is
The top-level menu item in the Options menu that enables CUA-mode
and its tooltip are self-descriptive enough.
I disagree.
The current menu item for enabling CUA-mode is "C-x/C-c/C-v Cut and Paste (CUA)"
and the tooltip is "Use C-z/C-x/C-c/C-v keys for undo/cut/copy/paste".
This gives a good hint about what is CUA-mode for.
Post by Aidan Kehoe
Post by Juri Linkov
Post by Aidan Kehoe
and doing all the other donkey-work to have the editor behave like what
they’re used to.
Experts can do this easily anyway.
And an editor that makes it unnecessary is still more attractive than one
where it must be done.
An editor that makes customization unnecessary? I never heard about
such an editor. As far as I recall even Notepad has one customizable
option - to toggle line wrapping :-)
Post by Aidan Kehoe
Post by Juri Linkov
Post by Aidan Kehoe
and minimal consideration for GUI users in this age of 17"
screens. Among other reasons.
Eclipse, VIM or Notepad++ seem to be what most of the power users I
know who chose an advanced editor recently are using.
I don't think VIM belongs to the category of Notepad-like editors.
And? I do know some Unix power-users.
You still haven't mentioned advantages of these editors for power users
over emacsen.
--
Juri Linkov
http://www.jurta.org/emacs/
Lőrentey Károly
2005-12-22 15:26:56 UTC
Permalink
Post by Aidan Kehoe
Post by Juri Linkov
Post by Aidan Kehoe
They abandon it because of stagnant development, the design and
implementation clusterfuck that is Mule from the perspective of European
language users (search for ö not working again!)
Not in the unicode-2 branch.
And? Emacs Multi-TTY has been stable for years,
It still has a five-page todo list.
Post by Aidan Kehoe
and there’s no sign of it being integrated.
It has always been clear that a new feature release will precede the
multi-tty merge. Emacs 22 will be an evolutionary release to make the
existing featureset shine. It's definitely worth the wait.
--
Károly
Stephen J. Turnbull
2005-12-17 16:22:53 UTC
Permalink
Nick> Perhaps you're bitter that XEmacs does seemed to have slowed
Nick> down, but please remember this list is for contributing to
Nick> Emacs development, not to knock it down.

Don't kid yourself. Of course XEmacs developers would like XEmacs to
move faster, but I don't see _active developers_ (like Aidan) terribly
concerned about it. We do feel bad for the users, but then, the users
could turn around and become developers if they wanted something done.

It is definitely arguable that Emacs is losing its appeal for new
users. You may have noticed the presence of a prominent former XEmacs
developer (Hrvoje Niksic) recently on this list. Although he made it
clear that he didn't have time to work around the specific problems he
has with XEmacs, and so has turned to the mainline again, he also
expressed his dismay that even with his customized Emacs environment,
there are still many features missing that come with (say) Eclipse out
of the box. He's not the only one to express such concerns, but he
was the most articulate I can recall.

Whether GNU and/or the Emacs project "should" worry about it is another
matter, but I don't think it's a good idea to put down Aidan because
he worries.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
Nick Roberts
2005-12-18 05:24:22 UTC
Permalink
...You may have noticed the presence of a prominent former XEmacs
developer (Hrvoje Niksic) recently on this list. Although he made it
clear that he didn't have time to work around the specific problems he
has with XEmacs, and so has turned to the mainline again, he also
expressed his dismay that even with his customized Emacs environment,
there are still many features missing that come with (say) Eclipse out
of the box.
Exactly. ISTR that Hrvoje contributed to Emacs development, even though
he may not share the whole vision. If Aidan chooses to do the same, I am
sure that will be welcome too.

Nick
Aidan Kehoe
2005-12-18 10:25:40 UTC
Permalink
...You may have noticed the presence of a prominent former XEmacs
developer (Hrvoje Niksic) recently on this list. Although he made it
clear that he didn't have time to work around the specific problems he
has with XEmacs, and so has turned to the mainline again, he also
expressed his dismay that even with his customized Emacs environment,
there are still many features missing that come with (say) Eclipse out
of the box.
Exactly. ISTR that Hrvoje contributed to Emacs development, even though
he may not share the whole vision. If Aidan chooses to do the same, I am
sure that will be welcome too.
I’ve contributed patches to Gnus and bug fixes, and all my XEmacs work is
assigned to the FSF. As things are, I value my mental health, and am
reasonably sure working primarily on GNU Emacs would be destructive to it.
(I have reason enough to go and get drunk alone without letting the
development of a text editor contribute to it.)
--
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.
David Kastrup
2005-12-18 12:23:54 UTC
Permalink
Post by Aidan Kehoe
I’ve contributed patches to Gnus and bug fixes, and all my XEmacs
work is assigned to the FSF. As things are, I value my mental
health, and am reasonably sure working primarily on GNU Emacs would
be destructive to it.
I am pretty sure it would. I just doubt that XEmacs scores better in
that department.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Aidan Kehoe
2005-12-18 12:47:49 UTC
Permalink
Post by David Kastrup
Post by Aidan Kehoe
I’ve contributed patches to Gnus and bug fixes, and all my XEmacs
work is assigned to the FSF. As things are, I value my mental
health, and am reasonably sure working primarily on GNU Emacs would
be destructive to it.
I am pretty sure it would. I just doubt that XEmacs scores better in
that department.
Well, working on it so far hasn’t been destructive to _my_ mental health;
quite the opposite. Your mileage may vary.
--
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.
David Kastrup
2005-12-18 12:57:19 UTC
Permalink
Post by Aidan Kehoe
Post by David Kastrup
Post by Aidan Kehoe
I’ve contributed patches to Gnus and bug fixes, and all my XEmacs
work is assigned to the FSF. As things are, I value my mental
health, and am reasonably sure working primarily on GNU Emacs would
be destructive to it.
I am pretty sure it would. I just doubt that XEmacs scores better in
that department.
Well, working on it so far hasn’t been destructive to _my_ mental
health; quite the opposite.
I can attest just the same for Emacs and myself. I am quite glad to
have been spared the predicament of the increasing number of mentally
disturbed people who back up slowly and wide-eyed while perfectly
mentally healthy people converse on the topic of editors.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup
2005-12-18 12:14:15 UTC
Permalink
Post by Nick Roberts
...You may have noticed the presence of a prominent former
XEmacs developer (Hrvoje Niksic) recently on this list. Although
he made it clear that he didn't have time to work around the
specific problems he has with XEmacs, and so has turned to the
mainline again, he also expressed his dismay that even with his
customized Emacs environment, there are still many features
missing that come with (say) Eclipse out of the box.
Exactly. ISTR that Hrvoje contributed to Emacs development, even
though he may not share the whole vision. If Aidan chooses to do
the same, I am sure that will be welcome too.
I don't think there is any question about that. A significant part of
the original Emacs/XEmacs animosoties arose exactly because of an
expressed preference for developer mindshare over actual code from
XEmacs.

But while I certainly am glad for people joining Emacs development,
even those that do just with a focus on coordinating compatibility, I
find it troublesome that the alternatives for them seemingly have lost
attraction. I don't think that ideology is involved in the decisions
for the bulk of developers and users, and so the question remains what
has changed in the last 10 years to make an independent free software
project with considerable developer base appear to slump in that
manner.

Maybe it is because Emacsen as a whole have dropped out of corporate
attention, and this impacted XEmacs' position more than that of Emacs.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Stephen J. Turnbull
2005-12-18 14:47:05 UTC
Permalink
Nick> Exactly. ISTR that Hrvoje contributed to Emacs development,
Nick> even though he may not share the whole vision.

He has done so. As have I, though my name isn't listed in AUTHORS
last I checked. :-) And of course my vision is definitely astigmatic.

Nick> If Aidan chooses to do the same, I am sure that will be
Nick> welcome too.

My point is that I believe his posts _are_ intended as a contribution,
not just as a defense of his fork-of-choice. Emacs _is_ losing
mindshare in the explosive growth of computer use, even if the number
of users and developers may still be increasing somewhat, and the
current community is as dedicated as ever. I think that loss of
mindshare unfortunate, too, though my reasons may be somewhat
different from Aidan's.

The loyal opposition is opposition, of course, but it is nonetheless
loyal.

I believe there's a point where the opposition should shut up, but I
can't fault Aidan if his judgment is that it's not been reached in
this issue yet. Timing is a little poor, this discussion should come
after the release (like just about everything :-).
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
David Kastrup
2005-12-18 15:07:53 UTC
Permalink
Post by Stephen J. Turnbull
I believe there's a point where the opposition should shut up,
Where would be the fun in that?
Post by Stephen J. Turnbull
but I can't fault Aidan if his judgment is that it's not been
reached in this issue yet. Timing is a little poor, this discussion
should come after the release (like just about everything :-).
"pent-up" will be the mot du jour then.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Eli Zaretskii
2005-12-18 19:26:27 UTC
Permalink
Date: Sun, 18 Dec 2005 23:47:05 +0900
Nick> Exactly. ISTR that Hrvoje contributed to Emacs development,
Nick> even though he may not share the whole vision.
He has done so. As have I, though my name isn't listed in AUTHORS
last I checked. :-)
Nothing unexpected here: AUTHORS is only updated (automatically, by a
Lisp program) as part of tarring a pretest or a release. So if your
name is somewhere in the logs or in the Author keyword of some Lisp
package, it will be in AUTHORS when Emacs is released next.
Richard M. Stallman
2005-12-19 04:38:40 UTC
Permalink
He has done so. As have I, though my name isn't listed in AUTHORS
last I checked.

You are in ChangeLog files, so you will get into AUTHORS
when we update it, shortly before the release.
Nikita Danilov
2005-12-17 16:52:04 UTC
Permalink
Aidan Kehoe <***@parhasard.net> writes:

[...]
Do you not understand what the GTK2 people did? They didn’t remove features,
it’s just as possible to use the new dialog box in the same way as the old.
Less obvious for what experts want to do, but experts are experts, they’ll
figure it out.
And while following this route they violated one of the most basic
premises of "UI for naive users" design:

At no point, user should be left stuck, without hint about
features available.

The point is not that file selector was "dumbed down". The point is that
it was made completely unintuitive (to the degree of being unusable) for
the "naive user" (which means "MS Windows user" nowadays).

Nikita.
Jan Djärv
2005-12-16 20:13:41 UTC
Permalink
Post by Juri Linkov
If there is some option that restores the old reasonable behavior in new
GTK2 dialogs, Emacs could set such an option by default.
The old one is still present in GTK, you can set x-use-old-gtk-file-dialog in
Emacs to enable it.

Jan D.
Juri Linkov
2005-12-17 10:57:14 UTC
Permalink
Post by Jan Djärv
Post by Juri Linkov
If there is some option that restores the old reasonable behavior in new
GTK2 dialogs, Emacs could set such an option by default.
The old one is still present in GTK, you can set x-use-old-gtk-file-dialog
in Emacs to enable it.
Thanks. I tried to set x-use-old-gtk-file-dialog to t, but even though it
looks like the old GTK file selection dialog, it is completely unusable:
its filename entry field is read-only and even C-l is not available to
enter filenames. It seems the old GTK file selection dialog is intentionally
broken to force users to the new GTK2 file chooser.
--
Juri Linkov
http://www.jurta.org/emacs/
Jan D.
2005-12-18 17:02:00 UTC
Permalink
Post by Juri Linkov
Post by Jan Djärv
Post by Juri Linkov
If there is some option that restores the old reasonable behavior in new
GTK2 dialogs, Emacs could set such an option by default.
The old one is still present in GTK, you can set x-use-old-gtk-file-dialog
in Emacs to enable it.
Thanks. I tried to set x-use-old-gtk-file-dialog to t, but even though it
its filename entry field is read-only and even C-l is not available to
enter filenames. It seems the old GTK file selection dialog is intentionally
broken to force users to the new GTK2 file chooser.
If you use it to open existing files it will be read only. Use the
"Visit New File" instead, it can actually be used to visit old files also.

Jan D.
Richard M. Stallman
2005-12-19 04:40:22 UTC
Permalink
If you use it to open existing files it will be read only.

That sounds like a bug, unless I've misunderstood the facts.
Which menu item does this?

Open File should not make files read only,
if the user can read them.
Jan D.
2005-12-19 23:18:35 UTC
Permalink
Post by Jan D.
If you use it to open existing files it will be read only.
That sounds like a bug, unless I've misunderstood the facts.
Which menu item does this?
Open File should not make files read only,
if the user can read them.
Sorry to be unclear, "it" refers to the text entry box in the
fileselection widget (the old GTK dialog). But I can just as well
make it so the user can enter file names there, it is just for the
new dialog we need to distinguish between open old and open new file.

Jan D.
Jan D.
2005-12-20 00:36:11 UTC
Permalink
Post by Jan D.
Sorry to be unclear, "it" refers to the text entry box in the
fileselection widget (the old GTK dialog). But I can just as well
make it so the user can enter file names there, it is just for the
new dialog we need to distinguish between open old and open new file.
No, I take that back. To fulfill the mustmatch_p parameter, we must
disable entering a file name in the text field.

Jan D.
Richard M. Stallman
2005-12-20 16:33:38 UTC
Permalink
No, I take that back. To fulfill the mustmatch_p parameter, we must
disable entering a file name in the text field.

I do not follow you. What are the practical consequences of this
for the user?
Jan D.
2005-12-20 19:21:45 UTC
Permalink
Post by Jan D.
No, I take that back. To fulfill the mustmatch_p parameter, we must
disable entering a file name in the text field.
I do not follow you. What are the practical consequences of this
for the user?
I don't know, but if some lisp code sets mustmatch to t, it probably
expects the returned file name to be an existing file.

Jan D.
Richard M. Stallman
2005-12-21 05:30:00 UTC
Permalink
I don't know, but if some lisp code sets mustmatch to t, it probably
expects the returned file name to be an existing file.

Not for the Open File menu item! The only reason we made that pass t
for MUSTMATCH is that someone thought that's appropriate for Open File
menu items.

If it works better, in practical terms, when MUSTMATCH is nil,
we can make it set MUSTMATCH to nil!
Richard M. Stallman
2005-12-20 05:32:56 UTC
Permalink
Sorry to be unclear, "it" refers to the text entry box in the
fileselection widget (the old GTK dialog).

If using that text entry box always opens existing files read-only,
even if you can write them, that is a bug. Can you fix the bug?

But I can just as well
make it so the user can enter file names there,

I don't follow.

it is just for the
new dialog we need to distinguish between open old and open new file.

Opening an old file should make the buffer writable, if the file is
writable, in both the old dialog and the new dialog.
Jan D.
2005-12-20 06:35:00 UTC
Permalink
Post by Jan D.
Sorry to be unclear, "it" refers to the text entry box in the
fileselection widget (the old GTK dialog).
If using that text entry box always opens existing files read-only,
even if you can write them, that is a bug. Can you fix the bug?
No, it is the text entry box in the file dialog that is read only,
i.e. when the dialog pops up to open an existing file, you can not
enter the file name in the text entry box, because that would make it
possible to enter a file name for a file that does not exist. The
buffer has the correct read/write state.

Jan D.
Richard M. Stallman
2005-12-21 02:58:11 UTC
Permalink
No, it is the text entry box in the file dialog that is read only,
i.e. when the dialog pops up to open an existing file, you can not
enter the file name in the text entry box, because that would make it
possible to enter a file name for a file that does not exist. The
buffer has the correct read/write state.

That is to say, it does not function as a file name entry box.

Could we fix this by always specifying that new files are allowed,
even in Open File?
Richard M. Stallman
2005-12-19 23:45:03 UTC
Permalink
I wrote

Open File should not make files read only,
if the user can read them.

I meant to write

Open File should not make files read only,
if the user can write them.
Jérôme Marant
2005-12-17 13:06:09 UTC
Permalink
Post by Jan Djärv
Post by Juri Linkov
If there is some option that restores the old reasonable behavior in new
GTK2 dialogs, Emacs could set such an option by default.
The old one is still present in GTK, you can set
x-use-old-gtk-file-dialog in Emacs to enable it.
This is exactly what I was asking for. Thanks!
--
Jérôme Marant
Pierre-Charles David
2005-12-16 18:53:23 UTC
Permalink
Post by Richard M. Stallman
These sound like reasonable features. What is missing is something
to give the user a clue to them.
The Gtk+ file chooser supports the addition of arbitrary widgets, which
are shown below the file list. One could use a toggle button to make the
"Show hidden files" feature visible:

toggle = gtk_check_button_new_with_label ("Show hidden files.");
gtk_widget_show (toggle);
gtk_file_chooser_set_extra_widget (GTK_FILE_CHOOSER (dialog),
toggle);
g_signal_connect (G_OBJECT (toggle_button), "clicked",
G_CALLBACK (toggle_visibility), G_OBJECT(dialog));

with:

static void toggle_visibility(GtkWidget *widget, gpointer data)
{
GtkFileChooser *dialog = GTK_FILE_CHOOSER(data);
gboolean visible = ! gtk_file_chooser_get_show_hidden(dialog);
gtk_file_chooser_set_show_hidden(dialog, visible);
}

The default visibility state could also be exposed as an Emacs
configuration variable.
Juri Linkov
2005-12-17 10:57:16 UTC
Permalink
Post by Pierre-Charles David
The Gtk+ file chooser supports the addition of arbitrary widgets, which
are shown below the file list. One could use a toggle button to make the
Since it is possible to add a "Show hidden files" toggle button to
the file chooser, is it possible to do the same for the filename
entry field from the small window that pop-ups after C-l?

This would be consistent with the default Emacs filename reading behavior,
i.e. the minibuffer in Emacs is like the filename entry field in the
file chooser, and the *Completions* buffer above it is like a list
of files in the file chooser.
--
Juri Linkov
http://www.jurta.org/emacs/
Jan D.
2005-12-18 17:02:28 UTC
Permalink
Post by Juri Linkov
Post by Pierre-Charles David
The Gtk+ file chooser supports the addition of arbitrary widgets, which
are shown below the file list. One could use a toggle button to make the
Since it is possible to add a "Show hidden files" toggle button to
the file chooser, is it possible to do the same for the filename
entry field from the small window that pop-ups after C-l?
This would be consistent with the default Emacs filename reading behavior,
i.e. the minibuffer in Emacs is like the filename entry field in the
file chooser, and the *Completions* buffer above it is like a list
of files in the file chooser.
I don't know, I'll look in to it. But I suspect no...

Jan D.
Jan D.
2005-12-22 09:27:17 UTC
Permalink
Post by Jan D.
I don't know, but if some lisp code sets mustmatch to t, it probably
expects the returned file name to be an existing file.
Not for the Open File menu item! The only reason we made that pass t
for MUSTMATCH is that someone thought that's appropriate for Open File
menu items.
Actually the reason was not just that someone thought it would be appropriate,
but that the GTK/OSX (and perhaps W32) file dialogs more or less require it.

For the new GTK file chooser, if you don't specify that it is selecting
existing files, it does not show the directory/file tree (you have to click
on a toggle to see it). Also, if we don't tell the new file chooser that
it is opening an existing file and the user selects an existing file, the
file chooser will pop up a dialog that asks the user if the file selected
should be replaced. So, for the new file chooser, the behaviour between
opening an existing file and saving a file is quite different. That is
what motivated the difference between new and open file in the current
Emacs.

But the old GTK file dialog does not make any distinction between saving and
opening, so for that one we could pass nil for MUSTMATCH.
Post by Jan D.
If it works better, in practical terms, when MUSTMATCH is nil,
we can make it set MUSTMATCH to nil!
Yes it can be done. But is it really worthwhile for a dialog that is
not default in the first place, and that will probably be gone from GTK soon?

Jan D.
Richard M. Stallman
2005-12-22 22:20:56 UTC
Permalink
Yes it can be done. But is it really worthwhile for a dialog that is
not default in the first place, and that will probably be gone from GTK soon?

If it is so easy, why not do it?

If the old file dialog works better, should we make it the default?
We could also pressure for it not to be deleted.
David Kastrup
2005-12-23 00:09:45 UTC
Permalink
Post by Jan D.
Yes it can be done. But is it really worthwhile for a dialog
that is not default in the first place, and that will probably
be gone from GTK soon?
If it is so easy, why not do it?
If the old file dialog works better, should we make it the default?
I don't think so. The point of a toolkit is not to have applications
behave differently.
Post by Jan D.
We could also pressure for it not to be deleted.
I think we should rather pressure for the new dialogue to become as
useful as the old one. That's the really important thing. It is
nonsense to have dumbed-down dialogs for one kind of application and
others for a different kind.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Jan D.
2005-12-23 11:38:47 UTC
Permalink
Post by Jan D.
Yes it can be done. But is it really worthwhile for a dialog that is
not default in the first place, and that will probably be gone from GTK soon?
If it is so easy, why not do it?
OK, I did it. If the old file dialog is used, Open in toolbar and menu
does not set mustmatch.
Post by Jan D.
If the old file dialog works better, should we make it the default?
We could also pressure for it not to be deleted.
I think Gnome is quite determined regarding this, the old file dialog
will be removed. It has some serious bugs w.r.t. international characters
in file names, and nobody is working on that. Also, by default, Gnome
applications use the new one, so I think the new one should be default
as it is more familiar by now.

Jan D.
Richard M. Stallman
2005-12-23 18:09:21 UTC
Permalink
Also, by default, Gnome
applications use the new one, so I think the new one should be default
as it is more familiar by now.

The sad thing is, it seems that the new one is so inconvenient that we
will have to teach people not to use it.

Is there any way we could put some sort of text into the new GNOME
file selector, saying "We know this is inconvenient, and we recommend
you use C-x C-f instead"? Could we display that in a small window
alongside the file selector?
Jan D.
2005-12-24 20:29:55 UTC
Permalink
Post by Jan D.
Also, by default, Gnome
applications use the new one, so I think the new one should be default
as it is more familiar by now.
The sad thing is, it seems that the new one is so inconvenient that we
will have to teach people not to use it.
Is there any way we could put some sort of text into the new GNOME
file selector, saying "We know this is inconvenient, and we recommend
you use C-x C-f instead"? Could we display that in a small window
alongside the file selector?
Yes, we can do this with the external widget feature in the new file
chooser. I will do this after the holidays so we can get some feedback
on the actual text. I suggest we add some text about how to enable the
old dialog also. I'll add the "show hidden files" also as suggested by
other posters. But there seems to be no way to add a button that can
enable the text input dialog,which is too bad.

Jan D.
Richard M. Stallman
2005-12-25 19:06:32 UTC
Permalink
Yes, we can do this with the external widget feature in the new file
chooser. I will do this after the holidays so we can get some feedback
on the actual text.

That is good.

Maybe it could also give help about typing C-l.
Jan D.
2005-12-27 10:47:36 UTC
Permalink
Post by Jan D.
Yes, we can do this with the external widget feature in the new file
chooser. I will do this after the holidays so we can get some feedback
on the actual text.
That is good.
Maybe it could also give help about typing C-l.
I've added it now, please take a look and see if it is ok. I may be a
bit long. I've attached a screen shot.
Jan D.
2005-12-27 13:31:28 UTC
Permalink
Post by Jan D.
Post by Jan D.
Yes, we can do this with the external widget feature in the new file
chooser. I will do this after the holidays so we can get some feedback
on the actual text.
That is good.
Maybe it could also give help about typing C-l.
I've added it now, please take a look and see if it is ok. I may be a
bit long. I've attached a screen shot.
I've reformatted the text a bit.

Jan D.
Stefan Monnier
2005-12-27 16:42:09 UTC
Permalink
Post by Jan D.
Post by Jan D.
Yes, we can do this with the external widget feature in the new file
chooser. I will do this after the holidays so we can get some feedback
on the actual text.
That is good.
Maybe it could also give help about typing C-l.
I've added it now, please take a look and see if it is ok. I may be a bit
long. I've attached a screen shot.
I've reformatted the text a bit.
[ "inconvinient" => "inconvenient"]

The mix of Swedish and English is too bad :-(
And yes, the text is pretty long. Suince the old Gtk dialog is on the way
out, I'd rather not advertise it, and instead try and make the new dialog
more usable. I think the only important info from this text is the
C-l thingy. Could we even do away with it by making the text
input area appear unconditionally?


Stefan
Jan D.
2005-12-28 10:50:22 UTC
Permalink
And yes, the text is pretty long. Suince the old Gtk dialog is on the way
out, I'd rather not advertise it, and instead try and make the new dialog
more usable. I think the only important info from this text is the
C-l thingy. Could we even do away with it by making the text
input area appear unconditionally?
As the text input area is a separate dialog that would be confusing.
And irritating if you don't want the text inout area.
Type C-l to display a file name text entry box.
If you don't like this file selector, customize
use-file-dialog to turn it off, or type C-x C-f to visit files.
I've changed it to the above.

Jan D.

Continue reading on narkive:
Loading...