Feature branches review please

Feature branches review please

[Ergus]

Hi:

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?

OTOH the highlight-completions branch is almost ready too. I have more
doubts about this and maybe I will be doing some unneeded things there,
so maybe a review with some critics and advises will be very very
welcome.

Best,
Ergus

Re: Feature branches review please

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

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

Thanks.  I've never used icomplete before, but FWIW I just gave it a
quick whirl with icomplete-separator set to "\n" and the orderless
package installed, and it seems to work fine.

The only thing that caught my eye in the code is that variables defined
with defvar-local can be set with setq; they don't need setq-local,
since they automatically become buffer-local when set.

> OTOH the highlight-completions branch is almost ready too. I have more
> doubts about this and maybe I will be doing some unneeded things there,
> so maybe a review with some critics and advises will be very very
> welcome.

I have yet to try this branch out, but it sounds cool.

-- 
Basil

Re: Feature branches review please

[Gregory Heytings via Emacs development discussions.]

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

2. These two lines do not implement a 100% correct icomplete-vertical, 
sometimes the prompt is still hidden (in cases where it could/should be 
displayed).  But the approach you use (calculating the height of the 
minibuffer contents pixelwise) is not 100% correct either.

3. The only correct approach is to ask redisplay to start displaying the 
minibuffer at beginning of buffer.  I provided a simple solution to do 
this, but Eli doesn't like it.  He thinks another solution (using text 
properties) should be implemented.  Stefan thinks yet another solution 
(using the buffer redisplay routines instead of using a specific code for 
minibuffers) should be used.  In short, there is no clear agreement.

4. FWIW, I (and a few others) have been using the solution I provided, and 
it works flawlessly.

Gregory

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

[Stefan Monnier]

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

FWIW, such actions would be a great addition to the generic completion.
If done well, it could help unify a bit more Ivy, Helm, Icomplete, and
the default completion.  Currently in Icomplete there is a very limited
and ad-hoc support for actions in the form of the "kill" action when
selecting buffers.

I think we should try and generalize that.  If someone with experience
with Ivy or Helm actions would like to tackle that, that'd be great.
And if they feel like they don't know enough about the minibuffer.el
code for that, don't be afraid: I'd be happy to help.


        Stefan

Re: Feature branches review please

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-05 21:51]:
> > 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?
> 
> FWIW, such actions would be a great addition to the generic completion.
> If done well, it could help unify a bit more Ivy, Helm, Icomplete, and
> the default completion.  Currently in Icomplete there is a very limited
> and ad-hoc support for actions in the form of the "kill" action when
> selecting buffers.

And why not include ivy straight into Emacs and then build on top of
it?

Also tabulated-list-mode would need built-in incremental narrowing
search. That would be great too. I have application working in that mode.

Who can help me check out the icomplete-vertical branch that I may
try? I am working on application Hyperscope that is based on
Engelbart's work and it uses browsable tabulated-list-mode. Sometimes
there are many choices, the list can be really long. Index of specific
pages in PDF file can be thousands and thousands. Of course I have
implemented incremental narrowing by using Helm and I wish to switch
it to something built-in.q I wish to give those to GNU ELPA soon. But
with focus on least number of packages from outside.

Insight with some bugs:
https://gnu.support/images/2020/11/2020-11-05/2020-11-05-22:14:01.ogv

and export to Org mode:
https://gnu.support/images/2020/11/2020-11-05/2020-11-05-22:23:20.ogv

For that system I need vertical incremental narrowing search. I would
be best if tabulated-list-mode provides such function.

Help me to checkout that ivertical branch. How do I get it?

I have tried git branch --list but I see only master.

Re: Feature branches review please

[Eli Zaretskii]

> Date: Thu, 5 Nov 2020 22:30:31 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Gregory Heytings <ghe@sdf.org>, Manuel Uberti <manuel.uberti@inventati.org>,
>  emacs-devel@gnu.org
> 
> Who can help me check out the icomplete-vertical branch that I may
> try?

Emacs:

  M-s M-w how to checkout a git branch RET

Re: Feature branches review please

[Adam Porter]

Jean Louis <bugs@gnu.support> writes:

