Re: GTK file selector

Re: GTK file selector

[Pierre-Charles David]

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

Re: GTK file selector

[Juri Linkov]

> 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:

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/

Re: GTK file selector

[Jan D.]

Juri Linkov wrote:

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

GTK file selector

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

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

Is there something to configure I missed?

Thanks.

--
Jérôme Marant

Re: GTK file selector

[Aidan Kehoe]

 Ar an ceathrú lá déag de mí na Nollaig, scríobh 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. 

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

Re: GTK file selector

[Jérôme Marant]

Quoting Aidan Kehoe <kehoea@parhasard.net>:

>
>  Ar an ceathrú lá déag de mí na Nollaig, scríobh 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

Re: GTK file selector

[Eli Zaretskii]

> Date: Wed, 14 Dec 2005 15:38:38 +0100
> From: =?iso-8859-1?b?Suly9G1l?= Marant <jerome.marant@free.fr>
> Cc: emacs-devel@gnu.org
> 
> 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.

Re: GTK file selector

[Jérôme Marant]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 14 Dec 2005 15:38:38 +0100
>> From: =?iso-8859-1?b?Suly9G1l?= Marant <jerome.marant@free.fr>
>> Cc: emacs-devel@gnu.org
>> 
>> 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

Re: GTK file selector

[Jan Djärv]

Jérôme Marant wrote:

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

Re: GTK file selector

[Jérôme Marant]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Jérôme Marant wrote:
>
>> 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

Re: GTK file selector

[Jan Djärv]

Jérôme Marant wrote:

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

Re: GTK file selector

[Jérôme Marant]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Jérôme Marant wrote:
>
>> 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

Re: GTK file selector

[Paul Pogonyshev]

Jérôme Marant wrote:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
> > Jérôme Marant wrote:
> >
> >> 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

Re: GTK file selector

[Mario Domenech Goulart]

Hello Jérôme

On 12/14/05, Jérôme Marant <jmarant@free.fr> wrote:

> 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

Re: GTK file selector

[Jérôme Marant]

Mario Domenech Goulart <mario.goulart@gmail.com> writes:

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

Re: GTK file selector

[Frank Schmitt]

Jérôme Marant <jmarant@free.fr> writes:

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

Re: GTK file selector

[Stephen Berman]

On Wed, 14 Dec 2005 16:28:14 +0100 Frank Schmitt <ich@frank-schmitt.net> wrote:

> Jérôme Marant <jmarant@free.fr> writes:
>
>> 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

Re: GTK file selector

[Richard M. Stallman]

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

Re: GTK file selector

[Juri Linkov]

>> 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/

Re: GTK file selector

[Aidan Kehoe]

 Ar an cúigiú lá déag de mí na Nollaig, scríobh Juri Linkov: 

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

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

Re: GTK file selector

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

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

> 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/

Re: GTK file selector

[Aidan Kehoe]

 Ar an séú lá déag de mí na Nollaig, scríobh 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.

 > So I still don't understand what is the target audience of Gnome
 > developers.
 > 
 > > 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. 

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

Re: GTK file selector

[Juri Linkov]

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

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

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

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

> and doing all the other donkey-work to have the editor behave like what
> they’re used to.

Experts can do this easily anyway.

> 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 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/

Re: GTK file selector

[Romain Francoise]

Juri Linkov <juri@jurta.org> writes:

>> 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 <romain@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

Re: GTK file selector

[Kaloian Doganov]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

On 16 дек 2005, romain@orebokech.com wrote:

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


-- 
Поздрави,
Калоян Доганов.
___________________________________________________________
Ако не отговарям на писмата Ви: http://6lyokavitza.org/mail

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: GTK file selector

[Romain Francoise]

Kaloian Doganov <kaloian@doganov.org> writes:

> It is fixed indeed.  I've just checked it out.

Thanks for checking!

> Thank you, Romain.

To give credit where it's due: it was Kenichi Handa who fixed this bug,
not me.

-- 
Romain Francoise <romain@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

Re: GTK file selector

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

>> 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 <storm@cua.dk> http://www.cua.dk

Re: GTK file selector

[Chong Yidong]

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

Re: GTK file selector

[Nick Roberts]

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

Re: GTK file selector

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

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

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

