Finding packages to enable by default

Finding packages to enable by default

[Tom]

It's been said in the uniquify thread that uniquify is one of
those packages which most users enable if they know it exists. I
agree and finding similarly useful packages which could be
enabled by default would help improving the initial user
experience.

In order to find these an elisp function could be written which
outputs the name of those packages which are shipped with emacs,
are disabled by default, but users enable them. This function
then could be sent to this list and other emacs
forums (emacs.reddit.com, etc.), so users can run it in their own
emacs and then send the output to some adress or person.

There the results can be summarized and those of these packages
which are enabled by, say, 75% of the users, should be enabled by
default in emacs.

Re: Finding packages to enable by default

[Stefan Monnier]

> In order to find these an elisp function could be written which
> outputs the name of those packages which are shipped with emacs,
> are disabled by default, but users enable them. This function
> then could be sent to this list and other emacs
> forums (emacs.reddit.com, etc.), so users can run it in their own
> emacs and then send the output to some adress or person.

Sounds good,


        Stefan

Re: Finding packages to enable by default

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 
> > In order to find these an elisp function could be written which
> > outputs the name of those packages which are shipped with emacs,
> > are disabled by default, but users enable them. This function
> > then could be sent to this list and other emacs
> > forums (emacs.reddit.com, etc.), so users can run it in their own
> > emacs and then send the output to some adress or person.
> 
> Sounds good,
> 

Is there a generic elisp way to list packages shipped with emacs
without listing them explicitly?

I guess checking if they are actually enabled is easier. If the
package is loaded then we can say it's enabled. Though it's
possible a package is loaded without being enabled, it may not
be typical, so we can ignore that.

Re: Finding packages to enable by default

[chad]

On 29 Nov 2013, at 10:54, Tom <adatgyujto@gmail.com> wrote:
> 
> Is there a generic elisp way to list packages shipped with emacs
> without listing them explicitly?
> 
> I guess checking if they are actually enabled is easier. If the
> package is loaded then we can say it's enabled. Though it's
> possible a package is loaded without being enabled, it may not
> be typical, so we can ignore that.

Tangentially related and maybe helpful for the future:

	https://github.com/jwiegley/use-package

	The use-package declaration macro allows you to isolate 
	package configuration in your ".emacs" in a way that is 
	performance-oriented and, well, just tidy. 

~Chad

Re: Finding packages to enable by default

[Stefan Monnier]

> Is there a generic elisp way to list packages shipped with emacs
> without listing them explicitly?

There's no easy and reliable way, but I don't think we need that.

> I guess checking if they are actually enabled is easier. If the
> package is loaded then we can say it's enabled. Though it's
> possible a package is loaded without being enabled, it may not
> be typical, so we can ignore that.

I think the contents of `features' is all we need.


        Stefan

Re: Finding packages to enable by default

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 
> > Is there a generic elisp way to list packages shipped with emacs
> > without listing them explicitly?
> 
> There's no easy and reliable way, but I don't think we need that.
> 

We are only interested in packages which are shipped with emacs,
so we should query only those. It's about activating some of these
builtin packages by default, so we have to filter external packages
from this list somehow, don't we?

symbol-file looks good, the provided features can be tested with it
and if the path is under the emacs installation directory then
we can say the feature is in a builtin package.

Re: Finding packages to enable by default

[Dmitry Gutov]

Tom <adatgyujto@gmail.com> writes:

> We are only interested in packages which are shipped with emacs,
> so we should query only those. It's about activating some of these
> builtin packages by default, so we have to filter external packages
> from this list somehow, don't we?

You can filter them out later, manually, in case some make it to the
top, which is not a given.

And if some do, that data can also be of interest.

Re: Finding packages to enable by default

[Tom]

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> You can filter them out later, manually, in case some make it to the
> top, which is not a given.
> 
> And if some do, that data can also be of interest.
> 

Okay, that makes sense.


The other question is: how the info should be collected. Maybe a bug
can be opened on the bug tracker, so people can send their 'features
to that and thus the replies would appear in one place on the web
interface of the bugtracker for that bug and they could be collected
from the web page quite easily.

Would it work? 

Re: Finding packages to enable by default

[Glenn Morris]

Tom wrote:

> The other question is: how the info should be collected. Maybe a bug
> can be opened on the bug tracker, so people can send their 'features
> to that and thus the replies would appear in one place on the web
> interface of the bugtracker for that bug and they could be collected
> from the web page quite easily.

I'd rather not fill up the bug tracker (and mailing list) with such things.
(But note that "features" is already recorded by default in M-x
report-emacs-bug.)

Why don't you invite people to send that information to you,
since this was your idea, then you can summarize the results for us in a
month or so?

Re: Finding packages to enable by default

[Stefan Monnier]

> (But note that "features" is already recorded by default in M-x
> report-emacs-bug.)

Indeed, we could already compile the data we have from bug-reports.


        Stefan

Re: Finding packages to enable by default

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 
> > (But note that "features" is already recorded by default in M-x
> > report-emacs-bug.)
> 
> Indeed, we could already compile the data we have from bug-reports.
> 

Good idea and it may be the easiest way if you have direct access to the 
database. 

The only question is how representative this data is, but the 
statistics can also answer this if we see the number of unique 
users contributed to it.

Re: Finding packages to enable by default

[Stefan Monnier]

> Good idea and it may be the easiest way if you have direct access to the 
> database.

IIRC the database could be retrieved via rsync.  Glenn would know.

> The only question is how representative this data is,

Clearly it suffers from some kind of bias since it only considers people
who submitted bug-reports.  Also, it will tend to be conservative since
we ask people to try and reproduce the bugs in "a vanilla config", so
they may end up sending their reports from an Emacs that's more
"vanilla" than their typical Emacs session.


        Stefan

Re: Finding packages to enable by default

[Glenn Morris]

Stefan Monnier wrote:

>> Good idea and it may be the easiest way if you have direct access to the 
>> database.
>
> IIRC the database could be retrieved via rsync.  Glenn would know.

I made all ~ 15000 original reports available at http://debbugs.gnu.org.
The file is called reports.tar.xz and is 55MB.
Serious callers only please (ie, only download this if you seriously
expect to use it).
I'll remove it in a week or so (if I remember).

Re: Finding packages to enable by default

[Tom]

Glenn Morris <rgm <at> gnu.org> writes:
ould be retrieved via rsync.  Glenn would know.
> 
> I made all ~ 15000 original reports available at http://debbugs.gnu.org.
> The file is called reports.tar.xz and is 55MB.

I gave it a shot, though due to the reasons given by Stefan the results 
may not be very meaningful. Here it is anyway with feature names and usage
counts. In case of multiple data from the same people I used their latest
configs:

http://pastebin.com/raw.php?i=wmrgg5Ct


Note that it's not perfect. If you look at the end you'll see broken
names, because the mail clients sometimes mangled the lines. For this 
reason and for the data not being representative it's better to 
collect this data some other way instead of relying on bug reports.

Re: Finding packages to enable by default

[Jambunathan K]

The methodology looks .... Ahem, suspicious.  May be you should share
with us how you ended up with this list in first place.

Tom <adatgyujto@gmail.com> writes:

> http://pastebin.com/raw.php?i=wmrgg5Ct

> indian : 429

...this and other quail(?) related things

Can anyone explain why it tops the charts?  Seems counter-intuitive to
me.

> czech : 429
> slovak : 429
> romanian : 429

These as well.

> overlay : 428
> text-properties : 428

What are these?  How should they be interpreted.  I haven't seen
features named like these?

Re: Finding packages to enable by default

[Tom]

Jambunathan K <kjambunathan <at> gmail.com> writes:

> 
> 
> The methodology looks .... Ahem, suspicious.  May be you should share
> with us how you ended up with this list in first place.
> 

I simply counted the features. Here's an example from one of the mails:

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
 

As you can see there are tibetan, slovak, etc. in it. 

Do a C-h v features in your emacs. I have tibetan, etc. in it, though
I never use the tibetian language. Do you have it also in features?

Note that those features which are turned on by deault in emacs
should be filtered from this list. That's why I asked earlier if these
can be listed automatically somehow.

Re: Finding packages to enable by default

[Jambunathan K]

Tom <adatgyujto@gmail.com> writes:

> Do a C-h v features in your emacs. I have tibetan, etc. in it, though
> I never use the tibetian language. Do you have it also in features?

Yes.

I also see text-properties, overlay there.  (This is amusing.)

It looks like your R&D is reaping benefits and the results are
countering the original intention.  Instead of enabling some features,
we should be disabling... Ha ha ha.

Re: Finding packages to enable by default

[Stefan Monnier]

> I gave it a shot, though due to the reasons given by Stefan the
> results  may not be very meaningful.  Here it is anyway with feature
> names and usage counts.

Thanks.

> http://pastebin.com/raw.php?i=wmrgg5Ct

I think you should filter out the ones that appear in `features' after
"emacs -Q".

> Note that it's not perfect.

Of course.  Another problem is that it includes all the packages loaded
by emacsbug, so I suggest maybe better would be to take the `features'
after "emacs -Q; M-x report-emacs-bug RET foo RET".

Another thing worthwhile would be to normalize the numbers as percentages.


        Stefan

Re: Finding packages to enable by default

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> I think you should filter out the ones that appear in `features' after
> "emacs -Q".
> 

This will hardly make a dent in the results, becase there 6000 items
in the list and emacs with -Q returns only 110 features for me.


It still leaves things like:

(x . 268)
(x-dnd . 267)
(x-win . 267)
(x-toolkit . 264)
(newcomment . 264)
(ring . 259)
(advice . 257)
(font-render-setting . 253)
(macroexp . 252)
(dbusbind . 249)
(cl . 246)
(comint . 243)
(tabulated-list . 241)
(easy-mmode . 239)
(kmacro . 236)
(edmacro . 232)
(gtk . 231)
(byte-compile . 230)
(bytecomp . 229)
(byte-opt . 229)
...

These seem fairly basic stuff.

I should mention that I use 24.1.1. Is it possible that the current
emacs has a much longer features list with -Q? Could someone using
the latest emacs check it?


 
> Another thing worthwhile would be to normalize the numbers as percentages.

Good idea, but first we should trim down the list somehow.

Re: Finding packages to enable by default

[Stefan Monnier]

>> I think you should filter out the ones that appear in `features' after
>> "emacs -Q".
> This will hardly make a dent in the results, becase there 6000 items
> in the list and emacs with -Q returns only 110 features for me.

Of course, "emacs -Q" has different features depending on the particular
Emacs you use, so we can trim it down a bit more this way, but if we
look at your sample:

> (x . 268)
> (x-dnd . 267)
> (x-win . 267)
> (x-toolkit . 264)
> (newcomment . 264)
> (ring . 259)
> (advice . 257)
> (font-render-setting . 253)
> (macroexp . 252)
> (dbusbind . 249)
> (cl . 246)
> (comint . 243)
> (tabulated-list . 241)
> (easy-mmode . 239)
> (kmacro . 236)
> (edmacro . 232)
> (gtk . 231)
> (byte-compile . 230)
> (bytecomp . 229)
> (byte-opt . 229)
> ...

We see that things like `x-win', `gtk', `macroexp', and `newcomment'
might be trimmed with a more careful handling of "emacs -Q".  But the
bulk of the "spurious" features that remain is made of packages which
"can't be *enabled*".

> These seem fairly basic stuff.

Indeed.

> I should mention that I use 24.1.1. Is it possible that the current
> emacs has a much longer features list with -Q?

Longer, yes, much longer, no.

I can't think of an easy to way to characterize a feature which can be
"enabled".  At least, not a way amenable to mechanization.  So I think
a human will have to go through the list and try to classify the
various features by hand.

Tho, maybe we could start by focusing on minor modes: go through the
list of packages, see if they correspond to an Elisp file, search the
file with a `define-minor-mode'.  It wouldn't have found uniquify, and
it will find packages which simply use minor-modes "internally", but
that might be a start.


        Stefan

Re: Finding packages to enable by default

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> We see that things like `x-win', `gtk', `macroexp', and `newcomment'
> might be trimmed with a more careful handling of "emacs -Q".  But the
> bulk of the "spurious" features that remain is made of packages which
> "can't be *enabled*".
>

As I see there are lots of infrastructure packages here (like
byte-opt, etc.) An other approach could be requiring several
complex default packages which would pull in these infrastucture
packages with them. So we do an emacs -Q then require these
packages (e.g. dired, gnus, etc.) they pull in a lot a supporting
packages and then we end up with a much more extensive default
features list which could be used to filter out lots of basic
stuff.

Which builtin packages would you say are good candidates for
this? They should be complex enough to require most of the usual
supporting packages (like mail, diff, url, w3m, etc.) with them.

Gnus?
Org?
Semantic?
Ediff?

Can we come up with a good set of this packages which would drag
in most of the usual supporting stuff with them when they are
required?

Re: Finding packages to enable by default

[Stefan Monnier]

> Which builtin packages would you say are good candidates for
> this? They should be complex enough to require most of the usual
> supporting packages (like mail, diff, url, w3m, etc.) with them.

> Gnus?
> Org?
> Semantic?
> Ediff?

> Can we come up with a good set of this packages which would drag
> in most of the usual supporting stuff with them when they are
> required?

Maybe we should look at it the other way: what do we want to use this for?
IIUC the idea was to try and decide what features to enable by default.
So, how can we recognize a "feature to enable"?
Major modes associated to file names don't really fit our needs,
for example.  Applications like Gnus, Ediff, or Org don't either.


        Stefan

Re: Finding packages to enable by default

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> Maybe we should look at it the other way: what do we want to use this for?
> IIUC the idea was to try and decide what features to enable by default.
> So, how can we recognize a "feature to enable"?
> Major modes associated to file names don't really fit our needs,
> for example.  Applications like Gnus, Ediff, or Org don't either.

We have the list of features enabled in user configs compiled from the bug
reports. 

The ideas was to filter out all the default/supporting features from this
list and then we're left with features which can be enabled. 

I did some manual filtering as a test and here are some of the top packages
which remained:

(ido . 137)
(uniquify . 136)
(imenu . 114)
(eldoc . 113)
(ispell . 107)
(flyspell . 91)
(recentf . 90)
(saveplace . 77)
(yasnippet . 75)
(windmove . 70)
(auto-complete . 66)
(delsel . 64)
(paredit . 49)
(iswitchb . 46)
(savehist . 43)
(linum . 38)
(icomplete . 34)
(winner . 34)
(hippie-exp . 32)
(ibuffer . 29)
...


As you can see uniqify is there.

Ido is at the top (iswitchb is also here) and ido/isiwtchb would really
make a much better first impression for new users than the default
very barebone buffer switching.

recentf/saveplace/savehist are all great improvements. They could be 
enabled by default.

winner/windmove suggest the default window movement is not very
convenient.


Of course, this package measurement should be repeated with
representative data, but even with the data acquired from bug reports
it gives some ideas for packages which could be enabled by default.

RE: Finding packages to enable by default

[Drew Adams]

> We have the list of features enabled in user configs compiled
> from the bug reports.

Which does not include any reports where users remove such info,
for whatever reasons (privacy concerns, irrelevant to the report,
verbosity/noise, whatever).

And even those reports that do include a features list do not
necessarily represent "user configs" that are actually used.
They represent configs that were used for sending a bug report.

Not saying that the info you gather this way has no meaning.
Just saying that not too much should be read into it (e.g.,
suppositions that it is representative in any way).

In sum, you have a list of features that were enabled when some
bug reports were sent.

Re: Finding packages to enable by default

[Tom]

Drew Adams <drew.adams <at> oracle.com> writes:

> 
> > We have the list of features enabled in user configs compiled
> > from the bug reports.
> 
> Which does not include any reports where users remove such info,
> for whatever reasons (privacy concerns, irrelevant to the report,
> verbosity/noise, whatever).

