fido-vertical bindings

fido-vertical bindings

[Ergus]

Hi Joao:

I just tried the new fido-vertical you added. I think there is a small
issue very simple to fix. In vertical mode either the right/left arrows
and C-n/p may be switched with the actual up/down and maybe C-r
C-s... to have a consistent behavior.

WDYT?

Best,
Ergus

Re: fido-vertical bindings

[João Távora]

Ergus <spacibba@aol.com> writes:

> I just tried the new fido-vertical you added.

I added it some time ago, IIRC.  What I've done very recently is make it
enable fido-mode automatically, so that you don't need two foo-mode
calls to get the desired functionality.  So

M-x fido-vertical-mode

is all you need.

> I think there is a small issue very simple to fix. In vertical mode
> either the right/left arrows and C-n/p may be switched with the actual
> up/down and maybe C-r C-s... to have a consistent behavior.

I had a tough time understanding what you meant, but now I think I do
and I just committed the patch after my sig.

If you use fido-vertical-mode, also notice the new goto-first/last stuff
suggested by Simon Lang in bug#49005.

João

diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 96b7e0f201..81fc6ff03c 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -624,6 +624,8 @@ icomplete-vertical-mode-minibuffer-map
   (let ((map (make-sparse-keymap)))
     (define-key map (kbd "C-n") 'icomplete-forward-completions)
     (define-key map (kbd "C-p") 'icomplete-backward-completions)
+    (define-key map (kbd "<down>") 'icomplete-forward-completions)
+    (define-key map (kbd "<up>") 'icomplete-backward-completions)
     (define-key map (kbd "M-<") 'icomplete-vertical-goto-first)
     (define-key map (kbd "M->") 'icomplete-vertical-goto-last)
     map)

Re: fido-vertical bindings

[Ergus]

Perfect!!

Very thanks Joao.

On Tue, Aug 17, 2021 at 01:08:37PM +0100, Jo�o T�vora wrote:
>Ergus <spacibba@aol.com> writes:
>
>> I just tried the new fido-vertical you added.
>
>I added it some time ago, IIRC.  What I've done very recently is make it
>enable fido-mode automatically, so that you don't need two foo-mode
>calls to get the desired functionality.  So
>
>M-x fido-vertical-mode
>
>is all you need.
>
>> I think there is a small issue very simple to fix. In vertical mode
>> either the right/left arrows and C-n/p may be switched with the actual
>> up/down and maybe C-r C-s... to have a consistent behavior.
>
>I had a tough time understanding what you meant, but now I think I do
>and I just committed the patch after my sig.
>
>If you use fido-vertical-mode, also notice the new goto-first/last stuff
>suggested by Simon Lang in bug#49005.
>
>Jo�o
>
>diff --git a/lisp/icomplete.el b/lisp/icomplete.el
>index 96b7e0f201..81fc6ff03c 100644
>--- a/lisp/icomplete.el
>+++ b/lisp/icomplete.el
>@@ -624,6 +624,8 @@ icomplete-vertical-mode-minibuffer-map
>   (let ((map (make-sparse-keymap)))
>     (define-key map (kbd "C-n") 'icomplete-forward-completions)
>     (define-key map (kbd "C-p") 'icomplete-backward-completions)
>+    (define-key map (kbd "<down>") 'icomplete-forward-completions)
>+    (define-key map (kbd "<up>") 'icomplete-backward-completions)
>     (define-key map (kbd "M-<") 'icomplete-vertical-goto-first)
>     (define-key map (kbd "M->") 'icomplete-vertical-goto-last)
>     map)
>
>
>

Re: fido-vertical bindings

[Ergus]

Just a question:

Why icomplete-scroll is not a custom? It is not intended to be set by
the user?

On Wed, Aug 18, 2021 at 02:25:58PM +0200, Ergus wrote:
>Perfect!!
>
>Very thanks Joao.
>
>On Tue, Aug 17, 2021 at 01:08:37PM +0100, Jo�o T�vora wrote:
>>Ergus <spacibba@aol.com> writes:
>>
>>>I just tried the new fido-vertical you added.
>>
>>I added it some time ago, IIRC.  What I've done very recently is make it
>>enable fido-mode automatically, so that you don't need two foo-mode
>>calls to get the desired functionality.  So
>>
>>M-x fido-vertical-mode
>>
>>is all you need.
>>
>>>I think there is a small issue very simple to fix. In vertical mode
>>>either the right/left arrows and C-n/p may be switched with the actual
>>>up/down and maybe C-r C-s... to have a consistent behavior.
>>
>>I had a tough time understanding what you meant, but now I think I do
>>and I just committed the patch after my sig.
>>
>>If you use fido-vertical-mode, also notice the new goto-first/last stuff
>>suggested by Simon Lang in bug#49005.
>>
>>Jo�o
>>
>>diff --git a/lisp/icomplete.el b/lisp/icomplete.el
>>index 96b7e0f201..81fc6ff03c 100644
>>--- a/lisp/icomplete.el
>>+++ b/lisp/icomplete.el
>>@@ -624,6 +624,8 @@ icomplete-vertical-mode-minibuffer-map
>>  (let ((map (make-sparse-keymap)))
>>    (define-key map (kbd "C-n") 'icomplete-forward-completions)
>>    (define-key map (kbd "C-p") 'icomplete-backward-completions)
>>+    (define-key map (kbd "<down>") 'icomplete-forward-completions)
>>+    (define-key map (kbd "<up>") 'icomplete-backward-completions)
>>    (define-key map (kbd "M-<") 'icomplete-vertical-goto-first)
>>    (define-key map (kbd "M->") 'icomplete-vertical-goto-last)
>>    map)
>>
>>
>>
>

Re: fido-vertical bindings

[João Távora]

Ergus <spacibba@aol.com> writes:

> Just a question:
>
> Why icomplete-scroll is not a custom?

No-one ever made it a customized variable.  I dislike too many customize
variables, but I don't oppose this one.

Expect `fido-vertical-mode` to override whatever you set there, though.
Fido-vertical-mode has a dropdown-style widget with icomplete-scroll set
to t.  If you don't like that (or or other Fidoesque detail), better
start with icomplete-vertical-mode and compose the many things you like
yourself, until you're happy.  Fido-mode is just one particular
customization of these many things that aims to emulate ido-mode (and a
typical dropdown widget, in the case of vertical stuff).

> It is not intended to be set by the user?

Users can set non-custom variables, too.

João

Re: fido-vertical bindings

[Ergus]

On Fri, Aug 20, 2021 at 10:55:29AM +0100, Jo�o T�vora wrote:
>Ergus <spacibba@aol.com> writes:
>
>> Just a question:
>>
>> Why icomplete-scroll is not a custom?
>
>No-one ever made it a customized variable.  I dislike too many customize
>variables,
That's the emacs way ;)

>but I don't oppose this one.
>
But if a variable can be safely changed by the user, then it must be a
custom, otherwise the variable is intended for internal use
right? So the "good" users assume they shouldn't touch it.

There are some others, should we change them too?

icomplete-tidy-shadowed-file-names
icomplete-in-buffer
icomplete-scroll

>Expect `fido-vertical-mode` to override whatever you set there, though.
>
icomplete-separator is overridden by all the vertical modes... so there
is a problem unrespecting the user customs any way.

This is why the initial attempt implementation I did for
icomplete-vertical used to check if there were newlines in
icomplete-separator; to respect somehow the user preferences and not add
new customs.

>Fido-vertical-mode has a dropdown-style widget with icomplete-scroll set
>to t.  If you don't like that (or or other Fidoesque detail), better
>start with icomplete-vertical-mode and compose the many things you like
>yourself, until you're happy.

I know, but the idea is that users can go to the customize page and find
the variables he can change and maybe what are the save values for them
if they want to manually tune their config.

>Fido-mode is just one particular
>customization of these many things that aims to emulate ido-mode (and a
>typical dropdown widget, in the case of vertical stuff).
>

>> It is not intended to be set by the user?
>
>Users can set non-custom variables, too.
>
But are harder to discover. The defcustom infrastructure and the
customize-* functions help us, as developers to improve user experience ;)

>Jo�o

Re: fido-vertical bindings

[André A. Gomes]

João Távora <joaotavora@gmail.com> writes:

> No-one ever made it a customized variable.  I dislike too many customize
> variables, but I don't oppose this one.

Interesting.  I'm just wondering, how does one decide what should be a
variable and a customize?  Thanks.


-- 
André A. Gomes
"Free Thought, Free World"

Re: fido-vertical bindings

[Ergus]

On Fri, Aug 20, 2021 at 02:51:48PM +0300, Andr� A. Gomes wrote:
>Jo�o T�vora <joaotavora@gmail.com> writes:
>
>> No-one ever made it a customized variable.  I dislike too many customize
>> variables, but I don't oppose this one.
>
>Interesting.  I'm just wondering, how does one decide what should be a
>variable and a customize?  Thanks.
>
If the user can modify it then it needs to be a customize. The users
shouldn't modify normal variables as they are intended to be for
internal uses only.





>
>-- 
>Andr� A. Gomes
>"Free Thought, Free World"

Re: fido-vertical bindings

[João Távora]

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

On Fri, Aug 20, 2021, 12:47 Ergus <spacibba@aol.com> wrote:

>No-one ever made it a customized variable.  I dislike too many customize
> >variables,
> That's the emacs way ;)
>

No, it's the custom.el way, which is a part of emacs, and which many users
like. Many others don't.

>but I don't oppose this one.
> >
> But if a variable can be safely changed by the user, then it must be a
> custom,


No. Not necessarily. There is, to the best of my understanding, no such
orthodoxy in Emacs. Maybe some other maintainer can correct me.

otherwise the variable is intended for internal use
> right? So the "good" users assume they shouldn't touch it.
>

No. The emacs user manual prescribes other ways to change variables, on
occasion. There is no such orthodoxy. Putting -- in a variable's prefix is
the way to mark it as intended for internal use.

This is why the initial attempt implementation I did for
> icomplete-vertical used to check if there were newlines in
> icomplete-separator; to respect somehow the user preferences and not add
> new customs.
>

In my experience, that kind of complexity to try to achieve custom.el
purity is always unwarranted.

>Users can set non-customizable variables
> But are harder to discover. The defcustom infrastructure and the

customize-* functions help us,
>

There are many means to discover variables and user visible structures.
That has been discussed at length here recently, so I won't repeat that
discussion.

João

>

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

Re: fido-vertical bindings

[João Távora]

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

On Fri, Aug 20, 2021, 12:51 André A. Gomes <andremegafone@gmail.com> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> Interesting.  I'm just wondering, how does one decide what should be a
> variable and a customize?
>

 I usually make variables and let others decide for me whether to "upgrade"
them. Another criteria is try to imagine it's there's any scenario where a
program might way to set that variable automatically. If there is, I'll
make a normal variable (and then again let other custom.el lovers worry
about the upgrading). Else I'll do the defcustom myself. If I'm creating a
very similar variable in form and function to another one, I'll follow
whichever style it has.

João

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

RE: [External] : Re: fido-vertical bindings

[Drew Adams]

> icomplete-separator is overridden by all the vertical modes...
> so there is a problem unrespecting the user customs any way.
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

FWIW (OT) -

I disagree with this black-&-white Emacs guideline, at
least if interpreted in a black-&-white, all-or-nothing
way.

The idea that code should not override (e.g. bind) a user
option is a sane one, as a general heuristic.  A user
preference needs to be respected.

On the other hand, it's not (should not be) the case that
no command should ever bind an option.  Use of a command
is itself optional.

If the purpose of the command requires binding an option,
AND if the doc for that command makes clear what happens
(e.g. the user's option value doesn't apply during
invocation of the command, but instead the behavior is
XYZ), then such binding can be appropriate.

It's about using common sense, keeping the user front
and center.  It's about communicating what the command
does clearly.  Then users can choose and have their
choices respected.  User choice is not only what option
value to set.  It can also be whether to use a command
that uses a different value of the option.
___

[Let's not forget that Customize itself offers commands
that let users change option values.  The purpose of
such commands involves possibly changing the value.
Interpreting the heuristic blindly would mean there
couldn't be any commands that let you set/change an
option value.  And yes, a library can define such
commands just as much as vanilla Emacs can do so.]
___

I'm not saying anything about Fido behavior here;
just a general opinion.  I dislike statements that a
command binding or ignoring an option value is
necessarily misguided or disrespectful of users.

Everything depends on what the command is designed to
do, AND whether its purpose is clearly doc'd for
users so they can choose without ignorance of the
behavior wrt the option.

RE: [External] : Re: fido-vertical bindings

[Drew Adams]

> > No-one ever made it a customized variable.  I dislike too many customize
> > variables, but I don't oppose this one.
> 
> Interesting.  I'm just wondering, how does one decide what should be a
> variable and a customize?  Thanks.

One considers things from an imagined user point
of view - multiple users, most users, minorities
of users, different kinds of users, in different
contexts.  But especially in the context of the
use case being addressed/considered.

There can't be any simple, hard-&-fast rule that's
useful for this.  Judgment's required, and people
can disagree about particular judgments.

(Just one opinion.)

RE: [External] : Re: fido-vertical bindings

[Drew Adams]

> If the user can modify it then it needs to be a customize. The users
> shouldn't modify normal variables as they are intended to be for
> internal uses only.

Wrong.  The whole idea or "internal only" is
inappropriate for free software, IMHO.

All it can mean is that you might not want
to modify XYZ because at some point Emacs dev
might change the code so that your code that
uses that modification no longer does what
you wrote it to do.

It's a head-up, to save you trouble dealing
with possible code changes. Any more limiting
interpretation of it is misguided, IMO.

User options and faces (the things we provide
Customize for) are _conveniences_.  Customize
exists for a reason, and that reason is not
to imprison users in a corral of only some
variables.

(Just one opinion.)

Re: [External] : Re: fido-vertical bindings

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Fri, 20 Aug 2021 15:42:17 +0000
> Cc: João Távora <joaotavora@gmail.com>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> The whole idea or "internal only" is inappropriate for free
> software, IMHO.

Bollocks.

RE: [External] : Re: fido-vertical bindings

[Drew Adams]

> > The whole idea or "internal only" is inappropriate for free
> > software, IMHO.
> 
> Bollocks.

Bollocks, IMHO.

Re: [External] : Re: fido-vertical bindings

[Richard Stallman]

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

  > > > The whole idea or "internal only" is inappropriate for free
  > > > software, IMHO.
  > > 
  > > Bollocks.

  > Bollocks, IMHO.

I agree with your position that "internal only" is reasonable.

"Internal only", in free software, means "We may change this interface
at any time.  Please don't call it.  If you do call it, and your code
breaks, that is not a bug; don't expect us to 'fix' it."

That is a perfectly legitimate position for a developer to take.

But please, when we disagree with someone else's opinion, let's
not use a harsh word such as "bollocks" to express disagreement.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: [External] : Re: fido-vertical bindings

[Drew Adams]

> > > > The whole idea or "internal only" is
> > > > inappropriate for free software, IMHO.
> > > Bollocks.
> > Bollocks, IMHO.
> 
> I agree with your position that "internal only" is
> reasonable, with the meaning you conveyed:
> 
> "Internal only", in free software, means "We may change this interface
> at any time.  Please don't call it.  If you do call it, and your code
> breaks, that is not a bug; don't expect us to 'fix' it."
> 
> That is a perfectly legitimate position for a developer to take.

Yes, it is.  And I think it's about what I said:

  All it can mean is that you might not want
  to modify XYZ because at some point Emacs dev
  might change the code so that your code that
  uses that modification no longer does what
  you wrote it to do.

  It's a head-up, to save you trouble dealing
  with possible code changes. Any more limiting
  interpretation of it is misguided, IMO.

It's letting users know that the code might
change at any time - you've been warned not to
expect otherwise.  I don't think it _can_
legitimately mean anything more than that.
It's an aid to users, as a heads-up.  It's not
a "Verboten!" sign.

I wrote in response to this:

 > If the user can modify it then it needs to be
 > a customize.  The users shouldn't modify normal
 > variables as they are intended to be for internal
 > uses only.

If that "should" is meant as "you probably don't
want to do that, and here's why: because you
probably don't want to write code that depends
on code that's likely to change" - then I agree
(for "internal" vars, not "normal" vars).

But if that "should" is meant as something more
than that, then I disagree.  There's nothing
"wrong" with ignoring an "internal only" sign.
There's nothing hidden or walled-off about such
code - and intentionally so, as free software.

If the "only" in "internal only" means we don't
want to encourage dependence on it, then yes.
If the "only" means something more, as in "ours
not yours - hands off!", then no.

And I don't think that "normal variables" are
considered for internal use only.  Most normal
variables aren't flagged as "internal only".
defcustoms aren't the only variables users can,
or "should" be able to, change.

(The old term for options, "user variables",
is even a bit unfortunate, as if only they
were open to use by users.)

There's a lot that can be packed into a little
expression such as "internal only".  Nuances
matter.  A message of "Off limits!" isn't very
helpful, IMO.  A message of "There be dragons!"
can be helpful.