RE: Feature branches review please (ivy hello)

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)

[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

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.

Re: Feature branches review please

[Jean Louis]

* Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-11-05 11:37]:
> 
> Hi Ergus,
> 
> > 
> > The icomplete-vertical feature branch is pretty much ready, please if
> > any maintainer could give it a last review and tell me anything else
> > needed to merge into master?
> > 
> 
> You may have followed the (heated) discussions about displaying completion
> candidates vertically in the minibuffer about a month ago.  Short summary:
> 
> 1. During these discussions, Eli added two lines in xdisp.c, and
> icomplete-vertical now only requires `(setq icomplete-separator
> "\n")'.

I hope that functions are made in the spirit of ivy and helm so that I
can build completion based system for any choices, not only minibuffer
built-in choices.

For ivy, I have this:

ivy-completing-read is an autoloaded compiled Lisp function in
‘ivy.el’.

(ivy-completing-read PROMPT COLLECTION &optional PREDICATE
REQUIRE-MATCH INITIAL-INPUT HISTORY DEF INHERIT-INPUT-METHOD)

icomplete-vertical would be very useful function and I hope it will
get:

- full window support, like poping out of minibuffer to full window
- settable size of minibuffer
- actions like ivy with M-o or helm with TAB

Then I could develop on built-in Emacs features instead of asking for
too many outside packages to be loaded.

Let me know how to get that branch, that I can test it.

Jean

Re: Feature branches review please

[Gregory Heytings via Emacs development discussions.]

>
> I hope that functions are made in the spirit of ivy and helm so that I 
> can build completion based system for any choices, not only minibuffer 
> built-in choices.
[...]
>
> (ivy-completing-read PROMPT COLLECTION &optional PREDICATE REQUIRE-MATCH 
> INITIAL-INPUT HISTORY DEF INHERIT-INPUT-METHOD)
>

In fact it's the opposite, that function is made in the spirit of Emacs' 
built-in completing-read function: (completing-read PROMPT COLLECTION 
&optional PREDICATE REQUIRE-MATCH INITIAL-INPUT HIST DEF 
INHERIT-INPUT-METHOD)

>
> - full window support, like poping out of minibuffer to full window
>

I'm not sure I understand what you mean, but it seems to me that this is a 
standard feature when reading from the minibuffer, when you press TAB a 
*Completions* buffer opens.

>
> - settable size of minibuffer
>

This is a separate feature, see max-mini-window-height.

>
> - actions like ivy with M-o or helm with TAB
>

This I don't know, what do you mean by "actions"?

Re: Feature branches review please

[Manuel Uberti]

On 05/11/20 17:10, Gregory Heytings via Emacs development discussions. wrote:
>>
>> - actions like ivy with M-o or helm with TAB
>>
> 
> This I don't know, what do you mean by "actions"?
> 

Probably something like the package embark[1] provides.


[1] https://github.com/oantolin/embark

-- 
Manuel Uberti
www.manueluberti.eu

Re: Feature branches review please

[Gregory Heytings via Emacs development discussions.]

>>> - actions like ivy with M-o or helm with TAB
>>
>> This I don't know, what do you mean by "actions"?
>
> Probably something like the package embark[1] provides.
>
> [1] https://github.com/oantolin/embark
>

Oh yes, I see.  In that case, no, I don't think such a feature is in the 
scope of icomplete.

Re: Feature branches review please

[Jean Louis]

* Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-11-05 20:06]:
> 
> > > > - actions like ivy with M-o or helm with TAB
> > > 
> > > This I don't know, what do you mean by "actions"?
> > 
> > Probably something like the package embark[1] provides.
> > 
> > [1] https://github.com/oantolin/embark
> > 
> 
> Oh yes, I see.  In that case, no, I don't think such a feature is in the
> scope of icomplete.

I don't think that embark is what I mean. Here is short screen how
actions are implemented in Helm with TAB:

https://gnu.support/images/tmp/2020-11-05-20:26:22.ogv

I can then choose what to do on the selection instead of the default
action. In Ivy actions are also there but with M-o

If function icomplete-completing-read is not there, I still need to
use external packages. It is more useful if it is there.

How can I checkout that branch?

Re: Feature branches review please

[Gregory Heytings via Emacs development discussions.]

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


>
> How can I checkout that branch?
>

As I said earlier in this thread, you can have icomplete-vertical without 
using that branch, with the master branch you only need to `(setq 
icomplete-separator "\n")'.

If you want a more robust solution however (neither the above nor the 
branch are always correct), you'll have to wait.  If you don't want to 
wait, you can try my proposed solution (see attached), which works for any 
version of Emacs >= 24.

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