> Who can help me check out the icomplete-vertical branch that I may
> try? I am working on application Hyperscope that is based on
> Engelbart's work and it uses browsable tabulated-list-mode. Sometimes
> there are many choices, the list can be really long. Index of specific
> pages in PDF file can be thousands and thousands. Of course I have
> implemented incremental narrowing by using Helm and I wish to switch
> it to something built-in.q I wish to give those to GNU ELPA soon. But
> with focus on least number of packages from outside.
>
> Insight with some bugs:
> https://gnu.support/images/2020/11/2020-11-05/2020-11-05-22:14:01.ogv

That looks interesting.  It reminds me of Semantic Synchrony, an Emacs
project which seems to not be very well known.  This video in particular
reminds me of yours: https://www.youtube.com/watch?v=R2vX2oZmUUM  See
also: https://github.com/synchrony/smsn

hyperscope

[Jean Louis]

* Adam Porter <adam@alphapapa.net> [2020-11-06 00:56]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Who can help me check out the icomplete-vertical branch that I may
> > try? I am working on application Hyperscope that is based on
> > Engelbart's work and it uses browsable tabulated-list-mode. Sometimes
> > there are many choices, the list can be really long. Index of specific
> > pages in PDF file can be thousands and thousands. Of course I have
> > implemented incremental narrowing by using Helm and I wish to switch
> > it to something built-in.q I wish to give those to GNU ELPA soon. But
> > with focus on least number of packages from outside.
> >
> > Insight with some bugs:
> > https://gnu.support/images/2020/11/2020-11-05/2020-11-05-22:14:01.ogv
> 
> That looks interesting.  It reminds me of Semantic Synchrony, an Emacs
> project which seems to not be very well known.  This video in particular
> reminds me of yours: https://www.youtube.com/watch?v=R2vX2oZmUUM  See
> also: https://github.com/synchrony/smsn

Ineed it looks very similar by concept. I will study that. My system
was meant primarily for me so that I can quickly pin point what I need
in the index and jump to specific reference. It is like augmented
bookmark system. Because it is database, once link type is defined
there is no limit to it.

Hyperscope is meant to:

- dwell in eww buffer, press w and later just insert hyperlink with
  good description

- dwell in any browser, obtain reference and quickly enter into
  database

- obtain reference from online video or specific time when to play
  video, and quickly enter database, or specific line in specific
  file, to jump quickly there, or PDF specific page or specific search
  term. Not all readers provide support for that.

- to obtain specific mail reference and jump to that specific mail

- use various indexes to enter into database, to quickly jump to very
  specific places

- to represent the database by various means, converting to Org is
  easy, but it could as well be dynamically published on WWW, Gopher,
  Gemini

- to allow multi user knowledge information editing or revisions (no
  idea how to make revisions yet), remotely

- to allow connections to other databases, meaning that only database
  is running on server and with permissions some people can view it
  and some people can edit it.

- to provide feature for any kind of hyperlinks

- raise collective IQ

For now I have these types of links:

 Web
 MPV play video at exact time
 Local File
 YouTube Video at exact time
 YouTube Video
 Dired Directory
 Launch Program
 Media
 Info Node
 PDF
 HyperScope ID
 Emacs Lisp
 PDF Query
 Org Heading
 Org
 PDF by Page Nr.
 Set
 DJVU
 Note
 Video

Re: hyperscope

[Eduardo Ochs]