> 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

Re: GTK file selector

[Jérôme Marant]

David Kastrup <dak@gnu.org> writes:

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

Re: GTK file selector

[David Kastrup]

Jérôme Marant <jmarant@free.fr> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>> 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.

> 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

Re: GTK file selector

[Jérôme Marant]

David Kastrup <dak@gnu.org> writes:


>> 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?

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

Re: GTK file selector

[David Kastrup]

Jérôme Marant <jmarant@free.fr> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>> 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.

>>> 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:

But we are not talking about the user interface here.  We are talking
about the release process.  All that is relevant in that regard is:

> 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

Re: GTK file selector

[Aidan Kehoe]

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

 Ar an seachtú lá déag de mí na Nollaig, scríobh David Kastrup: 

 > > 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:
 > 
 > But we are not talking about the user interface here.  We are talking
 > about the release process.  All that is relevant in that regard is:
 > 
 > > 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. 

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

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

Re: GTK file selector

[David Kastrup]

Aidan Kehoe <kehoea@parhasard.net> writes:

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

Re: GTK file selector

[Aidan Kehoe]

 Ar an t-ochtú lá déag de mí na Nollaig, scríobh David Kastrup: 

 > [...] 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.

Re: GTK file selector

[Jérôme Marant]

David Kastrup <dak@gnu.org> writes:

>> 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:
>
> But we are not talking about the user interface here.  We are talking
> about the release process.  All that is relevant in that regard is:

I'll explain later why I think it is indirectly relevant.

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

> actually had quite a bit of fallout with the XEmacs developers over
> integrating AUCTeX as a package into XEmacs.

Quite loudly ;-)

[...]

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

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

Re: GTK file selector

[David Kastrup]

Jérôme Marant <jmarant@free.fr> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> But we are not talking about the user interface here.  We are talking
>> about the release process.  All that is relevant in that regard is:
>
> I'll explain later why I think it is indirectly relevant.

Where?

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

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

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

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

> But for the average end users, I can say there is not anything worth
> waiting 4+ years.

Beg to differ.

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

> 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?

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

> 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

Re: GTK file selector

[Stephen J. Turnbull]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

    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.

Re: GTK file selector

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>>>>>> "David" == David Kastrup <dak@gnu.org> writes:
>
>     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

Re: GTK file selector

[Xavier Maillard]

   From: J?r?me Marant <jmarant@free.fr>
   Cc: emacs-devel@gnu.org

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

Re: GTK file selector

[Miles Bader]

Xavier Maillard <zedek@gnu-rox.org> writes:
>    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]

Re: GTK file selector

[Stefan Monnier]

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

Re: GTK file selector

[Xavier Maillard]

   Cc: emacs-devel@gnu.org
   From: Miles Bader <miles@gnu.org>

   Xavier Maillard <zedek@gnu-rox.org> writes:
   >    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

Re: GTK file selector

[Tom Tromey]

>>>>> "Xavier" == Xavier Maillard <zedek@gnu-rox.org> writes:

>    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

Re: GTK file selector

[Alfred M. Szmidt]

   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.

Re: GTK file selector

[Tom Tromey]

>>>>> "Alfred" == Alfred M\ Szmidt <Alfred> writes:

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

Re: GTK file selector

[Miles Bader]

Jérôme Marant <jmarant@free.fr> writes:
> 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]

Re: GTK file selector

[Eli Zaretskii]

> From: =?utf-8?Q?J=C3=A9r=C3=B4me_Marant?= <jmarant@free.fr>
> Date: Sat, 17 Dec 2005 14:05:30 +0100
> 
> David Kastrup <dak@gnu.org> writes:
> 
> 
> >> 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.

Re: GTK file selector

[Aidan Kehoe]

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.  

 Ar an séú lá déag de mí na Nollaig, scríobh Juri Linkov: 

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

 > > 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?

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

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

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

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

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

Re: GTK file selector

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

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

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

>  > > 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?

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

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

>  > > 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/

Re: GTK file selector

[Lőrentey Károly]

Aidan Kehoe <kehoea@parhasard.net> writes:
>  > > 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.

> 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

Re: GTK file selector

[Stephen J. Turnbull]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

    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.

Re: GTK file selector

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

Nick

