Re: Feature branches review please (ivy hello)

Re: Feature branches review please (ivy hello)

[Jean Louis]

* Gregory Heytings <ghe@sdf.org> [2020-11-06 12:19]:
> > I am looking for preferrably built-in system that will have narrowing
> > vertical incremental search, like built-in ivy or helm. Something that
> > ido or icomplete could become. Until then I keep ivy as most simplest
> > solution as I prefer package from GNU ELPA.

> Again I'm not sure I understand what you want, but I think you should try
> (setq completion-styles (cons 'flex completion-styles)).  With that setting
> you can narrow the candidates list with any character, you do not need to
> type the first characters.

Sounds like you do not know ivy or helm? Try using helm functions, you
may understand what is "narrowing incremental search". I may express
myself badly so I may need help to express me very nice.

> > You may see how dmenu which is separate program works under X Window
> > system to launch files:
> > 
> > 1.8M demo of dmenu program:
> > https://gnu.support/images/2020/11/2020-11-05/2020-11-06-01:38:29.ogv

Now the first demo works, click above to see. Click here below to see
the comparison between completion frameworks, others but icomplete (as
it is not complete yet).

https://gnu.support/images/2020/11/2020-11-06/2020-11-06-13:22:39.ogv

Here is demonstration of completions with helm, ivy, ido, and dmenu
(outside command): https://tools.suckless.org/dmenu/

1. Helm mode, can move up and down freely, have actions and multi
   selection possibility with highlighting. It can select by using
   reverse words. It is outside package with many contributors now
   hard to enter main Emacs.

2. Ivy mode is good candidate to enter main Emacs as it is on GNU ELPA
   already and author is willing. IT LACKS reverse word search. It has
   multiple action capability, highlighting and looks saner than
   Helm. This is my current choice.

3. dmenu is external program with beautiful user interface. User can
   move up and down and may use reverse words to come to selection.

4. ido-mode is built-in, I do not know how to get selection by using
   reverse order of words. For now I did not find if it has multiple
   choices option.

P.S. I am including author of Ivy Oleh Krehel with hope and proposal
to improve ivy with reverse order of words selections and hopefully to
include it in GNU Emacs.

You may test features to understand it by evaluating one by one here
below.

;; This is what Emacs needs as a built-in function what I name for now
;; "dynamic narrowing incremental search"

;; It would be very useful to have built-in Ivy or Ivy-like completion:
;;
;; 0. Function (YOU-NAME-THE-MODE-completing-read PROMPT COLLECTION &OPTIONAL ...)
;;    and possibility to automatically replace the built-in function named
;;    `completing-read' when `YOU-NAME-THE-MODE-mode' is turned on
;;
;; 1. It should get selection by using words in reverse order, for
;;    example to select "AMERICAN SAMOA" when one writes "SAMOA
;;    AMERICAN"
;;
;; 2. Highlighting like in Ivy or Helm or Dmenu
;;
;; 3. Capability to choose other actions, not only the default action,
;;    like M-o in Ivy or TAB in Helm.
;;
;; 4. Capability to choose multiple items, like marking of the item
;;    with C-c SPC in Helm and conducting actions on multiple items

(setq collection '("2 ÅLAND ISLANDS" "30 BOUVET ISLAND" "41 CAYMAN ISLANDS" "46 CHRISTMAS ISLAND" "47 COCOS (KEELING) ISLANDS" "52 COOK ISLANDS" "70 FALKLAND ISLANDS (MALVINAS)" "71 FAROE ISLANDS" "94 HEARD ISLAND AND MCDONALD ISLANDS" "134 MARSHALL ISLANDS" "160 NORFOLK ISLAND" "161 NORTHERN MARIANA ISLANDS"))

;; Normal built-in Emacs completion for: ISLAND CAYMAN
(helm-mode 1)
(completing-read "Country: " collection)

;; ivy completion from GNU ELPA: for ISLAND CAYMAN
(ivy-completing-read "Country: " collection)

;; ido completion
(ido-completing-read "Country: " collection)

;; dmenu is a dynamic menu for X, originally designed for dwm. It
;; manages large numbers of user-defined menu items efficiently
;; if somebody has better function to input let me know
(defun dmenu-completing-read (prompt collection)
  ;; &optional predicate require-match initial-input history def inherit-input-method)
  "Uses external `dmenu' command for Emacs completions."
  (let* ((collection (concat (string-join collection "\n") "\n"))
	 (file (string-to-file-force collection "/dev/shm/collection"))
	 (dmenu "dmenu"))
    (with-temp-buffer
      (call-process dmenu file (current-buffer) nil "-fn" "DejaVu:pixelsize=30" "-l" "10" "-i" "-b" "-p" prompt "-nb" "dark goldenrod" "-nb" "black")
      (string-trim (buffer-string)))))

(dmenu-completing-read "Country: " collection)
(dmenu-completing-read "Recent files: " (recentf-elements 10))

;; HELM completion, good example how it should look like in Emacs with
;; built-in function. There is some bug that says `eval-last-sexp'
;; which I did not put choose.

(helm-mode 1)
(completing-read "Country: " collection)

Only Helm mode and Dmenu show that reverse order of words can be
selected. Ivy need to improve.

Jean

Re: Feature branches review please (ivy hello)

[Oleh Krehel]

Hi Jean Louis,

> P.S. I am including author of Ivy Oleh Krehel with hope and proposal
> to improve ivy with reverse order of words selections and hopefully to
> include it in GNU Emacs.

Ivy already has the option of reverse order matching:

(setq ivy-re-builders-alist
      '((t . ivy--regex-ignore-order)))

It's not on by default, because the default setting, in my opinion,
results in a faster match if you know what you're looking for.

kind regards,
Oleh

Re: Feature branches review please (ivy hello)

[Jean Louis]

* Oleh Krehel <ohwoeowho@gmail.com> [2020-11-06 14:17]:
> Hi Jean Louis,
> 
> > P.S. I am including author of Ivy Oleh Krehel with hope and proposal
> > to improve ivy with reverse order of words selections and hopefully to
> > include it in GNU Emacs.
> 
> Ivy already has the option of reverse order matching:
> 
> (setq ivy-re-builders-alist
>       '((t . ivy--regex-ignore-order)))
> 
> It's not on by default, because the default setting, in my opinion,
> results in a faster match if you know what you're looking for.

I hope that it did not touch you. That is great that such function
exist. I did search with ivy with "ivy" and "match" as I was thinkin
it will be somewhere there.

Ivy is great, it is good replacement for Helm, as Helm is larger
package and I need it simpler. Especially I like cleaner user
interface, you know how Helm has minibuffer full of various
explanations for key bindings, but I do not find it helpful rather
confusing for end users.

That is great package and I am glad it is in GNU ELPA and this is what
I needed.

I have seen previous discussion about it entering main Emacs.

Question: Why not?

Re: Feature branches review please (ivy hello)

[Basil L. Contovounesios]

Jean Louis <bugs@gnu.support> writes:

> * Oleh Krehel <ohwoeowho@gmail.com> [2020-11-06 14:17]:
>> Hi Jean Louis,
>> 
>> > P.S. I am including author of Ivy Oleh Krehel with hope and proposal
>> > to improve ivy with reverse order of words selections and hopefully to
>> > include it in GNU Emacs.
>> 
>> Ivy already has the option of reverse order matching:
>> 
>> (setq ivy-re-builders-alist
>>       '((t . ivy--regex-ignore-order)))
>> 
>> It's not on by default, because the default setting, in my opinion,
>> results in a faster match if you know what you're looking for.
>
> I hope that it did not touch you. That is great that such function
> exist. I did search with ivy with "ivy" and "match" as I was thinkin
> it will be somewhere there.

The way Ivy performs matching is relatively customisable;
see (info "(ivy) Completion Styles").  Note that this is a separate
customisation mechanism to that of the built-in completion-styles.

> That is great package and I am glad it is in GNU ELPA and this is what
> I needed.
>
> I have seen previous discussion about it entering main Emacs.
>
> Question: Why not?

I already referred you to the correct thread for discussing that in
https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00172.html.

-- 
Basil

Re: Feature branches review please (ivy hello)

[Jean Louis]

* Basil L. Contovounesios <contovob@tcd.ie> [2020-11-06 14:49]:
> > I hope that it did not touch you. That is great that such function
> > exist. I did search with ivy with "ivy" and "match" as I was thinkin
> > it will be somewhere there.
> 
> The way Ivy performs matching is relatively customisable;
> see (info "(ivy) Completion Styles").  Note that this is a separate
> customisation mechanism to that of the built-in completion-styles.

I did not even see that info file exists, thank you. Now reading.

> > That is great package and I am glad it is in GNU ELPA and this is what
> > I needed.
> >
> > I have seen previous discussion about it entering main Emacs.
> >
> > Question: Why not?
> 
> I already referred you to the correct thread for discussing that in
> https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00172.html.

Do you refer to this issue:
https://github.com/abo-abo/swiper/issues/1597

Would that issue prevent ivy to to enter main Emacs?

Re: Feature branches review please (ivy hello)

[Gregory Heytings via Emacs development discussions.]

>> You may see how dmenu which is separate program works under X Window 
>> system to launch files:
>>
>> 1.8M demo of dmenu program: 
>> https://gnu.support/images/2020/11/2020-11-05/2020-11-06-01:38:29.ogv

I looked at this, I honestly don't see how this is different from 
icomplete/ido.  AFAICS you select a program name by typing its name.

>
> ;; 1. It should get selection by using words in reverse order, for
> ;;    example to select "AMERICAN SAMOA" when one writes "SAMOA
> ;;    AMERICAN"
>

Again, please try (setq completion-styles (cons 'flex completion-styles)). 
With this "foo bar" matches both "foo bar" and "bar foo" (and also "far 
boo", "boo far", ...).

>
> ;; 2. Highlighting like in Ivy or Helm or Dmenu
>

The default settings for icomplete/ido have some "highlighting", but 
probably not the one you want.  For example the current match is in bold.

>
> ;; 3. Capability to choose other actions, not only the default action,
> ;;    like M-o in Ivy or TAB in Helm.
> ;;
> ;; 4. Capability to choose multiple items, like marking of the item
> ;;    with C-c SPC in Helm and conducting actions on multiple items
>

These two features are not part of icomplete/ido, indeed.  If you need 
them, use ivy or helm.  Or wait until someone finds the time and energy to 
implement them for icomplete/ido.  Or find the time and energy to 
implement them for icomplete/ido.

Re: Feature branches review please (ivy hello)

[Stefan Monnier]

> I have seen previous discussion about it entering main Emacs.
> Question: Why not?

FWIW, here's my take on it: a package should be included in Emacs
if it's activated by default or if it's a library that's required by
many other packages.

To help relieve the pain that such a "minimalist" view implies,
I consider that some GNU ELPA packages (the most popular/impactful ones)
should be bundled into Emacs's tarball, starting with the
`gnu-elpa` package (https://elpa.gnu.org/packages/gnu-elpa.html).


        Stefan

Re: Feature branches review please (ivy hello)

[Stefan Monnier]

> Again, please try (setq completion-styles (cons 'flex
>  completion-styles)). With this "foo bar" matches both "foo bar" and "bar
>  foo" (and also "far boo", "boo far", ...).

Does it?

>> ;; 2. Highlighting like in Ivy or Helm or Dmenu

BTW, could people who argue for particular feature take the trouble of
actually describing the feature instead of saying "like Foo"?


        Stefan

Re: Feature branches review please (ivy hello)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 06 Nov 2020 08:56:45 -0500
> Cc: Oleh Krehel <ohwoeowho@gmail.com>, emacs-devel@gnu.org
> 
> > I have seen previous discussion about it entering main Emacs.
> > Question: Why not?
> 
> FWIW, here's my take on it: a package should be included in Emacs
> if it's activated by default or if it's a library that's required by
> many other packages.

We didn't make such a decision, AFAIK, and as a matter of fact, a
large part of what comes today with Emacs doesn't pass this test.

A prerequisite for making such a decision would be to find a way of
bundling ELPA packages into an Emacs tarball when preparing a
release.  We haven't yet found the way of doing that, although some
discussions were held about what would that entail.

Personally, I think promoting the above concept before the decision
was made is something to avoid, because it sends the wrong message.

Re: Feature branches review please (ivy hello)

[Gregory Heytings via Emacs development discussions.]

>> Again, please try (setq completion-styles (cons 'flex 
>> completion-styles)). With this "foo bar" matches both "foo bar" and 
>> "bar foo" (and also "far boo", "boo far", ...).
>
> Does it?
>

Hmmm, no, you're right, it doesn't.  I don't use that setting, I tried it 
briefly and wrongly concluded that it worked that way.  What would be 
needed is a "superflex" completion-style where characters can be given in 
any order ;-)

Re: Feature branches review please (ivy hello)

[Stefan Monnier]

>> > I have seen previous discussion about it entering main Emacs.
>> > Question: Why not?
>> FWIW, here's my take on it: a package should be included in Emacs
>> if it's activated by default or if it's a library that's required by
>> many other packages.
> We didn't make such a decision, AFAIK,

Indeed, I only stated my opinion.

> and as a matter of fact, a large part of what comes today with Emacs
> doesn't pass this test.

Yup.  And moving packages out of Emacs is extra work with very
little payback.  There's theory and then there's practice ;-)

> A prerequisite for making such a decision would be to find a way of
> bundling ELPA packages into an Emacs tarball when preparing a
> release.  We haven't yet found the way of doing that, although some
> discussions were held about what would that entail.

FWIW, there's an existing patch which does that.  It's more a question
of making the decision and then managing the consequences.

> Personally, I think promoting the above concept before the decision
> was made is something to avoid, because it sends the wrong message.

What I wrote above is not any kind of decision.  It's "my take on it".
And that's been my take on it for many years now, and it guides the way
I argue for or against inclusion of packages in Emacs and in GNU ELPA.


        Stefan

Re: Feature branches review please (ivy hello)

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-06 16:57]:
> > I have seen previous discussion about it entering main Emacs.
> > Question: Why not?
> 
> FWIW, here's my take on it: a package should be included in Emacs
> if it's activated by default or if it's a library that's required by
> many other packages.

From Wikipedia:
https://en.wikipedia.org/wiki/Incremental_search

The first documented use of incremental search was in EMACS on ITS in
the late 1970s.[1] This was one of the many essential Emacs features
Richard Stallman included in his reimplementation, GNU Emacs. Other
noteworthy programs containing this functionality in the 1980s include
bash and Canon Cat.[2] These early implementations offered single line
feedback, not lists of suggestions.

Emacs has the built-in `ido-mode' which is definitely useful compared
to the built-in completion yet is not 

But not as nearly useful as helm, which practically or legally or
willingly cannot be imported into GNU ELPA or into Emacs.

Ivy comes as useful compromise.

RE: Feature branches review please (ivy hello)

[Drew Adams]

[Forwarding to the list, as it got dropped from
Reply All.]

> >> Again, please try (setq completion-styles (cons 'flex
> >> completion-styles)). With this "foo bar" matches both "foo bar" and
> >> "bar foo" (and also "far boo", "boo far", ...).
> >
> > Does it?
> 
> Hmmm, no, you're right, it doesn't.  I don't use that setting, I tried it
> briefly and wrongly concluded that it worked that way.  What would be
> needed is a "superflex" completion-style where characters can be given in
> any order ;-)

tl;dr: Matching without respect to order in
the target involves multiple separate matches.
___

What's usually called "flex" matching (Icicles
calls it "scatter") just matches bits of the
pattern you provide _in order_, one after the
other.  The matches are scattered throughout
the target, but they are _in order_ there.