On Fri, 6 Nov 2020 at 06:10, Jean Louis <bugs@gnu.support> wrote:
>
> * Adam Porter <adam@alphapapa.net> [2020-11-06 00:56]:
> > Jean Louis <bugs@gnu.support> writes:
> >
> > > Who can help me check out the icomplete-vertical branch that I may
> > > try? I am working on application Hyperscope that is based on
> > > Engelbart's work and it uses browsable tabulated-list-mode. Sometimes
> > > there are many choices, the list can be really long. Index of specific
> > > pages in PDF file can be thousands and thousands. Of course I have
> > > implemented incremental narrowing by using Helm and I wish to switch
> > > it to something built-in.q I wish to give those to GNU ELPA soon. But
> > > with focus on least number of packages from outside.
> > >
> > > Insight with some bugs:
> > > https://gnu.support/images/2020/11/2020-11-05/2020-11-05-22:14:01.ogv
> >
> > That looks interesting.  It reminds me of Semantic Synchrony, an Emacs
> > project which seems to not be very well known.  This video in particular
> > reminds me of yours: https://www.youtube.com/watch?v=R2vX2oZmUUM  See
> > also: https://github.com/synchrony/smsn
>
> Ineed it looks very similar by concept. I will study that. My system
> was meant primarily for me so that I can quickly pin point what I need
> in the index and jump to specific reference. It is like augmented
> bookmark system. Because it is database, once link type is defined
> there is no limit to it.
>
> Hyperscope is meant to:
>
> - dwell in eww buffer, press w and later just insert hyperlink with
>   good description
>
> - dwell in any browser, obtain reference and quickly enter into
>   database
>
> - obtain reference from online video or specific time when to play
>   video, and quickly enter database, or specific line in specific
>   file, to jump quickly there, or PDF specific page or specific search
>   term. Not all readers provide support for that.
>
> - to obtain specific mail reference and jump to that specific mail
>
> - use various indexes to enter into database, to quickly jump to very
>   specific places
>
> - to represent the database by various means, converting to Org is
>   easy, but it could as well be dynamically published on WWW, Gopher,
>   Gemini
>
> - to allow multi user knowledge information editing or revisions (no
>   idea how to make revisions yet), remotely
>
> - to allow connections to other databases, meaning that only database
>   is running on server and with permissions some people can view it
>   and some people can edit it.
>
> - to provide feature for any kind of hyperlinks
>
> - raise collective IQ
>
> For now I have these types of links:
>
>  Web
>  MPV play video at exact time
>  Local File
>  YouTube Video at exact time
>  YouTube Video
>  Dired Directory
>  Launch Program
>  Media
>  Info Node
>  PDF
>  HyperScope ID
>  Emacs Lisp
>  PDF Query
>  Org Heading
>  Org
>  PDF by Page Nr.
>  Set
>  DJVU
>  Note
>  Video

Hi Jean Louis,

do you have examples of the syntax of these links and of what we need
to make them work? I am especially interested in "MPV play video at
exact time", "Launch Program", "Media", "PDF by Page Nr." and "Set"...

I am asking because one of the topics of my talk at the next EmacsConf
(in a few weeks!) is how eev implements links to all these things,
and I want to compare eev's approach with other packages. See:

  http://angg.twu.net/eev-intros/find-pdf-like-intro.html
  http://angg.twu.net/eev-intros/find-audiovideo-intro.html

I know org-player and org-pdftools, but I found them hard to set up.

Thanks in advance, I hope =),

  Eduardo Ochs
  http://angg.twu.net/emacsconf2019.html
  http://angg.twu.net/emacsconf2020.html

Re: hyperscope

[Jean Louis]

* Eduardo Ochs <eduardoochs@gmail.com> [2020-11-06 21:19]:
> do you have examples of the syntax of these links and of what we need
> to make them work? I am especially interested in "MPV play video at
> exact time", "Launch Program", "Media", "PDF by Page Nr." and
> "Set"...

I do not have universal approach similar like URL, it is database
approach such as (hyperscope 123) where ID 123 is defined to open
specific video at specific time. Links are shown to user on screen as
such and users define them but they are not accessible without
database.

> I am asking because one of the topics of my talk at the next EmacsConf
> (in a few weeks!) is how eev implements links to all these things,
> and I want to compare eev's approach with other packages. See:
> 
>   http://angg.twu.net/eev-intros/find-pdf-like-intro.html
>   http://angg.twu.net/eev-intros/find-audiovideo-intro.html

I was researching eev before weeks and it has alignment with some
principles of collective IQ creation, so I may as well include eev
mode in my hyperscope if such exist. 

Here are some functions handling those links, you may see that mpv
opens up by using id

(defun hlink-mpv-play-video-at-exact-time (id)
  (let* ((link (hlinks-link id))
	 (arguments (hlinks-arguments id))
	 (command (format "mpv --start=%s '%s'" arguments link)))
    (async-shell-command command)
    (hlink-description-show id)))

(defun hlink-show-pdf-by-page (link argument)
  "Opens the PDF page by number"
  (funcall (intern hyperscope-pdf-function) link argument))

hyperscope-pdf-function:

