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

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

Re: Suggest installer optionally set ALTERNATE_EDITOR


From: Joel Reicher
Subject: Re: Suggest installer optionally set ALTERNATE_EDITOR
Date: Wed, 27 Apr 2022 03:47:26 +1000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (windows-nt)

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: help-emacs-windows@gnu.org
>> From: Joel Reicher <joel.reicher@gmail.com>
>> Date: Tue, 26 Apr 2022 23:48:44 +1000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > The above is perfectly OK as your personal preferences.  But I'm not
>> > at all sure they should be the default behavior.
>> 
>> I'm not suggesting they should be the default; I believe this should be an 
>> *option* in the installer.
>
> Sorry for my misunderstanding.
>
> However, in that case, why just those few?  Emacs is full of
> potentially useful opt-in features that we could suggest as part of
> the installation.  Some of those specifically target MS-Windows.  As
> just one example, why not suggest to turn on w32-use-native-image-API?
> that will allow people to be able to display several image formats
> without installing additional libraries.
>
> IOW, if we are to think about offering optional behavior, the list of
> potentially useful settings is much longer than just those few you
> mention, and now my question would be: why only those?

The question is specifically what should be offered by the installer. It's 
entirely possible it would be good for the installer to offer more than I have 
mentioned, but probably not "everything". I think we want the installer to give 
users a "flying start", but it is not a replacement for Customize, etc.

>> In terms of other platforms, I think you might be implying there aren't 
>> significant cultural differences. If so, I believe that's a mistake. My 
>> assessment is that Windows users are accustomed to graphical shells, UNIX 
>> users are accustomed to xterm and window managers, and in all honesty I 
>> can't speak for Linux users.
>
> First, I believe this view of users of Unix and GNU/Linux systems as
> less GUI-oriented than Windows users is outdated.  Nowadays, with most
> popular Unix desktop environments having stolen every possible aspect
> of Windows look-and-feel (as if there's no other good GUI concept
> under the sun), users expect to see the same graphical shells on all
> systems.
>
> In any case, Emacs always strives to provide as uniform experience as
> possible on all platforms, for the benefit of those of us who work in
> several different ones and those who may one day change their main
> systems.  I would hate to see that change significantly.  Cultural
> differences do exist, but using Emacs is a culture in itself, and at
> least IME it is nice to have a large part of your development
> environment remain virtually unchanged, and thus as familiar as it
> gets, when you move between platforms.

My guess (and it is a guess) is that committed/advanced Emacs users tend to use 
Emacs itself as the shell (this is true for me, even on Windows, for exactly 
the reasons you mention).

The current suggestion targets users of other shells; i.e. Emacs newcomers.

Windows users have their shell prescribed (until they find an alternative), and 
I know what that prescription looks like; most of the time it's a delegate. 
Files are injected by web browsers or email clients, and opened by helper 
applications registered with the shell. The shell tends not to be used for much 
actual work on its own, and there's a strong expectation of one instance of 
each application.

If the same is true on other, less prescriptive platforms, I'm all for making 
the delegation work well there, but I personally don't know what those shells 
look like, or people's use of them.

I'd be interested in knowing if anyone runs multiple Emacs processes though. 
Even though I wasn't suggesting emacs-server as a default, perhaps it's a good 
step towards consistency and encouraging users to consider having Emacs itself 
as a shell.

Thanks and regards,

       - Joel



reply via email to

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