(defvar-local start-display-at-beginning-of-minibuffer nil)
(defun start-display-at-beginning-of-minibuffer (&rest args)
  (when (and start-display-at-beginning-of-minibuffer (minibufferp))
    (set-window-start-at-begin (point-min) (point))))
(defun set-window-start-at-begin (beg end)
  (when (< (+ beg 2) end)
    (set-window-start nil beg)
    (unless (pos-visible-in-window-p end nil t)
      (set-window-start-at-begin (+ beg (/ (- end beg) 2)) end))))
(add-hook 'window-scroll-functions #'start-display-at-beginning-of-minibuffer)
(add-hook 'post-command-hook #'start-display-at-beginning-of-minibuffer)

(setq icomplete-separator "\n")
(add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t)))
(defun icomplete-vertical-reformat-completions (completions)
  (save-match-data
    (if (string-match "^\\((.*)\\|\\[.*\\]\\)?{\\(\\(?:.\\|\n\\)+\\)}" completions)
        (format "%s \n%s" (or (match-string 1 completions) "") (match-string 2 completions))
      completions)))
(advice-add 'icomplete-completions :filter-return #'icomplete-vertical-reformat-completions)

Re: Feature branches review please

[Jean Louis]

Alright, it is in master branch, I have it.

When I do:

{C-h v RET icomplete-separator RET} then I get option to customize.

When I enter there: \n without quotes I get this completion:

~doe/\nntp/\ntor etc. so it deos not work well as intended from
customize. You maybe wish to verify that for users. Did you try
changing it in customize yourself? So it will not work with the
advise. It is not well made customization, OK? I consider that bug.

If I do in customize {C-q C-j} then I get new line in customize which
then does work. Not everybody will know how to tweak that.

This of course works directly:

(setq icomplete-separator "\n")

It does not work smooth as ivy. I wish it could.

I am supposed to click TAB even if it matches, clicking ENTER creates
new buffer with half of the file name. Ivy allows me to click enter if
I am on the match which is faster.

icomplete-mode works well with M-j so far.

I am asking myself what is the big difference between icomplete and
ido now. icomplete is doing what difference?