(defun hyperscope-evince (file &optional page query)
  "Opens PDF with evince document viewer"
  (let* ((command "evince")
	 (command (if page (format "%s --page-index=%s" command page) command))
	 (command (if query (format "%s -l '%s'" command query) command))
	 (command (format "%s '%s'" command file)))
    (async-shell-command command)))

> I know org-player and org-pdftools, but I found them hard to set up.

It is better you make simple eev based functions to handle such links.

Maybe this function below can open PDF inside of Emacs at specific
page number for maybe specific query in PDF/DJVU/DVI or specific
match. But it could be as well not functional. I have to test it to
confirm, but you could reuse for evv to view PDF/DJVU/DVI finely
grained inside of Emacs.

(defun doc-view-open-file (file &optional page-number query match)
  "Opens PDF file in GNU Emacs at specific page number or at
specific match"
  (let* ((allowed-extensions '("pdf" "djvu" "dvi"))
	 (file-ext (file-name-extension file))
	 (match (if match match 0)))
    (when (and (file-exists-p file)
	       (seq-contains-p allowed-extensions file-ext 'equalp))
      (setq doc-view--current-search-matches nil)
      (let ((created (create-file-buffer file))
	    (buffer (get-file-buffer file)))
	(switch-to-buffer created)
	(set-visited-file-name file t)
	(insert file)
	(doc-view-mode)
	(read-only-mode)
	(when page-number
	  (doc-view-goto-page page-number))
	(when query
	  (let ((txt (expand-file-name "doc.txt"
				       (doc-view--current-cache-dir))))
	    (if (file-readable-p txt)
		(progn
		  (setq doc-view--current-search-matches
			(doc-view-search-internal query txt))
		  (doc-view-search-next-match match)))))))))

Re: Feature branches review please

[Jean Louis]

* Adam Porter <adam@alphapapa.net> [2020-11-06 00:56]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Who can help me check out the icomplete-vertical branch that I may
> > try? I am working on application Hyperscope that is based on
> > Engelbart's work and it uses browsable tabulated-list-mode. Sometimes
> > there are many choices, the list can be really long. Index of specific
> > pages in PDF file can be thousands and thousands. Of course I have
> > implemented incremental narrowing by using Helm and I wish to switch
> > it to something built-in.q I wish to give those to GNU ELPA soon. But
> > with focus on least number of packages from outside.
> >
> > Insight with some bugs:
> > https://gnu.support/images/2020/11/2020-11-05/2020-11-05-22:14:01.ogv
> 
> That looks interesting.  It reminds me of Semantic Synchrony, an Emacs
> project which seems to not be very well known.  This video in particular
> reminds me of yours: https://www.youtube.com/watch?v=R2vX2oZmUUM  See
> also: https://github.com/synchrony/smsn

Thank you.

I was thinking it is Emacs, now I see it is Java and other stuff. I
find many good practical references there. On my side I simply use
PostgreSQL and it must be possible to use any kind of database when it
gets polished.

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

[Ergus]

On Thu, Nov 05, 2020 at 08:39:03PM +0000, Gregory Heytings via Emacs development discussions. wrote:
>
>>
>>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),

In which case the branch is not 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.

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

[Gregory Heytings via Emacs development discussions.]

>> 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),
>
> In which case the branch is not correct?
>

This has been discussed at length earlier: it is in practice impossible to 
calculate the height of the minibuffer, and to calculate the size of the 
completion candidates list to insert in the minibuffer.  Yet you need to 
do both to have a correct solution with the approach of the branch.

Re: Feature branches review please

[Jean Louis]

* Gregory Heytings <ghe@sdf.org> [2020-11-06 00:19]:
> 
> > > 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),
> > 
> > In which case the branch is not correct?
> > 
> 
> This has been discussed at length earlier: it is in practice impossible to
> calculate the height of the minibuffer, and to calculate the size of the
> completion candidates list to insert in the minibuffer.  Yet you need to do
> both to have a correct solution with the approach of the branch.

While this may not be mathematically possible, it can be observed that
ivy simply works much better then both the reinvented icomplete-mode
and built-in ido-mode.

Re: Feature branches review please

[Stefan Monnier]

> This has been discussed at length earlier: it is in practice impossible to
> calculate the height of the minibuffer, and to calculate the size of the
> completion candidates list to insert in the minibuffer.  Yet you need to do
> both to have a correct solution with the approach of the branch.

