RE: Finding packages to enable by default

RE: Finding packages to enable by default

[Drew Adams]

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

Thank you.  Exactly my point.  Combining the two gives the benefits of
each, and without the distraction of any cursor bouncing.

RE: Finding packages to enable by default

[Drew Adams]

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

Yup, very useful.  This one should be a no-brainer (at least for modes
where matching "parens" is important).

Re: Finding packages to enable by default

[Tak Kunihiro]

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

When point is on a window with buffer that cannot be edited, many
modes such like dired make `q' close the window.  The winner-dwim does
similar regardless where the point is.  Thus I propose `C-x q' or
`C-q' although they are taken.

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).
>
> When point is on a window with buffer that cannot be edited, many
> modes such like dired make `q' close the window.  The winner-dwim does
> similar regardless where the point is.  Thus I propose `C-x q' or
> `C-q' although they are taken.

I suppose you mean using `C-x q' to quit window, and `C-u C-x q'
to "un-quit", but with bindings to `winner-undo' and `winner-redo'.
In bug#13167 we considered binding `C-x q' to `quit-window' itself
because `winner-undo' is quite different from `quit-window' that
doesn't not necessarily restore the previous window configuration,
so `winner-undo' and `quit-window' require different key bindings.

Re: Finding packages to enable by default

[Tak Kunihiro]

>>>>> | 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).
>>
>> When point is on a window with buffer that cannot be edited, many
>> modes such like dired make `q' close the window.  The winner-dwim does
>> similar regardless where the point is.  Thus I propose `C-x q' or
>> `C-q' although they are taken.
> 
> I suppose you mean using `C-x q' to quit window, and `C-u C-x q'
> to "un-quit", but with bindings to `winner-undo' and `winner-redo'.
> In bug#13167 we considered binding `C-x q' to `quit-window' itself
> because `winner-undo' is quite different from `quit-window' that
> doesn't not necessarily restore the previous window configuration,
> so `winner-undo' and `quit-window' require different key bindings.

Thank you to scoop what I meant.

How about `C-x C-_' or `C-x _' for "winner-undo" analogous to `C-_'
for "undo"?

I think that `C-x C-0' for "text-scale-adjust" has a nice interface
that accepts `+' or `-' after initiation.  Analogous to that, after
initiation, `_' or `-' can be assigned to "winner-undo" and `=' or `+'
for "winner-undo".

Re: Finding packages to enable by default

[Juri Linkov]

> How about `C-x C-_' or `C-x _' for "winner-undo" analogous to `C-_'
> for "undo"?
>
> I think that `C-x C-0' for "text-scale-adjust" has a nice interface
> that accepts `+' or `-' after initiation.  Analogous to that, after
> initiation, `_' or `-' can be assigned to "winner-undo" and `=' or `+'
> for "winner-undo".

This makes sense.  But there is no intuitive key for "redo" to bind to
`winner-redo'.  Or maybe `C-x C-_' should support both `winner-undo'
and `winner-redo' like `C-_' uses a non-undo command to break
the sequence of undo commands.

OTOH, when using the key `C-x M-left' we could display two buttons in
the toolbar with arrows representing visually the meaning of `C-x M-left'
with the left arrow to go to the previous window configuration, and the
right arrow to go to the next window configuration.

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.

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

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.

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

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)