I indicated the same thing in my last paragraph saying this
test should be repeated with more representative data. (Collecting
the value of 'features from users with a fully configured emacs.)

So it's obvious the data is not sufficient, but I suspect we'll
see most of these packages among the top ones again if more data is 
collected.

RE: Finding packages to enable by default

[Drew Adams]

> I suspect we'll see most of these packages among the top ones
> again if more data is collected.

Sounds like you think that the data gathered this way is in fact
a representative sample, at least wrt most of the features reported.

You might be right, but why do you think so?

So far, I see no reason.  Whether it is these features in reports
today or different ones in reports tomorrow, why suppose that
(most) bug-report features are representative of user configs?

The purpose of gathering that feature data for bugs is, hopefully
(but alas probably not so commonly), to learn something about the
context that manifested the bug.

That context is not necessarily representative of the user's
typical config.  In fact, it might well be pared down to provide
the context of a minimal repro recipe being reported.  In short,
a bug report is not a feature report.

But again,

>> Not saying that the info you gather this way has no meaning.
>> Just saying that not too much should be read into it (e.g.,
>> suppositions that it is representative in any way).

and on that I guess we agree.

Re: Finding packages to enable by default

[Tom]

Drew Adams <drew.adams <at> oracle.com> writes:
> 
> Sounds like you think that the data gathered this way is in fact
> a representative sample, at least wrt most of the features reported.
> 
> You might be right, but why do you think so?
> 

Because these are the exact packages I see coming up again and again
when reading emacs forums. From the top ones I see ido, recentf, 
yasnippet, etc. discussed very frequently.

But I agree the data is not representative, so it's only my suspicion
(based on my personal observations) that these are really popular
packages.

[RFC] Micro-Init files in GNU ELPA & Survey suggestions(Re: Finding packages to enable by default)

[Jambunathan K]

In your list, `desktop' is conscpicous by it's absence.  

Tom <adatgyujto@gmail.com> writes:

> if more data is collected.

The third suggestion down below will obsolete the need for collecting
data.  Maintainers don't have to pull the common customization, the
users themselves will start pushing common customizations here.

A robust and ready-usable "Init file" is what every new user of Emacs
will love to get over with.

----------------------------------------------------------------
 
Org-mode customization survey:
============================

Carsten or Bastien will have more information on this.

    http://lists.gnu.org/archive/html/emacs-orgmode/2013-10/msg00858.html

If I understand correctly, the idea is to enumerate 40 or 50 variables
that tops the charts and offer it as "recommended set" for
customization.   

----------------------------------------------------------------

Use Emacswiki
=============

The best method will be to create an Emacs Wiki page, where each user
upvotes a feature [1].  Initially entry, based on my own .emacs will be
something like

| column-number-mode       | 1 |
| desktop-save-mode        | 1 |
| electric-indent-mode     | 1 |
| electric-pair-mode       | 1 |
| global-goto-address-mode | 1 |
| global-hi-lock-mode      | 1 |
| gnus-dired-mode          | 1 |
| icomplete-mode           | 1 |
| ido-mode                 | 1 |
| savehist-mode            | 1 |
| show-paren-mode          | 1 |
| url-handler-mode         | 1 |
| which-function-mode      | 1 |
| whitespace-global-modes  | 1 |

I will also add dired-x, dired-hide-details to that list.

The Survey page can have the above table, while the Comments_On_Survey
page can contain any additional comments that the user wants to add.


[1] My IP address which typically starts with 115.*.*.*.* is censored
    Drew if you are reading this, it is a bad idea to have long-living
    spam filter that block SO MANY ip addresses.  Consider unblocking
    that IP address.  (I have never spammed emacwiki, btw.)

----------------------------------------------------------------

Micro-Init files in Use GNU ELPA
================================

I think GNU ELPA is a nice place to create "sharable init files".  The
init file is not a monolith, but focuses on a particular usecase.

Once such a file is introduced, these files themselves will have a life
of their own.  They become a "clearing house for common configuration"
for a particular use-case.  These files can also serve as bickering
points for evolving a consensus what goes in what value it takes.

Emacs maintainers can also have a clear idea on usage patterns and the
most common configurations.

I have proposed my idea here:
http://lists.gnu.org/archive/html/help-gnu-emacs/2013-11/msg00432.html

Some examples are:

0. basic.el

   Set up user-full-name and user-mail-address.

   (custom-set-variables
    '(user-mail-address "kjambunathan@gmail.com"))

1. indian-holidays.el  (Upgraded every year)

    (custom-set-variables
     '(calendar-date-style (quote european))
     '(calendar-holidays
       (quote
        ((holiday-fixed 1 1 "New Year's Day")
         (holiday-fixed 1 26 "Republic Day")
         (holiday-fixed 8 15 "Independence Day")
         (holiday-fixed 10 2 "Gandhi Jayanthi")
         (holiday-fixed 12 25 "Christmas")
         (indian-holidays)))))

    (defun indian-holidays ()
      '(((1 14 2013) "Pongal")

        ((11 2 2013) "Deepavali")
        ((11 14 2013) "Muharram")))

----------------------------------------------------------------

2. gmane.el

   Add news.gmane.org and automatically subscribe the user to the
   mailing lists.

----------------------------------------------------------------

3. gmail.el (depends on basic.el)

   Set up the smtp and imap or pop server. 

----------------------------------------------------------------



   

Re: [RFC] Micro-Init files in GNU ELPA & Survey suggestions(Re: Finding packages to enable by default)

[Tom]

Jambunathan K <kjambunathan <at> gmail.com> writes:
> 
> In your list, `desktop' is conscpicous by it's absence.  
> 

Lacking an automated method I manually scanned the list and deleted items
which seemed irrelevant. You're right, desktop should be there.
According to the full list I posted it had a count of 70, so it should be
around windmove in the filtered list. I must have deleted it by 
accident.


> The best method will be to create an Emacs Wiki page, where each user
> upvotes a feature [1].  Initially entry, based on my own .emacs will be
> something like

How do you make sure one user can upvote a feature only once and doesn't
boost the score of his favorite feature with several edits? Emacs Wiki
requires no login and stuff.


> I think GNU ELPA is a nice place to create "sharable init files".  The
> init file is not a monolith, but focuses on a particular usecase.
> 
> Once such a file is introduced, these files themselves will have a life
> of their own. They become a "clearing house for common configuration"
> for a particular use-case.  These files can also serve as bickering
> points for evolving a consensus what goes in what value it takes.

Will this consensus be representative? Won't average users just add the
necessary lines to their own init files where they can modify them,
leaving the bickering to the usual emacs-devel contributors?

Re: [RFC] Micro-Init files in GNU ELPA & Survey suggestions(Re: Finding packages to enable by default)

[Jambunathan K]

Tom <adatgyujto@gmail.com> writes:

> How do you make sure one user can upvote a feature only once and doesn't
> boost the score of his favorite feature with several edits? Emacs Wiki
> requires no login and stuff.

You - Tom, The field worker and statistician - are offloaded.

The statistics could be indicative/representative.  i.e., it is not only
the statistic but one among the many data set collected.  It is not
necessary for the figures to be accurate.

In Emacswiki, certain pages can be password protected.  So, if you
create a special cookie and hide it in a trail where intermediate to
experienced folks take a walk, then the task is done.  There would be
less fudging.

More than anything else - Plain Old, Trust.

>> I think GNU ELPA is a nice place to create "sharable init files".  The
>> init file is not a monolith, but focuses on a particular usecase.
>> 
>> Once such a file is introduced, these files themselves will have a life
>> of their own. They become a "clearing house for common configuration"
>> for a particular use-case.  These files can also serve as bickering
>> points for evolving a consensus what goes in what value it takes.
>
> Will this consensus be representative?

It's just one more datapoint to rely on.

The biggest advantage is it will be very useful.  Anyways, it is a nice
experiment.

It is a practical solution to age-old tradition of sharing init files
and welcoming

Instead of being P2P and the resulting inherent fragmentation and
distortion of information it would centralize the common configuration.

If a user asks, how to use Gnus to read Gmail, you say install gmail.el
and put your password and username here.  Done.  One more user
converted.

> Won't average users just add the necessary lines to their own init
> files where they can modify them, leaving the bickering to the usual
> emacs-devel contributors?

The package maintainer - not the Emacs maintainers - will take a hit.
Emacs maintainers merely have to bootstrap and encourage the use of it.

Average users and not-so serious users don't sign copyright assignments
or disclaimers.  I like to think of CA or CD as a barrier or a gate to
keep away mildly interesting folks.

Speaking of copyright, these are configuration files.  So a different
sort of copyright policy could be appropriate for these files.

I also suggest having a non-GNU elpa hosted on savannah.

    http://elpa.nongnu.org

Re: [RFC] Micro-Init files in GNU ELPA & Survey suggestions(Re: Finding packages to enable by default)

[Jambunathan K]

One advantage of micro-init files is that it would discourage the use of

1. Monolithic init files.  "Micro" is just pieces that you assemble on
   your own.  Pull in stuff you want not the whole crap kind of thing.
   
2. Use of "Org" file as an init file.  It is problematic in practice.

       http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125

       

Re: [RFC] Micro-Init files in GNU ELPA

[Ted Zlatanov]

On Wed, 04 Dec 2013 10:34:59 +0530 Jambunathan K <kjambunathan@gmail.com> wrote: 

JK> I also suggest having a non-GNU elpa hosted on savannah.
JK>     http://elpa.nongnu.org

Why not start your own ELPA repository?

Ted

Re: [RFC] Micro-Init files in GNU ELPA

[Ted Zlatanov]

On Wed, 04 Dec 2013 01:25:44 +0530 Jambunathan K <kjambunathan@gmail.com> wrote: 

JK> Micro-Init files in Use GNU ELPA
JK> ================================

It's pretty standard to post RFCs in a new thread, not 6 paragraphs deep
in unrelated e-mails.

JK> I think GNU ELPA is a nice place to create "sharable init files".  The
JK> init file is not a monolith, but focuses on a particular usecase.

JK> Once such a file is introduced, these files themselves will have a life
JK> of their own.  They become a "clearing house for common configuration"
JK> for a particular use-case.  These files can also serve as bickering
JK> points for evolving a consensus what goes in what value it takes.

I think all of these will cause problems

- deprecation of variables
- incompatibility of snippets
- dependencies
- loss of configurability and visibility
- bug and maintenance burden on the submitters
- documentation (or lack thereof)

I personally would not use or enjoy such a system.

Ted

Re: [RFC] Micro-Init files in GNU ELPA

[Jambunathan K]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think all of these will cause problems
>
> - deprecation of variables
> - incompatibility of snippets
> - dependencies
> - loss of configurability and visibility
> - bug and maintenance burden on the submitters
> - documentation (or lack thereof)

My suggestion acknowledges the existing behaviour and merely
systematizes it.

My suggestion is a practical suggestion that need to be tested on the
field and dismissed with a theoretical object.

Many businesses have

1. Small-businesses-suite
2. Pre-configured, Plug-and-play appliances

They do make money (In GNU parlance, happy FLOSS users).

> I personally would not use or enjoy such a system.

That's precisely the point.  You don't have to.

Installing packages from GNU ELPA is optional.  Most intermediate to
expert Emacs users will not use such a system.

But new users will.

Re: [RFC] Micro-Init files in GNU ELPA

[Ted Zlatanov]

On Thu, 05 Dec 2013 10:16:25 +0530 Jambunathan K <kjambunathan@gmail.com> wrote: 

JK> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I think all of these will cause problems
>> 
>> - deprecation of variables
>> - incompatibility of snippets
>> - dependencies
>> - loss of configurability and visibility
>> - bug and maintenance burden on the submitters
>> - documentation (or lack thereof)

JK> My suggestion acknowledges the existing behaviour and merely
JK> systematizes it.

JK> My suggestion is a practical suggestion that need to be tested on the
JK> field and dismissed with a theoretical object.

Your suggestion is completely impractical if it doesn't consider the
practical problems I listed.  Saying "like GNU ELPA but for
configuration snippets" is like saying "like a car but flying and for
giraffes."  Let's talk about how it will fly.

>> I personally would not use or enjoy such a system.

JK> That's precisely the point.  You don't have to.

JK> Installing packages from GNU ELPA is optional.  Most intermediate to
JK> expert Emacs users will not use such a system.

JK> But new users will.

I am intermediate-to-expert and I use and love the GNU ELPA.  I'd love
to see a new way to configure Emacs; I remember discussing Assistants on
emacs-devel a while back.  Assistants are interactive wizards,
implemented by Lars years ago in Gnus but I have yet to figure out how
to use them as a programmer.  Assistants are much closer to what I'd
like to see in Emacs for new users.

Packages and configuration snippets are completely different things.
If you want to argue that they can be treated the same way at the user
level, take the practical concerns I listed into consideration.  Those
are concerns with any package system you present to a user.

Ted

Re: [RFC] Micro-Init files in GNU ELPA

[joakim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 05 Dec 2013 10:16:25 +0530 Jambunathan K <kjambunathan@gmail.com> wrote: 
>
> JK> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> I think all of these will cause problems
>>> 
>>> - deprecation of variables
>>> - incompatibility of snippets
>>> - dependencies
>>> - loss of configurability and visibility
>>> - bug and maintenance burden on the submitters
>>> - documentation (or lack thereof)
>
> JK> My suggestion acknowledges the existing behaviour and merely
> JK> systematizes it.
>
> JK> My suggestion is a practical suggestion that need to be tested on the
> JK> field and dismissed with a theoretical object.
>
> Your suggestion is completely impractical if it doesn't consider the
> practical problems I listed.  Saying "like GNU ELPA but for
> configuration snippets" is like saying "like a car but flying and for
> giraffes."  Let's talk about how it will fly.
>
>>> I personally would not use or enjoy such a system.
>
> JK> That's precisely the point.  You don't have to.
>
> JK> Installing packages from GNU ELPA is optional.  Most intermediate to
> JK> expert Emacs users will not use such a system.
>
> JK> But new users will.
>
> I am intermediate-to-expert and I use and love the GNU ELPA.  I'd love
> to see a new way to configure Emacs; I remember discussing Assistants on
> emacs-devel a while back.  Assistants are interactive wizards,
> implemented by Lars years ago in Gnus but I have yet to figure out how
> to use them as a programmer.  Assistants are much closer to what I'd
> like to see in Emacs for new users.
>
> Packages and configuration snippets are completely different things.
> If you want to argue that they can be treated the same way at the user
> level, take the practical concerns I listed into consideration.  Those
> are concerns with any package system you present to a user.

There is already a "configuration snippet system" deployed to GNU ELPA.
The various color themes provided there.

I use something similar locally: https://github.com/jave/zen-mode

It provides a means to switch between different emacs setups, defined as
themes.

So, if you would like to deploy a bunch of particular settings together as a
theme , you can already do that.

You cant meaningfully deploy a theme that requires user action like this
of course. That would require something like the "Assistant"
idea. However, I think theres room for both ideas, as already evidenced
by colour themes.

> Ted
>
>

-- 
Joakim Verona

Re: [RFC] Micro-Init files in GNU ELPA

[Jambunathan K]

joakim@verona.se writes:

> I use something similar locally: https://github.com/jave/zen-mode

We need to start sharing and colloborating on such packages so that each
user can "choose a mask" or "switch between masks" for his Emacs.

This will make Emacs more personal (than it already is).

Another important part of my proposal is to have packages distributed
via gnu.org servers.  Such package can be distributed as part of say

    http://user.elpa.gnu.org

Re: [RFC] Micro-Init files in GNU ELPA

[T.V. Raman]

While on the topic of elpa, could we make sure that elpa packages
come with info files?  Almost none of them appear to at this point.
-- 

-- 


On 12/5/13, Jambunathan K <kjambunathan@gmail.com> wrote:
> joakim@verona.se writes:
>
>> I use something similar locally: https://github.com/jave/zen-mode
>
> We need to start sharing and colloborating on such packages so that each
> user can "choose a mask" or "switch between masks" for his Emacs.
>
> This will make Emacs more personal (than it already is).
>
> Another important part of my proposal is to have packages distributed
> via gnu.org servers.  Such package can be distributed as part of say
>
>     http://user.elpa.gnu.org
>
>

Re: [RFC] Micro-Init files in GNU ELPA

[Stefan Monnier]

> While on the topic of elpa, could we make sure that elpa packages
> come with info files?  Almost none of them appear to at this point.

For the single-file packages, we don't yet have a way to provide any
Texinfo manual.  For the multi-file packages, we do, but it's up to the
package's maintainer to provide a Texinfo manual.  It would be nice to
have more of them, but I don't want to make it a prerequsite.


        Stefan

Re: [RFC] Micro-Init files in GNU ELPA

[Tom Tromey]

Stefan> For the single-file packages, we don't yet have a way to provide any
Stefan> Texinfo manual.

I think there's no real reason to.  If you have multiple files, make a
multi-file package.  I think it isn't that hard; and in any case an
alternative scheme seems like it would have to be at least as
complicated.

Tom

Re: [RFC] Micro-Init files in GNU ELPA

[Stephen J. Turnbull]

Tom Tromey writes:

 > Stefan> For the single-file packages, we don't yet have a way to provide any
 > Stefan> Texinfo manual.
 > 
 > I think there's no real reason to.  If you have multiple files, make a
 > multi-file package.  I think it isn't that hard; and in any case an
 > alternative scheme seems like it would have to be at least as
 > complicated.

IWBNI we had a package containing all the Info docs (maybe even
including Emacs core docs -- MacPorts, for example, doesn't install
the lispref).  Then people could install that package and have the
best available information about packages they haven't installed yet.
It would have to be treated specially since it would probably
duplicate docs that other packages want to install.

Re: [RFC] Micro-Init files in GNU ELPA

[Stephen J. Turnbull]

Jambunathan K writes:
 > joakim@verona.se writes:
 > 
 > > I use something similar locally: https://github.com/jave/zen-mode
 > 
 > We need to start sharing and colloborating on such packages so that each
 > user can "choose a mask" or "switch between masks" for his Emacs.

As you were at pains to point out in another thread, there's no *need*
for "us" to do any "sharing" or "collaborating".  Each of us is free
to do what we want, and you agree that's as it should be.  It's quite
clear that the only person who *wants* to do anything, or even thinks
it would be valuable if *somebody else* did, is *you*.  So just get
started, and stop telling others what they "need" to do.

Re: [RFC] Micro-Init files in GNU ELPA

[Jambunathan K]

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

> It's quite clear that the only person who *wants* to do anything, or
> even thinks it would be valuable if *somebody else* did, is *you*.

When I propose it usually means that I may as well run with it.  It is
usually the case.

> So just get started, and stop telling others what they "need" to do.

There is a possibility for confusion.  I cannot command Oscar in any
way.  I didn't intend to.

Re: Finding packages to enable by default

[Jambunathan K]

Drew Adams <drew.adams@oracle.com> writes:

> it is representative in any way

Representative is stringent requirement.  Not required here.  Indicative
is good enough.

Another way to look at it is this:

It is representative of a segment of users


1. Tom's list is representative of "The complainers".

2. Emacswiki stats is representative of "The Emacs Trivia Collectors".

3. Andrew's list is representative of "Social workers".

4. We can have twitterers

Likewise for reddit or IRC channels.

Each of these channels of information dissemination (Village Pump) has a
characteristic and a profile of it's own.

----------------------------------------------------------------

Saying Emacs user (in Emacs mailing list) is not useful
=======================================================

I am adding this remark for emphasis.  This remark is better read in
conjunction with my "micro-init" suggestion.

Instead of saying Emacs users, we start saying Novelists, Programmers,
Gnus users, Students, Literate Programmers, Frame users, Old timers,
Young ones, Retro theme users.

Such a sub-categorisation allows for nuanced discussions and a richer
perspective on how one may talk to others.

Disposing my 0 cents worth of wisdom.

Re: Finding packages to enable by default

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> Instead of saying Emacs users, we start saying Novelists, Programmers,
> Gnus users, Students, Literate Programmers, Frame users, Old timers,
> Young ones, Retro theme users.

Clustering of Packages
======================

Another interesting thing would be to "Cluster the Packages".  By
clustering, I mean co-occurrence.

For example, there is large affinity between

1. c-mode <=> which-funciton-mode.
2. text-mode (org-mode) <=> flyspell-mode <=> dictionary/thesaurus
3. org-mode <=> org-indent-mode
4. semantic <=>  global-semantic-idle-scheduler-mode
5. nxml-mode <=> css-mode

Nothing I say is new.  Hopefully someone intereseted in exercising his
visualization skills listener picks up the ball and runs with it.

Re: Finding packages to enable by default

[Stefan Monnier]

> I did some manual filtering as a test and here are some of the top packages
> which remained:

> (ido . 137)
> (uniquify . 136)
> (imenu . 114)
> (eldoc . 113)
> (ispell . 107)
> (flyspell . 91)
> (recentf . 90)
> (saveplace . 77)
> (yasnippet . 75)
> (windmove . 70)
> (auto-complete . 66)
> (delsel . 64)
> (paredit . 49)
> (iswitchb . 46)
> (savehist . 43)
> (linum . 38)
> (icomplete . 34)
> (winner . 34)
> (hippie-exp . 32)
> (ibuffer . 29)
> ...

Great, thanks.  `uniquify' is now enabled by default.
`ido' is rather problematic because it's a very different interface with
incompatible key-bindings and it is not a superset of the current
default completion UI.

> Ido is at the top (iswitchb is also here) and ido/isiwtchb would really
> make a much better first impression for new users than the default
> very barebone buffer switching.

Iswitchb is marked obsolete in the trunk: you can get the same
functionality with icomplete-mode.  So you can increase the count of
`icomplete-mode' for all users who have enabled iswitchb without
enabling icomplete-mode.

The plan for "ido by default" is rather to slowly make ido obsolete by
adding the corresponding functionality either in the default completion
UI or in icomplete-mode.
An alternative is to try and re-implement it on top of the current
completion UI.  To a large extent, it boils down to the same.

> Of course, this package measurement should be repeated with
> representative data, but even with the data acquired from bug reports
> it gives some ideas for packages which could be enabled by default.

Indeed.  But I think it can be a good starting point for discussions
about individual packages.


        Stefan

Re: Finding packages to enable by default

[Andrew Hyatt]

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

This isn't the more scientific package usage measurements found elsewhere
in this thread, but I asked on the Google+ Emacs community, and got a list
of the following packages people thought should be enabled by default:

cua-mode
cua-selection-mode
column-number-mode
delete-selection-mode
desktop-save-mode
dired-x
global-linnum-mode
global-subword-mode
ido-mode
icomplete-mode
iswitchb-mode
recentf-mode
savehist-mode
saveplace
show-paren-mode
size-indication-mode
uniquify
which-function-mode
winner-mode

There's more, but the rest are variable settings, keybindings and misc
functions that are useful. You can find all of it at
https://plus.google.com/+AndrewHyatt/posts/RTguQsNobjg (may not work
without javascript).



On Tue, Dec 3, 2013 at 11:09 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > I did some manual filtering as a test and here are some of the top
> packages
> > which remained:
>
> > (ido . 137)
> > (uniquify . 136)
> > (imenu . 114)
> > (eldoc . 113)
> > (ispell . 107)
> > (flyspell . 91)
> > (recentf . 90)
> > (saveplace . 77)
> > (yasnippet . 75)
> > (windmove . 70)
> > (auto-complete . 66)
> > (delsel . 64)
> > (paredit . 49)
> > (iswitchb . 46)
> > (savehist . 43)
> > (linum . 38)
> > (icomplete . 34)
> > (winner . 34)
> > (hippie-exp . 32)
> > (ibuffer . 29)
> > ...
>
> Great, thanks.  `uniquify' is now enabled by default.
> `ido' is rather problematic because it's a very different interface with
> incompatible key-bindings and it is not a superset of the current
> default completion UI.
>
> > Ido is at the top (iswitchb is also here) and ido/isiwtchb would really
> > make a much better first impression for new users than the default
> > very barebone buffer switching.
>
> Iswitchb is marked obsolete in the trunk: you can get the same
> functionality with icomplete-mode.  So you can increase the count of
> `icomplete-mode' for all users who have enabled iswitchb without
> enabling icomplete-mode.
>
> The plan for "ido by default" is rather to slowly make ido obsolete by
> adding the corresponding functionality either in the default completion
> UI or in icomplete-mode.
> An alternative is to try and re-implement it on top of the current
> completion UI.  To a large extent, it boils down to the same.
>
> > Of course, this package measurement should be repeated with
> > representative data, but even with the data acquired from bug reports
> > it gives some ideas for packages which could be enabled by default.
>
> Indeed.  But I think it can be a good starting point for discussions
> about individual packages.
>
>
>         Stefan
>
>
>

[-- Attachment #2: Type: text/html, Size: 8125 bytes --]

Re: Finding packages to enable by default

[Jambunathan K]

Andrew Hyatt <ahyatt@gmail.com> writes:

> I asked on the Google+ Emacs community, and got a list of the
> following packages people thought should be enabled by default:

Did you collect relative weights, by any chance.

Re: Finding packages to enable by default

[Bozhidar Batsov]

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

On 4 December 2013 06:21, Andrew Hyatt <ahyatt@gmail.com> wrote:

> This isn't the more scientific package usage measurements found elsewhere
> in this thread, but I asked on the Google+ Emacs community, and got a list
> of the following packages people thought should be enabled by default:
>
> cua-mode
> cua-selection-mode
> column-number-mode
> delete-selection-mode
> desktop-save-mode
> dired-x
> global-linnum-mode
> global-subword-mode
> ido-mode
> icomplete-mode
> iswitchb-mode
> recentf-mode
> savehist-mode
> saveplace
> show-paren-mode
> size-indication-mode
> uniquify
>  which-function-mode
> winner-mode
>
> There's more, but the rest are variable settings, keybindings and misc
> functions that are useful. You can find all of it at
> https://plus.google.com/+AndrewHyatt/posts/RTguQsNobjg (may not work
> without javascript).
>
>
>
Based on my experience maintaining Prelude and perusing other popular
configs (ESK, Emacs Live, etc) I'd say the following are good candidates:

* column-number-mode
* delete-selection-mode
* recentf-mode
* savehist-mode
* saveplace
* size-indication-mode
* show-paren-mode
* dired-x
* uniquify (which is already enabled anyways)

All of those are not particularly intrusive and it seems a lot of Emacs
users are using them anyways.  I guess we should avoid enabling by default
packages that are known to be problematic in some situations (like linum
and which-function-mode) and packages that significantly alter the current
default behaviour (like ido).

I also think we should consider replacing dabbrev-expand with hippie-expand
(just rebind `M-/`).


>
> On Tue, Dec 3, 2013 at 11:09 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:
>
>> > I did some manual filtering as a test and here are some of the top
>> packages
>> > which remained:
>>
>> > (ido . 137)
>> > (uniquify . 136)
>> > (imenu . 114)
>> > (eldoc . 113)
>> > (ispell . 107)
>> > (flyspell . 91)
>> > (recentf . 90)
>> > (saveplace . 77)
>> > (yasnippet . 75)
>> > (windmove . 70)
>> > (auto-complete . 66)
>> > (delsel . 64)
>> > (paredit . 49)
>> > (iswitchb . 46)
>> > (savehist . 43)
>> > (linum . 38)
>> > (icomplete . 34)
>> > (winner . 34)
>> > (hippie-exp . 32)
>> > (ibuffer . 29)
>> > ...
>>
>> Great, thanks.  `uniquify' is now enabled by default.
>> `ido' is rather problematic because it's a very different interface with
>> incompatible key-bindings and it is not a superset of the current
>> default completion UI.
>>
>> > Ido is at the top (iswitchb is also here) and ido/isiwtchb would really
>> > make a much better first impression for new users than the default
>> > very barebone buffer switching.
>>
>> Iswitchb is marked obsolete in the trunk: you can get the same
>> functionality with icomplete-mode.  So you can increase the count of
>> `icomplete-mode' for all users who have enabled iswitchb without
>> enabling icomplete-mode.
>>
>> The plan for "ido by default" is rather to slowly make ido obsolete by
>> adding the corresponding functionality either in the default completion
>> UI or in icomplete-mode.
>> An alternative is to try and re-implement it on top of the current
>> completion UI.  To a large extent, it boils down to the same.
>>
>> > Of course, this package measurement should be repeated with
>> > representative data, but even with the data acquired from bug reports
>> > it gives some ideas for packages which could be enabled by default.
>>
>> Indeed.  But I think it can be a good starting point for discussions
>> about individual packages.
>>
>>
>>         Stefan
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 9690 bytes --]

Re: Finding packages to enable by default

[Stefan Monnier]

>> cua-mode

I don't think this can be default in the foreseeable future.  We can
(and do try to) make it super-easy to enable it, but it's hard to go
much further than that, given the inherent difficulties and associated
occasional quirks.

>> cua-selection-mode

IIRC this is basically delete-selection-mode, so I'll disregard it.

>> column-number-mode

We could enable this.  I hadn't noticed it as a popular choice, but
if people like it, I have no particular objection and AFAIK the code is
ready for it.
[ I don't use it myself, but I probably wouldn't bother disabling it
either.  ]

>> delete-selection-mode

I do not want to enable delete-selection-mode in its current state.
I would welcome a new interactive-form element (along the lines of "^")
which would cause deletion of the region if active, and which could be
added to self-insert-command, yank, and a few others.
Maybe under the control of a new value of `delete-active-region'.

Once this is done, I'd have no technical objection to enabling it by
default, tho I don't know if that's really the desire of the majority.

[ I don't use it myself, and I'd probably disable it for my own use.  ]

>> desktop-save-mode

IIUC there's no technical hurdle either.  I dislike the functionality
(the whole point of restarting Emacs, for me, is to get rid of the
umpteen frames and buffers ;-).  But if most people like it...

>> dired-x

No opinion on this one (I basically don't use dired).

>> global-linum-mode

linum is buggy, so it's not an option.  nlinum-mode would be a better
choice, but the potential performance issues, together with the extra
screen real-estate used up... I have a hard time believing that most
people would want it enabled everywhere.

>> global-subword-mode

Hmm... never thought about it, but I guess I could see why that could
be popular.  I haven't looked much at the implementation, but other than
that I could go along with it.

>> icomplete-mode

I see icomplete as "the way to add ido/iswitchb functionality to the
default completion", so I like it in this sense, but I'm not sure about
enabling it by default.  I had it enabled in my .emacs but got rid of it
at some point, can't remember why.

>> iswitchb-mode

Obsolete.

>> recentf-mode

I see no reason not to enable it, indeed.

>> savehist-mode
>> saveplace

Actually, for these (as for recentf-mode), I do remember one reason:
when multiple Emacsen as running at the same time, they all want to
change the same file(s) and end up stepping on each others's toes.
So if we want to enable these, we'd first need to address this
technical issue.

>> show-paren-mode

Too much in your face for me.  It doesn't seem to be that popular.

>> size-indication-mode

Uses up too much mode-line estate, IMO.  I instead use the relative size
of the scrollbar thumb as an indicator of the total file size.

>> uniquify

Already enabled by default now.

>> which-function-mode

It can be a bit unreliable, but enabling it might be an opportunity to
fix those issues.  It does seem to call for a improvement on mode-line
length (probably by auto-contracting some of its elements, such as the
buffer name, the mode names, ...).

>> winner-mode

I could go along with that.  Tho I'd also like to see more generally
improved handling of window-state handling (ability to save&restore
window-states.  We can do that via window-configurations in registers,
but it only works in a single frame, and can't be saved, and I feel like
registers are "too hard to find").


        Stefan

Re: Finding packages to enable by default

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> >> recentf-mode
> 
> I see no reason not to enable it, indeed.
> 
> >> savehist-mode
> >> saveplace
> 
> Actually, for these (as for recentf-mode), I do remember one reason:
> when multiple Emacsen as running at the same time, they all want to
> change the same file(s) and end up stepping on each others's toes.
> So if we want to enable these, we'd first need to address this
> technical issue.

Stepping on each other's toes simply means the later exiting emacs
overwrites the other's history file. Even if it happens (though I
don't think the majority of people runs multiple Emacsen that often)
it's much better than having no history saved at all.

So these packages improve the user experience even without adressing 
the above issue first, which may not be an issue at all for most
users who run only a single emacs instance.

Re: Finding packages to enable by default

[Alex Schroeder]

Tom <adatgyujto@gmail.com> writes:

> Stepping on each other's toes simply means the later exiting emacs
> overwrites the other's history file. Even if it happens (though I
> don't think the majority of people runs multiple Emacsen that often)
> it's much better than having no history saved at all.

Don't we have the same problem with all the comint modes that save a
history of user input?

Re: Finding packages to enable by default

[Tom]

Alex Schroeder <alex <at> gnu.org> writes:

> Don't we have the same problem with all the comint modes that save a
> history of user input?
> 

I suppose so. It's certainly not a showstopper issue.

Re: Finding packages to enable by default

[Stefan Monnier]

> Stepping on each other's toes simply means the later exiting emacs
> overwrites the other's history file.

Thus losing history info, yes.  But it's not that simple.  You may get
prompted (apparently "out of nowhere") if the two processes happen to
write "at the same time".

> Even if it happens (though I don't think the majority of people runs
> multiple Emacsen that often) it's much better than having no history
> saved at all.

That's not how it works: if you occasionally get prompted because of an
option you enabled, it doesn't bother you too much.  But if you suddenly
get prompted for (apparently) no reason because of a feature you never
heard of and never enabled yourself it's much more annoying.

So in order to enable something by default, we need a higher standard
of robustness.


        Stefan

Re: Finding packages to enable by default

[Davis Herring]

> So in order to enable something by default, we need a higher standard
> of robustness.

Because its data is semi-permanent for many users and thus more
valuable, I implemented such robustness for desktop.el several years
ago.  It seems to me that, with these several similar packages (and yet
more written by third parties), we probably want to have a flag that
says "this Emacs is the blessed historian" that, via a lock file, is set
for at most (usually, exactly) one Emacs process at a time.  (Desktop
actually supports multiple desktop files, so perhaps it should really be
that each Emacs is the historian for a directory (under which these
various histories are stored) or for none.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Finding packages to enable by default

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 
> > Stepping on each other's toes simply means the later exiting emacs
> > overwrites the other's history file.
> 
> Thus losing history info, yes.  But it's not that simple.  You may get
> prompted (apparently "out of nowhere") if the two processes happen to
> write "at the same time".

Can this warning be suppressed and have the history overwritten without
a warning? If so then it's a simple fix (shells do the same thing) and
makes it possible to enable this feature by default. 

For most users this will do, because the majority of users don't run
multiple instances of Emacs anyway, and a more sophisticated solution
can be devised later. 

Re: Finding packages to enable by default

[Stefan Monnier]

> Can this warning be suppressed and have the history overwritten without
> a warning?

I don't think there's a strong technical reason why it can't be done.
I was just pointing out that in their current state they can't be
enabled by default.


        Stefan "who enabled savehist-mode a few years ago and after
                trying to solve these problems for himself (only at the
                Elisp level), ended up setting up different files for
                the different instances."

Re: Finding packages to enable by default

[Stephen J. Turnbull]

Tom writes:
 > Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
 > 
 > > 
 > > > Stepping on each other's toes simply means the later exiting emacs
 > > > overwrites the other's history file.
 > > 
 > > Thus losing history info, yes.  But it's not that simple.  You may get
 > > prompted (apparently "out of nowhere") if the two processes happen to
 > > write "at the same time".
 > 
 > Can this warning be suppressed and have the history overwritten without
 > a warning? If so then it's a simple fix (shells do the same thing) and
 > makes it possible to enable this feature by default. 

Emacs is not a shell.  I don't mind losing shell history because it's
very repetitive, and long snippets I typically save to my .zshrc or
.profile with a history|tail|head|cut pipeline (which itself I really
ought to make a shell function for) because I know they'll get tromped
if/when I shutdown.

 > For most users this will do,

The word "most" should immediately clue you that this is inappropriate
as a default.  In particular, I don't use recentf because I have the
files in buffers.  The desktop file saves them for me on restart.
That would be a massive annoyance if that got overwritten because I
forgot to use -q on an experimental emacs instance.

Re: Finding packages to enable by default

[Rüdiger Sonderfeld]

On Wednesday 04 December 2013 15:18:39 Stefan Monnier wrote:
> >> show-paren-mode
> 
> Too much in your face for me.  It doesn't seem to be that popular.

It seems to be rather popular in the EmacsWiki Survey.  So far 19/22 people 
have it enabled, which makes it the most popular one.  The sample size is 
rather small of course and EmacsWiki certainly has a bias towards people who 
write elisp code.

http://www.emacswiki.org/emacs/FrequentlyEnabledPackages_Emacs244_Survey

Regards,
Rüdiger

Re: Finding packages to enable by default

[Tom]

Rüdiger Sonderfeld <ruediger <at> c-plusplus.de> writes:

> 
> On Wednesday 04 December 2013 15:18:39 Stefan Monnier wrote:
> > >> show-paren-mode
> > 
> > Too much in your face for me.  It doesn't seem to be that popular.
> 
> It seems to be rather popular in the EmacsWiki Survey.  So far 19/22 people 
> have it enabled, which makes it the most popular one.  The sample size is 
> rather small of course and EmacsWiki certainly has a bias towards people who 
> write elisp code.
> 

Someone who has a reddit account should post it to 
http://www.reddit.com/r/emacs/ for more exposure.

Re: Finding packages to enable by default

[Tom]

Tom <adatgyujto <at> gmail.com> writes:

> Someone who has a reddit account should post it to 
> http://www.reddit.com/r/emacs/ for more exposure.

Apparently, someone has already done it:

http://www.reddit.com/r/emacs/comments/1s3850/
emacswiki_frequentlyenabledpackages_emacs244/

Re: Finding packages to enable by default

[Dmitry Gutov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> column-number-mode
>
> We could enable this.  I hadn't noticed it as a popular choice, but
> if people like it, I have no particular objection and AFAIK the code is
> ready for it.

It is a rather popular choice, yes.

>>> global-linum-mode
>
> linum is buggy, so it's not an option.  nlinum-mode would be a better
> choice, but the potential performance issues, together with the extra
> screen real-estate used up... I have a hard time believing that most
> people would want it enabled everywhere.

I've seen many people expect this feature automatically, coming from
other editors. I don't use it, personally, so this is one of the
examples where I'd prefer newbies to adapt to change and just look at
the mode-line in the rare instances they really need the line number.

>>> show-paren-mode
>
> Too much in your face for me.  It doesn't seem to be that popular.

It's rather popular, actually. And IMHO, it's much less annoying and
confusing than the cursor-jumping behavior of blink-matching-paren,
which is enabled by default now.

>>> winner-mode
>
> I could go along with that.

+1. Whenever the window-handling code does something different from what
I'd expect, winner-mode saves the day.

Re: Finding packages to enable by default

[martin rudalics]

 >>>> show-paren-mode
 >> Too much in your face for me.  It doesn't seem to be that popular.
 >
 > It's rather popular, actually. And IMHO, it's much less annoying and
 > confusing than the cursor-jumping behavior of blink-matching-paren,
 > which is enabled by default now.

`blink-matching-paren' never ceases to horrify me when I have to use
emacs -Q.  I'd strongly prefer having `show-paren-mode' (or nothing)
instead.

 >>>> winner-mode
 >> I could go along with that.
 >
 > +1. Whenever the window-handling code does something different from what
 > I'd expect, winner-mode saves the day.

Whenever it happens again do not hesitate to file a complaint here, too.

martin

Re: Finding packages to enable by default

[Bozhidar Batsov]

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

On 5 December 2013 09:00, martin rudalics <rudalics@gmx.at> wrote:

> >>>> show-paren-mode
> >> Too much in your face for me.  It doesn't seem to be that popular.
> >
> > It's rather popular, actually. And IMHO, it's much less annoying and
> > confusing than the cursor-jumping behavior of blink-matching-paren,
> > which is enabled by default now.
>
> `blink-matching-paren' never ceases to horrify me when I have to use
> emacs -Q.  I'd strongly prefer having `show-paren-mode' (or nothing)
> instead.
>
>
+1 - I don't think we need show-paren-mode enabled by default that much,
but we definitely need to disable
the horrible `blink-matching-paren'.


>
> >>>> winner-mode
> >> I could go along with that.
> >
> > +1. Whenever the window-handling code does something different from what
> > I'd expect, winner-mode saves the day.
>
> Whenever it happens again do not hesitate to file a complaint here, too.
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 1651 bytes --]

Re: Finding packages to enable by default

[Stefan Monnier]

> +1 - I don't think we need show-paren-mode enabled by default that
> much, but we definitely need to disable the horrible
> `blink-matching-paren'.

I do think we need some paren-matching enabled by default.
I'm surprised blink-matching-paren can elicit such strong sentiments,
since I myself find it very nice, providing just enough info to be
useful (including when the open paren is out of sight) without getting
in the way (you can just ignore the cursor-jump if you don't care about
it).

>> > +1. Whenever the window-handling code does something different from what
>> > I'd expect, winner-mode saves the day.
>> Whenever it happens again do not hesitate to file a complaint here, too.

Just a guess, but the window-handling can "mess up" without it being
a bug, so the "something different from what I'd expect" may still be
"the right choice" in general.


        Stefan

RE: Finding packages to enable by default

[Drew Adams]

> > +1 - I don't think we need show-paren-mode enabled by default that
> > much, but we definitely need to disable the horrible
> > `blink-matching-paren'.
> 
> I do think we need some paren-matching enabled by default.
> I'm surprised blink-matching-paren can elicit such strong sentiments,
> since I myself find it very nice, providing just enough info to be
> useful (including when the open paren is out of sight) without getting
> in the way (you can just ignore the cursor-jump if you don't care about it).

FWIW, I have both `show-paren-mode' and `blink-matching-paren' turned on.

There is *no* cursor bouncing from the latter, when both are on (at least
I don't notice any).

And the latter gives me the advantage of showing info in the echo area
whenever the match is off-window.

Re: Finding packages to enable by default

[Dmitry Gutov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I do think we need some paren-matching enabled by default.
> I'm surprised blink-matching-paren can elicit such strong sentiments,

Maybe it would've elicited better reception if the blinking was not
performed with a cursor jump (if the cursor stayed where it was, and the
blink was performed in, say, show-paren-match).  As it is, my first
impression of using it was, how do I get my cursor back?

> since I myself find it very nice, providing just enough info to be
> useful (including when the open paren is out of sight) without getting
> in the way (you can just ignore the cursor-jump if you don't care about
> it).

You can ignore it after the first impression wears off and you get it,
but it still takes some small amount of cognitive load that maybe would
be better spent elsewhere.

>>> > +1. Whenever the window-handling code does something different from what
>>> > I'd expect, winner-mode saves the day.
>>> Whenever it happens again do not hesitate to file a complaint here, too.

Yes, sure, thanks. Though some of my expectations might be different
from the general public.

> Just a guess, but the window-handling can "mess up" without it being
> a bug, so the "something different from what I'd expect" may still be
> "the right choice" in general.

Also yes.

Re: Finding packages to enable by default

[Stefan Monnier]

>> I do think we need some paren-matching enabled by default.
>> I'm surprised blink-matching-paren can elicit such strong sentiments,
> Maybe it would've elicited better reception if the blinking was not
> performed with a cursor jump (if the cursor stayed where it was, and the
> blink was performed in, say, show-paren-match).  As it is, my first
> impression of using it was, how do I get my cursor back?

Indeed, we could definitely make it so the cursor stays put while we
highlight the other end.


        Stefan

RE: Finding packages to enable by default

[Drew Adams]

> Indeed, we could definitely make it so the cursor stays put while we
> highlight the other end.

As I said, if you enable also `show-paren-mode', then the cursor stays 
put (AFAICT).  You get the advantages of both: message when needed and
highlighting.

Just make that combination the default.  Anyone wanting just the
blinking can turn off `show-paren-mode'.  Anyone not wanting the
off-window msg can turn off `blink-matching-paren'.

Re: Finding packages to enable by default

[Stefan Monnier]

> As I said, if you enable also `show-paren-mode', then the cursor stays 
> put (AFAICT).  You get the advantages of both: message when needed and
> highlighting.

No, the difference is that show-paren-mode highlights the other end *all
the time*, rather than only when inserting the closing paren.


        Stefan

RE: Finding packages to enable by default

[Drew Adams]

> > As I said, if you enable also `show-paren-mode', then the cursor stays
> > put (AFAICT).  You get the advantages of both: message when needed and
> > highlighting.
> 
> No, the difference is that

Hm.  "No" what?  "Difference"?  What are you comparing?

I said nothing about a difference - nothing to correct wrt "the
difference", AFAIK.

> show-paren-mode highlights the other end *all the time*, rather than
> only when inserting the closing paren.

Yes, it does.  And?  Does that contradict what I said?  What I said is
that there is no apparent movement of the cursor - no blinking noticed,
when both are turned on.

1. Some people have said, and I agree, that `show-paren-mode' should be
   on by default: highlight both ends.

2. Others have countered that an advantage of `blink-matching-paren'
   over `show-paren-mode' is that tells you where the other end is,
   when it is off-window.  I agree: `blink-matching-paren' should
   remain on (non-nil) by default.

3. No one (maybe you?) has spoken in favor of the jump-and-blink
   behavior of `blink-matching-paren'.  Some have called it annoying.
   But turning on `show-paren-mode' nullifies this behavior, AFAICT.

Putting 1 & 2 together is what I suggested: (1) highlighting both
ends, from `show-paren-mode', and (2) provide an informative msg when
the other end is off-window, from `blink-matching-paren'.

AFAICT, turning them both on does 1 + 2 without 3 (no jump & blink).

Am I missing something?

Re: Finding packages to enable by default

[Jambunathan K]

My 0 cents.

An expert user may have different requirements or may look at atypical
source files.  But he cannot count himself in for this survey.

`show-paren-mode' is topping the list.  That it's behaviour "suffices"
is what matters.  Whether there is an alternate behaviour that is
"superior" shouldn't matter much.

Drew Adams <drew.adams@oracle.com> writes:

> 2. Others have countered that an advantage of `blink-matching-paren'
>    over `show-paren-mode' is that tells you where the other end is,
>    when it is off-window.  I agree: `blink-matching-paren' should
>    remain on (non-nil) by default.

> 3. No one (maybe you?) has spoken in favor of the jump-and-blink
>    behavior of `blink-matching-paren'.  Some have called it annoying.
>    But turning on `show-paren-mode' nullifies this behavior, AFAICT.

It is easy to tell when the other end is out of view.  In that case, I
can scroll so that both ends are within the screen.

Otherwise, I just use C-M-n and C-M-p. I don't need blinking. It works
for me.

RE: Finding packages to enable by default

[Drew Adams]

> `show-paren-mode' is topping the list.

Good.

> That it's behaviour "suffices" is what matters.  Whether there is
> an alternate behaviour that is "superior" shouldn't matter much.

Check whether you don't have both turned on.  `blink-matching-paren'
is ON by default.  If you then turn on `show-paren-mode' then you are
seeing the same behavior I suggested.  If you want to see `s-p-m'
without `b-m-p', then turn off `b-m-p'.

> > 2. Others have countered that an advantage of `blink-matching-paren'
> >    over `show-paren-mode' is that tells you where the other end is,
> >    when it is off-window.  I agree: `blink-matching-paren' should
> >    remain on (non-nil) by default.
> 
> > 3. No one (maybe you?) has spoken in favor of the jump-and-blink
> >    behavior of `blink-matching-paren'.  Some have called it annoying.
> >    But turning on `show-paren-mode' nullifies this behavior, AFAICT.
> 
> It is easy to tell when the other end is out of view.  In that case, I
> can scroll so that both ends are within the screen.
> Otherwise, I just use C-M-n and C-M-p.

Did you try the different possibilities?  (2 values each * 2 "modes")

You are clearly missing the point, here.

What `blink-matching-paren' does is not just tell you THAT the other
end is out of view.  It shows you the code that your right paren
matches.

I suspect that you are seeing that message anyway (since `b-m-p' is
on by default).  Try turning off `b-m-p' and you will see no such
indication of what matches.  Not as helpful.

> I don't need blinking. It works for me.

Please reread what I wrote.  I don't need blinking either.  And with
what I suggested there is no blinking.

Re: Finding packages to enable by default

[Jambunathan K]

Drew Adams <drew.adams@oracle.com> writes:

> I suspect that you are seeing that message anyway

`blink-matching-paren' kicks in when I INSERT the paren.
`show-paren-mode' works even when I am BROWSING around.

CMIIW, `blink-matching-paren' gives no feedback when I am just reading
the code and not editing it.

1. Reading (Comprehending others or one's own code) is more frequent
   than creating new code.

2. Blinking and Echoing is most definitely NOT what I want (particularly
   when I am editing the code).

NOTE: I have been editing as well as reading ox-odt.el for good part of
last 1-2 years.  As a reader and an editor, I can say show-paren-mode is
what I want.  (I use a netbook, so even simple forms are out of view)

`blink-matching-paren' ... No Thanks!  It makes NO practical difference
to the majority of people and use cases out there.

Re: Finding packages to enable by default

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Fri, 06 Dec 2013 12:07:57 +0530
> Cc: Andrew Hyatt <ahyatt@gmail.com>, Tom <adatgyujto@gmail.com>,
> 	emacs-devel <emacs-devel@gnu.org>, martin rudalics <rudalics@gmx.at>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>,
> 	Bozhidar Batsov <bozhidar@batsov.com>, Dmitry Gutov <dgutov@yandex.ru>
> 
> `blink-matching-paren' ... No Thanks!  It makes NO practical difference
> to the majority of people and use cases out there.

It shows you the matching paren in the echo area when that matching
paren is off-screen.  So it saves you the trip to the other end, just
to see what source code is there.  That's very useful.

Re: Finding packages to enable by default

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Fri, 06 Dec 2013 11:23:04 +0530
> Cc: Andrew Hyatt <ahyatt@gmail.com>, Tom <adatgyujto@gmail.com>,
> 	emacs-devel <emacs-devel@gnu.org>, martin rudalics <rudalics@gmx.at>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>,
> 	Bozhidar Batsov <bozhidar@batsov.com>, Dmitry Gutov <dgutov@yandex.ru>
> 
> 
> Drew Adams <drew.adams@oracle.com> writes:
> 
> > 2. Others have countered that an advantage of `blink-matching-paren'
> >    over `show-paren-mode' is that tells you where the other end is,
> >    when it is off-window.  I agree: `blink-matching-paren' should
> >    remain on (non-nil) by default.
> 
> > 3. No one (maybe you?) has spoken in favor of the jump-and-blink
> >    behavior of `blink-matching-paren'.  Some have called it annoying.
> >    But turning on `show-paren-mode' nullifies this behavior, AFAICT.
> 
> It is easy to tell when the other end is out of view.  In that case, I
> can scroll so that both ends are within the screen.
> 
> Otherwise, I just use C-M-n and C-M-p. I don't need blinking. It works
> for me.

Can someone please tell me what is this argument about?  AFAIR, when
you activate show-paren-mode, the jump-and-blink behavior is disabled,
so what you get is a highlight of the opposite paren when it is on
screen, and an echo area message when it is not.  So what is the
problem you are arguing about here?  What did I miss?

Re: Finding packages to enable by default

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:

> Can someone please tell me what is this argument about?  AFAIR, when
> you activate show-paren-mode, the jump-and-blink behavior is disabled,
> so what you get is a highlight of the opposite paren when it is on
> screen, and an echo area message when it is not.  So what is the
> problem you are arguing about here?  What did I miss?

`show-paren-mode' user here.

Instead of relying on echo area for feedback, I use sexp motion commands
to reach the other end.  I am talking about MY workflow not a problem.

Re: Finding packages to enable by default

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: ahyatt@gmail.com,  adatgyujto@gmail.com,  emacs-devel@gnu.org,  rudalics@gmx.at,  monnier@iro.umontreal.ca,  bozhidar@batsov.com,  dgutov@yandex.ru,  drew.adams@oracle.com
> Date: Fri, 06 Dec 2013 16:50:05 +0530
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can someone please tell me what is this argument about?  AFAIR, when
> > you activate show-paren-mode, the jump-and-blink behavior is disabled,
> > so what you get is a highlight of the opposite paren when it is on
> > screen, and an echo area message when it is not.  So what is the
> > problem you are arguing about here?  What did I miss?
> 
> `show-paren-mode' user here.
> 
> Instead of relying on echo area for feedback, I use sexp motion commands
> to reach the other end.  I am talking about MY workflow not a problem.

Good for you, but what does this have to do with the current
discussion, which is about the _defaults_?

Re: Finding packages to enable by default

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:

> Good for you, but what does this have to do with the current
> discussion, which is about the _defaults_?

Just ignore me or put me in kill file.  It will be good for you.

RE: Finding packages to enable by default

[Drew Adams]

> Instead of relying on echo area for feedback, I use sexp motion commands
> to reach the other end.  I am talking about MY workflow not a problem.

I still wonder whether you have actually tried it.  Why anyone would want
to "reach the other end" in such a context is beyond me.

(Reaching the other end momentarily, was the point of `blink-matching-paren',
which behavior you (and I) do not prefer.)

Re: Finding packages to enable by default

[Jambunathan K]

Drew Adams <drew.adams@oracle.com> writes:

> I still wonder whether you have actually tried it.

I am not interested in trying all 4 combinations.

CMIIW, show-paren-mode works for reading (as well).  blink-* is for
editing.

> Why anyone would want to "reach the other end" in such a context is
> beyond me.

Don't ask me why...  It is just so.  C-M-n and C-M-p, I can do with no
second thought.

NOTE: We are sharing notes on how we ourselves use a feature.  So I
believe my - as is everyone else's - noting counts.

Re: Finding packages to enable by default

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 05 Dec 2013 23:28:00 -0500
> Cc: Andrew Hyatt <ahyatt@gmail.com>, Tom <adatgyujto@gmail.com>,
> 	emacs-devel <emacs-devel@gnu.org>, martin rudalics <rudalics@gmx.at>,
> 	Bozhidar Batsov <bozhidar@batsov.com>, Dmitry Gutov <dgutov@yandex.ru>
> 
> the difference is that show-paren-mode highlights the other end *all
> the time*, rather than only when inserting the closing paren.

Which is a good thing: if you somehow miss the momentary highlight,
you'd need to delete and reinsert the paren to see it again.  When you
edit a complex sexp, you might wish to see the matching parens after
they are already inserted.  show-paren-mode solves this nuisance
(which happens to me all the time when I use "emacs -Q").

Of course, I'm a veteran and devoted user of show-paren-mode.

Re: Finding packages to enable by default

[martin rudalics]

 > Indeed, we could definitely make it so the cursor stays put while we
 > highlight the other end.

Good idea.  Maybe we could enhance the highlight-paren-mode menu entry
in the course of such a change.

martin

Re: Finding packages to enable by default

[Stefan Monnier]

>> Indeed, we could definitely make it so the cursor stays put while we
>> highlight the other end.
> Good idea.

Patch welcome.
But do hurry, the feature freeze immins pretty hard these days,


        Stefan

Re: Finding packages to enable by default

[Juanma Barranquero]

On Fri, Dec 6, 2013 at 6:30 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> But do hurry, the feature freeze immins pretty hard these days,

Will the feature freeze preclude installing the new Ada mode if it
delays for a while? It is not yet ready, but Stephen Leake just said
today in the Ada mode list that he's "finally working on polishing the
code for a release!"

    J

Re: Finding packages to enable by default

[Stefan Monnier]

>> But do hurry, the feature freeze immins pretty hard these days,
> Will the feature freeze preclude installing the new Ada mode if it
> delays for a while?

Could be, yes.


        Stefan

Re: Finding packages to enable by default

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> But do hurry, the feature freeze immins pretty hard these days,
>> Will the feature freeze preclude installing the new Ada mode if it
>> delays for a while?
>
> Could be, yes.

Speaking of feature freezes and packages -- is there any chance js2-mode
could become the default JavaScript mode in Emacs?  It's so much better
than the standard JavaScript mode that it isn't even funny.

It's perhaps the best mode available for Emacs at all, and JavaScript is
the language du jour, so it seems a pity that it's not used by default.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Finding packages to enable by default

[Dmitry Gutov]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Speaking of feature freezes and packages -- is there any chance js2-mode
> could become the default JavaScript mode in Emacs?  It's so much better
> than the standard JavaScript mode that it isn't even funny.

Personally, I'd prefer to keep it in ELPA, because Git.

Good news is, since ~18 hours ago, js-mode indentation code has feature
parity with js2-mode (aside from a couple of simplifications).

So when Emacs 24.4 is released, we'll make js2-mode derive from js-mode
and reuse the merged indentation logic. With a compatibility shim for
older Emacsen, I guess.

> It's perhaps the best mode available for Emacs at all, and JavaScript is
> the language du jour, so it seems a pity that it's not used by default.

Installing from ELPA shouldn't be a problem for anyone.

The use of a parser is an opinionated choice, and maybe we should leave
it to users. It's not hard to imagine that js-mode + flymake using
jslint or jshint can be a better fit for some workflows, and I've read
a few opinions stating that.

Re: Finding packages to enable by default

[Stefan Monnier]

> So when Emacs 24.4 is released, we'll make js2-mode derive from js-mode

That would be great.

> The use of a parser is an opinionated choice, and maybe we should leave
> it to users. It's not hard to imagine that js-mode + flymake using
> jslint or jshint can be a better fit for some workflows, and I've read
> a few opinions stating that.

That doesn't preclude merging js2-mode into Emacs (by making the parser
optional).  In any case, I think the way to do it, is to work on the
tarball script so as to bundle some ELPA packages into the tarball.


        Stefan

Re: Finding packages to enable by default

[Dmitry Gutov]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> That doesn't preclude merging js2-mode into Emacs (by making the parser
> optional).

That would just mean making js2-mode optional, i.e. bundling it, but
keeping js-mode as the default.

> In any case, I think the way to do it, is to work on the
> tarball script so as to bundle some ELPA packages into the tarball.

Sounds fine to me. Personally, I'm hoping this would also allow to move
the bigger packages, such as Org and CEDET, outside of the Emacs tree.

Re: Finding packages to enable by default

[Stefan Monnier]

>> That doesn't preclude merging js2-mode into Emacs (by making the parser
>> optional).
> That would just mean making js2-mode optional, i.e. bundling it, but
> keeping js-mode as the default.

Well, yes, make js2-mode as a kind of minor mode.  I don't have a strong
opinion whether it should be enabled or disabled by default.

>> In any case, I think the way to do it, is to work on the
>> tarball script so as to bundle some ELPA packages into the tarball.
> Sounds fine to me.  Personally, I'm hoping this would also allow to move
> the bigger packages, such as Org and CEDET, outside of the Emacs tree.

That's kind of the idea, yes.


        Stefan

Re: Finding packages to enable by default

[Dmitry Gutov]

On 11.12.2013 16:09, Stefan Monnier wrote:
> Well, yes, make js2-mode as a kind of minor mode.

It already has a minor mode, too. :)

Re: Finding packages to enable by default

[Stephen Leake]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Dec 6, 2013 at 6:30 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> But do hurry, the feature freeze immins pretty hard these days,

This is the first I've heard of a feature freeze; where are such things
announced?

I often skip large parts of this list, so if it is only announced here,
I could easily miss it.

> Will the feature freeze preclude installing the new Ada mode if it
> delays for a while? It is not yet ready, but Stephen Leake just said
> today in the Ada mode list that he's "finally working on polishing the
> code for a release!"

My plan is to put Ada mode 5.0 in MELPA first, in the hopes of getting
more beta testers. Then it might move to ELPA.

I don't think it should stay in Emacs core, mainly because I don't have
write privs to Emacs core, and also because I can manage M/ELPA via Git
rather than Bazaar.

-- 
-- Stephe

Re: Finding packages to enable by default

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Sun, 08 Dec 2013 14:23:02 -0600
> 
> >> But do hurry, the feature freeze immins pretty hard these days,
> 
> This is the first I've heard of a feature freeze; where are such things
> announced?

Here:

  http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00500.html

Re: Finding packages to enable by default

[Juanma Barranquero]

On Sun, Dec 8, 2013 at 9:23 PM, Stephen Leake
<stephen_leake@stephe-leake.org> wrote:

> I don't think it should stay in Emacs core, mainly because I don't have
> write privs to Emacs core, and also because I can manage M/ELPA via Git
> rather than Bazaar.

It is your call, but I'd hate having it outside the Emacs core. That
would mean either removing the 4.0 mode from Emacs, or keeping it as
an obsolete and no-longer-maintained package. Emacs is first of all a
programmer's editor (historically, I mean), and there's a reason why
it has a lisp/progmodes directory.

    J

ada mode [was Re: Finding packages to enable by default]

[Glenn Morris]

Stephen Leake wrote:

> mainly because I don't have write privs to Emacs core

?

You are a member of the Savannah Emacs project since 2008:

http://savannah.gnu.org/users/stephen_leake

That means that you've had write privs all that time.

Re: ada mode [was Re: Finding packages to enable by default]

[Stephen Leake]

Glenn Morris <rgm@gnu.org> writes:

> Stephen Leake wrote:
>
>> mainly because I don't have write privs to Emacs core
>
> ?
>
> You are a member of the Savannah Emacs project since 2008:
>
> http://savannah.gnu.org/users/stephen_leake
>
> That means that you've had write privs all that time.

Ah. I did not realize a Savannah account gave write privs to Emacs; I
assumed there was a more involved process.

Guess I'll give it a try. 

But I still prefer Git over Bzr (I understand it's not up to a vote for
Emacs core).

-- 
-- Stephe

Re: ada mode [was Re: Finding packages to enable by default]

[Rüdiger Sonderfeld]

On Thursday 12 December 2013 10:42:21 Stephen Leake wrote:
> But I still prefer Git over Bzr (I understand it's not up to a vote for
> Emacs core).

You can use git remote-bzr to pull and push from/to the Bzr repo.  I've 
recently made two commits that way and it worked rather well.

Regards,
Rüdiger

Re: Finding packages to enable by default

[Stefan Monnier]

> My plan is to put Ada mode 5.0 in MELPA first, in the hopes of getting
> more beta testers.  Then it might move to ELPA.

Installing it into Emacs's core just before the freeze will give you
even more testers.

> I don't think it should stay in Emacs core, mainly because I don't have
> write privs to Emacs core,

As Glenn pointed out, you do.

If you want to move it to GNU ELPA, we could do that, but then I'd want
to include this ELPA package into the Emacs tarball.  This said, it'd be
kind of a pain in the rear to do (lots of work to make sure the shift
from "core" to "external package" is sufficiently smooth).


        Stefan

Re: Finding packages to enable by default

[Stephen Leake]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> My plan is to put Ada mode 5.0 in MELPA first, in the hopes of getting
>> more beta testers.  Then it might move to ELPA.
>
> Installing it into Emacs's core just before the freeze will give you
> even more testers.

Yes, but also less ability to provide timely updates to fix problems.
That's an advantage of ELPA that I didn't mention before.

>> I don't think it should stay in Emacs core, mainly because I don't have
>> write privs to Emacs core,
>
> As Glenn pointed out, you do.
>
> If you want to move it to GNU ELPA, we could do that, but then I'd want
> to include this ELPA package into the Emacs tarball.  

That makes sense.

> This said, it'd be
> kind of a pain in the rear to do (lots of work to make sure the shift
> from "core" to "external package" is sufficiently smooth).

I have not tried packages in Emacs yet, so I can't really comment on
that. 

A much bigger lack of smoothness will caused by the fact that this is a
complete rewrite. I have been attempting to keep things as upwardly
compatible as possible. But it is not even close to 100%; the major
functionality in the menu is the same, and the main user options are
there, although renamed with obsoleted aliases. Some of the user
functions are the same, but others have changed. 

No one so far has complained about that, but I've only got a handful of
testers so far.

So I think it makes sense to leave Ada mode 4.0 in core while
introducing 5.0 in ELPA. Does that mean the file names and major mode
name have to be distinct? I hope not.

Since ELPA packages can be updated independent of core or other
packgages, managing a major change like this is easier in ELPA than in
core.

After 5.x is stable would be time to obsolete or delete Ada mode 5.0.

--
-- Stephe

Re: Finding packages to enable by default

[Dmitry Gutov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Indeed, we could definitely make it so the cursor stays put while we
>>> highlight the other end.
>> Good idea.
>
> Patch welcome.

Comments?

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2013-12-03 01:19:24 +0000
+++ lisp/simple.el	2013-12-11 03:40:09 +0000
@@ -6308,8 +6308,15 @@
 START can be nil, if it was not found.
 The function should return non-nil if the two tokens do not match.")
 
+(defvar blink-matching--overlay
+  (let ((ol (make-overlay (point) (point) nil t)))
+    (overlay-put ol 'face 'show-paren-match)
+    (delete-overlay ol)
+    ol)
+  "Overlay used to highlight the matching paren.")
+
 (defun blink-matching-open ()
-  "Move cursor momentarily to the beginning of the sexp before point."
+  "Momentarily highlight the beginning of the sexp before point."
   (interactive)
   (when (and (not (bobp))
 	     blink-matching-paren)
@@ -6351,13 +6358,18 @@
             (message "No matching parenthesis found"))))
        ((not blinkpos) nil)
        ((pos-visible-in-window-p blinkpos)
-        ;; Matching open within window, temporarily move to blinkpos but only
-        ;; if `blink-matching-paren-on-screen' is non-nil.
+        ;; Matching open within window, temporarily highlight char
+        ;; after blinkpos but only if `blink-matching-paren-on-screen'
+        ;; is non-nil.
         (and blink-matching-paren-on-screen
              (not show-paren-mode)
              (save-excursion
-               (goto-char blinkpos)
-               (sit-for blink-matching-delay))))
+               (move-overlay blink-matching--overlay blinkpos (1+ blinkpos)
+                             (current-buffer))
+               (overlay-put blink-matching--overlay
+                            'priority show-paren-priority)
+               (sit-for blink-matching-delay)
+               (delete-overlay blink-matching--overlay))))
        (t
         (save-excursion
           (goto-char blinkpos)

Re: Finding packages to enable by default

[martin rudalics]

 >               (save-excursion
 > -               (goto-char blinkpos)
 > -               (sit-for blink-matching-delay))))
 > +               (move-overlay blink-matching--overlay blinkpos (1+ blinkpos)
 > +                             (current-buffer))
 > +               (overlay-put blink-matching--overlay
 > +                            'priority show-paren-priority)
 > +               (sit-for blink-matching-delay)
 > +               (delete-overlay blink-matching--overlay))))

I think there's no more need to save the excursion here.

But maybe someone likes the old behavior and we should provide an option
(like a special value 'jump for `blink-matching-paren') to support it.

martin

Re: Finding packages to enable by default

[Dmitry Gutov]

On 11.12.2013 10:13, martin rudalics wrote:
> I think there's no more need to save the excursion here.

Good point. If there are no further comments, I'll install it in a day 
or so.

> But maybe someone likes the old behavior and we should provide an option
> (like a special value 'jump for `blink-matching-paren') to support it.

Maybe. But unless someone explicitly says they prefer the old behavior, 
I'd rather not provide that extra option.

Re: Finding packages to enable by default

[Stefan Monnier]

>> (save-excursion
>> -               (goto-char blinkpos)
>> -               (sit-for blink-matching-delay))))
>> +               (move-overlay blink-matching--overlay blinkpos (1+ blinkpos)
>> +                             (current-buffer))
>> +               (overlay-put blink-matching--overlay
>> +                            'priority show-paren-priority)
>> +               (sit-for blink-matching-delay)
>> +               (delete-overlay blink-matching--overlay))))
> I think there's no more need to save the excursion here.

Agreed.  OTOH there is a strong need for unwind-protect, in case the
user hits C-g during the delay.

One other problem: the show-paren-match face should be moved to
simple.el or faces.el.

> But maybe someone likes the old behavior and we should provide an option
> (like a special value 'jump for `blink-matching-paren') to support it.

I agree with Dmitry that we can wait.


        Stefan

Re: Finding packages to enable by default

[Dmitry Gutov]

On 11.12.2013 16:13, Stefan Monnier wrote:
> Agreed.  OTOH there is a strong need for unwind-protect, in case the
> user hits C-g during the delay.

Right!

> One other problem: the show-paren-match face should be moved to
> simple.el or faces.el.

And the `show-paren-priority' variable? It, too?

Re: Finding packages to enable by default

[Stefan Monnier]

>> One other problem: the show-paren-match face should be moved to
>> simple.el or faces.el.
> And the `show-paren-priority' variable? It, too?

I don't think so, no.


        Stefan

Re: Finding packages to enable by default

[Dmitry Gutov]

On 11.12.2013 16:13, Stefan Monnier wrote:
> OTOH there is a strong need for unwind-protect, in case the
> user hits C-g during the delay.
>
> One other problem: the show-paren-match face should be moved to
> simple.el or faces.el.

Done. I also moved the paren-showing-faces group, and the second face in 
it: show-paren-mismatch, which seemed appropriate.

show-paren-mismatch still declares paren-showing (which is defined in 
paren.el) as one of its parens, not sure what to do about that.

Re: Finding packages to enable by default

[martin rudalics]

 > I'm surprised blink-matching-paren can elicit such strong sentiments,
 > since I myself find it very nice, providing just enough info to be
 > useful (including when the open paren is out of sight) without getting
 > in the way (you can just ignore the cursor-jump if you don't care about
 > it).

It's indeed the combination of a default blinking cursor (the one from
`blink-cursor-mode' namely) _and_ the cursor jump that horrifies me.  If
you are used to a non-blinking cursor and `show-paren-mode' like me,
such effects can be distracting.  But I certainly don't want to impose
my habits on anyone.

martin

Re: Finding packages to enable by default

[Stephen J. Turnbull]

Stefan Monnier writes:

 > >> column-number-mode
 > 
 > We could enable this.

XEmacs has enabled it by default for a decade.  It's not unpopular.
We've had only one or two complaints about the flicker in the
modeline, and those from Ancien Hacquers.

 > >> delete-selection-mode

This gets vocifierous opposition although it's undeniably popular.

 > >> global-linum-mode

Ditto, but not so popular.

 > >> show-paren-mode
 > 
 > Too much in your face for me.  It doesn't seem to be that popular.

Vociferous opposition, no support for default when suggested.

 > >> uniquify
 > 
 > Already enabled by default now.

Ditto.

FWIW, the important one is column-number-mode which is tested and
liked in our users.

Steve

Re: Finding packages to enable by default

[Jambunathan K]

For emphasis (and for the last time), I will pitch for micro-init
suggestion [1, 2].

----------------------------------------------------------------

Your objections seem to fall under

1. Not appropriate for all
   - In the face for me etc.
   
2. Not widely usable
   - Not now, may be in future
   - buggy
   - problematic under certain scenarios

These are in "conflict" with the popularity of the options.

----------------------------------------------------------------

My micro-init suggestion deals with the above problem by

1. Segmenting the users AND packages in to classes 

2. Shifts the responsibility and blame to users themselves.  Because
   they asked for these packages to be enabled.

    http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00093.html


Bingo! 100% satisfied customers.
    
----------------------------------------------------------------

Here is how I see the above problems handled with micro-packages:

1. common.el

   (fset 'yes-or-no-p 'y-or-n-p)

2. winnt-users.el

    cua-mode
    delete-selection-mode
    linum-mode

3. programmers.el

   which-function-mode
   outline-minor-mode

4. lispers.el (depends on 3 above)

   show-paren-mode

5. history-junkies.el

    recentf-mode
    savehist-mode
    saveplace
    desktop

----------------------------------------------------------------

[1] Don't say Emacs users, segment them

    http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00093.html

[2] Package co-occurrence:

    http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00111.html
    

Re: Finding packages to enable by default

[Josh]

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

On Wed, Dec 4, 2013 at 12:18 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> >> dired-x
>
> No opinion on this one (I basically don't use dired).
>

Is there any reason why dired-x and/or dired-aux could not be integrated
with dired proper?  Together they provide a good deal of useful
functionality,
but I was oblivious to their existence for quite a long time because their
constituent functions and variables did not appear among the results of my
documentation searches.

[-- Attachment #2: Type: text/html, Size: 888 bytes --]

RE: Finding packages to enable by default

[Drew Adams]

> Is there any reason why dired-x and/or dired-aux could not be
> integrated with dired proper?  Together they provide a good
> deal of useful functionality, but I was oblivious to their
> existence for quite a long time because their constituent
> functions and variables did not appear among the results of
> my documentation searches.

+1

And we've been around this block before, more than once.

Re: Finding packages to enable by default

[Jambunathan K]

Josh <josh@foxtail.org> writes:

> dired-x and/or dired-aux

> dired-aux

Did you take the survey, btw?  I don't find an entry for dired-aux in
the survey.  May be you should.

If dired-aux is seeded, may be more people may vote for it.

A _good way to think_ about dired-x is this:

   Not all people use dired.  Of those who do, dired-x is invariable on.

ps: dired-x is around 33% of users.

icomplete-mode vs. iswitchb

[Alex Schroeder]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Iswitchb is marked obsolete in the trunk: you can get the same
> functionality with icomplete-mode.

How does one achieve that? When I tried icomplete-mode, I was unable to
figure out how to do that.

(progn
  (iswitchb-mode 0)
  (icomplete-mode 1)
  (get-buffer-create "mytesta")
  (get-buffer-create "mytestb")
  (get-buffer-create "yourtesta")
  (get-buffer-create "yourtestb"))

1. How to pick the first item on the list without typing a lot? I want
   to type a substring RET to pick the most recent buffer. With
   icomplete-mode I type t e s t TAB and get test*. TAB gets me a
   *Completion* buffer at which point I need to read all of them, look
   for the bold characters, pick the right one (a), find the key on the
   keyboard, press that, and even worse, hit C-a and type additional
   characters (my) at the beginingg of the string in order to switch to
   mytesta.

2. How to quickly rotate through the list? I want to type t e s t C-s
   C-s C-s or equivalent to pick the third item on the list. With
   icomplete-mode I feel like trying M-p, M-n, <up>, <down>, <left>,
   <right>...

A generic completion should also sort the entry by "most recently used"
and I'm not sure how icomplete can do this. iswitchb-mode still feels a
lot more useful to me.

I'm back to using iswitchb-mode...

(progn
  (iswitchb-mode 1)
  (icomplete-mode 0))

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

> How does one achieve that? When I tried icomplete-mode, I was unable to
> figure out how to do that.

Which version of Emacs?

> (progn
>   (iswitchb-mode 0)
>   (icomplete-mode 1)
>   (get-buffer-create "mytesta")
>   (get-buffer-create "mytestb")
>   (get-buffer-create "yourtesta")
>   (get-buffer-create "yourtestb"))

> 1. How to pick the first item on the list without typing a lot? I want
>    to type a substring RET to pick the most recent buffer. With
>    icomplete-mode I type t e s t TAB and get test*.

why type TAB?  The list of completions is already displayed in the
minibuffer after typing "t e s t".

> 2. How to quickly rotate through the list? I want to type t e s t C-s

C-. and C-,  (the logic behind those is that , and . are just below <
and > in the US keyboard).

> A generic completion should also sort the entry by "most recently used"
> and I'm not sure how icomplete can do this.

It does sort by "most recently used" based on the history variable,


        Stefan

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

>> 1. How to pick the first item on the list without typing a lot? I want
>> to type a substring RET to pick the most recent buffer. With
>> icomplete-mode I type t e s t TAB and get test*.
> Why type TAB?

Oh, I think I understand.  You should hit C-j to select the
first item.  If you prefer TAB, then do

  (define-key icomplete-minibuffer-map [?\t]
              'minibuffer-force-complete-and-exit)

>> 2. How to quickly rotate through the list? I want to type t e s t C-s
> C-. and C-,  (the logic behind those is that , and . are just below <
> and > in the US keyboard).

Of course, you can also use C-s and C-r with something like:

  (define-key icomplete-minibuffer-map [?\C-s]
              'icomplete-forward-completions)
  (define-key icomplete-minibuffer-map [?\C-r]
              'icomplete-backward-completions)


-- Stefan

Re: icomplete-mode vs. iswitchb

[Alex Schroeder]

Strangely enough the default keybindings you mention (C-j, C-., C-,) are all undefined in my version of Emacs (24.3.1).

-- 
Typed on a tiny keyboard. Sorry for being terse.

On 05.12.2013, at 03:05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>>> 1. How to pick the first item on the list without typing a lot? I want
>>> to type a substring RET to pick the most recent buffer. With
>>> icomplete-mode I type t e s t TAB and get test*.
>> Why type TAB?
> 
> Oh, I think I understand.  You should hit C-j to select the
> first item.  If you prefer TAB, then do
> 
>  (define-key icomplete-minibuffer-map [?\t]
>              'minibuffer-force-complete-and-exit)
> 
>>> 2. How to quickly rotate through the list? I want to type t e s t C-s
>> C-. and C-,  (the logic behind those is that , and . are just below <
>> and > in the US keyboard).
> 
> Of course, you can also use C-s and C-r with something like:
> 
>  (define-key icomplete-minibuffer-map [?\C-s]
>              'icomplete-forward-completions)
>  (define-key icomplete-minibuffer-map [?\C-r]
>              'icomplete-backward-completions)
> 
> 
> -- Stefan
> 

Re: icomplete-mode vs. iswitchb

[Bozhidar Batsov]

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

Seems to me they are defined only on 24.4. iswitchb was marked as obsolete only a few weeks ago. 

-- 
Cheers,
Bozhidar

On December 5, 2013 at 2:46:59 PM, Alex Schroeder (alex@gnu.org) wrote:

Strangely enough the default keybindings you mention (C-j, C-., C-,) are all undefined in my version of Emacs (24.3.1).  

--  
Typed on a tiny keyboard. Sorry for being terse.  

On 05.12.2013, at 03:05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:  

>>> 1. How to pick the first item on the list without typing a lot? I want  
>>> to type a substring RET to pick the most recent buffer. With  
>>> icomplete-mode I type t e s t TAB and get test*.  
>> Why type TAB?  
>  
> Oh, I think I understand. You should hit C-j to select the  
> first item. If you prefer TAB, then do  
>  
> (define-key icomplete-minibuffer-map [?\t]  
> 'minibuffer-force-complete-and-exit)  
>  
>>> 2. How to quickly rotate through the list? I want to type t e s t C-s  
>> C-. and C-, (the logic behind those is that , and . are just below <  
>> and > in the US keyboard).  
>  
> Of course, you can also use C-s and C-r with something like:  
>  
> (define-key icomplete-minibuffer-map [?\C-s]  
> 'icomplete-forward-completions)  
> (define-key icomplete-minibuffer-map [?\C-r]  
> 'icomplete-backward-completions)  
>  
>  
> -- Stefan  
>  


[-- Attachment #2: Type: text/html, Size: 2329 bytes --]

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

> Strangely enough the default keybindings you mention (C-j, C-., C-,) are all
> undefined in my version of Emacs (24.3.1).

Indeed, iswitchb is not obsolete in 24.3, because icomplete-mode in that
version does not provide the corresponding features.


        Stefan

Re: icomplete-mode vs. iswitchb

[Mathias Dahl]

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

Hi,

Since I am a long time iswitchb-mode user I decided to give icomplete-mode
a try for switching buffers.

I tried the following under GNU Emacs 24.3.50.1 (i686-pc-mingw32) of
2013-12-07 on LEG570:

runemacs -Q
C-x C-f foo.el RET
C-x C-f foo.template RET
M-x icomplete-mode RET
C-x b *scratch* RET
C-x b oo

When do this I see this in the minibuffer:

Switch to buffer (default foo.template): oo[.]{template | el}

By using C-j I can switch to a buffer and C-, and C-. cycles between the
matches as described earlier. But the completion hint is totally weird. If
I type just one "o" above, it works as it should.

Is this a bug or the (very strange) intended functionality?

/Mathias



On Thu, Dec 5, 2013 at 7:26 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > Strangely enough the default keybindings you mention (C-j, C-., C-,) are
> all
> > undefined in my version of Emacs (24.3.1).
>
> Indeed, iswitchb is not obsolete in 24.3, because icomplete-mode in that
> version does not provide the corresponding features.
>
>
>         Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 1770 bytes --]

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

> But the completion hint is totally weird.  If I type just one "o"
> above, it works as it should.

I don't see much difference between the "oo" case you've shown and the
"o" case, so I don't see why one "works as it should" while the other
"is totally weird".

Can you explain a bit more?


        Stefan

Re: icomplete-mode vs. iswitchb

[Mathias Dahl]

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

>
> > But the completion hint is totally weird.  If I type just one "o"
> > above, it works as it should.
>
> I don't see much difference between the "oo" case you've shown and the
> "o" case, so I don't see why one "works as it should" while the other
> "is totally weird".
>
> Can you explain a bit more?


You're right, there is no difference. I must have been drunk, or
something... ;)

Still, regardless of I type "o" or "oo", I do not see the full buffer names
in the list of hits. However, if I type "e" instead I see all buffer names
that match "e", including foo.el and foo.template.

Does this scenario work well for you?

/Mathias

[-- Attachment #2: Type: text/html, Size: 1097 bytes --]

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

> Still, regardless of I type "o" or "oo", I do not see the full buffer names
> in the list of hits. However, if I type "e" instead I see all buffer names
> that match "e", including foo.el and foo.template.

Duh!  Right, sorry for missing this obvious part.  Looks like a bug,
indeed.  Could you make it a bug-report, so we get a tracking number
for it?


        Stefan

Re: icomplete-mode vs. iswitchb

[Mathias Dahl]

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

>
> > Still, regardless of I type "o" or "oo", I do not see the full buffer
> names
> > in the list of hits. However, if I type "e" instead I see all buffer
> names
> > that match "e", including foo.el and foo.template.
>
> Duh!  Right, sorry for missing this obvious part.  Looks like a bug,
> indeed.  Could you make it a bug-report, so we get a tracking number
> for it?
>

Done. Bug 16219 created.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16219

/Mathias

[-- Attachment #2: Type: text/html, Size: 968 bytes --]

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

>> Duh!  Right, sorry for missing this obvious part.  Looks like a bug,
>> indeed.  Could you make it a bug-report, so we get a tracking number
>> for it?
> Done. Bug 16219 created.
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16219

Oh well, I fixed it a few days ago already ;-)


        Stefan

Re: icomplete-mode vs. iswitchb

[Mathias Dahl]

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

>
> > Done. Bug 16219 created.
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16219
>
> Oh well, I fixed it a few days ago already ;-)
>

What a lovely Christmas present ;)

/Mathias

[-- Attachment #2: Type: text/html, Size: 560 bytes --]

Re: icomplete-mode vs. iswitchb

[Alex Schroeder]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 1. How to pick the first item on the list without typing a lot? I want
>>    to type a substring RET to pick the most recent buffer. With
>>    icomplete-mode I type t e s t TAB and get test*.
>
> why type TAB?  The list of completions is already displayed in the
> minibuffer after typing "t e s t".
>
>> 2. How to quickly rotate through the list? I want to type t e s t C-s
>
> C-. and C-,  (the logic behind those is that , and . are just below <
> and > in the US keyboard).

Thank you for your suggestions. Perhaps my main problem was that I
didn't see these documented anywhere. I looked at the icomplete-mode
doc-string, the icomplete.el commentary, and the icomplete-completions
doc-string since it was mentioned in the documentary, and I searched the
Emacs manual index for icomplete. I will give it another try.

FWIW, I'm currently using: GNU Emacs 24.3.1 (i686-apple-darwin, NS
apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.org, and some other
GNU Emacs binary built for Windows in the office.

Re: icomplete-mode vs. iswitchb

[Josh]

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

On Wed, Dec 4, 2013 at 5:30 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> C-. and C-,  (the logic behind those is that , and . are just below <
> and > in the US keyboard).
>

These keys do not exist in -nw sessions, and as of revno 115388 I see
no alternative bindings for icomplete-{forward,backward}-completions.

[-- Attachment #2: Type: text/html, Size: 712 bytes --]

Re: icomplete-mode vs. iswitchb

[Stephen Eglen]

> C-. and C-,  (the logic behind those is that , and . are just below <
> and > in the US keyboard).

For iswitchb/ido users, this is not going to be very intuitive -- would
you consider also C-s and C-r for those two rotation commands?  I think
those bindings are more logical, as you are searching forwards (or
backwards) through the completion list.

Also, the logic behind . and , doesn't help those many people not on a US
keyboard!

Stephen

Re: icomplete-mode vs. iswitchb

[Jambunathan K]

Stephen Eglen <S.J.Eglen@damtp.cam.ac.uk> writes:

>> C-. and C-,  (the logic behind those is that , and . are just below <
>> and > in the US keyboard).
>
> For iswitchb/ido users, this is not going to be very intuitive -- would
> you consider also C-s and C-r for those two rotation commands?  I think
> those bindings are more logical, as you are searching forwards (or
> backwards) through the completion list.
>
> Also, the logic behind . and , doesn't help those many people not on a US
> keyboard!

Here is some historical context...

2013-02-15  Jambunathan K  <kjambunathan@gmail.com>

	* iswitchb.el (iswitchb-read-buffer): Bind `C-.' and `C-,' to
	`iswitchb-next-match' and `iswitchb-prev-match' resply.
	* ido.el (ido-init-completion-maps): Bind `C-.' and `C-,' to
	`ido-next-match' and `ido-prev-match' resply.
	* icomplete.el (icomplete-minibuffer-map): Unbind `C-s' and `C-r'.
	Bind `C-.' and `C-,' to `icomplete-forward-completions' and
	`icomplete-backward-completions' (Bug#13708).

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13602        

>
> Stephen

Re: icomplete-mode vs. iswitchb

[Stephen Eglen]

On Sun, Dec 08 2013, Jambunathan K wrote:

> Here is some historical context...

Thanks, I missed this earlier discussoin (was it on emacs-devel as well
as on the debug?)

I take responsibility for picking C-s and C-r (I think it was me,
all those years ago).  I'd like to still keep them, so as long as they
can be added back in with an easy hook, that would be okay.

Stephen

>
> 2013-02-15  Jambunathan K  <kjambunathan@gmail.com>
>
> 	* iswitchb.el (iswitchb-read-buffer): Bind `C-.' and `C-,' to
> 	`iswitchb-next-match' and `iswitchb-prev-match' resply.
> 	* ido.el (ido-init-completion-maps): Bind `C-.' and `C-,' to
> 	`ido-next-match' and `ido-prev-match' resply.
> 	* icomplete.el (icomplete-minibuffer-map): Unbind `C-s' and `C-r'.
> 	Bind `C-.' and `C-,' to `icomplete-forward-completions' and
> 	`icomplete-backward-completions' (Bug#13708).
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13602        
>
>>
>> Stephen

Re: icomplete-mode vs. iswitchb

[Josh]

On Sun, Dec 8, 2013 at 11:05 AM, Stephen Eglen
<S.J.Eglen@damtp.cam.ac.uk> wrote:
>> C-. and C-,  (the logic behind those is that , and . are just below <
>> and > in the US keyboard).
>
> For iswitchb/ido users, this is not going to be very intuitive -- would
> you consider also C-s and C-r for those two rotation commands?  I think
> those bindings are more logical, as you are searching forwards (or
> backwards) through the completion list.
>
> Also, the logic behind . and , doesn't help those many people not on a US
> keyboard!

Furthermore, C-. and C-, are not available in ttys.

More importantly however, icomplete's key bindings would be a moot
point in any rational discussion about iswitchb's successor given
the fact that all of the available evidence indicates that users
prefer ido to icomplete by a wide margin, and that to the best of my
knowledge the _only_ argument that has been put forward in icomplete's
favor is Stefan's presumption that the package preferred by the
majority of users could not be configured to behave like the package
preferred by a far smaller minority.

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

> favor is Stefan's presumption that the package preferred by the
> majority of users could not be configured to behave like the package
> preferred by a far smaller minority.

WTF are you talking about?  IDO is just as available as ever.


        Stefan

Re: icomplete-mode vs. iswitchb

[Josh]

On Tue, Dec 10, 2013 at 8:04 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> favor is Stefan's presumption that the package preferred by the
>> majority of users could not be configured to behave like the package
>> preferred by a far smaller minority.
>
> WTF are you talking about?  IDO is just as available as ever.

Are you being deliberately obtuse or do you read as selectively as you
quote?  You have said that icomplete is to replace iswitchb.  I have
argued that ido would be a more suitable replacement because all of
the available evidence strongly suggests that users prefer ido over
icomplete by a wide margin, not to mention the fact that a substantial
amount of library and user code is built on top of ido.  There is an
ongoing discussion about features that ought to be enabled by default
to improve the experience of new users and this discussion has largely
been based on features' current popularity, about which we now have
good insight thanks to the efforts of those who have extracted that
information from bug reports and who have organized and participated
in the wiki poll.  In this context it seems obvious that such a popular
library as ido should be enabled by default, but instead you have
chosen the polar opposite for ido, to "slowly obsolete" it for reasons
unknown.  Can you seriously not see how this appears irrational?

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

>>> favor is Stefan's presumption that the package preferred by the
>>> majority of users could not be configured to behave like the package
>>> preferred by a far smaller minority.
>> WTF are you talking about?  IDO is just as available as ever.
> Are you being deliberately obtuse or do you read as selectively as you
> quote?  You have said that icomplete is to replace iswitchb.

Which has nothing to do with IDO.

> I have argued that ido would be a more suitable replacement because
> all of the available evidence strongly suggests that users prefer ido
> over icomplete by a wide margin, not to mention the fact that
> a substantial amount of library and user code is built on top of ido.

That's fine, but the reason why we've had iswitchb until now is because
apparently IDO was not a replacement, but rather another feature which
took iswtchb's and then added a host of other things.

And this situation hasn't changed, so no, AFAIK, ido is not
a replacement for iswitchb.

To put it some other way: where were you all in the last 10 years or so
that we've had iswitchb and ido, without complaining that we should mark
iswitchb as obsolete and replace it with ido?

> There is an ongoing discussion about features that ought to be enabled
> by default to improve the experience of new users and this discussion
> has largely been based on features' current popularity, about which we
> now have good insight thanks to the efforts of those who have
> extracted that information from bug reports and who have organized and
> participated in the wiki poll.  In this context it seems obvious that
> such a popular library as ido should be enabled by default, but
> instead you have chosen the polar opposite for ido, to "slowly
> obsolete" it for reasons unknown.  Can you seriously not see how this
> appears irrational?

I already said that enabling IDO by default is not on the table not
because IDO doesn't provide nice features but because:
- it's not a superset of the current completion UI features (it doesn't
  understand all the new completion table features).
- it is not fully "ui compatible", in that several keybindings clash in
  very significant ways with the current completion.
I fully agree that we'd like to make some/many of the features offered
by IDO available by default, but since enabling IDO is not an option,
the second best is to slowly integrate the two, which is not
a small undertaking.


        Stefan

Re: icomplete-mode vs. iswitchb

[Stephen Eglen]

> That's fine, but the reason why we've had iswitchb until now is because
> apparently IDO was not a replacement, but rather another feature which
> took iswtchb's and then added a host of other things.

I disagree -- to most iswitchb/ido users, I am sure they regard ido as a
replacement for iswitchb; as I show below you can easily get iswitchb
behaviour with it.

>
> And this situation hasn't changed, so no, AFAIK, ido is not
> a replacement for iswitchb.
>
> To put it some other way: where were you all in the last 10 years or so
> that we've had iswitchb and ido, without complaining that we should mark
> iswitchb as obsolete and replace it with ido?

Well, I don't recall many  complaints about ido vs iswitchb -- most
people were happy to use one or the other.  Probably more people use
ido, as it offers more features.  But I have just tested this:

(setq ido-mode 'buffer)
(ido-mode 1)

and this is pretty much what iswitchb offers.  There may be some
edge-cases and minor visual differences, but most iswitchb users will
probably cope!  So why not just mark iswitchb as obsolete and recommend
ido for those users?  I have no problem with that.  In fact, I 
suggested (perhaps privately to Kim, author of ido) several years ago we
can do this.  But as iswitchb hasn't need much maintenance (by me) over
the years I've never found sufficient need to merge it.

ido is favoured here:
http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00528.html

And, in the interests of balance, here is RMS's view against making
iswitchb (or ido) on by default:

http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg02058.html

!

Stephen

Re: icomplete-mode vs. iswitchb

[Dmitry Gutov]

Stephen Eglen <S.J.Eglen@damtp.cam.ac.uk> writes:

> Well, I don't recall many  complaints about ido vs iswitchb -- most
> people were happy to use one or the other.  Probably more people use
> ido, as it offers more features.  But I have just tested this:
>
> (setq ido-mode 'buffer)
> (ido-mode 1)

Setting aside the fact that it doesn't do what you intended (ido-mode
ends up set to `both', see this variable's docstring for details), if it
did, the users would end up with less functionality than if they use
icomplete-mode, which provides completion suggestions in all cases where
Emacs knows how to complete - not only buffers, but files, functions,
variables, etc.

If we enable ido-mode for both buffers and files, we:

- Still don't get completions in other cases (though there's a
  third-party package for that, called ido-ubiquitous).
  
- Present users with a somewhat complicated behavior in `find-file'
  case. Off the top of my head, opening a non-existent file with name
  similar to one existing file is non-intuitive: I don't think we want
  to force users to look through documentation for that `C-j' binding.

Re: icomplete-mode vs. iswitchb

[Stephen Eglen]

On Thu, Dec 12 2013, Dmitry Gutov wrote:

> Setting aside the fact that it doesn't do what you intended (ido-mode
> ends up set to `both', see this variable's docstring for details)

Thank you; so I should do:
(ido-mode 'buffers)


I have no opinion (yet) on the merits of icomplete vs iswitchb/ido, as I
have not yet tried icomplete.  All I'm saying is that ido seems a more
natural successor to iswitchb.

S

Re: icomplete-mode vs. iswitchb

[Josh]

On Thu, Dec 12, 2013 at 4:26 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> Stephen Eglen <S.J.Eglen@damtp.cam.ac.uk> writes:
>
>> Well, I don't recall many  complaints about ido vs iswitchb -- most
>> people were happy to use one or the other.  Probably more people use
>> ido, as it offers more features.  But I have just tested this:
>>
>> (setq ido-mode 'buffer)
>> (ido-mode 1)
>
> Setting aside the fact that it doesn't do what you intended (ido-mode
> ends up set to `both', see this variable's docstring for details), if it
> did, the users would end up with less functionality than if they use
> icomplete-mode, which provides completion suggestions in all cases where
> Emacs knows how to complete - not only buffers, but files, functions,
> variables, etc.

I'm afraid I don't understand.  Is the argument that ido is too featureful
for iswitchb users, as Stefan has written[0]:

    We can't tell iswitchb users that ido makes iswitchb obsolete, since ido
    does a lot more and maybe they don't want all that extra functionality
    (and I'm not sure to what extend ido can be configured to behave like
    iswitchb does).
    I assume that if they're still using iswitchb by now, it's because they
    indeed don't want ido.

or that Stephen's configuration snippet makes ido less featureful
than icomplete, the package to which iswitchb users are being
forcibly migrated, as you wrote above?  If there is some coherent
articulable standard being applied that is consistent with both of
these arguments I don't see it.  Why is uncertainty about whether ido
could be configured to behave like iswitchb sufficient to disqualify
ido out of hand without even the pretense of investigating, whereas
given similar uncertainty about whether icomplete could be so
configured the assumption is "it should be possible to configure
icomplete-mode's behavior to be pretty close to iswitchb-mode"[1]?

[0] http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00545.html
[1] http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00529.html

Re: icomplete-mode vs. iswitchb

[chad]

On 12 Dec 2013, at 04:26, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> - Present users with a somewhat complicated behavior in `find-file'
>  case. Off the top of my head, opening a non-existent file with name
>  similar to one existing file is non-intuitive: I don't think we want
>  to force users to look through documentation for that `C-j' binding.

My experience matches this; I've seen multiple people quit using
ido because of this exact behavior (find-file'ing a new file), and
also because of how it opens directories in find-file (i.e. it
doesn't). I believe they ~all liked icomplete.

I would guess that an ido that didn't do this by default is probably
a more attractive default.

I get that many people prefer ido to iswitchb, and I think it'd be
great if emacs provided completion by default. I wonder if any of
the ido fans have tried icomplete? I believe that Stefan's long
term suggestion is that features merge from icomplete, ido, and
emacs' default completion (perhaps stopping by helm and anything
along the way?). Some people seem to be afraid that ido will be
somehow excised, which I don't think is going to happen.

I hope that helps,
~Chad

Re: icomplete-mode vs. iswitchb

[Dmitry Gutov]

chad <chadpbrown@gmail.com> writes:

> My experience matches this; I've seen multiple people quit using
> ido because of this exact behavior (find-file'ing a new file), and
> also because of how it opens directories in find-file (i.e. it
> doesn't). I believe they ~all liked icomplete.
>
> I would guess that an ido that didn't do this by default is probably
> a more attractive default.

Probably, yes. But that would be a fairly different mode of operation,
doing basically what icomplete does.

> I get that many people prefer ido to iswitchb, and I think it'd be
> great if emacs provided completion by default. I wonder if any of
> the ido fans have tried icomplete?

icomplete is less obtrusive, but ido is definitely more efficient, with
its non-prefix and flex matching.

And, in order to not have to bother with C-j for items not present in
the existing set, with icomplete you always have type or press Tab to
get to the desired item, maybe several times, even if the item is the
first in the list.

Thus, for switching buffers, icomplete is less efficient than both ido
and iswitchb.

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

> icomplete is less obtrusive, but ido is definitely more efficient, with
> its non-prefix and flex matching.

icomplete uses completion-styles, so it also has substring matching.
Currently, noone has ported ido's flex matching to completion-styles,
tho, indeed.

> And, in order to not have to bother with C-j for items not present in
> the existing set, with icomplete you always have type or press Tab to
> get to the desired item, maybe several times, even if the item is the
> first in the list.

icomplete-mode now has C-j to "select the first element", so you don't
need to press TAB or type anything to get to it.


        Stefan

Re: icomplete-mode vs. iswitchb

[Dmitry Gutov]

On 13.12.2013 04:56, Stefan Monnier wrote:
>> icomplete is less obtrusive, but ido is definitely more efficient, with
>> its non-prefix and flex matching.
>
> icomplete uses completion-styles, so it also has substring matching.
> Currently, noone has ported ido's flex matching to completion-styles,
> tho, indeed.
>
>> And, in order to not have to bother with C-j for items not present in
>> the existing set, with icomplete you always have type or press Tab to
>> get to the desired item, maybe several times, even if the item is the
>> first in the list.
>
> icomplete-mode now has C-j to "select the first element", so you don't
> need to press TAB or type anything to get to it.

Huh, I didn't know that. Thanks for the clarifications.

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

>> Well, I don't recall many complaints about ido vs iswitchb -- most
>> people were happy to use one or the other.  Probably more people use
>> ido, as it offers more features.

That's still not very relevant: those who like ido can (and should) use ido.

>> But I have just tested this:
>> (setq ido-mode 'buffer)
>> (ido-mode 1)

Seems to do more than iswitchb: it also change C-x C-f.

> did, the users would end up with less functionality than if they use
> icomplete-mode, which provides completion suggestions in all cases where
> Emacs knows how to complete - not only buffers, but files, functions,
> variables, etc.

Actually, that's a point *against* icomplete-mode, when taken as
a replacement for iswitchb.

I think I'm beginning to understand the emotional response, tho: people
seem to think that putting icomplete-mode in the obsolete data is a kind
of *recommendation*, which is not the intention.

I'll just add ido-mode in there as well, which I hope will stop the
religious hysteria.


        Stefan

Re: icomplete-mode vs. iswitchb

[Stephen Eglen]

On Thu, Dec 12 2013, Stefan Monnier wrote:

>>> But I have just tested this:
>>> (setq ido-mode 'buffer)
>>> (ido-mode 1)
>
> Seems to do more than iswitchb: it also change C-x C-f.

yes, sorry that was my mistake; but
   (ido-mode 'buffers)
is a drop-in replacement for iswitchb from what I can see and does not
hijack find-file.

> I think I'm beginning to understand the emotional response, tho: people
> seem to think that putting icomplete-mode in the obsolete data is a kind
> of *recommendation*, which is not the intention.
>
> I'll just add ido-mode in there as well, which I hope will stop the
> religious hysteria.

Yes, all that's needed (from my viewpoint) is to note that "(ido-mode
'buffers)" will mean iswitchb users will not see any significant
changes.  If they want to try out icomplete, fine (and I will try it out
myself!).

Stephen

Re: icomplete-mode vs. iswitchb

[Josh]

On Thu, Dec 12, 2013 at 10:20 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> I'll just add ido-mode in there as well, which I hope will stop the
> religious hysteria.

If you're at all prone to introspection, you might ponder why the
reasoned arguments backed by evidence that I have put forward
strike you as "religious hysteria."

Re: icomplete-mode vs. iswitchb

[Josh]

On Wed, Dec 11, 2013 at 7:33 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> To put it some other way: where were you all in the last 10 years or so
> that we've had iswitchb and ido, without complaining that we should mark
> iswitchb as obsolete and replace it with ido?

I have been happily using ido.  I already told you that I know others
who have been happily using iswitchb.  Why should I complain and
agitate to get something that my friends like obsoleted?

>> There is an ongoing discussion about features that ought to be enabled
>> by default to improve the experience of new users and this discussion
>> has largely been based on features' current popularity, about which we
>> now have good insight thanks to the efforts of those who have
>> extracted that information from bug reports and who have organized and
>> participated in the wiki poll.  In this context it seems obvious that
>> such a popular library as ido should be enabled by default, but
>> instead you have chosen the polar opposite for ido, to "slowly
>> obsolete" it for reasons unknown.  Can you seriously not see how this
>> appears irrational?
>
> I already said that enabling IDO by default is not on the table not
> because IDO doesn't provide nice features but because:
> - it's not a superset of the current completion UI features (it doesn't
>   understand all the new completion table features).

Actually enumerating the ways in which it falls short would help
interested people understand the scope of the problem and perhaps
take on adding support for those features.

> - it is not fully "ui compatible", in that several keybindings clash in
>   very significant ways with the current completion.

I suppose you're talking about C-s and C-r here; are there others?
In any case, such bindings could be trivially changed to adhere to
the current completion key binding conventions and then exposing a
simple disabled-by-default "classic ido key bindings" customization
to retain the existing UI for those of us who prefer it.

The most frequent complaint I hear about ido is the one Dmitry
mentioned about C-j for finding new files; I agree that this behavior
is non-intuitive and undesirable for new users, but it seems likely
that we could work out a more intuitive default interface and make
the current behavior opt-in for experienced ido users.

> I fully agree that we'd like to make some/many of the features offered
> by IDO available by default,

As I have pointed out, there is quite a bit of library and user code
built on top of ido, i.e. depending on its current interfaces and
behavior, so "offering the features" is not sufficient to avoid
breaking that code.

> but since enabling IDO is not an option,
> the second best is to slowly integrate the two, which is not
> a small undertaking.

Would it be an option if support were added for the current
completion UI features you mentioned and the key bindings were
harmonized with current completion key binding conventions?  If
so, will you please enumerate the missing features?  If not, what
else stands in the way?

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

>> Also, the logic behind . and , doesn't help those many people not on a US
>> keyboard!
> Furthermore, C-. and C-, are not available in ttys.

Indeed, I'm not very happy with `C-.' and `C-,'.  I'm very open to
suggestions (but of course, please take into account the previous
discussion that lead to choosing those key-bindings).


        Stefan

Re: icomplete-mode vs. iswitchb

[Stephen Eglen]

On Wed, Dec 04 2013, Alex Schroeder wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Iswitchb is marked obsolete in the trunk: you can get the same
>> functionality with icomplete-mode.

As the author of iswitchb, I was slightly surprised to see this, but
only because I was expecting (or hoping) that it would be superseded by
ido.el!  Is ido.el also marked as obsolete?

Stephen

Re: icomplete-mode vs. iswitchb

[Stefan Monnier]

> As the author of iswitchb, I was slightly surprised to see this, but
> only because I was expecting (or hoping) that it would be superseded by
> ido.el!

No, ido is a superset of iswitchb, but AFAICT there's no way to
customize ido such that it works like iswitchb.

> Is ido.el also marked as obsolete?

No.


        Stefan

Re: icomplete-mode vs. iswitchb

[Josh]

On Fri, Dec 6, 2013 at 9:39 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
SM> SE> As the author of iswitchb, I was slightly surprised to see this, but
SM> SE> only because I was expecting (or hoping) that it would be superseded by
SM> SE> ido.el!

As was I, and I pressed the point[0] until it became clear to me that
Stefan had already made up his mind.

SM> No, ido is a superset of iswitchb, but AFAICT there's no way to
SM> customize ido such that it works like iswitchb.

This seems like a decision that merits more investigation than "AFAICT".

SM> SE> Is ido.el also marked as obsolete?
SM> No.

Well... not yet; see below.  The subject of ido came up again a couple
of weeks later in the "Finding packages to enable by default" thread[1]:

SM> Tom> I did some manual filtering as a test and here are some of
the top packages
SM> Tom> which remained:
SM> Tom> (ido . 137)
    [12 features omitted]
SM> Tom> (iswitchb . 46)
    [ 2 features omitted]
SM> Tom> (icomplete . 34)
SM> Tom> (winner . 34)
    [...]
SM> Tom> Ido is at the top (iswitchb is also here) and ido/isiwtchb would really
SM> Tom> make a much better first impression for new users than the default
SM> Tom> very barebone buffer switching.
SM>
SM> Iswitchb is marked obsolete in the trunk: you can get the same
SM> functionality with icomplete-mode.  So you can increase the count of
SM> `icomplete-mode' for all users who have enabled iswitchb without
SM> enabling icomplete-mode.

Ido's count of 137 is still far greater than the combined count of 80
for icomplete and iswitchb, even leaving aside the tenuous assumption
that 100% of iswitchb users would make an informed choice in
icomplete's favor.

As mentioned, here's the bit about ido's obsolescence:

SM> The plan for "ido by default" is rather to slowly make ido obsolete by
SM> adding the corresponding functionality either in the default completion
SM> UI or in icomplete-mode.
SM> An alternative is to try and re-implement it on top of the current
SM> completion UI.  To a large extent, it boils down to the same.

There's a lot of user code and many libraries built on top of ido.  If it's
obsoleted down the line I hope there is an effort to preserve the
current interfaces and behavior to minimize breakage.  Is that the plan?

[0] http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00507.html
[1] http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00103.html

jlf

Re: icomplete-mode vs. iswitchb

[Stephen Eglen]

On Fri, Dec 06 2013, Josh wrote:

> As was I, and I pressed the point[0] until it became clear to me that
> Stefan had already made up his mind.

THanks for that link Josh, I had missed that thread.

> SM> No, ido is a superset of iswitchb, but AFAICT there's no way to
> SM> customize ido such that it works like iswitchb.
>
> This seems like a decision that merits more investigation than
> "AFAICT".

I agree.  I am copying Kim on this thread, as Kim might be better
placed to answer that.  My reading of the docstring for ido-mode would
suggest that setting it to 'buffer would mean it works like iswitchb.

> SM> The plan for "ido by default" is rather to slowly make ido obsolete by
> SM> adding the corresponding functionality either in the default completion
> SM> UI or in icomplete-mode.
> SM> An alternative is to try and re-implement it on top of the current
> SM> completion UI.  To a large extent, it boils down to the same.

there's a fair bit of logic in iswitchb (and ido) to work with specifics
of buffer switching (e.g. whether to show it in same window/other
window, new frame).  Is that in icomplete.el?  Likewise, little niceties
like deleting buffers (with C-k).

>
> There's a lot of user code and many libraries built on top of ido.  If it's
> obsoleted down the line I hope there is an effort to preserve the
> current interfaces and behavior to minimize breakage.  Is that the
> plan?

Yes, that's my hope too -- we use 'ido' extensively now in ESS for one.

What is the best way for me to test the iswitchb-like behaviour with
icomplete?

Stephen


> [0] http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00507.html
> [1] http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00103.html

Re: Finding packages to enable by default

[Tom]

Glenn Morris <rgm <at> gnu.org> writes:
> 
> Why don't you invite people to send that information to you,
> since this was your idea, then you can summarize the results for us in a
> month or so?
> 

Because I'd rather see some automated way of collecting data,
than having to manually assemble hundreds (thousands?)
of such reports.

Re: Finding packages to enable by default

[Glenn Morris]

Tom wrote:

> Glenn Morris <rgm <at> gnu.org> writes:
>> 
>> Why don't you invite people to send that information to you, since
>> this was your idea, then you can summarize the results for us in a
>> month or so?
>> 
> Because I'd rather see some automated way of collecting data, than
> having to manually assemble hundreds (thousands?) of such reports.

The necessary automation is just filtering and parsing of emails, which
anyone can do who is willing to put in the effort. debbugs.gnu.org has
no ability to do this for you.

(The actual real work will come after that, and will likely be substantial.)

Re: Finding packages to enable by default

[Tom]

Glenn Morris <rgm <at> gnu.org> writes:

> 
> The necessary automation is just filtering and parsing of emails, which
> anyone can do who is willing to put in the effort. debbugs.gnu.org has
> no ability to do this for you.
> 

I found an easy way to collect the data without any coding effort. 
Google Docs provides web forms which can be created with a few clicks
and then can be put on the web. Users can submit their features in
the form, the submitted data is collected automatically in a spreadsheet
and then can be downloaded in different formats (CSV, etc.)

Re: Finding packages to enable by default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Using Google Docs requires running nonfree software.
(It is Javascript software that comes in the web pages.)
That is an unethical system.

We must not ask people to use Google Docs.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Finding packages to enable by default

[Tom]

Richard Stallman <rms <at> gnu.org> writes:

> 
> Using Google Docs requires running nonfree software.
> (It is Javascript software that comes in the web pages.)
> That is an unethical system.
> 
> We must not ask people to use Google Docs.
> 

People don't have to use Google Docs. The web form is a regular HTML
form which works without Javascript, so users can submit their data
without JS and no login is required either to submit the form.

I have to use Google web services for my work anyway, so I can export
the data as text from the spreadsheet when enough data is received and
then make the resulting CSV file available somewhere.

Re: Finding packages to enable by default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    People don't have to use Google Docs. The web form is a regular HTML
    form which works without Javascript, so users can submit their data
    without JS and no login is required either to submit the form.

This is ok to ask people to use.

    I have to use Google web services for my work anyway, so I can export
    the data as text from the spreadsheet when enough data is received and
    then make the resulting CSV file available somewhere.

It still bothers me in spirit, but I won't argue against it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Finding packages to enable by default

[Josh]

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

On Fri, Nov 29, 2013 at 1:01 PM, Tom <adatgyujto@gmail.com> wrote:

> We are only interested in packages which are shipped with emacs,
> so we should query only those.


On the contrary, those packages which are widely adopted by users
despite not being shipped with Emacs are of the _greatest_ interest,
by virtue of the fact that large numbers of users have decided that
the functionality they provide is important enough to warrant making
the effort to install them from ELPA or Marmalade or Github or
wherever else.  The popularity of third-party libraries such as
dash.el ("a modern list library for Emacs")[0] and s.el ("the long
lost Emacs string manipulation library")[1] demonstrates that many
users find Emacs' support for such functionality inadequate and
points out an obvious opportunity for improvement by addressing
those weaknesses in Emacs proper.

[0] https://github.com/magnars/dash.el
[1] https://github.com/magnars/s.el

Josh

[-- Attachment #2: Type: text/html, Size: 1641 bytes --]

Re: Finding packages to enable by default

[Jambunathan K]

Josh <josh@foxtail.org> writes:

> the _greatest_ interest

If this indeed deeply felt, I suggest that people put it write in GNU
Emacs or Gnu Elpa.  We don't need lots of clearing houses of useful
libraries.  A single clearing house should suffice.

A simple (casual) remark:

1. Put in GNU ELPA.
2. Accept contributions only from Assigned or Disclaiming parties

will do great good.

This remark may or may not work.  Atleast it will be heard.

Re: Finding packages to enable by default

[Alex Schroeder]

Tom <adatgyujto <at> gmail.com> writes:

> [...] the results can be summarized and those of these packages
> which are enabled by, say, 75% of the users, should be enabled by
> default in emacs.

The Survey on Emacs Wiki has reached close to 100 people.
When will we close it? There's no point in letting it run
for too long, I think.

Re: Finding packages to enable by default

[Alex Schroeder]

Alex Schroeder <alex <at> gnu.org> writes:

> 
> Tom <adatgyujto <at> gmail.com> writes:
> 
> > [...] the results can be summarized and those of these packages
> > which are enabled by, say, 75% of the users, should be enabled by
> > default in emacs.
> 
> The Survey on Emacs Wiki has reached close to 100 people.
> When will we close it? There's no point in letting it run
> for too long, I think.

I keep wondering: When is the survey on the wiki going to be stopped? We now
have 119 people more or less that answered it. 	Is Jambunathan going to
close it and report the results?

I guess I have a vague fear of there being no point: people keep adding
their votes, but it never gets reported back to emacs-devel, nobody uses it
to argue in favor of enabling a particular package by default, and so on. If
the entire discussion and the survey will only result in column-number-mode
being enabled by default, I'll be disappointed.

Re: Finding packages to enable by default

[Jambunathan K]

> I keep wondering: When is the survey on the wiki going to be stopped?

It will stop on it's own.

> If the entire discussion and the survey will only result in
> column-number-mode being enabled by default

There were bug reports, discussions and improvements surrounding the top
few packages.

Just to keep you happy here is the table.

Alex Schroeder <alex@gnu.org> writes:

For ease of interpretation, Horizontal rules are drawn at 62%, 50%, 37%,
25% and 12% levels (i.e., in steps of 1/8)

#+CONSTANTS: N=120
| Packages/Modes                                   | % Users |
|--------------------------------------------------+---------|
| column-number-mode                               |      70 |
|--------------------------------------------------+---------|
| uniquify                                         |      69 |
| show-paren-mode                                  |      65 |
|--------------------------------------------------+---------|
| ido-mode                                         |      60 |
| transient-mark-mode                              |      51 |
|--------------------------------------------------+---------|
| ibuffer                                          |      45 |
| recentf-mode                                     |      43 |
| blink-cursor-mode                                |      41 |
| flyspell-mode                                    |      41 |
| font-lock-mode                                   |      38 |
|--------------------------------------------------+---------|
| eldoc-mode                                       |      36 |
| org-mode                                         |      36 |
| global-font-lock-mode                            |      35 |
| line-number-mode                                 |      35 |
| winner-mode                                      |      35 |
| dired-x                                          |      33 |
| ido-everywhere                                   |      31 |
| auto-fill-mode                                   |      30 |
| abbrev-mode                                      |      30 |
| windmove                                         |      30 |
| delete-selection-mode                            |      25 |
|--------------------------------------------------+---------|
| saveplace                                        |      23 |
| desktop-save-mode                                |      22 |
| display-time-mode                                |      21 |
| server-mode                                      |      21 |
| which-function-mode                              |      20 |
| hippie-exp                                       |      18 |
| savehist-mode                                    |      18 |
| imenu                                            |      17 |
| tramp                                            |      17 |
| global-subword-mode                              |      16 |
| org-capture                                      |      16 |
| auto-encryption-mode                             |      15 |
| tooltip-mode                                     |      15 |
| icomplete-mode                                   |      14 |
| ffap                                             |      13 |
| size-indication-mode                             |      13 |
| cua-selection-mode                               |      12 |
| dired-hide-details-mode                          |      12 |
| file-name-shadow-mode                            |      12 |
| mouse-wheel-mode                                 |      12 |
| visual-line-mode                                 |      12 |
|--------------------------------------------------+---------|
| auto-compression-mode                            |      11 |
| global-hl-line-mode                              |      11 |
| subword-mode                                     |      11 |
| linum-mode                                       |      10 |
| visible-bell                                     |      10 |
| auto-composition-mode                            |      10 |
| cua-mode                                         |      10 |
| electric-indent-mode                             |      10 |
| hs-minor-mode                                    |      10 |
| kill-whole-line                                  |      10 |
| global-auto-revert-mode                          |       9 |
| global-linum-mode                                |       9 |
| reftex-mode                                      |       9 |
| compilation-minor-mode                           |       8 |
| electric-pair-mode                               |       8 |
| ispell-minor-mode                                |       8 |
| global-whitespace-mode                           |       7 |
| cl                                               |       6 |
| iswitchb-mode                                    |       6 |
| org-src-mode                                     |       6 |
| shell-dirtrack-mode                              |       6 |
| edebug-mode                                      |       5 |
| whitespace-mode                                  |       5 |
| orgtbl-mode                                      |       5 |
| printing                                         |       5 |
| rectangle-mark-mode                              |       5 |
| delete-by-moving-to-trash                        |       4 |
| erc-mode                                         |       4 |
| global-cwarn-mode                                |       4 |
| global-hi-lock-mode                              |       4 |
| hide-ifdef-mode                                  |       4 |
| mouse-avoidance-mode                             |       4 |
| auto-completion-mode                             |       3 |
| autoinsert                                       |       3 |
| bs-show                                          |       3 |
| semantic-mode                                    |       3 |
| auto-image-file-mode                             |       2 |
| electric-layout-mode                             |       2 |
| epa-file-enable                                  |       2 |
| generic-x                                        |       2 |
| global-visual-line-mode                          |       2 |
| descr-text                                       |       1 |
| orgstruct++-mode                                 |       1 |
| outline-minor-mode                               |       1 |
| advice                                           |       0 |
| ange-ftp                                         |       0 |
| ansi-color                                       |       0 |
| apropos                                          |       0 |
| bookmark                                         |       0 |
| buffer-menu-mode                                 |       0 |
| buff-menu                                        |       0 |
| bytecomp                                         |       0 |
| byte-opt                                         |       0 |
| color                                            |       0 |
| comint                                           |       0 |
| compile                                          |       0 |
| cus-edit                                         |       0 |
| cus-theme                                        |       0 |
| debug                                            |       0 |
| delsel                                           |       0 |
| desktop                                          |       0 |
| diff-mode                                        |       0 |
| dired-aux                                        |       0 |
| display-battery-mode                             |       0 |
| easymenu                                         |       0 |
| easy-mmode                                       |       0 |
| ede-minor-mode                                   |       0 |
| ediff                                            |       0 |
| edmacro                                          |       0 |
| emacs-lisp-mode                                  |       0 |
| facemenu                                         |       0 |
| face-remap                                       |       0 |
| faces                                            |       0 |
| files                                            |       0 |
| finder                                           |       0 |
| find-func                                        |       0 |
| frame                                            |       0 |
| frameset                                         |       0 |
| global-ede-mode                                  |       0 |
| global-semantic-decoration-mode                  |       0 |
| global-semantic-highlight-func-mode              |       0 |
| global-semantic-idle-completions-mode            |       0 |
| global-semantic-idle-local-symbol-highlight-mode |       0 |
| global-semantic-idle-scheduler-mode              |       0 |
| global-semantic-idle-summary-mode                |       0 |
| global-semantic-mru-bookmark-mode                |       0 |
| global-semantic-stickyfunc-mode                  |       0 |
| global-semanticdb-minor-mode                     |       0 |
| grep                                             |       0 |
| help                                             |       0 |
| help-fns                                         |       0 |
| help-mode                                        |       0 |
| hl-line                                          |       0 |
| image                                            |       0 |
| image-dired                                      |       0 |
| image-file                                       |       0 |
| info-mode                                        |       0 |
| isearch                                          |       0 |
| iso-transl                                       |       0 |
| kmacro                                           |       0 |
| lisp-mnt                                         |       0 |
| lisp-mode                                        |       0 |
| lpr                                              |       0 |
| ls-lisp                                          |       0 |
| menu-bar                                         |       0 |
| menu-bar-mode                                    |       0 |
| minibuffer-depth-indicate-mode                   |       0 |
| misearch                                         |       0 |
| mouse                                            |       0 |
| mwheel                                           |       0 |
| newcomment                                       |       0 |
| outline                                          |       0 |
| package                                          |       0 |
| page                                             |       0 |
| paren                                            |       0 |
| pc-selection-mode                                |       0 |
| pp                                               |       0 |
| ps-print                                         |       0 |
| regexp-opt                                       |       0 |
| register                                         |       0 |
| replace                                          |       0 |
| ring                                             |       0 |
| shadow                                           |       0 |
| shell                                            |       0 |
| simple                                           |       0 |
| thingatpt                                        |       0 |
| time-date                                        |       0 |
| timer                                            |       0 |
| tool-bar                                         |       0 |
| tramp-ftp                                        |       0 |
| url-handler-mode                                 |       0 |
| url-parse                                        |       0 |
| url-vars                                         |       0 |
| view-mode                                        |       0 |
| wid-edit                                         |       0 |
| window                                           |       0 |
#+TBLFM: $2= 100.0 * $INVALID/ $N; %d;

Re: Finding packages to enable by default

[Stefan Monnier]

> Just to keep you happy here is the table.

I edited the table to remove the modes that are already enabled by
default in 24.4 (as well as removing the major modes which aren't
really applicable to this discussion anyway).

> | column-number-mode                               |      70 |

Since it's so popular, I think it makes sense to enable it by default.

> | show-paren-mode                                  |      65 |

In 24.4, we changed the blink-open-paren feature so it doesn't move the
cursor but instead highlights the open-paren with the same face as
show-paren-mode, so it brings the default a bit closer to show-paren-mode.

But given the popularity, we could consider enabling it by default.

> | ido-mode                                         |      60 |

I like several of IDO's features, but we can't just enable it by default
for various reasons:
- it does not support completion-styles.
- some use cases are very poorly supported (handled by escaping back to
  the "old" completion mechanism), which means that the UI ends up too
  complex for a default setting.
I don't see how to solve the first problem without spending serious
efforts re-writing important parts of ido.el.  And the second will/would
require changing the UI in ways which might not please IDO users (for
whom the extra UI complexity is a good tradeoff).

So as explained elsewhere already I think the way to move forward on
this front is by adding IDO-ish features to the default completion code.
`icomplete-mode' is one such feature and in 24.4 it has been extended to
get closer.
So if you use IDO, please try icomplete-mode instead (and add
`substring' to the `completion-styles').  If you then miss an IDO
feature, please M-x report-emacs-bug (and ideally provide a patch that
implements the feature).

> | ibuffer                                          |      45 |

I have the impression that it was decided at some point that the default
buffer-list be switched to Ibuffer.  I must have dreamt it, tho.
In any case, we can't perform such a switch right now, because Ibuffer
does not offer all the features of list-buffers.  The most glaring is
the header-line.
If someone could try and bring Ibuffer's default behavior closer to
list-buffers, then I think we could switch.

> | recentf-mode                                     |      43 |

I don't see any reason not to enable this by default.

> | flyspell-mode                                    |      41 |

I'd be happy to enable this by default, but we currently don't have
a `global-flyspell-mode', so we need someone to write one for us.
Such a global mode should be careful to only enable flyspell where it
"makes sense".  E.g. I think that by default in prog-mode buffers, only
strings and comments should be flyspell'd.

> | eldoc-mode                                       |      36 |

This is my pet missing feature when I run "emacs -Q", so yes, I want
this enabled by default.  Here also, tho, we first need
a global-eldoc-mode.

> | winner-mode                                      |      35 |

If we can come up with good keybindings, then we can indeed enable it
by default.

> | dired-x                                          |      33 |

Fine by me.

> | ido-everywhere                                   |      31 |

Hmm... the IDO discussion above was actually talking about
ido-everywhere.  I don't really like the idea of using completely
different completion UIs for files&buffers.

> | auto-fill-mode                                   |      30 |

In which modes?

> | abbrev-mode                                      |      30 |

Not sure what I think about this one.

> | windmove                                         |      30 |

I like this as well.  I'm a little worried about occupying the
S-<left/right/up/down> bindings, tho: it's pretty easy to keep the shift
modifier pressed inadvertently.

> | delete-selection-mode                            |      25 |

We've been getting closer to this one over time, so we may get there at
some point.  I'm not completely sure we're ready for it yet.  But in any
case, I don't like the current implementation, so before we can switch
someone will have to re-implement it along the same lines as what was
done for the shift-select-mode, i.e. have the affected command call the
delete-selection code themselves, rather than use a pre-command-hook.

If you look at delsel.el, you'll see that few commands are affected, and
changing self-insert-command would be sufficient to cover a few of the
other ones as well, so the changes should really be pretty small.

I think I'll stop here for now,


        Stefan

RE: Finding packages to enable by default

[Drew Adams]

FWIW -

> > | abbrev-mode                                      |      30 |
> > | auto-fill-mode                                   |      30 |
> > | column-number-mode                               |      70 |
> > | delete-selection-mode                            |      25 |
> > | dired-x                                          |      33 |
> > | eldoc-mode                                       |      36 |
> > | flyspell-mode                                    |      41 |
> > | show-paren-mode                                  |      65 |
> > | ibuffer                                          |      45 |
> > | ido-everywhere                                   |      31 |
> > | ido-mode                                         |      60 |
> > | recentf-mode                                     |      43 |
> > | windmove                                         |      30 |
> > | winner-mode                                      |      35 |

> I edited the table to remove the modes that are already enabled by
> default in 24.4 (as well as removing the major modes which aren't
> really applicable to this discussion anyway).

You edited the table where?  The table is on Emacs Wiki:
http://www.emacswiki.org/emacs/FrequentlyEnabledPackages_Emacs244_Survey
It was last updated yesteday by Brian Kavanagh.  140 users have now
recorded their use data there.  The figures you cite are apparently
from Jambuhathan's mail of 2013-12-17 (when 120 users were reported).

For the same libraries you cite, for example, the wiki page now shows:

| abbrev-mode                                         |      41 |
| auto-fill-mode                                      |      44 |
| column-number-mode                                  |      92 |
| delete-selection-mode                               |      33 |
| dired-x                                             |      47 |
| eldoc-mode                                          |      52 |
| flyspell-mode                                       |      56 |
| show-paren-mode                                     |      87 |
| ibuffer                                             |      61 |
| ido-everywhere                                      |      45 |
| ido-mode                                            |      84 |
| recentf-mode                                        |      59 |
| windmove                                            |      39 |
| winner-mode                                         |       8 |

(I have no explanation for why or how winner-mode went down.  I
suspect that someone introduced a typo when editing it, but that
part of the history is not available AFAIK.  I and others have been
keeping an eye out for mistakes, but this checking was done manually,
and was clearly error-prone.)

[delete-selection-mode]
> We've been getting closer to this one over time, so we may get there at
> some point.  I'm not completely sure we're ready for it yet.  But in any
> case, I don't like the current implementation, so before we can switch
> someone will have to re-implement it along the same lines as what was
> done for the shift-select-mode, i.e. have the affected command call the
> delete-selection code themselves, rather than use a pre-command-hook.

Please write a new library for that (like you did for linum.el etc.).
Please leave the design of delsel.el and `delete-selection-mode' alone.

> If you look at delsel.el, you'll see that few commands are affected,
> and changing self-insert-command would be sufficient to cover a few
> of the other ones as well, so the changes should really be pretty small.

Each time this has been talked about, the interface for programmers
of what you have proposed has not been at all like that of delsel.el,
which is simple to use and flexible: just set a property on a command.

I know the downside to that design (your objections), but I also
appreciate the upside (just mentioned).  I hope you will not simply
jettison the longstanding design for something less lispy.

Or rather, that would be welcome, as long as it is a separate (new)
library.  I don't even mind if you deprecate the old design (i.e.,
delsel.el) as far as GNU Emacs is concerned, as long as users can
still find and use it.

I would object to its wholesale replacement by another design under
the same names: delsel.el and `delete-selection-mode'.  Instead,
please do what you did for nlinum.el vs linum.el and your new advice
thingy vs defadvice, if you want to try a new design.

Just one opinion.

Re: Finding packages to enable by default

[Daimrod]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> | flyspell-mode                                    |      41 |
>
> I'd be happy to enable this by default, but we currently don't have
> a `global-flyspell-mode', so we need someone to write one for us.
> Such a global mode should be careful to only enable flyspell where it
> "makes sense".  E.g. I think that by default in prog-mode buffers, only
> strings and comments should be flyspell'd.

Couldn't we just use regular hooks instead of a global mode?
(add-hook 'text-mode-hook 'flyspell-mode)
(add-hook 'prog-mode-hook 'flyspell-prog-mode)


Best,
-- 
Daimrod/Greg

Re: Finding packages to enable by default

[Teemu Likonen]

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

Stefan Monnier [2014-06-19 11:26:40 -04:00] wrote:

>> | flyspell-mode                                    |      41 |
>
> I'd be happy to enable this by default, but we currently don't have a
> `global-flyspell-mode', so we need someone to write one for us. Such a
> global mode should be careful to only enable flyspell where it "makes
> sense". E.g. I think that by default in prog-mode buffers, only
> strings and comments should be flyspell'd.

Please, no. I think flyspell is too intrusive to be enabled by default.
People can easily write a couple of hooks to turn it on where it makes
sense to _them_. I never use flyspell-mode. I wrote wcheck-mode[1]
because I wanted faster and more configurable checker. Ispell-based
checkers are not enough. But I wouldn't suggest that wcheck-mode should
be enabled by default.

--------------------
1. https://github.com/tlikonen/wcheck-mode

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: Finding packages to enable by default

[Thorsten Jolitz]

Teemu Likonen <tlikonen@iki.fi> writes:

> Stefan Monnier [2014-06-19 11:26:40 -04:00] wrote:
>
>>> | flyspell-mode                                    |      41 |
>>
>> I'd be happy to enable this by default, but we currently don't have a
>> `global-flyspell-mode', so we need someone to write one for us. Such a
>> global mode should be careful to only enable flyspell where it "makes
>> sense". E.g. I think that by default in prog-mode buffers, only
>> strings and comments should be flyspell'd.
>
> Please, no. I think flyspell is too intrusive to be enabled by
> default.

1+ 

-- 
cheers,
Thorsten

Re: Finding packages to enable by default

[Stefan Monnier]

> Please, no. I think flyspell is too intrusive to be enabled by default.

Maybe that's something we should fix, then.  But nowadays I consider it
"standard" to do basic spell-checking on-the-fly, in any "text editing
area".


        Stefan

Re: Finding packages to enable by default

[Teemu Likonen]

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

Stefan Monnier [2014-06-20 08:56:36 -04:00] wrote:

>> Please, no. I think flyspell is too intrusive to be enabled by
>> default.
>
> Maybe that's something we should fix, then. But nowadays I consider it
> "standard" to do basic spell-checking on-the-fly, in any "text editing
> area".

Perhaps it's a standard. I, for one, use on-the-fly spelling checker a
lot in Emacs, just never flyspell.

If any spell-checker is enabled by default it should also actually work
with all/most human languages and the way users expect. Otherwise it
gets in the way. There are languages which can't be spell-checked with
ispell-like programs and it seems that Emacs's ispell/flyspell is very
much tied to those.

For me Emacs' ispell/flyspell are pretty much useless. I use Voikko
spell-checker for Finnish language and Enchant for others. Enchant is a
shared library and a generic interface for many checker engines
(including ispell, aspell, myspell etc.).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: Finding packages to enable by default

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Date: Fri, 20 Jun 2014 16:38:22 +0300
> Cc: emacs-devel@gnu.org
> 
> If any spell-checker is enabled by default it should also actually work
> with all/most human languages and the way users expect. Otherwise it
> gets in the way. There are languages which can't be spell-checked with
> ispell-like programs

Which languages are those?  Do you mean Finnish, or do you mean
something else?

> and it seems that Emacs's ispell/flyspell is very much tied to
> those.

How do you see that ispell.el is specific to "ispell-like programs"?

> For me Emacs' ispell/flyspell are pretty much useless. I use Voikko
> spell-checker for Finnish language and Enchant for others. Enchant is a
> shared library and a generic interface for many checker engines
> (including ispell, aspell, myspell etc.).

I always thought Hunspell should support Finnish, since it was written
to support Hungarian.  What am I missing?

Re: Finding packages to enable by default

[Teemu Likonen]

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

Eli Zaretskii [2014-06-20 17:04:37 +03:00] wrote:

>> If any spell-checker is enabled by default it should also actually
>> work with all/most human languages and the way users expect.
>> Otherwise it gets in the way. There are languages which can't be
>> spell-checked with ispell-like programs
>
> Which languages are those?  Do you mean Finnish, or do you mean
> something else?

I mean that Ispell-like programs can't be used either because a
dictionary for a language doesn't exist (a lot of languages) or
can't/doesn't provide a decent checker for a language (Finnish, at
least).

> How do you see that ispell.el is specific to "ispell-like programs"?

I'm confused. From where I see it ispell.el is about ispell-like
interface all over the place.

> I always thought Hunspell should support Finnish, since it was written
> to support Hungarian. What am I missing?

In theory Hunspell probably could but it doesn't. Finnish people use
Voikko which is a shared library that provides spell-checker,
hyphenation, syntax checker, morphological analyze. It's the Finnish
high-quality language technology which everybody in the free software
world uses.

Enchant spelling checker library can use Voikko as a back-end. Enchant
even provides a simple ispell-like command-line tool which has ispell
switches "-d", "-a" and "-l". Didn't manage to get it working with Emacs
ispell/flyspell.

But my ultimate point is not me or Finnish. Spell-checking task depends
on so many things outside the scope of Emacs project. So many different
languages, different checker engines, missing dictionaries, missing
engines. In many situations automatically enabled flyspell-mode just
wouldn't work. I think it's a bad idea to turn on such feature by
default.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: Finding packages to enable by default

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Fri, 20 Jun 2014 18:17:35 +0300
> 
> But my ultimate point is not me or Finnish. Spell-checking task depends
> on so many things outside the scope of Emacs project. So many different
> languages, different checker engines, missing dictionaries, missing
> engines. In many situations automatically enabled flyspell-mode just
> wouldn't work. I think it's a bad idea to turn on such feature by
> default.

Seems to me that it is up to the people who use those "other
spell-checkers" to enhance ispell.el to support them.  This is the
first time I personally hear that many languages are left out because
the spellers which support them don't provide the Ispell-like
interface which Emacs expects.  If there are so many of them, where
are all those users? why didn't anyone submit changes to ispell.el to
support those languages and spell-checkers?  Why didn't you, for that
matter?

Re: Finding packages to enable by default

[Teemu Likonen]

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

Eli Zaretskii [2014-06-20 21:34:01 +03:00] wrote:

> If there are so many of them, where are all those users? why didn't
> anyone submit changes to ispell.el to support those languages and
> spell-checkers? Why didn't you, for that matter?

I thought that flyspell-mode was too slow and had problems with
back-ends with decent Finnish support (Enchant and now obsolete
tmispell-voikko). I switched to speck-mode[1] for a while. It was better
but still too slow in some situations and didn't work with Enchant. It,
too, was tied to ispell interface. I began to think that more generic
approach is better. So I wrote wcheck-mode[2] which has very different
configuration concepts, and it's fast.

You asked where are all those users and why they haven't contributed to
ispell.el. I can only speak for myself. I think that, with very
different spell-checker concepts, it's easier to write a new checker
From scratch. That's kind of contribution too. I got what I wanted: fast
on-the-fly checker which works with anything and is very configurable.
Maybe some of those "other people" are using wcheck-mode too so their
itch have been scratched and they don't need to care about ispell.el.

But even if flyspell was replaced with my wcheck-mode (which I'm not
suggesting) I wouldn't enable it by default. The reason is the same: too
intrusive, so much unknown variables outside the scope of Emacs.


--------------------
 1. http://www.emacswiki.org/emacs/SpeckMode
 2. https://github.com/tlikonen/wcheck-mode

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: Finding packages to enable by default

[Stefan Monnier]

>> If there are so many of them, where are all those users? why didn't
>> anyone submit changes to ispell.el to support those languages and
>> spell-checkers? Why didn't you, for that matter?

> I thought that flyspell-mode was too slow and had problems with
> back-ends with decent Finnish support (Enchant and now obsolete
> tmispell-voikko). I switched to speck-mode[1] for a while. It was better
> but still too slow in some situations and didn't work with Enchant. It,
> too, was tied to ispell interface. I began to think that more generic
> approach is better. So I wrote wcheck-mode[2] which has very different
> configuration concepts, and it's fast.

I just had a look at wcheck-mode and it looks very interesting.
Would you be interesting in contributing the code (we could at
a minimum include it in GNU ELPA, tho I think it might be worthwhile in
Emacs itself).

I see it is "display and timer driven".  The "display driven" part is
interesting since it saves you from having to "touch" text before it
gets syntax-checked.  And the "timer driven" part makes it less
intrusive performance-wise.  Also it operates on larger chunks of text
at a time, which is more efficient.

I have a question: why does it use window-scroll-functions and such
hooks instead of using jit-lock?  [ I've been meaning to try and
implement a new spell-checking package using jit-lock, but it seems
to keep getting lower on the todo list.  ]

One downside for the user is that ispell.el's M-TAB might not work as
well since by the time wcheck's timer runs to discover your typo, the
user might "too far".


        Stefan

wcheck-mode (was: Finding packages to enable by default)

[Teemu Likonen]

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

Stefan Monnier [2014-06-20 21:28:08 -04:00] wrote:

> I just had a look at wcheck-mode and it looks very interesting. Would
> you be interesting in contributing the code (we could at a minimum
> include it in GNU ELPA, tho I think it might be worthwhile in Emacs
> itself).

Either way is fine. The papers have been signed so I guess you can just
pull the code. Potentially Emacs developers can improve it. I'm pretty
much of type "I just scratch my own itches" and to me wcheck is about
ready. So I'm not interested in new heavy maintenance burden. But I'm
here and can help.

> I see it is "display and timer driven". The "display driven" part is
> interesting since it saves you from having to "touch" text before it
> gets syntax-checked. And the "timer driven" part makes it less
> intrusive performance-wise. Also it operates on larger chunks of text
> at a time, which is more efficient.

I remember trying a couple of different things years ago and they all
were based on the idea of reading the buffers' window content kind of
visually. Invisible text is skipped and text outside window areas is not
read nor painted.

> I have a question: why does it use window-scroll-functions and such
> hooks instead of using jit-lock?

Maybe just because I'm not familiar with jit-lock. Wcheck uses some of
its features, though. Anyway, the idea is to trigger wcheck read event
for after any change in window configuration, buffer content, outline
visibility etc. It's perfectly fine to use other methods if they offer
similar trigger. After a quick look, maybe through jit-lock-register?

> One downside for the user is that ispell.el's M-TAB might not work as
> well since by the time wcheck's timer runs to discover your typo, the
> user might "too far".

Wcheck's "action" feature uses synchronous process to get information
From its back-end program. Maybe wcheck's version of M-TAB feature can
be implemented similar way. I've never used M-TAB, though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: wcheck-mode

[Stefan Monnier]

> Either way is fine. The papers have been signed so I guess you can just
> pull the code. Potentially Emacs developers can improve it. I'm pretty
> much of type "I just scratch my own itches" and to me wcheck is about
> ready. So I'm not interested in new heavy maintenance burden. But I'm
> here and can help.

Thanks.  I just added it to the `elpa' branch, so the 2014.6.21 version
should appear tomorrow-ish on GNU ELPA.

>> I have a question: why does it use window-scroll-functions and such
>> hooks instead of using jit-lock?
> Maybe just because I'm not familiar with jit-lock. Wcheck uses some of
> its features, though. Anyway, the idea is to trigger wcheck read event
> for after any change in window configuration, buffer content, outline
> visibility etc. It's perfectly fine to use other methods if they offer
> similar trigger. After a quick look, maybe through jit-lock-register?

Yes, jit-lock-register is the right entry point.  It should take care of
"change in window configuration, buffer content, outline visibility
etc..."

>> One downside for the user is that ispell.el's M-TAB might not work as
>> well since by the time wcheck's timer runs to discover your typo, the
>> user might "too far".
> Wcheck's "action" feature uses synchronous process to get information
> From its back-end program. Maybe wcheck's version of M-TAB feature can
> be implemented similar way. I've never used M-TAB, though.

I was thinking more of the fact that by the time wcheck has highlighted
the misspelled word, the user might be "too far" already, so we'd need to
tweak the semantics to be "fix the spelling of the last misspelled word,
no matter how far it is", which makes it incompatible with a M-TAB
binding (since M-TAB is used for many other things at the same time, we
don't want this fix-spelling action to constantly hide the other ones).


        Stefan

Re: Finding packages to enable by default

[Stefan Monnier]

> Perhaps it's a standard. I, for one, use on-the-fly spelling checker a
> lot in Emacs, just never flyspell.

Good, so we agree.

> If any spell-checker is enabled by default it should also actually work
> with all/most human languages and the way users expect.  Otherwise it
> gets in the way.  There are languages which can't be spell-checked with
> ispell-like programs and it seems that Emacs's ispell/flyspell is very
> much tied to those.

Yes, that's also part of what's needed to enable it by default, indeed.


        Stefan

Re: Finding packages to enable by default

[Sebastien Vauban]

Stefan Monnier wrote:
>> Please, no. I think flyspell is too intrusive to be enabled by default.
>
> Maybe that's something we should fix, then.  But nowadays I consider it
> "standard" to do basic spell-checking on-the-fly, in any "text editing
> area".

I, too, consider that it'd be normal to have Ispelling enabled by
default.

The only error I have with Flyspell (with Aspell) is that, in French,
such a correct sentence:

--8<---------------cut here---------------start------------->8---
Peut-on avoir un tiret entre deux mots ?
(May we have a dash between two words?)
--8<---------------cut here---------------end--------------->8---

gets underlined at "Peut-on" -- while a dash must be inserted in the
interrogation style, when we invert the verb and the subject.

Though, I'm quite positive it can be fixed with some Emacs settings,
even if I did not find them yet ;-)

Best regards,
  Seb

PS- Similarly, I remember that Ispell did not recognize compound words
    with apostrophes in them (for example, "l'avion" -- the
    plane)... but that one was solved by switching to Aspell.

-- 
Sebastien Vauban

Re: Finding packages to enable by default

[Juri Linkov]

>> | winner-mode                                      |      35 |
>
> If we can come up with good keybindings, then we can indeed enable it
> by default.

`C-x C-left' switches to the previous buffer, so similarly
`C-x M-left' could switch to the previous window configuration.

Also in browser's UI `M-left' switches to the previous page
(roughly corresponding to the window configuration).

>> | windmove                                         |      30 |
>
> I like this as well.  I'm a little worried about occupying the
> S-<left/right/up/down> bindings, tho: it's pretty easy to keep the shift
> modifier pressed inadvertently.

`S-' conflicts with `shift-select-mode', but since both
`M-S-left' and `C-S-left' are bound to the same command,
`M-S-' could be taken for windmove.

Re: Finding packages to enable by default

[Sebastien Vauban]

Juri Linkov wrote:
>>> | windmove                                         |      30 |
>>
>> I like this as well.  I'm a little worried about occupying the
>> S-<left/right/up/down> bindings, tho: it's pretty easy to keep the shift
>> modifier pressed inadvertently.
>
> `S-' conflicts with `shift-select-mode', but since both
> `M-S-left' and `C-S-left' are bound to the same command,
> `M-S-' could be taken for windmove.

It surely conflicts as well with Org key bindings.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Finding packages to enable by default

[Glenn Morris]

Stefan Monnier wrote:

>> | recentf-mode                                     |      43 |
>
> I don't see any reason not to enable this by default.

Me neither, but I think it needs some work, since it uses features
(easymenu, tree-widget) that I imagine we do not want to preload.

I think maybe it needs to be split into a preloaded core that does the
basic stuff, and an autoloaded remainder that does the more complex
stuff (eg the tree-widget part).

I think the easymenu stuff should just be dropped; ie the menu position
should be fixed. (I anticipate howls of protest from the usual suspects.)
No other standard menu-item is customizable in this way.

>> | dired-x                                          |      33 |
>
> Fine by me.

I still think it contains "a few useful features and a lot of cruft."

(http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00718.html)