With the current display code on `master`, I don't think the behaviors
you refer to can qualify as incorrect.  You can argue that they are
less often preferable than some other choice, but that's a far cry from
incorrect, IMO, and then should be fairly uncommon.  So it's definitely
not very high priority and shouldn't decide whether we install
a particular version of the code right now.


        Stefan

Re: Feature branches review please

[Gregory Heytings via Emacs development discussions.]

>> This has been discussed at length earlier: it is in practice impossible 
>> to calculate the height of the minibuffer, and to calculate the size of 
>> the completion candidates list to insert in the minibuffer.  Yet you 
>> need to do both to have a correct solution with the approach of the 
>> branch.
>
> With the current display code on `master`, I don't think the behaviors 
> you refer to can qualify as incorrect.
>

Which is why I said, in the two previous mails, "not 100% correct" and 
"not always correct".  I did not think it was necessary to repeat "always" 
here.

>
> You can argue that they are less often preferable than some other 
> choice, but that's a far cry from incorrect, IMO, and then should be 
> fairly uncommon.  So it's definitely not very high priority and 
> shouldn't decide whether we install a particular version of the code 
> right now.
>

My point is that now that `(setq icomplete-separator "\n")' works (in most 
but not all cases), there is no need for the specific vertical-icomplete 
implementation anymore.  What is (or could be) needed is an implementation 
that is "more correct" (correct in all cases).

Re: Feature branches review please

[Ergus]

On Thu, Nov 05, 2020 at 10:00:57PM +0000, Gregory Heytings via Emacs development discussions. wrote:
>
>>>This has been discussed at length earlier: it is in practice 
>>>impossible to calculate the height of the minibuffer, and to 
>>>calculate the size of the completion candidates list to insert in 
>>>the minibuffer.  Yet you need to do both to have a correct 
>>>solution with the approach of the branch.
>>
>>With the current display code on `master`, I don't think the 
>>behaviors you refer to can qualify as incorrect.
>>
>
>Which is why I said, in the two previous mails, "not 100% correct" and 
>"not always correct".  I did not think it was necessary to repeat 
>"always" here.
>
>>
>>You can argue that they are less often preferable than some other 
>>choice, but that's a far cry from incorrect, IMO, and then should be 
>>fairly uncommon.  So it's definitely not very high priority and 
>>shouldn't decide whether we install a particular version of the code 
>>right now.
>>
>
>My point is that now that `(setq icomplete-separator "\n")' works (in 
>most but not all cases), there is no need for the specific 
>vertical-icomplete implementation anymore.  What is (or could be) 
>needed is an implementation that is "more correct" (correct in all 
>cases).
>
I don't totally agree is the same than the branch.

The completion like "compi{compilation" with fido mode is still there,
in the same line and is not intuitive; the ellipsis is not shown and the
{} and [] are still there and hard coded. icomplete-prospects-height is
not respected either because the number of candidates is still
calculated with the window-width and adding the candidates length which
actually makes no sense at all in vertical mode.

The pixel calculation is just part of the modifications in the branch.

Re: Feature branches review please

[Gregory Heytings via Emacs development discussions.]