Re: GTK file selector

[Aidan Kehoe]

 Ar an t-ochtú lá déag de mí na Nollaig, scríobh 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’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.

Re: GTK file selector

[David Kastrup]

Aidan Kehoe <kehoea@parhasard.net> writes:

> 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

Re: GTK file selector

[Aidan Kehoe]

 Ar an t-ochtú lá déag de mí na Nollaig, scríobh David Kastrup: 

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

Re: GTK file selector

[David Kastrup]

Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an t-ochtú lá déag de mí na Nollaig, scríobh David Kastrup: 
>
>  > > 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

Re: GTK file selector

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

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

Re: GTK file selector

[Stephen J. Turnbull]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

    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.

Re: GTK file selector

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> I believe there's a point where the opposition should shut up,

Where would be the fun in that?

> 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

Re: GTK file selector

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sun, 18 Dec 2005 23:47:05 +0900
> Cc: Aidan Kehoe <kehoea@parhasard.net>, Juri Linkov <juri@jurta.org>,
> 	emacs-devel@gnu.org
> 
> >>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:
> 
>     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.

Re: GTK file selector

[Richard M. Stallman]

    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.

Re: GTK file selector

[Nikita Danilov]

Aidan Kehoe <kehoea@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.

Re: GTK file selector

[Jan Djärv]

Juri Linkov wrote:

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

Re: GTK file selector

[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/

Re: GTK file selector

[Jan D.]

Juri Linkov wrote:

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

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.

Re: GTK file selector

[Richard M. Stallman]

    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.

Re: GTK file selector

[Jan D.]

19 dec 2005 kl. 05.40 skrev Richard M. Stallman:

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

Re: GTK file selector

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

Re: GTK file selector

[Richard M. Stallman]

    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?

Re: GTK file selector

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

Re: GTK file selector

[Richard M. Stallman]

    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!

Re: GTK file selector

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

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

Re: GTK file selector

[Richard M. Stallman]

    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.

Re: GTK file selector

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

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

> 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

Re: GTK file selector

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

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

Re: GTK file selector

[Richard M. Stallman]

      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?

Re: GTK file selector

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

Re: GTK file selector

[Richard M. Stallman]

    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.

Re: GTK file selector

[Jan D.]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

Richard M. Stallman wrote:

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

[-- Attachment #2: file.jpg --]
[-- Type: image/jpeg, Size: 46531 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: GTK file selector

[Jan D.]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

Jan D. wrote:

> Richard M. Stallman wrote:
>
>>    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.


[-- Attachment #2: file.jpg --]
[-- Type: image/jpeg, Size: 41586 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: GTK file selector

[Stefan Monnier]

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

Re: GTK file selector

[Jan D.]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

Stefan Monnier wrote:

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


Richard M. Stallman wrote:

>It looks better than I expected.  I recommend changing the message to this:
>
>
>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.



[-- Attachment #2: file.jpg --]
[-- Type: image/jpeg, Size: 37863 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: GTK file selector

[Richard M. Stallman]

    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.

Re: GTK file selector

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

Re: GTK file selector

[Richard M. Stallman]

    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?

Re: GTK file selector

[Richard M. Stallman]

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.

Re: GTK file selector

[Jérôme Marant]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Juri Linkov wrote:
>
>> 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

Re: GTK file selector

[Reiner Steib]

On Wed, Dec 14 2005, Jérôme Marant wrote:

> I may be dumb but with the current GTK file selector, 

[ See http://thread.gmane.org/439E24E2.1070201%40gmx.net for a related
  discussion ]

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

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

Ctrl-l

> 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/

Re: GTK file selector

[Jérôme Marant]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Dec 14 2005, Jérôme Marant wrote:
>
>> 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.

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

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

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

I think I can switch back to C-x C-f ;-)

-- 
Jérôme Marant

Re: GTK file selector

[Emfox Zhou]

Jérôme Marant <jmarant@free.fr> writes:

> 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? :)

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

> Is there something to configure I missed?
>
> Thanks.
>
> --
> Jérôme Marant

Re: GTK file selector

[Richard M. Stallman]

    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?

Re: GTK file selector

[Jérôme Marant]

"Richard M. Stallman" <rms@gnu.org> writes:

> 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?

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