By your advise I have also changed the third parameter for
ido-decorations to: {C-q C-j and I have also got vertical ido
completion.

I expect to be able to move in vertical line, not only type
letters. Feeling is rigid, I cannot move up and down with familiar
keys likes C-n or C-p like I can do in ivy-mode or in helm

My feeling is that icomplete-mode is downgrade of ido-mode as it has
less keybindings, or better, icomplete is not complete.

Both ido-mode and icomplete-mode are so much worse than ivy mode.

Why ivy-mode cannot enter Emacs as it is GNU ELPA?

And then in Emacs there are two packages doing basically the same
function, ido-mode and icomplete-mode. I cannot know why. I am giving
you my opinion and review as user who would like to have: narrowing
incremental search with movements up and down, actions and
X-completing-read function.

Here is video and comparison between ido-mode, icomplete-mode,
ivy-mode and helm-mode, size 59M, about 9 minutes:
https://gnu.support/images/2020/11/2020-11-05/2020-11-06-00:03:17.ogv

Let us first see ido-mode C-j did not work as expected. I am used to
ivy-mode, my fault. Maybe it is separator. Even with my customization,
C-j is not working. What does ido-mode map says? There is no
ido-mode-map and no description of mode map as I expect to get it with
{C-h m} but I can see in the source that key bindings are well defined.

ido-mode selects text only partially, does not automatically choose
from selection if it matches. I may be familiar with ivy/helm and
expect that when I press enter on the match that it should work. I
have to complete it myself in full by using TAB, coming to EOL so that
ido-mode recognizes it. Not what I expect. Only horizontal works for
ido-mode. Visually ido-mode can work vertically if third parameter of
ido-decorations is changed to C-q C-j but it does not function in
selection. So why icomplete vertically when you can improve ido-mode
in the same way to be vertical? It looks as more mature package. 

Then I have tried icomplete in vertical mode. I cannot move with
familiar keys up and down. So I cannot see what is down. That is what
I expected.

Then I have tried again with ido-mode. And it was better, more visible
files. Then I've tried again icomplete-mode and I got confused as I
could not see nothing by moving up and down, it is far from my
vertical related expectations.

Then I have tested horizontal I complete and it gives me feeling of
not being nearly close to ido-mode. But is better than vertical. But
ido-mode is much better than icomplete-mode.

Now to ivy-mode. What you see on video with M-o are actions. That is
so useful. Let us say you create icomplete-find-files, you may want to
delete, rename, copy and do other actions with files.

counsel package utilizs ivy-mode to create exactly that, to cd, open,
open externally, open as root, to open read only, to delete, to copy,
move or mkdir. Those are actions, very necessary and common in other
completion frameworks.

Then I have checked helm-find-files which is definitely the best. No
question about it.

But ivy-mode is light, it is in GNU ELPA (easier to install on
multiple machines) and way better than ido or icomplete.

Summary of these four reviewed:

1. helm-find-files, best but overkill, and outside of Emacs GNU ELPA

2. ivy-mode and counsel are in GNU ELPA, ivy works great.

3. ido-mode works well, it has user functions and looks pretty mature

4. icomplete-mode reinvents the wheel and is already in Emacs. I get
   surprised. I was reviewing it some days before and I did not get
   what it is as it looked like bad version of ido-mode.

Thank you.

Jean

Re: Feature branches review please

[Gregory Heytings via Emacs development discussions.]

>
> I expect to be able to move in vertical line, not only type letters. 
> Feeling is rigid, I cannot move up and down with familiar keys likes C-n 
> or C-p like I can do in ivy-mode or in helm
>

With icomplete-mode, C-h m tells you that:

C-, is icomplete-backward-completions
C-. is icomplete-forward-completions

And you can always:

(define-key icomplete-minibuffer-map (kbd "C-n") 'icomplete-forward-completions)
(define-key icomplete-minibuffer-map (kbd "C-p") 'icomplete-backward-completions)

>
> Maybe it is separator. Even with my customization, C-j is not working.
>

With icomplete-mode C-j would do what you want (it is bound to 
icomplete-force-complete-and-exit).

I looked at your video, most of the time I do not understand what you try 
to do.  Of course nothing works as you expect it to work, out of the box, 
without reading any documentation.

And yes, ivy and helm have more features, so if you prefer ivy or helm, 
just use ivy or helm.

>
> 4. icomplete-mode reinvents the wheel and is already in Emacs.
>

No, icomplete-mode does not reinvent the wheel, it came first, then came 
ido-mode, then ivy and helm.

Re: Feature branches review please

[Jean Louis]

* Gregory Heytings <ghe@sdf.org> [2020-11-06 01:25]:
> 
> > 
> > I expect to be able to move in vertical line, not only type letters.
> > Feeling is rigid, I cannot move up and down with familiar keys likes C-n
> > or C-p like I can do in ivy-mode or in helm
> > 
> 
> With icomplete-mode, C-h m tells you that:
> 
> C-, is icomplete-backward-completions
> C-. is icomplete-forward-completions

Sorry for omission.

I am not used to those keys. When you are in M-x shell or in terminal,
or in bash, or in eshell keys are C-p and C-n, those keys are
everywhere. Of course I am not used to C-, and C-. even they could be
popular, I have no idea. 

> (define-key icomplete-minibuffer-map (kbd "C-n") 'icomplete-forward-completions)
> (define-key icomplete-minibuffer-map (kbd "C-p")
> 'icomplete-backward-completions)

Of course I can.

But I need not do it in ivy- helm-, and is surprise for ido- and
icomplete- to follow different key bindings. I am giving you review,
it is not that I will use icomplete. I am giving you impression upon
which you may think and maybe act, ideas for considerations.

> I looked at your video, most of the time I do not understand what you try to
> do.  Of course nothing works as you expect it to work, out of the box,
> without reading any documentation.

I have been demonstrating differences, maybe it is too fast. I have
tried moving up and down and narrowing the search, showing actions and
possibilities. Comparing icomplete to ido.

> And yes, ivy and helm have more features, so if you prefer ivy or helm, just
> use ivy or helm.

That I know already. 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.

> > 4. icomplete-mode reinvents the wheel and is already in Emacs.
> 
> No, icomplete-mode does not reinvent the wheel, it came first, then came
> ido-mode, then ivy and helm.

OK it came first, then ido-mode became better, it had to be
merged. Now we have ido-mode that works and icomplete coming that does
not work but does anything what ido-mode does. Sorry I get confused
there.

What I need is basically dmenu for Emacs. Simple and general approach
for narrowing incremental search. That opens up plethora of
opportunities which I am already using. But I could make packages for
Emacs. Dmenu: https://tools.suckless.org/dmenu/

- database backed accounting becomes easy to do

- multi-companies issuing many invoices for variety of goods or
  articles

- supermarket inventory

- managing unlimited mailing lists

- accurate statistics provisioning with graphs for organizations

- translations

- template expansion for website revision systems

- website revision system

- handling tasks

- handling SMS-es, emails, locations on file system

- human resource management

- relations between people

- contact management

- sales flow

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 could as well use dmenu from within Emacs, that would be useful but
it would be mixture of various interfaces. It can complete any kind of
lists. 

System should be by KISS principle. Even ivy and helm are way too
complicated. Helm has too many options on display and is not user
friendly. 

Re: Feature branches review please

[Gregory Heytings via Emacs development discussions.]

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

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

404 Not Found...

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)

[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

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)

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

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

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

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

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

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

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