>> My point is that now that `(setq icomplete-separator "\n")' works (in 
>> most but not all cases), there is no need for the specific 
>> vertical-icomplete implementation anymore.  What is (or could be) 
>> needed is an implementation that is "more correct" (correct in all 
>> cases).
>
> I don't totally agree is the same than the branch.
>
> The completion like "compi{compilation" with fido mode is still there, 
> in the same line and is not intuitive; the ellipsis is not shown and the 
> {} and [] are still there and hard coded. icomplete-prospects-height is 
> not respected either because the number of candidates is still 
> calculated with the window-width and adding the candidates length which 
> actually makes no sense at all in vertical mode.
>

These are details, which AFAICS require only minor modifications to the 
existing code.

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

[Basil L. Contovounesios]

Jean Louis <bugs@gnu.support> writes:

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

There's a different thread for that:

https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg01095.html
https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00114.html

> But ivy-mode is light

Depends on what you compare it to. ;)

-- 
Basil

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

Could ivy minibuffer stay where it is?

[Jean Louis]

Oleh, is there a setting for Ivy that minibuffer stays where it is?

You may see the difference between:

counsel-M-x

and

helm-M-x as this one creates 2 buffers, one for selection while
minibuffer stays where it is. This is my preferred way of work. As
user is typing and should not move his eyes or focus from familiar
place in this case minibuffer.

Could you consider adding such option that prompt remains in the
minibuffer while selection is above minibuffer?

Re: Could ivy minibuffer stay where it is?

[Basil L. Contovounesios]

Jean Louis <bugs@gnu.support> writes:

> Oleh, is there a setting for Ivy that minibuffer stays where it is?
>
> You may see the difference between:
>
> counsel-M-x
>
> and
>
> helm-M-x as this one creates 2 buffers, one for selection while
> minibuffer stays where it is. This is my preferred way of work. As
> user is typing and should not move his eyes or focus from familiar
> place in this case minibuffer.
>
> Could you consider adding such option that prompt remains in the
> minibuffer while selection is above minibuffer?

Ivy was explicitly designed with the minibuffer in mind, just like
built-in minibuffer completion.  That said, it's possible to customise
where completions appear.  For example, in-buffer completion is
displayed in an overlay at point, not in the minibuffer.
See e.g. the following for more information:

- https://github.com/abo-abo/swiper/wiki/ivy-display-function
- ivy-display-functions-alist
- ivy-display-functions-props
- https://github.com/tumashu/ivy-posframe

-- 
Basil

Re: Could ivy minibuffer stay where it is?

[Jean Louis]

* Basil L. Contovounesios <contovob@tcd.ie> [2020-11-06 18:21]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Oleh, is there a setting for Ivy that minibuffer stays where it is?
> >
> > You may see the difference between:
> >
> > counsel-M-x
> >
> > and
> >
> > helm-M-x as this one creates 2 buffers, one for selection while
> > minibuffer stays where it is. This is my preferred way of work. As
> > user is typing and should not move his eyes or focus from familiar
> > place in this case minibuffer.
> >
> > Could you consider adding such option that prompt remains in the
> > minibuffer while selection is above minibuffer?
> 
> Ivy was explicitly designed with the minibuffer in mind, just like
> built-in minibuffer completion.  That said, it's possible to customise
> where completions appear.  For example, in-buffer completion is
> displayed in an overlay at point, not in the minibuffer.
> See e.g. the following for more information:
> 
> - https://github.com/abo-abo/swiper/wiki/ivy-display-function
> - ivy-display-functions-alist
> - ivy-display-functions-props
> - https://github.com/tumashu/ivy-posframe

That is it! Definitely good solution.

Can that function `ivy-display-function-window' be included in ivy on
GNU ELPA?

This is to build applications based on GNU ELPA package, to minimize
any outside dependencies.

Re: Could ivy minibuffer stay where it is?

[Basil L. Contovounesios]

Jean Louis <bugs@gnu.support> writes:

> * Basil L. Contovounesios <contovob@tcd.ie> [2020-11-06 18:21]:
>> Jean Louis <bugs@gnu.support> writes:
>> 
>> > Oleh, is there a setting for Ivy that minibuffer stays where it is?
>> >
>> > You may see the difference between:
>> >
>> > counsel-M-x
>> >
>> > and
>> >
>> > helm-M-x as this one creates 2 buffers, one for selection while
>> > minibuffer stays where it is. This is my preferred way of work. As
>> > user is typing and should not move his eyes or focus from familiar
>> > place in this case minibuffer.
>> >
>> > Could you consider adding such option that prompt remains in the
>> > minibuffer while selection is above minibuffer?
>> 
>> Ivy was explicitly designed with the minibuffer in mind, just like
>> built-in minibuffer completion.  That said, it's possible to customise
>> where completions appear.  For example, in-buffer completion is
>> displayed in an overlay at point, not in the minibuffer.
>> See e.g. the following for more information:
>> 
>> - https://github.com/abo-abo/swiper/wiki/ivy-display-function
>> - ivy-display-functions-alist
>> - ivy-display-functions-props
>> - https://github.com/tumashu/ivy-posframe
>
> That is it! Definitely good solution.
>
> Can that function `ivy-display-function-window' be included in ivy on
> GNU ELPA?

I don't know, that's Oleh's call.  I vaguely remember a preference for
showcasing these potential customisations in the wiki, rather than
maintaining them as part of Ivy, but I'm not sure.

-- 
Basil

Re: Could ivy minibuffer stay where it is?

[Oleh Krehel]

>> That is it! Definitely good solution.
>>
>> Can that function `ivy-display-function-window' be included in 
>> ivy on
>> GNU ELPA?
>
> I don't know, that's Oleh's call.  I vaguely remember a 
> preference for
> showcasing these potential customisations in the wiki, rather 
> than
> maintaining them as part of Ivy, but I'm not sure.