To match multiple patterns without regard to
order in the target, you need to match the
patterns separately, each against the original
target or each against the result of previous
matching.

Icicles or library orderless.el provides such
behavior.

With Icicles, you can match a pattern (regexp,
fuzzy, flex, substring, whatever), and then you
can match another pattern ... etc.  Because the
component matches are separate the resulting
overall matches have those component matches in
any order.

Re: Feature branches review please (ivy hello)

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-11-06 19:32]:
> To match multiple patterns without regard to
> order in the target, you need to match the
> patterns separately, each against the original
> target or each against the result of previous
> matching.
> 
> Icicles or library orderless.el provides such
> behavior.

https://www.emacswiki.org/emacs/DrewsElispLibraries

Incremental search on that page does not give me: orderless.el - where
is it?

Jean

Re: Feature branches review please (ivy hello)

[Jean Louis]

* Gregory Heytings <ghe@sdf.org> [2020-11-06 15:08]:
> 
> > > You may see how dmenu which is separate program works under X Window
> > > system to launch files:
> > > 
> > > 1.8M demo of dmenu program:
> > > https://gnu.support/images/2020/11/2020-11-05/2020-11-06-01:38:29.ogv
> 
> I looked at this, I honestly don't see how this is different from
> icomplete/ido.  AFAICS you select a program name by typing its name.
> 
> > 
> > ;; 1. It should get selection by using words in reverse order, for
> > ;;    example to select "AMERICAN SAMOA" when one writes "SAMOA
> > ;;    AMERICAN"
> > 
> 
> Again, please try (setq completion-styles (cons 'flex completion-styles)).
> With this "foo bar" matches both "foo bar" and "bar foo" (and also "far
> boo", "boo far", ...).

I will test that tip, thank you.

> > ;; 3. Capability to choose other actions, not only the default action,
> > ;;    like M-o in Ivy or TAB in Helm.
> > ;;
> > ;; 4. Capability to choose multiple items, like marking of the item
> > ;;    with C-c SPC in Helm and conducting actions on multiple items
> > 
> 
> These two features are not part of icomplete/ido, indeed.  If you need them,
> use ivy or helm.  Or wait until someone finds the time and energy to
> implement them for icomplete/ido.  Or find the time and energy to implement
> them for icomplete/ido.

I do use, though my priority is on reusing code which is inside of
Emacs in first place, then GNU ELPA, then anything else outside.

RE: Feature branches review please (ivy hello)

[Drew Adams]

> > Icicles or library orderless.el provides such
> > behavior.
> 
> https://urldefense.com/v3/__https://www.emacswiki.org/emacs/DrewsElispLibrari
> es__;!!GqivPVa7Brio!PeXT38xLaZ0WLPhzhQoy50PH99rQt9z2shHRkvYnymiDP96UbGsrHqcRD
> 1EpQbPv$
> 
> Incremental search on that page does not give me: orderless.el - where
> is it?

It's not one of my libraries.  I mentioned it because,
like Icicles "progressive completion", it lets you get
matches of multiple patterns without respect to order.

Googling "orderless.el" tells me it's here:

https://github.com/oantolin/orderless

Re: Feature branches review please (ivy hello)

[Gregory Heytings via Emacs development discussions.]

>> Again, please try (setq completion-styles (cons 'flex 
>> completion-styles)). With this "foo bar" matches both "foo bar" and 
>> "bar foo" (and also "far boo", "boo far", ...).
>
> I will test that tip, thank you.
>

Sorry, I erred here, flex matching (which I don't use) does not work the 
way I thought.

Re: Feature branches review please (ivy hello)

[Basil L. Contovounesios]

Jean Louis <bugs@gnu.support> writes:
> * Basil L. Contovounesios <contovob@tcd.ie> [2020-11-06 14:49]:
>> > That is great package and I am glad it is in GNU ELPA and this is what
>> > I needed.
>> >
>> > I have seen previous discussion about it entering main Emacs.
>> >
>> > Question: Why not?
>> 
>> I already referred you to the correct thread for discussing that in
>> https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00172.html.
>
> Do you refer to this issue:
> https://github.com/abo-abo/swiper/issues/1597

No, what I meant is that there is a different mailing thread for
discussing the inclusion of Ivy with the subject "Include ivy + counsel
in Emacs core?".

> Would that issue prevent ivy to to enter main Emacs?

Not necessarily.

-- 
Basil

orderless/bookmarks

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-11-06 22:28]:
> > > Icicles or library orderless.el provides such
> > > behavior.
> > 
> > https://urldefense.com/v3/__https://www.emacswiki.org/emacs/DrewsElispLibrari
> > es__;!!GqivPVa7Brio!PeXT38xLaZ0WLPhzhQoy50PH99rQt9z2shHRkvYnymiDP96UbGsrHqcRD
> > 1EpQbPv$
> > 
> > Incremental search on that page does not give me: orderless.el - where
> > is it?
> 
> It's not one of my libraries.  I mentioned it because,
> like Icicles "progressive completion", it lets you get
> matches of multiple patterns without respect to order.
> 
> Googling "orderless.el" tells me it's here:
> https://github.com/oantolin/orderless

Thank you.

I was also researching bookmark handlers in bookmark.el in built-in
Emacs.

From: bookmark-alist
HANDLER is a function that provides the bookmark-jump behavior for a
specific kind of bookmark instead of the default `bookmark-default-handler'.
This is the case for Info bookmarks, for instance.  HANDLER must accept
a bookmark as its single argument.

I am following it inside as I may wish to use built-in bookmark
functions for storage into database that later may be expanded into
various different formats.