I think `ivy-display-function-window' is not in a good enough 
state to be included as part of Ivy. My suggestion right now, if 
you want to avoid the minibuffer, is to use 
https://github.com/tumashu/ivy-posframe. It's higher quality and 
more customizable.

But if someone wants to work on `ivy-display-function-window' to 
make it usable, PRs are welcome.

kind regards,
Oleh

Re: Could ivy minibuffer stay where it is?

[Jean Louis]

* Oleh Krehel <ohwoeowho@gmail.com> [2020-11-07 15:52]:
> > > That is it! Definitely good solution.
> > > 
> > > Can that function `ivy-display-function-window' be included in ivy
> > > on
> > > GNU ELPA?
> > 
> > I don't know, that's Oleh's call.  I vaguely remember a preference for
> > showcasing these potential customisations in the wiki, rather than
> > maintaining them as part of Ivy, but I'm not sure.
> 
> I think `ivy-display-function-window' is not in a good enough state to be
> included as part of Ivy. My suggestion right now, if you want to avoid the
> minibuffer, is to use https://github.com/tumashu/ivy-posframe. It's higher
> quality and more customizable.

Alright, I appreciate your help.

Purpose of enhancement is not for me to find what to use, as if I want
to avoid ivy I can use helm or use X, but that is not the point. My
proposal is to enhance ivy as ivy is in GNU ELPA and I am trying that
new packages I am preparing are not dependent on libraries outside of
GNU ELPA (for now).

> But if someone wants to work on `ivy-display-function-window' to
> make it usable, PRs are welcome.

I am not familiar with that code but use it in other code.

Is there way to automatically switch for every ivy completion to
ivy-display-function-window?

Re: Could ivy minibuffer stay where it is?

[Oleh Krehel]

> Is there way to automatically switch for every ivy completion to
> ivy-display-function-window?

(setq ivy-display-functions-alist '((t 
. ivy-display-function-window)))

Re: Could ivy minibuffer stay where it is?

[Jean Louis]

* Oleh Krehel <ohwoeowho@gmail.com> [2020-11-08 14:21]:
> 
> > Is there way to automatically switch for every ivy completion to
> > ivy-display-function-window?
> 
> (setq ivy-display-functions-alist '((t . ivy-display-function-window)))

Oh, how could I miss that. It was in front of my eyes. Thank you.

Do you mind giving me a tip to turn on something like hl-line-mode in
ivy. That would enhance visibility where user watches with eyes. Fnacy
highlighting ivy remains but whole line gets hl-line-mode. I have
tried with ivy-mode-hook but it stays where is cursors. That is what
is meant to do. I was wrongly thinking that double cursor is on ivy
match

Window mode has its problems I can see here. If you make something
like that then I can give you hints what is happening. Now is useless
for outside function to explain.

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.

Re: Feature branches review please

[Juri Linkov]

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

In shell, C-p and C-n move through the history, not through completions.
Here's is an excerpt from the bash man page:

  previous-history (C-p)
    Fetch the previous command from the history list, moving back in the list.

  next-history (C-n)
    Fetch the next command from the history list, moving forward in the list.

Maybe icomplete could be more DWIM, and when completions are displayed,
then use [up] and [down] keys to move through completions, otherwise
move through the history when the minibuffer contents is empty.

RE: Feature branches review please

[Drew Adams]

> In shell, C-p and C-n move through the history, not through
> completions.
> 
> Maybe icomplete could be more DWIM, and when completions are displayed,
> then use [up] and [down] keys to move through completions, otherwise
> move through the history when the minibuffer contents is empty.

C-p and C-n in the minibuffer should do what they
do normally.  The minibuffer is a text-editing
buffer, and it can have multiple lines of text.

(For minibuffer history we have M-p and M-n instead.)
___

FWIW, in Icicles the `up' and `down' arrows do cycle
among completion candidates.

And `C-up' and `C-down' cycle and act on each candidate,
in turn.  (You can apply the same command to multiple
candidates, in any order.  Cycling follows the current
sort order.)

And `C-M-up' and `C-M-down' show help on each candidate,
in turn.

And `C-wheel-up' and C-wheel-down', and same with `C-M-',
do the same kinds of cycling.

And `C-S-up' and `C-S-down' are like `C-up' and `C-down',
but they use an alternate action.  And likewise, with the
mouse wheel.

Re: Feature branches review please

[Alan Mackenzie]

Hello, Jean.

On Thu, Nov 05, 2020 at 20:32:32 +0300, Jean Louis wrote:

[ .... ]

> How can I checkout that branch?

I'm not sure if anybody's answered this question yet, so here is the
answer to what I think you're asking:

    $ git branch --list --all

should show you all the branches available at savannah.  There will be
lots of entries like

    remotes/origin/feature/icomplete-vertical

in the resulting output.

So all you now need to do is

    $ git checkout feature/icomplete-vertical

, which should fetch the branch from savannah for you and make it
current.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Feature branches review please

[Jean Louis]

* Alan Mackenzie <acm@muc.de> [2020-11-06 13:32]:
> I'm not sure if anybody's answered this question yet, so here is the
> answer to what I think you're asking:
> 
>     $ git branch --list --all
> 
> should show you all the branches available at savannah.  There will be
> lots of entries like
> 
>     remotes/origin/feature/icomplete-vertical

Thank you. I tried git branch --list and did not know for --all and
now I can see it. That will be great.

Re: Feature branches review please

[Jean Louis]

* Gregory Heytings <ghe@sdf.org> [2020-11-05 19:10]:
> 
> > 
> > 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.

I mean that icomplete should provide function for others:
`icomplete-completing-read' just in the spirit of Emacs.

> > - actions like ivy with M-o or helm with TAB
> > 
> 
> This I don't know, what do you mean by "actions"?

Thank you, thank you.

I also forgot to mention multiple choice.

Let us say I have a list COLLECTION, I can feed it into

- helm-completing-read
- ido-completing-read
- ivy-completing-read

there may be others. Some of them automatically replace the built-in
completing read.

Now in helm and ivy (what as that is all what I know until now), there
are "actions" which can determine what to do on the specific
selection. In helm I can press TAB to see actions, then I can choose
one of actions. In Ivy I press M-o

For example if ivy-mode is turned on, I can do C-x b and there is list
of buffers with incremental search, I can press M-o and I can see
actions: insert, copy, find file, other window, kill and
rename. Actions are customizable

As I prefer working with built-ins and reusing the built-in Emacs Lisp
functions, that is why I am asking you. Ivy is in GNU ELPA, helm is
outside of GNU ELPA, but best would be to have vertical completion
similar to both of them, but built-in.

Another point is that icomplete-completing-read should allow multiple
selections. In helm I can select with C-SPC multiple lines or choices.

Summary;

- if possible, provide multiple choices for icomplete, so that
  multiple list items can be returned

- provide actions on the selection, as default action is when I
  choose it, but I could have different selection. For example default
  action would be to view contact details, but I could have selection
  to send email to contact.

- incremental search is I guess there, I did not try that yet

- I like when completion function can find it in reverse, for example
  when writing words "Doe John" can select "He was John Doe"

I would be eventually using ido-mode, but it is not adequate and does
not have vertical incremental serach. Helm is best so far but it is
overkill for many applications. So now I am using `ivy-mode' as it is
in GNU ELPA. Even better would be to have incremental visual selection
with icomplete-* if it will come into main Emacs.

Jean

Re: Feature branches review please

[Andrii Kolomoiets]

Ergus <spacibba@aol.com> writes:

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

I'm not the maintainer, but can you please look into the following
issue?

Completions candidates not visible in the minibuffer-only frame.

In 'emacs -Q':
1. Enable icomplete-mode:
M-x icomplete-mode
2. Evaluate:
(setq resize-mini-frames t)
(setq icomplete-separator "\n")
(setq icomplete-prospects-height 4)
3. M-x i

Minibuffer now contains three completion candidates and ellipsis.

Repeat the same steps in
emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

Minibuffer now contains no completion candidates but only ellipsis.

Thank you!