zsh-workers
 help / color / mirror / code / Atom feed
* [RFC PATCH 0/3] Improve defaults
@ 2022-08-24  4:31 Felipe Contreras
  2022-08-24  4:31 ` [RFC PATCH 1/3] Make SAVEHIST default to HISTSIZE Felipe Contreras
                   ` (4 more replies)
  0 siblings, 5 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-08-24  4:31 UTC (permalink / raw)
  To: zsh-workers; +Cc: Felipe Contreras

It doesn't make much sense to specify so many options when simple
defaults can do it.

So instead of this:

    HISTFILE ~/.histfile
    HISTSIZE 1000
    SAVEHIST 1000

We can just do:

    HISTFILE ~/.histfile

I personally don't see the need to specify a file when virtually every
software dumps their history by default, but it's a start.

From what I can see most people simply set SAVEHIST to HISTSIZE, so it
makes sense to have a value to make them equal by default. I used -1.

I've tried for a while have the most minimal .zshrc file that is useful,
and never is that small. This should help.

Felipe Contreras (3):
  Make SAVEHIST default to HISTSIZE
  Increase default HISTSIZE to 1000
  FAQ: sync newuser-install

 Etc/FAQ.yo                            | 19 ++++++-------------
 Functions/Newuser/zsh-newuser-install |  2 --
 Src/builtin.c                         |  2 +-
 Src/hist.c                            | 14 ++++++++++----
 Src/init.c                            |  1 +
 StartupFiles/zshrc                    |  2 +-
 configure.ac                          |  2 +-
 7 files changed, 20 insertions(+), 22 deletions(-)

-- 
2.37.2.351.g9bf691b78c.dirty



^ permalink raw reply	[flat|nested] 93+ messages in thread

* [RFC PATCH 1/3] Make SAVEHIST default to HISTSIZE
  2022-08-24  4:31 [RFC PATCH 0/3] Improve defaults Felipe Contreras
@ 2022-08-24  4:31 ` Felipe Contreras
  2022-08-24  4:31 ` [RFC PATCH 2/3] Increase default HISTSIZE to 1000 Felipe Contreras
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-08-24  4:31 UTC (permalink / raw)
  To: zsh-workers; +Cc: Felipe Contreras

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Etc/FAQ.yo                            | 10 +++-------
 Functions/Newuser/zsh-newuser-install |  1 -
 Src/builtin.c                         |  2 +-
 Src/hist.c                            | 14 ++++++++++----
 Src/init.c                            |  1 +
 5 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo
index 8c795685a..a334dd384 100644
--- a/Etc/FAQ.yo
+++ b/Etc/FAQ.yo
@@ -1626,19 +1626,15 @@ work?)
 sect(Why is my history not being saved?)
 label(321)
 
-  In zsh, you need to set three variables to make sure your history is
+  In zsh, you need to set two variables to make sure your history is
   written out when the shell exits.  For example,
   verb(
     HISTSIZE=200
     HISTFILE=~/.zsh_history
-    SAVEHIST=200
   )
   tt($HISTSIZE) tells the shell how many lines to keep internally,
-  tt($HISTFILE) tells it where to write the history, and tt($SAVEHIST),
-  the easiest one to forget, tells it how many to write out.  The
-  simplest possibility is to set it to the same as tt($HISTSIZE) as
-  above.  There are also various options affecting history; see the
-  manual.
+  tt($HISTFILE) tells it where to write the history.  There are also various
+  options affecting history; see the manual.
 
 sect(How do I get a variable's value to be evaluated as another variable?)
 
diff --git a/Functions/Newuser/zsh-newuser-install b/Functions/Newuser/zsh-newuser-install
index 9e911d07c..26fcaed77 100644
--- a/Functions/Newuser/zsh-newuser-install
+++ b/Functions/Newuser/zsh-newuser-install
@@ -792,7 +792,6 @@ __zni_history_config() {
   __zni_apply_defaults -p \
     HISTSIZE 1000 "Number of lines of history kept within the shell." \
     HISTFILE $zdmsg/.histfile "File where history is saved." \
-    SAVEHIST 1000 "Number of lines of history to save to \$HISTFILE."
 
   if __zni_display_and_edit "History configuration"; then
     install_state[history]="Unsaved changes"
diff --git a/Src/builtin.c b/Src/builtin.c
index a7b7755a7..4c928d9bf 100644
--- a/Src/builtin.c
+++ b/Src/builtin.c
@@ -1442,7 +1442,7 @@ bin_fc(char *nam, char **argv, Options ops, int func)
     if (OPT_ISSET(ops,'p')) {
 	char *hf = "";
 	zlong hs = DEFAULT_HISTSIZE;
-	zlong shs = 0;
+	zlong shs = hs;
 	int level = OPT_ISSET(ops,'a') ? locallevel : -1;
 	if (*argv) {
 	    hf = *argv++;
diff --git a/Src/hist.c b/Src/hist.c
index bff0abe61..6cc612724 100644
--- a/Src/hist.c
+++ b/Src/hist.c
@@ -238,6 +238,12 @@ static zlong histfile_linect;
 
 /* save history context */
 
+static inline zlong
+get_savehistsiz(void)
+{
+    return savehistsiz < 0 ? histsiz : savehistsiz;
+}
+
 /**/
 void
 hist_context_save(struct hist_stack *hs, int toplevel)
@@ -1348,7 +1354,7 @@ putoldhistentryontop(short keep_going)
     if (isset(HISTEXPIREDUPSFIRST) && !(he->node.flags & HIST_DUP)) {
 	static zlong max_unique_ct = 0;
 	if (!keep_going)
-	    max_unique_ct = savehistsiz;
+	    max_unique_ct = get_savehistsiz();
 	do {
 	    if (max_unique_ct-- <= 0 || he == hist_ring) {
 		max_unique_ct = 0;
@@ -2904,7 +2910,7 @@ savehistfile(char *fn, int err, int writeflags)
     int extended_history = isset(EXTENDEDHISTORY);
     int ret;
 
-    if (!interact || savehistsiz <= 0 || !hist_ring
+    if (!interact || savehistsiz == 0 || !hist_ring
      || (!fn && !(fn = getsparam("HISTFILE"))))
 	return;
     if (writeflags & HFILE_FAST) {
@@ -2915,7 +2921,7 @@ savehistfile(char *fn, int err, int writeflags)
 	}
 	if (!he || lockhistfile(fn, 0))
 	    return;
-	if (histfile_linect > savehistsiz + savehistsiz / 5)
+	if (histfile_linect > get_savehistsiz() + get_savehistsiz() / 5)
 	    writeflags &= ~HFILE_FAST;
     }
     else {
@@ -3086,7 +3092,7 @@ savehistfile(char *fn, int err, int writeflags)
 		/* Zeroing histactive avoids unnecessary munging of curline. */
 		histactive = 0;
 		/* The NULL leaves HISTFILE alone, preserving fn's value. */
-		pushhiststack(NULL, savehistsiz, savehistsiz, -1);
+		pushhiststack(NULL, get_savehistsiz(), savehistsiz, -1);
 
 		hist_ignore_all_dups |= isset(HISTSAVENODUPS);
 		readhistfile(fn, err, 0);
diff --git a/Src/init.c b/Src/init.c
index 871d46b12..8a95192a9 100644
--- a/Src/init.c
+++ b/Src/init.c
@@ -962,6 +962,7 @@ setupvals(char *cmd, char *runscript, char *zsh_name)
     noeval = 0;
     curhist = 0;
     histsiz = DEFAULT_HISTSIZE;
+    savehistsiz = -1;
     inithist();
 
     cmdstack = (unsigned char *) zalloc(CMDSTACKSZ);
-- 
2.37.2.351.g9bf691b78c.dirty



^ permalink raw reply	[flat|nested] 93+ messages in thread

* [RFC PATCH 2/3] Increase default HISTSIZE to 1000
  2022-08-24  4:31 [RFC PATCH 0/3] Improve defaults Felipe Contreras
  2022-08-24  4:31 ` [RFC PATCH 1/3] Make SAVEHIST default to HISTSIZE Felipe Contreras
@ 2022-08-24  4:31 ` Felipe Contreras
  2022-08-24  4:31 ` [RFC PATCH 3/3] FAQ: sync newuser-install Felipe Contreras
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-08-24  4:31 UTC (permalink / raw)
  To: zsh-workers; +Cc: Felipe Contreras

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Etc/FAQ.yo                            | 9 +++------
 Functions/Newuser/zsh-newuser-install | 1 -
 StartupFiles/zshrc                    | 2 +-
 configure.ac                          | 2 +-
 4 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo
index a334dd384..74f8fbf6f 100644
--- a/Etc/FAQ.yo
+++ b/Etc/FAQ.yo
@@ -1626,15 +1626,12 @@ work?)
 sect(Why is my history not being saved?)
 label(321)
 
-  In zsh, you need to set two variables to make sure your history is
-  written out when the shell exits.  For example,
+  In zsh, you need to set the location where you want the history to be written
+  with tt($HISTFILE).  For example,
   verb(
-    HISTSIZE=200
     HISTFILE=~/.zsh_history
   )
-  tt($HISTSIZE) tells the shell how many lines to keep internally,
-  tt($HISTFILE) tells it where to write the history.  There are also various
-  options affecting history; see the manual.
+  There are also various options affecting history; see the manual.
 
 sect(How do I get a variable's value to be evaluated as another variable?)
 
diff --git a/Functions/Newuser/zsh-newuser-install b/Functions/Newuser/zsh-newuser-install
index 26fcaed77..c952ff03a 100644
--- a/Functions/Newuser/zsh-newuser-install
+++ b/Functions/Newuser/zsh-newuser-install
@@ -790,7 +790,6 @@ ${(F)unparsed}
 
 __zni_history_config() {
   __zni_apply_defaults -p \
-    HISTSIZE 1000 "Number of lines of history kept within the shell." \
     HISTFILE $zdmsg/.histfile "File where history is saved." \
 
   if __zni_display_and_edit "History configuration"; then
diff --git a/StartupFiles/zshrc b/StartupFiles/zshrc
index d4e1d03cc..f8a0233bf 100644
--- a/StartupFiles/zshrc
+++ b/StartupFiles/zshrc
@@ -79,7 +79,7 @@ export HELPDIR=/usr/share/zsh/$ZSH_VERSION/help  # directory for run-help functi
 unalias run-help && autoload -Uz run-help
 
 MAILCHECK=300
-HISTSIZE=200
+HISTSIZE=1000
 DIRSTACKSIZE=20
 
 # Watch for my friends
diff --git a/configure.ac b/configure.ac
index 890ef8dd2..6ca5c9189 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3213,7 +3213,7 @@ AH_TOP([/***** begin user configuration section *****/
 #define USE_SUSPENDED 1
  
 /* The default history buffer size in lines */
-#define DEFAULT_HISTSIZE 30
+#define DEFAULT_HISTSIZE 1000
 
 /* The default editor for the fc builtin */
 #define DEFAULT_FCEDIT "vi"
-- 
2.37.2.351.g9bf691b78c.dirty



^ permalink raw reply	[flat|nested] 93+ messages in thread

* [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24  4:31 [RFC PATCH 0/3] Improve defaults Felipe Contreras
  2022-08-24  4:31 ` [RFC PATCH 1/3] Make SAVEHIST default to HISTSIZE Felipe Contreras
  2022-08-24  4:31 ` [RFC PATCH 2/3] Increase default HISTSIZE to 1000 Felipe Contreras
@ 2022-08-24  4:31 ` Felipe Contreras
  2022-08-24  9:06   ` Daniel Shahaf
  2022-08-24 20:58 ` [RFC PATCH 0/3] Improve defaults Bart Schaefer
  2022-08-24 21:39 ` Mikael Magnusson
  4 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-08-24  4:31 UTC (permalink / raw)
  To: zsh-workers; +Cc: Felipe Contreras

Better to use the same HISTFILE in both.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Etc/FAQ.yo | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo
index 74f8fbf6f..326993314 100644
--- a/Etc/FAQ.yo
+++ b/Etc/FAQ.yo
@@ -1629,7 +1629,7 @@ label(321)
   In zsh, you need to set the location where you want the history to be written
   with tt($HISTFILE).  For example,
   verb(
-    HISTFILE=~/.zsh_history
+    HISTFILE=~/.histfile
   )
   There are also various options affecting history; see the manual.
 
-- 
2.37.2.351.g9bf691b78c.dirty



^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24  4:31 ` [RFC PATCH 3/3] FAQ: sync newuser-install Felipe Contreras
@ 2022-08-24  9:06   ` Daniel Shahaf
  2022-08-24 17:32     ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Daniel Shahaf @ 2022-08-24  9:06 UTC (permalink / raw)
  To: zsh-workers

Felipe Contreras wrote on Wed, 24 Aug 2022 04:31 +00:00:
> Better to use the same HISTFILE in both.

Agreed, but...

> +++ b/Etc/FAQ.yo
> @@ -1629,7 +1629,7 @@ label(321)
>    In zsh, you need to set the location where you want the history to be written
>    with tt($HISTFILE).  For example,
>    verb(
> -    HISTFILE=~/.zsh_history
> +    HISTFILE=~/.histfile

The default name should include "zsh" somewhere for coexistence with
other programs.  So, I'd rather keep the FAQ as-is.

Cheers,

Daniel

>    )


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24  9:06   ` Daniel Shahaf
@ 2022-08-24 17:32     ` Felipe Contreras
  2022-08-24 18:28       ` Eric Cook
  2022-08-25  8:04       ` Daniel Shahaf
  0 siblings, 2 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-08-24 17:32 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On Wed, Aug 24, 2022 at 4:12 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Felipe Contreras wrote on Wed, 24 Aug 2022 04:31 +00:00:
> > Better to use the same HISTFILE in both.
>
> Agreed, but...
>
> > +++ b/Etc/FAQ.yo
> > @@ -1629,7 +1629,7 @@ label(321)
> >    In zsh, you need to set the location where you want the history to be written
> >    with tt($HISTFILE).  For example,
> >    verb(
> > -    HISTFILE=~/.zsh_history
> > +    HISTFILE=~/.histfile
>
> The default name should include "zsh" somewhere for coexistence with
> other programs.  So, I'd rather keep the FAQ as-is.

I agree having a '.zsh_' prefix is more consistent with other
programs, but then that's what should be in the newuser-install
script, no?

I actually think this should be the default, no need for *everyone* to
specify this.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24 17:32     ` Felipe Contreras
@ 2022-08-24 18:28       ` Eric Cook
  2022-08-24 19:11         ` Felipe Contreras
  2022-08-25  8:04       ` Daniel Shahaf
  1 sibling, 1 reply; 93+ messages in thread
From: Eric Cook @ 2022-08-24 18:28 UTC (permalink / raw)
  To: zsh-workers

On 8/24/22 13:32, Felipe Contreras wrote:
> On Wed, Aug 24, 2022 at 4:12 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>>
>> Felipe Contreras wrote on Wed, 24 Aug 2022 04:31 +00:00:
>>> Better to use the same HISTFILE in both.
>>
>> Agreed, but...
>>
>>> +++ b/Etc/FAQ.yo
>>> @@ -1629,7 +1629,7 @@ label(321)
>>>     In zsh, you need to set the location where you want the history to be written
>>>     with tt($HISTFILE).  For example,
>>>     verb(
>>> -    HISTFILE=~/.zsh_history
>>> +    HISTFILE=~/.histfile
>>
>> The default name should include "zsh" somewhere for coexistence with
>> other programs.  So, I'd rather keep the FAQ as-is.
>
> I agree having a '.zsh_' prefix is more consistent with other
> programs, but then that's what should be in the newuser-install
> script, no?
>
> I actually think this should be the default, no need for *everyone* to
> specify this.
>

Yes *everyone* should specify it.

Aside from the arbitrary bump in HISTSIZE, if HISTFILE is set by default and
zsh is invoked with -f which is common when debugging or testing you get the
expected defaults. But if the user typically increases SAVEHIST from said
default, because regardless of what you set it to, people will change it to
their preference, you create the same problem that other shells like bash have,
the truncation of HISTFILE to the default SAVEHIST upon the exit of that zsh -f session.
usually without the user noticing for a period of time.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24 18:28       ` Eric Cook
@ 2022-08-24 19:11         ` Felipe Contreras
  2022-08-24 19:24           ` Matthew Martin
  2022-08-24 19:25           ` Eric Cook
  0 siblings, 2 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-08-24 19:11 UTC (permalink / raw)
  To: Eric Cook; +Cc: zsh-workers

On Wed, Aug 24, 2022 at 1:33 PM Eric Cook <llua@gmx.com> wrote:
>
> On 8/24/22 13:32, Felipe Contreras wrote:
> > On Wed, Aug 24, 2022 at 4:12 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >>
> >> Felipe Contreras wrote on Wed, 24 Aug 2022 04:31 +00:00:
> >>> Better to use the same HISTFILE in both.
> >>
> >> Agreed, but...
> >>
> >>> +++ b/Etc/FAQ.yo
> >>> @@ -1629,7 +1629,7 @@ label(321)
> >>>     In zsh, you need to set the location where you want the history to be written
> >>>     with tt($HISTFILE).  For example,
> >>>     verb(
> >>> -    HISTFILE=~/.zsh_history
> >>> +    HISTFILE=~/.histfile
> >>
> >> The default name should include "zsh" somewhere for coexistence with
> >> other programs.  So, I'd rather keep the FAQ as-is.
> >
> > I agree having a '.zsh_' prefix is more consistent with other
> > programs, but then that's what should be in the newuser-install
> > script, no?
> >
> > I actually think this should be the default, no need for *everyone* to
> > specify this.
>
> Yes *everyone* should specify it.

Why?

All programs dump their history by default. Node, python, ruby, less,
mariadb, and of course bash and ksh. Those are the ones that I can
easily find.

> Aside from the arbitrary bump in HISTSIZE, if HISTFILE is set by default and
> zsh is invoked with -f which is common when debugging or testing you get the
> expected defaults. But if the user typically increases SAVEHIST from said
> default, because regardless of what you set it to, people will change it to
> their preference, you create the same problem that other shells like bash have,
> the truncation of HISTFILE to the default SAVEHIST upon the exit of that zsh -f session.
> usually without the user noticing for a period of time.

So because of this corner case that 99.99% of people are never going
to hit we should bother 100% of users. It doesn't seem like an issue
worthy of so much consideration. Moreover, it could be solved in other
ways, like not setting HISTFILE when NO_RCS is on.

Cheers.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24 19:11         ` Felipe Contreras
@ 2022-08-24 19:24           ` Matthew Martin
  2022-08-24 19:25           ` Eric Cook
  1 sibling, 0 replies; 93+ messages in thread
From: Matthew Martin @ 2022-08-24 19:24 UTC (permalink / raw)
  To: zsh-workers

On Wed, Aug 24, 2022 at 02:11:20PM -0500, Felipe Contreras wrote:
> On Wed, Aug 24, 2022 at 1:33 PM Eric Cook <llua@gmx.com> wrote:
> >
> > On 8/24/22 13:32, Felipe Contreras wrote:
> > > On Wed, Aug 24, 2022 at 4:12 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > >>
> > >> Felipe Contreras wrote on Wed, 24 Aug 2022 04:31 +00:00:
> > >>> Better to use the same HISTFILE in both.
> > >>
> > >> Agreed, but...
> > >>
> > >>> +++ b/Etc/FAQ.yo
> > >>> @@ -1629,7 +1629,7 @@ label(321)
> > >>>     In zsh, you need to set the location where you want the history to be written
> > >>>     with tt($HISTFILE).  For example,
> > >>>     verb(
> > >>> -    HISTFILE=~/.zsh_history
> > >>> +    HISTFILE=~/.histfile
> > >>
> > >> The default name should include "zsh" somewhere for coexistence with
> > >> other programs.  So, I'd rather keep the FAQ as-is.
> > >
> > > I agree having a '.zsh_' prefix is more consistent with other
> > > programs, but then that's what should be in the newuser-install
> > > script, no?
> > >
> > > I actually think this should be the default, no need for *everyone* to
> > > specify this.
> >
> > Yes *everyone* should specify it.
> 
> Why?
> 
> All programs dump their history by default. Node, python, ruby, less,
> mariadb, and of course bash and ksh. Those are the ones that I can
> easily find.

However by default zsh does not and changing that now is backwards
incompatible with users who do not set HISTFILE.

(Aside: OpenBSD's ksh does not save history by default.)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24 19:11         ` Felipe Contreras
  2022-08-24 19:24           ` Matthew Martin
@ 2022-08-24 19:25           ` Eric Cook
  2022-08-24 19:40             ` Eric Cook
  2022-08-24 20:03             ` Felipe Contreras
  1 sibling, 2 replies; 93+ messages in thread
From: Eric Cook @ 2022-08-24 19:25 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: zsh-workers

On 8/24/22 15:11, Felipe Contreras wrote:
> On Wed, Aug 24, 2022 at 1:33 PM Eric Cook <llua@gmx.com> wrote:
>>
>> On 8/24/22 13:32, Felipe Contreras wrote:
>>> On Wed, Aug 24, 2022 at 4:12 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>>>>
>>>> Felipe Contreras wrote on Wed, 24 Aug 2022 04:31 +00:00:
>>>>> Better to use the same HISTFILE in both.
>>>>
>>>> Agreed, but...
>>>>
>>>>> +++ b/Etc/FAQ.yo
>>>>> @@ -1629,7 +1629,7 @@ label(321)
>>>>>      In zsh, you need to set the location where you want the history to be written
>>>>>      with tt($HISTFILE).  For example,
>>>>>      verb(
>>>>> -    HISTFILE=~/.zsh_history
>>>>> +    HISTFILE=~/.histfile
>>>>
>>>> The default name should include "zsh" somewhere for coexistence with
>>>> other programs.  So, I'd rather keep the FAQ as-is.
>>>
>>> I agree having a '.zsh_' prefix is more consistent with other
>>> programs, but then that's what should be in the newuser-install
>>> script, no?
>>>
>>> I actually think this should be the default, no need for *everyone* to
>>> specify this.
>>
>> Yes *everyone* should specify it.
>
> Why?
>
> All programs dump their history by default. Node, python, ruby, less,
> mariadb, and of course bash and ksh. Those are the ones that I can
> easily find.
>To avoid the problem i mentioned, also there are existing users that like
the current behavior since they do not use shell history. at work i don't use it.

>> Aside from the arbitrary bump in HISTSIZE, if HISTFILE is set by default and
>> zsh is invoked with -f which is common when debugging or testing you get the
>> expected defaults. But if the user typically increases SAVEHIST from said
>> default, because regardless of what you set it to, people will change it to
>> their preference, you create the same problem that other shells like bash have,
>> the truncation of HISTFILE to the default SAVEHIST upon the exit of that zsh -f session.
>> usually without the user noticing for a period of time.
>
> So because of this corner case that 99.99% of people are never going
> to hit we should bother 100% of users. It doesn't seem like an issue
> worthy of so much consideration. Moreover, it could be solved in other
> ways, like not setting HISTFILE when NO_RCS is on.

Starting the shell without your dotfiles is commonly given advice when troubleshooting
weird behavior, found across this mailing list, places like stackexchange and irc,
It's not a corner case.




^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24 19:25           ` Eric Cook
@ 2022-08-24 19:40             ` Eric Cook
  2022-08-24 20:03             ` Felipe Contreras
  1 sibling, 0 replies; 93+ messages in thread
From: Eric Cook @ 2022-08-24 19:40 UTC (permalink / raw)
  To: Zsh hackers list

On 8/24/22 15:25, Eric Cook wrote:
> On 8/24/22 15:11, Felipe Contreras wrote:
>> On Wed, Aug 24, 2022 at 1:33 PM Eric Cook <llua@gmx.com> wrote:
>>>
>>> On 8/24/22 13:32, Felipe Contreras wrote:
>>>> On Wed, Aug 24, 2022 at 4:12 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>>>>>
>>>>> Felipe Contreras wrote on Wed, 24 Aug 2022 04:31 +00:00:
>>>>>> Better to use the same HISTFILE in both.
>>>>>
>>>>> Agreed, but...
>>>>>
>>>>>> +++ b/Etc/FAQ.yo
>>>>>> @@ -1629,7 +1629,7 @@ label(321)
>>>>>>      In zsh, you need to set the location where you want the history to be written
>>>>>>      with tt($HISTFILE).  For example,
>>>>>>      verb(
>>>>>> -    HISTFILE=~/.zsh_history
>>>>>> +    HISTFILE=~/.histfile
>>>>>
>>>>> The default name should include "zsh" somewhere for coexistence with
>>>>> other programs.  So, I'd rather keep the FAQ as-is.
>>>>
>>>> I agree having a '.zsh_' prefix is more consistent with other
>>>> programs, but then that's what should be in the newuser-install
>>>> script, no?
>>>>
>>>> I actually think this should be the default, no need for *everyone* to
>>>> specify this.
>>>
>>> Yes *everyone* should specify it.
>>
>> Why?
>>
>> All programs dump their history by default. Node, python, ruby, less,
>> mariadb, and of course bash and ksh. Those are the ones that I can
>> easily find.
> To avoid the problem i mentioned, also there are existing users that like
> the current behavior since they do not use shell history. at work i don't use it.
>
To avoid the problem i mentioned, also there are existing users that like
the current behavior since they do not use shell history. at work i don't use it.
*fixed quoting


>> So because of this corner case that 99.99% of people are never going
>> to hit we should bother 100% of users. It doesn't seem like an issue
>> worthy of so much consideration. Moreover, it could be solved in other
>> ways, like not setting HISTFILE when NO_RCS is on.
>
> Starting the shell without your dotfiles is commonly given advice when troubleshooting
> weird behavior, found across this mailing list, places like stackexchange and irc,
> It's not a corner case.
>

Also the truncation is common enough in other shells like bash, that the same community
that created shellcheck thought to give advice on how to avoid it.
http://mywiki.wooledge.org/BashFAQ/088#Using_extended_attributes



^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24 19:25           ` Eric Cook
  2022-08-24 19:40             ` Eric Cook
@ 2022-08-24 20:03             ` Felipe Contreras
  2022-08-24 20:11               ` Eric Cook
  1 sibling, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-08-24 20:03 UTC (permalink / raw)
  To: Eric Cook; +Cc: zsh-workers

On Wed, Aug 24, 2022 at 2:25 PM Eric Cook <llua@gmx.com> wrote:
> On 8/24/22 15:11, Felipe Contreras wrote:
> > On Wed, Aug 24, 2022 at 1:33 PM Eric Cook <llua@gmx.com> wrote:

> >> Aside from the arbitrary bump in HISTSIZE, if HISTFILE is set by default and
> >> zsh is invoked with -f which is common when debugging or testing you get the
> >> expected defaults. But if the user typically increases SAVEHIST from said
> >> default, because regardless of what you set it to, people will change it to
> >> their preference, you create the same problem that other shells like bash have,
> >> the truncation of HISTFILE to the default SAVEHIST upon the exit of that zsh -f session.
> >> usually without the user noticing for a period of time.
> >
> > So because of this corner case that 99.99% of people are never going
> > to hit we should bother 100% of users. It doesn't seem like an issue
> > worthy of so much consideration. Moreover, it could be solved in other
> > ways, like not setting HISTFILE when NO_RCS is on.
>
> Starting the shell without your dotfiles is commonly given advice when troubleshooting
> weird behavior, found across this mailing list, places like stackexchange and irc,
> It's not a corner case.

Starting the shell without dotfiles does not produce the behavior you
described, this isn't the corner-case. The corner-case you described
is more specific.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24 20:03             ` Felipe Contreras
@ 2022-08-24 20:11               ` Eric Cook
  2022-08-24 20:27                 ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Eric Cook @ 2022-08-24 20:11 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: zsh-workers

On 8/24/22 16:03, Felipe Contreras wrote:
> Starting the shell without dotfiles does not produce the behavior you
> described, this isn't the corner-case. The corner-case you described
> is more specific.

Yes, it currently doesn't because HISTFILE isn't set by zsh by default.
a startup file has to do this, but if

> I actually think this should be the default, no need for *everyone* to
specify this.

the `this' here is setting HISTFILE, you will create a situation where
unintentional data loss happens if zsh sets HISTFILE by default, a user
increases SAVEHIST from the default and starts zsh without their dotfiles.
Those three conditions would cause the shell to truncate HISTFILE back to
the default value of SAVEHIST.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24 20:11               ` Eric Cook
@ 2022-08-24 20:27                 ` Felipe Contreras
  2022-08-24 20:53                   ` Eric Cook
  0 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-08-24 20:27 UTC (permalink / raw)
  To: Eric Cook; +Cc: zsh-workers

On Wed, Aug 24, 2022 at 3:11 PM Eric Cook <llua@gmx.com> wrote:
>
> On 8/24/22 16:03, Felipe Contreras wrote:
> > Starting the shell without dotfiles does not produce the behavior you
> > described, this isn't the corner-case. The corner-case you described
> > is more specific.
>
> Yes, it currently doesn't because HISTFILE isn't set by zsh by default.
> a startup file has to do this, but if
>
> > I actually think this should be the default, no need for *everyone* to
> specify this.
>
> the `this' here is setting HISTFILE, you will create a situation where
> unintentional data loss happens if zsh sets HISTFILE by default, a user
> increases SAVEHIST from the default and starts zsh without their dotfiles.
> Those three conditions would cause the shell to truncate HISTFILE back to
> the default value of SAVEHIST.

So it's more than one condition, so it's more than just starting with
NO_RCS. That's what I meant by "more specific".

*If* my proposed patches are applied, SAVEHIST by default would be
1000, *and* if HISTFILE had some default--which is something my
proposed patches don't do, but could be considered for zsh 6.0, *then*
this could happen:

1. The user has configured SAVEHIST to something greater than 1000
2. The user starts zsh with NO_RCS (e.g. zsh -f)

Yes, that is an issue, but I would guess those two conditions would
only be met 0.01% of the time at best, which is why I claim this is a
corner-case. Moreover, this could be easily avoided by HISTFILE not
having a default if NO_RCS is set, could it not?

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24 20:27                 ` Felipe Contreras
@ 2022-08-24 20:53                   ` Eric Cook
  0 siblings, 0 replies; 93+ messages in thread
From: Eric Cook @ 2022-08-24 20:53 UTC (permalink / raw)
  To: Zsh hackers list

On 8/24/22 16:27, Felipe Contreras wrote:
> *If* my proposed patches are applied, SAVEHIST by default would be
> 1000, *and* if HISTFILE had some default--which is something my
> proposed patches don't do, but could be considered for zsh 6.0, *then*
> this could happen:
>
> 1. The user has configured SAVEHIST to something greater than 1000
> 2. The user starts zsh with NO_RCS (e.g. zsh -f)
>
> Yes, that is an issue, but I would guess those two conditions would
> only be met 0.01% of the time at best, which is why I claim this is a
> corner-case. Moreover, this could be easily avoided by HISTFILE not
> having a default if NO_RCS is set, could it not?
>

You keep throwing out these random percentages from no where, i am
telling you as someone that helps people use unix shells over the years
that starting your shell without your dotfiles isn't a corner case, there
isn't a reason to guess, you can search this mailing list for the frequency
of use, the README when discussing reporting bugs mention reproducing
possible bugs from zsh -f.

I've commonly seen people wonder why they lost shell history in other shells
only to find out they started them in such a way their dotfiles wasn't sourced,
when they increased the default size of history events being saved.

But yes, in a hypothetical proposal of setting HISTFILE by default.
not doing so when NO_RCS/-f is used would prevent the subtle data loss problem.
Had i not chimed in on it though, i doubt the precaution would've been taken.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 0/3] Improve defaults
  2022-08-24  4:31 [RFC PATCH 0/3] Improve defaults Felipe Contreras
                   ` (2 preceding siblings ...)
  2022-08-24  4:31 ` [RFC PATCH 3/3] FAQ: sync newuser-install Felipe Contreras
@ 2022-08-24 20:58 ` Bart Schaefer
  2022-08-24 21:50   ` Felipe Contreras
  2022-08-24 21:39 ` Mikael Magnusson
  4 siblings, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-08-24 20:58 UTC (permalink / raw)
  To: Zsh hackers list

On Tue, Aug 23, 2022 at 9:37 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> It doesn't make much sense to specify so many options when simple
> defaults can do it.

Personally speaking, I disapprove of almost every hunk of this
patchset.  Side-effects upon existing uses of "fc -p" are not
considered, nor are use cases involving SHARE_HISTORY, APPEND_HISTORY,
INC_APPEND_HISTORY, and HIST_SAVE_NO_DUPS, although I suppose in most
of the latter cases users will already be populating the full set of
variables.

Specifically with respect to the value of HISTFILE, the use of
".histfile" in zsh-newuser-install has always been a bit questionable
and seems to assume a $ZDOTDIR exists ... a previous common practice
was to use ~/.zhistory (although the only place that's codified is in
the csh-to-zsh conversion script c2z).


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 0/3] Improve defaults
  2022-08-24  4:31 [RFC PATCH 0/3] Improve defaults Felipe Contreras
                   ` (3 preceding siblings ...)
  2022-08-24 20:58 ` [RFC PATCH 0/3] Improve defaults Bart Schaefer
@ 2022-08-24 21:39 ` Mikael Magnusson
  4 siblings, 0 replies; 93+ messages in thread
From: Mikael Magnusson @ 2022-08-24 21:39 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: zsh-workers

n 8/24/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> It doesn't make much sense to specify so many options when simple
> defaults can do it.
>
> So instead of this:
>
>     HISTFILE ~/.histfile
>     HISTSIZE 1000
>     SAVEHIST 1000
>
> We can just do:
>
>     HISTFILE ~/.histfile
>
> I personally don't see the need to specify a file when virtually every
> software dumps their history by default, but it's a start.

I have a keybind that toggles history on/off, so if i know i'm going
to be running eg 'make' and './someprogram' alternatingly a bunch of
times, i don't pollute my history with it. It used to be implemented
by unsetting HISTFILE (it uses the zshaddhistory() hook now, but
others may still do it the other way), so it would be quite an
incompatible change.

> From what I can see most people simply set SAVEHIST to HISTSIZE, so it
> makes sense to have a value to make them equal by default. I used -1.

In my experience having magical defaults usually leads to more
confusion, not less. (Not a strong argument against these particular
patches perhaps.)

> I've tried for a while have the most minimal .zshrc file that is useful,
> and never is that small. This should help.

As you're in the process of finding out, part of the reason the
minimal useful .zshrc is not that small is that people have very
varying preferences as to what should be in there.

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 0/3] Improve defaults
  2022-08-24 20:58 ` [RFC PATCH 0/3] Improve defaults Bart Schaefer
@ 2022-08-24 21:50   ` Felipe Contreras
  2022-08-24 22:18     ` Bart Schaefer
  0 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-08-24 21:50 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Wed, Aug 24, 2022 at 3:58 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Tue, Aug 23, 2022 at 9:37 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > It doesn't make much sense to specify so many options when simple
> > defaults can do it.
>
> Personally speaking, I disapprove of almost every hunk of this
> patchset.  Side-effects upon existing uses of "fc -p" are not
> considered,

How are they not considered?

> nor are use cases involving SHARE_HISTORY, APPEND_HISTORY,
> INC_APPEND_HISTORY, and HIST_SAVE_NO_DUPS,

Once again, how are they not considered?

> Specifically with respect to the value of HISTFILE, the use of
> ".histfile" in zsh-newuser-install has always been a bit questionable
> and seems to assume a $ZDOTDIR exists ... a previous common practice
> was to use ~/.zhistory (although the only place that's codified is in
> the csh-to-zsh conversion script c2z).

That's not an argument in favor of having two different recommended
files. I personally don't care which is the recommended one, I just
think it should be the same in the FAQ and new-user-install.

Cheers.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 0/3] Improve defaults
  2022-08-24 21:50   ` Felipe Contreras
@ 2022-08-24 22:18     ` Bart Schaefer
  2022-08-24 22:54       ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-08-24 22:18 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Zsh hackers list

On Wed, Aug 24, 2022 at 2:50 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Wed, Aug 24, 2022 at 3:58 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > Side-effects upon existing uses of "fc -p" are not
> > considered,
>
> How are they not considered?

"fc -p" with no other arguments explicitly resets the variables to
their defaults.  The current default for SAVEHIST is zero, so having
that become nonzero is an issue.  Changing the default HISTSIZE is
less of a concern but still affects "fc -p".

> > nor are use cases involving SHARE_HISTORY, APPEND_HISTORY,
> > INC_APPEND_HISTORY, and HIST_SAVE_NO_DUPS,
>
> Once again, how are they not considered?

Simply that usually when any of those are set, which is not uncommon,
it makes much less sense to have equivalent values of SAVEHIST and
HISTSIZE.   As I said, that's probably a case where they're all being
set anyway, but these patches aren't helpful.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 0/3] Improve defaults
  2022-08-24 22:18     ` Bart Schaefer
@ 2022-08-24 22:54       ` Felipe Contreras
  0 siblings, 0 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-08-24 22:54 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Wed, Aug 24, 2022 at 5:18 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Wed, Aug 24, 2022 at 2:50 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > On Wed, Aug 24, 2022 at 3:58 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > >
> > > Side-effects upon existing uses of "fc -p" are not
> > > considered,
> >
> > How are they not considered?
>
> "fc -p" with no other arguments explicitly resets the variables to
> their defaults.

Yes, which includes HISTFILE="", so SAVEHIST doesn't matter.

> The current default for SAVEHIST is zero, so having
> that become nonzero is an issue.

How? Saving 1000 lines to "" is a no-op.

If the user does "fc -p tmp_history" then SAVEHIST will not be the
default, but whatever the user has specified.

> Changing the default HISTSIZE is less of a concern but still affects "fc -p".

Only if the user hasn't set HISTSIZE.

I'm not familiar with "fc -p/P", but I read the code, and I fail to
see the issue.

> > > nor are use cases involving SHARE_HISTORY, APPEND_HISTORY,
> > > INC_APPEND_HISTORY, and HIST_SAVE_NO_DUPS,
> >
> > Once again, how are they not considered?
>
> Simply that usually when any of those are set, which is not uncommon,
> it makes much less sense to have equivalent values of SAVEHIST and
> HISTSIZE.

Yes, but if the user has set APPEND_HISTORY, and SAVEHIST=HISTSIZE
doesn't make much sense, then the user surely has set SAVEHIST to a
value that does make sense (i.e. not 0), therefore changing the
default value of SAVEHIST is irrelevant.

> As I said, that's probably a case where they're all being
> set anyway, but these patches aren't helpful.

The default values don't have to be helpful in all configurations,
only in the majority of them. For all the rest the user can specify
something other than the default, like they are doing right now.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-24 17:32     ` Felipe Contreras
  2022-08-24 18:28       ` Eric Cook
@ 2022-08-25  8:04       ` Daniel Shahaf
  2022-08-25 22:22         ` Bart Schaefer
  1 sibling, 1 reply; 93+ messages in thread
From: Daniel Shahaf @ 2022-08-25  8:04 UTC (permalink / raw)
  To: zsh-workers

Felipe Contreras wrote on Wed, 24 Aug 2022 17:32 +00:00:
> On Wed, Aug 24, 2022 at 4:12 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > Felipe Contreras wrote on Wed, 24 Aug 2022 04:31 +00:00:
> > > Better to use the same HISTFILE in both.
> >
> > Agreed, but...
> >
> > > +++ b/Etc/FAQ.yo
> > > @@ -1629,7 +1629,7 @@ label(321)
> > >    In zsh, you need to set the location where you want the history to be written
> > >    with tt($HISTFILE).  For example,
> > >    verb(
> > > -    HISTFILE=~/.zsh_history
> > > +    HISTFILE=~/.histfile
> >
> > The default name should include "zsh" somewhere for coexistence with
> > other programs.  So, I'd rather keep the FAQ as-is.
> 
> I agree having a '.zsh_' prefix is more consistent with other
> programs, but then that's what should be in the newuser-install
> script, no?
> 
> I actually think this should be the default, no need for *everyone* to
> specify this.

Setting HISTFILE does /two/ things:

1. Enable saving history to disk
2. Specify the name of the file history would be stored in

Would it be easier to consense here if we could separate these two
functions?  E.g., if history saving remained off by default but we had
a way for a user to say "Please save history and use the default filename
for that"?

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-25  8:04       ` Daniel Shahaf
@ 2022-08-25 22:22         ` Bart Schaefer
  2022-08-25 22:44           ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-08-25 22:22 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On Thu, Aug 25, 2022 at 1:11 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Would it be easier to consense here if we could separate these two
> functions?  E.g., if history saving remained off by default but we had
> a way for a user to say "Please save history and use the default filename
> for that"?

I don't think making things more complicated is likely to help, no.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-25 22:22         ` Bart Schaefer
@ 2022-08-25 22:44           ` Felipe Contreras
  2022-08-25 23:08             ` Bart Schaefer
  0 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-08-25 22:44 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Daniel Shahaf, zsh-workers

On Thu, Aug 25, 2022 at 5:23 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Thu, Aug 25, 2022 at 1:11 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > Would it be easier to consense here if we could separate these two
> > functions?  E.g., if history saving remained off by default but we had
> > a way for a user to say "Please save history and use the default filename
> > for that"?
>
> I don't think making things more complicated is likely to help, no.

This is *less* complicated:

    setopt SAVE_HISTORY

than:

    HISTFILE=~/.histfile
    HISTSIZE=1000
    SAVEHIST=1000

Not more.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-25 22:44           ` Felipe Contreras
@ 2022-08-25 23:08             ` Bart Schaefer
  2022-08-26  4:22               ` Felipe Contreras
  2022-08-26  5:20               ` Daniel Shahaf
  0 siblings, 2 replies; 93+ messages in thread
From: Bart Schaefer @ 2022-08-25 23:08 UTC (permalink / raw)
  To: Zsh hackers list

On Thu, Aug 25, 2022 at 3:44 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> This is *less* complicated:

Every addition of an option to change the way something works is
making the shell as a whole more complicated and the interactions
among the settings more difficult to explain and understand.

Unless there's an important behavior that it's simply not possible to
accomplish with the existing configuration controls, adding magical
interdependencies and switches to enable same is not IMO a good plan.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-25 23:08             ` Bart Schaefer
@ 2022-08-26  4:22               ` Felipe Contreras
  2022-08-31 11:43                 ` Vincent Lefevre
  2022-08-26  5:20               ` Daniel Shahaf
  1 sibling, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-08-26  4:22 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Thu, Aug 25, 2022 at 6:13 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Thu, Aug 25, 2022 at 3:44 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > This is *less* complicated:
>
> Every addition of an option to change the way something works is
> making the shell as a whole more complicated and the interactions
> among the settings more difficult to explain and understand.

That isn't true. That would be like saying every commit makes the code
more complicated. Some commits do, sure, but not all.

There are commits specifically designed to *reduce* complexity, and
such changes are called refactoring.

Options can be refactored too. Some changes in options can actually
make multiple options unnecessary, thus reducing complexity. Others
can simplify the explanation.

This:

  sect(Why is my history not being saved?)
  label(321)

    In zsh you need to specifically enable history:
    verb(
      setopt SAVE_HISTORY
    )

Is simpler than this:

  sect(Why is my history not being saved?)
  label(321)

    In zsh, you need to set three variables to make sure your history is
    written out when the shell exits.  For example,
    verb(
      HISTSIZE=200
      HISTFILE=~/.zsh_history
      SAVEHIST=200
    )
    tt($HISTSIZE) tells the shell how many lines to keep internally,
    tt($HISTFILE) tells it where to write the history, and tt($SAVEHIST),
    the easiest one to forget, tells it how many to write out.  The
    simplest possibility is to set it to the same as tt($HISTSIZE) as
    above.  There are also various options affecting history; see the
    manual.

Moreover, not all options nor all interactions need to be explained.

There's a minimum set of options which are necessary to explain in
order to make zsh useful to most people though. It is in the best
interest of every user of zsh that these minimum options are as few as
possible and as simple to explain as possible.

Why would we intentionally make things harder for most new users?

Cheers.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-25 23:08             ` Bart Schaefer
  2022-08-26  4:22               ` Felipe Contreras
@ 2022-08-26  5:20               ` Daniel Shahaf
  2022-08-26 13:57                 ` Mikael Magnusson
  2022-08-27  2:24                 ` Bart Schaefer
  1 sibling, 2 replies; 93+ messages in thread
From: Daniel Shahaf @ 2022-08-26  5:20 UTC (permalink / raw)
  To: zsh-workers

Bart Schaefer wrote on Thu, 25 Aug 2022 23:08 +00:00:
> On Thu, Aug 25, 2022 at 3:44 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>>
>> This is *less* complicated:
>
> Every addition of an option to change the way something works is
> making the shell as a whole more complicated and the interactions
> among the settings more difficult to explain and understand.
>
> Unless there's an important behavior that it's simply not possible to
> accomplish with the existing configuration controls,

Does "enable saving of history without specifying the history file's name" qualify?

> adding magical interdependencies and switches to enable same is not
> IMO a good plan.

What I had in mind was a new option, HIST_RECORD, and have it implicitly
setopt'd by assignment to $HISTFILE and implicitly unsetopt'd by «unset
HISTFILE«»; and then the default (zsh -f) could be to have HISTFILE set to some
value but HIST_RECORD off.

This design:

- would not change the default behaviour.

- would be compatible with existing dotfiles, since assigning to
  HISTFILE would set HIST_RECORD implicitly.

- would provide the ability to enable history without particularly
  caring about the filename it's saved in, which would put us on par
  with most other programs.  Most programs don't require the user
  to name files the user doesn't interact with directly.  (cc(1) goes even
  further with its default output filenames, such as foo.o and a.out.)

- /would/ be an action at a distance.  However, in this case,
  considering a user who unsets $HISTFILE in a universe in which
  HIST_RECORD exists,  I don't immediately see what alternative
  behaviour that user might expect.  As to a user who sets $HISTFILE and
  expects HIST_RECORD to remain off, that's backwards compatibility.

If that's nevertheless undersirable, then we could go the deprecation
route: leave $HISTFILE as is; add an entirely new way to specify the
history file's name and whether writing to it is enabled (perhaps a
couple of zstyles); in 5.10 recommend that people transition to the new
way; starting 5.11 issue a warning if the old way is used, saying it's
deprecated and will be removed no sooner than ${date or version number}.

Any other alternatives?

[The option's proposed name was chosen for consistency with other
options and for avoidance of ambiguity with $SAVEHIST.]

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-26  5:20               ` Daniel Shahaf
@ 2022-08-26 13:57                 ` Mikael Magnusson
  2022-08-26 14:04                   ` Roman Perepelitsa
  2022-08-26 18:44                   ` Felipe Contreras
  2022-08-27  2:24                 ` Bart Schaefer
  1 sibling, 2 replies; 93+ messages in thread
From: Mikael Magnusson @ 2022-08-26 13:57 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On 8/26/22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Bart Schaefer wrote on Thu, 25 Aug 2022 23:08 +00:00:
>> On Thu, Aug 25, 2022 at 3:44 PM Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>>
>>> This is *less* complicated:
>>
>> Every addition of an option to change the way something works is
>> making the shell as a whole more complicated and the interactions
>> among the settings more difficult to explain and understand.
>>
>> Unless there's an important behavior that it's simply not possible to
>> accomplish with the existing configuration controls,
>
> Does "enable saving of history without specifying the history file's name"
> qualify?
>
>> adding magical interdependencies and switches to enable same is not
>> IMO a good plan.
>
> What I had in mind was a new option, HIST_RECORD, and have it implicitly
> setopt'd by assignment to $HISTFILE and implicitly unsetopt'd by «unset
> HISTFILE«»; and then the default (zsh -f) could be to have HISTFILE set to
> some
> value but HIST_RECORD off.
>
> This design:
>
> - would not change the default behaviour.
>
> - would be compatible with existing dotfiles, since assigning to
>   HISTFILE would set HIST_RECORD implicitly.
>
> - would provide the ability to enable history without particularly
>   caring about the filename it's saved in, which would put us on par
>   with most other programs.  Most programs don't require the user
>   to name files the user doesn't interact with directly.  (cc(1) goes even
>   further with its default output filenames, such as foo.o and a.out.)
>
> - /would/ be an action at a distance.  However, in this case,
>   considering a user who unsets $HISTFILE in a universe in which
>   HIST_RECORD exists,  I don't immediately see what alternative
>   behaviour that user might expect.  As to a user who sets $HISTFILE and
>   expects HIST_RECORD to remain off, that's backwards compatibility.
>
> If that's nevertheless undersirable, then we could go the deprecation
> route: leave $HISTFILE as is; add an entirely new way to specify the
> history file's name and whether writing to it is enabled (perhaps a
> couple of zstyles); in 5.10 recommend that people transition to the new
> way; starting 5.11 issue a warning if the old way is used, saying it's
> deprecated and will be removed no sooner than ${date or version number}.
>
> Any other alternatives?
>
> [The option's proposed name was chosen for consistency with other
> options and for avoidance of ambiguity with $SAVEHIST.]

My vote is to do nothing.

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-26 13:57                 ` Mikael Magnusson
@ 2022-08-26 14:04                   ` Roman Perepelitsa
  2022-08-26 23:43                     ` Lawrence Velázquez
  2022-08-26 18:44                   ` Felipe Contreras
  1 sibling, 1 reply; 93+ messages in thread
From: Roman Perepelitsa @ 2022-08-26 14:04 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Daniel Shahaf, zsh-workers

On Fri, Aug 26, 2022 at 4:03 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> My vote is to do nothing.

Ditto (not that my vote matters).

Roman.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-26 13:57                 ` Mikael Magnusson
  2022-08-26 14:04                   ` Roman Perepelitsa
@ 2022-08-26 18:44                   ` Felipe Contreras
  2022-08-27  0:23                     ` Mikael Magnusson
  1 sibling, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-08-26 18:44 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Daniel Shahaf, zsh-workers

On Fri, Aug 26, 2022 at 9:02 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> On 8/26/22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > Bart Schaefer wrote on Thu, 25 Aug 2022 23:08 +00:00:
> >> On Thu, Aug 25, 2022 at 3:44 PM Felipe Contreras
> >> <felipe.contreras@gmail.com> wrote:
> >>>
> >>> This is *less* complicated:
> >>
> >> Every addition of an option to change the way something works is
> >> making the shell as a whole more complicated and the interactions
> >> among the settings more difficult to explain and understand.
> >>
> >> Unless there's an important behavior that it's simply not possible to
> >> accomplish with the existing configuration controls,
> >
> > Does "enable saving of history without specifying the history file's name"
> > qualify?
> >
> >> adding magical interdependencies and switches to enable same is not
> >> IMO a good plan.
> >
> > What I had in mind was a new option, HIST_RECORD, and have it implicitly
> > setopt'd by assignment to $HISTFILE and implicitly unsetopt'd by «unset
> > HISTFILE«»; and then the default (zsh -f) could be to have HISTFILE set to
> > some
> > value but HIST_RECORD off.
> >
> > This design:
> >
> > - would not change the default behaviour.
> >
> > - would be compatible with existing dotfiles, since assigning to
> >   HISTFILE would set HIST_RECORD implicitly.
> >
> > - would provide the ability to enable history without particularly
> >   caring about the filename it's saved in, which would put us on par
> >   with most other programs.  Most programs don't require the user
> >   to name files the user doesn't interact with directly.  (cc(1) goes even
> >   further with its default output filenames, such as foo.o and a.out.)
> >
> > - /would/ be an action at a distance.  However, in this case,
> >   considering a user who unsets $HISTFILE in a universe in which
> >   HIST_RECORD exists,  I don't immediately see what alternative
> >   behaviour that user might expect.  As to a user who sets $HISTFILE and
> >   expects HIST_RECORD to remain off, that's backwards compatibility.
> >
> > If that's nevertheless undersirable, then we could go the deprecation
> > route: leave $HISTFILE as is; add an entirely new way to specify the
> > history file's name and whether writing to it is enabled (perhaps a
> > couple of zstyles); in 5.10 recommend that people transition to the new
> > way; starting 5.11 issue a warning if the old way is used, saying it's
> > deprecated and will be removed no sooner than ${date or version number}.
> >
> > Any other alternatives?
> >
> > [The option's proposed name was chosen for consistency with other
> > options and for avoidance of ambiguity with $SAVEHIST.]
>
> My vote is to do nothing.

That is not an argument. Do you care to explain why?

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-26 14:04                   ` Roman Perepelitsa
@ 2022-08-26 23:43                     ` Lawrence Velázquez
  2022-08-27 15:17                       ` Daniel Shahaf
  0 siblings, 1 reply; 93+ messages in thread
From: Lawrence Velázquez @ 2022-08-26 23:43 UTC (permalink / raw)
  To: zsh-workers

On Fri, Aug 26, 2022, at 10:04 AM, Roman Perepelitsa wrote:
> On Fri, Aug 26, 2022 at 4:03 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>>
>> My vote is to do nothing.
>
> Ditto (not that my vote matters).

+1

-- 
vq


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-26 18:44                   ` Felipe Contreras
@ 2022-08-27  0:23                     ` Mikael Magnusson
  2022-08-27  0:31                       ` Bart Schaefer
  2022-08-27  0:35                       ` Felipe Contreras
  0 siblings, 2 replies; 93+ messages in thread
From: Mikael Magnusson @ 2022-08-27  0:23 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Daniel Shahaf, zsh-workers

On 8/26/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> On Fri, Aug 26, 2022 at 9:02 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>>
>> On 8/26/22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>> > Bart Schaefer wrote on Thu, 25 Aug 2022 23:08 +00:00:
>> >> On Thu, Aug 25, 2022 at 3:44 PM Felipe Contreras
>> >> <felipe.contreras@gmail.com> wrote:
>> >>>
>> >>> This is *less* complicated:
>> >>
>> >> Every addition of an option to change the way something works is
>> >> making the shell as a whole more complicated and the interactions
>> >> among the settings more difficult to explain and understand.
>> >>
>> >> Unless there's an important behavior that it's simply not possible to
>> >> accomplish with the existing configuration controls,
>> >
>> > Does "enable saving of history without specifying the history file's
>> > name"
>> > qualify?
>> >
>> >> adding magical interdependencies and switches to enable same is not
>> >> IMO a good plan.
>> >
>> > What I had in mind was a new option, HIST_RECORD, and have it
>> > implicitly
>> > setopt'd by assignment to $HISTFILE and implicitly unsetopt'd by «unset
>> > HISTFILE«»; and then the default (zsh -f) could be to have HISTFILE set
>> > to
>> > some
>> > value but HIST_RECORD off.
>> >
>> > This design:
>> >
>> > - would not change the default behaviour.
>> >
>> > - would be compatible with existing dotfiles, since assigning to
>> >   HISTFILE would set HIST_RECORD implicitly.
>> >
>> > - would provide the ability to enable history without particularly
>> >   caring about the filename it's saved in, which would put us on par
>> >   with most other programs.  Most programs don't require the user
>> >   to name files the user doesn't interact with directly.  (cc(1) goes
>> > even
>> >   further with its default output filenames, such as foo.o and a.out.)
>> >
>> > - /would/ be an action at a distance.  However, in this case,
>> >   considering a user who unsets $HISTFILE in a universe in which
>> >   HIST_RECORD exists,  I don't immediately see what alternative
>> >   behaviour that user might expect.  As to a user who sets $HISTFILE
>> > and
>> >   expects HIST_RECORD to remain off, that's backwards compatibility.
>> >
>> > If that's nevertheless undersirable, then we could go the deprecation
>> > route: leave $HISTFILE as is; add an entirely new way to specify the
>> > history file's name and whether writing to it is enabled (perhaps a
>> > couple of zstyles); in 5.10 recommend that people transition to the new
>> > way; starting 5.11 issue a warning if the old way is used, saying it's
>> > deprecated and will be removed no sooner than ${date or version
>> > number}.
>> >
>> > Any other alternatives?
>> >
>> > [The option's proposed name was chosen for consistency with other
>> > options and for avoidance of ambiguity with $SAVEHIST.]
>>
>> My vote is to do nothing.
>
> That is not an argument. Do you care to explain why?

Not really, I haven't had great experiences arguing with you before.
You gave these examples earlier:

  sect(Why is my history not being saved?)
  label(321)

    In zsh you need to specifically enable history:
    verb(
      setopt SAVE_HISTORY
    )

vs

  sect(Why is my history not being saved?)
  label(321)

    In zsh, you need to set three variables to make sure your history is
    written out when the shell exits.  For example,
    verb(
      HISTSIZE=200
      HISTFILE=~/.zsh_history
      SAVEHIST=200
    )

But realistically the former actually has to be

autoload is-at-least
if is-at-least 5.8; then
  setopt SAVE_HISTORY
else
  HISTSIZE=200
  HISTFILE=~/.zsh_history
  SAVEHIST=200
fi

which isn't really a win. Besides that, the whole thing is way too
disruptive just for you to save 2 lines in your .zshrc.

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-27  0:23                     ` Mikael Magnusson
@ 2022-08-27  0:31                       ` Bart Schaefer
  2022-08-27  3:18                         ` Felipe Contreras
  2022-08-27  0:35                       ` Felipe Contreras
  1 sibling, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-08-27  0:31 UTC (permalink / raw)
  To: zsh-workers

On Fri, Aug 26, 2022 at 5:23 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> Besides that, the whole thing is way too
> disruptive just for you to save 2 lines in your .zshrc.

Pretty much exactly that.  The argument FOR doing something has to be
persuasive, rebutting specific counterpoints is only part of that.  I
haven't seen anyone yet supporting your position without modification.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-27  0:23                     ` Mikael Magnusson
  2022-08-27  0:31                       ` Bart Schaefer
@ 2022-08-27  0:35                       ` Felipe Contreras
  1 sibling, 0 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-08-27  0:35 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Daniel Shahaf, zsh-workers

On Fri, Aug 26, 2022 at 7:23 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> On 8/26/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > On Fri, Aug 26, 2022 at 9:02 AM Mikael Magnusson <mikachu@gmail.com> wrote:

> >> My vote is to do nothing.
> >
> > That is not an argument. Do you care to explain why?
>
> Not really, I haven't had great experiences arguing with you before.

You don't have to argue with me, you can just state your argument for
the record.

> But realistically the former actually has to be
>
> autoload is-at-least
> if is-at-least 5.8; then
>   setopt SAVE_HISTORY
> else
>   HISTSIZE=200
>   HISTFILE=~/.zsh_history
>   SAVEHIST=200
> fi
>
> which isn't really a win.

That's absolutely not true. You don't have to change your
configuration one iota.

If you use your .zshrc file in multiple zsh versions, then *you* keep
using your old configuration:

  HISTSIZE=200
  HISTFILE=~/.zsh_history
  SAVEHIST=200

I always use the latest version of zsh, so my .zshrc can be:

  setopt save_history

You don't have to like my configuration, that's why it's mine. And you
are not forced to use the new options in your configuration, that's
why it's yours.

> Besides that, the whole thing is way too
> disruptive just for you to save 2 lines in your .zshrc.

I decide what I do with my .zshrc, how would the new option disrupt
your configuration if you don't have to change a thing?

Cheers.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-26  5:20               ` Daniel Shahaf
  2022-08-26 13:57                 ` Mikael Magnusson
@ 2022-08-27  2:24                 ` Bart Schaefer
  2022-08-27 15:40                   ` Daniel Shahaf
  1 sibling, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-08-27  2:24 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On Thu, Aug 25, 2022 at 10:27 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Bart Schaefer wrote on Thu, 25 Aug 2022 23:08 +00:00:
> >
> > Unless there's an important behavior that it's simply not possible to
> > accomplish with the existing configuration controls,
>
> Does "enable saving of history without specifying the history file's name" qualify?

Has anyone other than Felipe asserted that this behavior is important?
 IMO it qualifies on the second clause but not on the first.

> What I had in mind was a new option, HIST_RECORD, and have it implicitly
> setopt'd by assignment to $HISTFILE and implicitly unsetopt'd by «unset
> HISTFILE«»;

I am not sanguine about the idea of linking an option and a parameter
together that way.

> If that's nevertheless undersirable, then we could go the deprecation
> route: leave $HISTFILE as is; add an entirely new way to specify the
> history file's name and whether writing to it is enabled (perhaps a
> couple of zstyles);

Also not excited about deprecating the current settings nor about
tying built-in shell behavior to zstyle.  Currently zstyles only
affect operations that are provided via scripts or shell functions.

> Any other alternatives?

I haven't worked through all the details yet, but perhaps a zmodload
module?  The boot routine could assign to the three variables and then
(I think) even unload the module again.  Felipe's zshrc would do
"zmodload zsh/default_history" (or whatever).  The module could be
compiled for all but the most ancient of older versions of zsh if a
packager wanted to do so.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-27  0:31                       ` Bart Schaefer
@ 2022-08-27  3:18                         ` Felipe Contreras
  2022-08-27  3:52                           ` Lawrence Velázquez
  0 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-08-27  3:18 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

On Fri, Aug 26, 2022 at 7:31 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Fri, Aug 26, 2022 at 5:23 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> >
> > Besides that, the whole thing is way too
> > disruptive just for you to save 2 lines in your .zshrc.
>
> Pretty much exactly that.  The argument FOR doing something has to be
> persuasive, rebutting specific counterpoints is only part of that.  I
> haven't seen anyone yet supporting your position without modification.

I'm not sure what you mean. The argument in favor is right there: it
potentially reduces the number of options required in the
configuration.

If you are a zsh veteran who has carefully curated his .zshrc
configuration over a period of 30 years and has 1000 lines of
configuration, sure, saving 2 lines is negligible, in which case don't
use the new configuration.

But if you are an 18yo kid who just installed zsh, a configuration of
3 lines vs. a configuration of 1 line makes a difference of 67%.
That's quite a lot.

A better experience for new users is just better. The
`zsh-newuser-install` script is a step in the right direction, but in
my view it shouldn't be necessary. Running zsh with no configuration
should do a decent job for most people by default.

The ideal minimal configuration that does a good enough job for most
people should be *zero* lines. Even if we never get there, any line
saved is a step in the right direction.

Cheers.


--
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-27  3:18                         ` Felipe Contreras
@ 2022-08-27  3:52                           ` Lawrence Velázquez
  2022-08-27 15:44                             ` Daniel Shahaf
  2022-08-30 19:31                             ` Felipe Contreras
  0 siblings, 2 replies; 93+ messages in thread
From: Lawrence Velázquez @ 2022-08-27  3:52 UTC (permalink / raw)
  To: Felipe Contreras, Bart Schaefer; +Cc: zsh-workers

On Fri, Aug 26, 2022, at 11:18 PM, Felipe Contreras wrote:
> On Fri, Aug 26, 2022 at 7:31 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>>
>> On Fri, Aug 26, 2022 at 5:23 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>> >
>> > Besides that, the whole thing is way too
>> > disruptive just for you to save 2 lines in your .zshrc.
>>
>> Pretty much exactly that.  The argument FOR doing something has to be
>> persuasive, rebutting specific counterpoints is only part of that.  I
>> haven't seen anyone yet supporting your position without modification.
>
> I'm not sure what you mean. The argument in favor is right there: it
> potentially reduces the number of options required in the
> configuration.

We know what your argument is.  Some of us just are not persuaded
by it.


> But if you are an 18yo kid who just installed zsh, a configuration of
> 3 lines vs. a configuration of 1 line makes a difference of 67%.
> That's quite a lot.

It's not a lot.  It's still two lines.  Using an impressive-looking
percentage doesn't change this.


> A better experience for new users is just better. The
> `zsh-newuser-install` script is a step in the right direction, but in
> my view it shouldn't be necessary. Running zsh with no configuration
> should do a decent job for most people by default.
>
> The ideal minimal configuration that does a good enough job for most
> people should be *zero* lines. Even if we never get there, any line
> saved is a step in the right direction.

If we were starting from a blank slate, I'm sure more of us would
be on board.  As it is, there are tradeoffs regarding compatibility
and interactions with existing functionality.  You seem to not care
about that and want "a better experience for new users" at all cost,
but we don't have to agree.


-- 
vq


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-26 23:43                     ` Lawrence Velázquez
@ 2022-08-27 15:17                       ` Daniel Shahaf
  2022-08-27 15:34                         ` Roman Perepelitsa
  0 siblings, 1 reply; 93+ messages in thread
From: Daniel Shahaf @ 2022-08-27 15:17 UTC (permalink / raw)
  To: zsh-workers

Lawrence Velázquez wrote on Fri, 26 Aug 2022 23:43 +00:00:
> On Fri, Aug 26, 2022, at 10:04 AM, Roman Perepelitsa wrote:
>> On Fri, Aug 26, 2022 at 4:03 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>>>
>>> My vote is to do nothing.
>>
>> Ditto (not that my vote matters).
>
> +1

Your votes matter, but I have to agree with Felipe when he pointed out
that a vote with a rationale has more weight than one without.  (That's
because adding a rationale makes the argument falsifiable, makes it possible
to offer alternatives, and so on, whereas a vote without an argument becomes
a binary choice that's going to leave at least one side unhappy.  Or, at
least, that's my rationale for my opinion stated above :-))

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-27 15:17                       ` Daniel Shahaf
@ 2022-08-27 15:34                         ` Roman Perepelitsa
  0 siblings, 0 replies; 93+ messages in thread
From: Roman Perepelitsa @ 2022-08-27 15:34 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On Sat, Aug 27, 2022 at 5:23 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Lawrence Velázquez wrote on Fri, 26 Aug 2022 23:43 +00:00:
> > On Fri, Aug 26, 2022, at 10:04 AM, Roman Perepelitsa wrote:
> >> On Fri, Aug 26, 2022 at 4:03 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> >>>
> >>> My vote is to do nothing.
> >>
> >> Ditto (not that my vote matters).
> >
> > +1
>
> Your votes matter, but I have to agree with Felipe when he pointed out
> that a vote with a rationale has more weight than one without.  (That's
> because adding a rationale makes the argument falsifiable, makes it possible
> to offer alternatives, and so on, whereas a vote without an argument becomes
> a binary choice that's going to leave at least one side unhappy.  Or, at
> least, that's my rationale for my opinion stated above :-))

It wasn't my attempt to engage in an argument with Felipe. In fact, I
would very much like to avoid that regardless of the topic. Based on
past experience it would result in nothing but waste of time and
frustration.

I voiced my opinion to let zsh maintainers know which side of the
argument appears more persuasive to me. I'm acting in the capacity of
an observer here without having any arguments of my own..

Roman.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-27  2:24                 ` Bart Schaefer
@ 2022-08-27 15:40                   ` Daniel Shahaf
  2022-08-27 15:55                     ` Bart Schaefer
  0 siblings, 1 reply; 93+ messages in thread
From: Daniel Shahaf @ 2022-08-27 15:40 UTC (permalink / raw)
  To: zsh-workers

Bart Schaefer wrote on Sat, 27 Aug 2022 02:24 +00:00:
> On Thu, Aug 25, 2022 at 10:27 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>>
>> Bart Schaefer wrote on Thu, 25 Aug 2022 23:08 +00:00:
>> >
>> > Unless there's an important behavior that it's simply not possible to
>> > accomplish with the existing configuration controls,
>>
>> Does "enable saving of history without specifying the history file's name" qualify?
>
> Has anyone other than Felipe asserted that this behavior is important?
>  IMO it qualifies on the second clause but not on the first.
>

It's one fewer thing for the user to care about.  I wouldn't go so far
as to call it "important" but I do think it would be nice to have.

From a more theoretical perspective, removing the need to set HISTFILE
would allow us to one day move the history storage to something other
than files without requiring all users of history to change their
dotfiles.  (I'm thinking of, say, someone putting their history in
redis.)  Then again, saving history in files "ought to be enough for
anybody" :-)

>> What I had in mind was a new option, HIST_RECORD, and have it implicitly
>> setopt'd by assignment to $HISTFILE and implicitly unsetopt'd by «unset
>> HISTFILE«»;
>
> I am not sanguine about the idea of linking an option and a parameter
> together that way.

OK, then how about a new special variable?  It's precedented for
variables to be magical (e.g., path/PATH, functrace).  We could have a
HIST_RECORD variable with the following semantics:

- getter: returns 1 (mathematical true) if HISTFILE is not empty and 0
  (mathematical false) if HISTFILE is unset.  (If HISTFILE is empty,
  then <handwave/>.)

- setter: If set to zero, unsets HISTFILE (again, that's like the
  connection between path and PATH).  If set to a true value, set
  HISTFILE to... Hmm, I'm not sure.  To a well-known value specified at
  configure time, probably?  Felipe, WDYT?

Net result: HIST_RECORD=1 DTRT's.

Of course, at this point we might as well make it a (possibly module-
provided) builtin, so it's less surprising and more extensible.

>> If that's nevertheless undersirable, then we could go the deprecation
>> route: leave $HISTFILE as is; add an entirely new way to specify the
>> history file's name and whether writing to it is enabled (perhaps a
>> couple of zstyles);
>
> Also not excited about deprecating the current settings nor about
> tying built-in shell behavior to zstyle.  Currently zstyles only
> affect operations that are provided via scripts or shell functions.
>

And moreover, zstyle itself is a module whereas history is not.
Good point.

>> Any other alternatives?
>
> I haven't worked through all the details yet, but perhaps a zmodload
> module?  The boot routine could assign to the three variables and then
> (I think) even unload the module again.  Felipe's zshrc would do
> "zmodload zsh/default_history" (or whatever).  The module could be
> compiled for all but the most ancient of older versions of zsh if a
> packager wanted to do so.

If it's just this, then, s/zmodload module/$fpath function/, surely,
since this /can/ be implemented as a function?  The function could
unfunction itself, too.

Or if we do a special parameter or a new builtin, that could be done
in a module.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-27  3:52                           ` Lawrence Velázquez
@ 2022-08-27 15:44                             ` Daniel Shahaf
  2022-08-30 19:31                             ` Felipe Contreras
  1 sibling, 0 replies; 93+ messages in thread
From: Daniel Shahaf @ 2022-08-27 15:44 UTC (permalink / raw)
  To: zsh-workers

Lawrence Velázquez wrote on Sat, 27 Aug 2022 03:52 +00:00:
> On Fri, Aug 26, 2022, at 11:18 PM, Felipe Contreras wrote:
>> On Fri, Aug 26, 2022 at 7:31 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>>>
>>> On Fri, Aug 26, 2022 at 5:23 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>>> >
>>> > Besides that, the whole thing is way too
>>> > disruptive just for you to save 2 lines in your .zshrc.
>>>
>>> Pretty much exactly that.  The argument FOR doing something has to be
>>> persuasive, rebutting specific counterpoints is only part of that.  I
>>> haven't seen anyone yet supporting your position without modification.
>>
>> I'm not sure what you mean. The argument in favor is right there: it
>> potentially reduces the number of options required in the
>> configuration.
>
> We know what your argument is.  Some of us just are not persuaded
> by it.
>
>
>> But if you are an 18yo kid who just installed zsh, a configuration of
>> 3 lines vs. a configuration of 1 line makes a difference of 67%.
>> That's quite a lot.
>
> It's not a lot.  It's still two lines.  Using an impressive-looking
> percentage doesn't change this.

I think of it less as two more lines in the dotfile and more as five
more minutes figuring things out on first use ("What's this XDG thing
that page says I should set HISTFILE to?") and 15 more seconds typing
the values in every time one installs zsh without access to their dotfiles.

Put differently: Do people who enable history usually care what file it's saved in?

No?  They why is that information a non-optional argument of the API?

Cheers,

Daniel

>> A better experience for new users is just better. The
>> `zsh-newuser-install` script is a step in the right direction, but in
>> my view it shouldn't be necessary. Running zsh with no configuration
>> should do a decent job for most people by default.
>>
>> The ideal minimal configuration that does a good enough job for most
>> people should be *zero* lines. Even if we never get there, any line
>> saved is a step in the right direction.
>
> If we were starting from a blank slate, I'm sure more of us would
> be on board.  As it is, there are tradeoffs regarding compatibility
> and interactions with existing functionality.  You seem to not care
> about that and want "a better experience for new users" at all cost,
> but we don't have to agree.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-27 15:40                   ` Daniel Shahaf
@ 2022-08-27 15:55                     ` Bart Schaefer
  2022-08-27 17:53                       ` Daniel Shahaf
  0 siblings, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-08-27 15:55 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On Sat, Aug 27, 2022 at 8:41 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> From a more theoretical perspective, removing the need to set HISTFILE
> would allow us to one day move the history storage to something other
> than files

Given the (ahem) brisk adoption of alternatives to GDBM for ztie, that
seems unlikely, but if it were going to be implemented wouldn't it
more likely be as an extension to one of the existing history
parameters?

> Bart Schaefer wrote on Sat, 27 Aug 2022 02:24 +00:00:
> >
> > I haven't worked through all the details yet, but perhaps a zmodload
> > module?
>
> If it's just this, then, s/zmodload module/$fpath function/, surely

A shell function can't be static-linked to the base shell to guarantee
it's availability.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-27 15:55                     ` Bart Schaefer
@ 2022-08-27 17:53                       ` Daniel Shahaf
  0 siblings, 0 replies; 93+ messages in thread
From: Daniel Shahaf @ 2022-08-27 17:53 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

Bart Schaefer wrote on Sat, 27 Aug 2022 15:55 +00:00:
> On Sat, Aug 27, 2022 at 8:41 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>>
>> From a more theoretical perspective, removing the need to set HISTFILE
>> would allow us to one day move the history storage to something other
>> than files
>
> Given the (ahem) brisk adoption of alternatives to GDBM for ztie, that
> seems unlikely, but if it were going to be implemented wouldn't it
> more likely be as an extension to one of the existing history
> parameters?

Which parameter?  I think such an extension might work as magic syntax
in HISTFILE itself (e.g., using URL syntax, or special-casing arguments
whose first character is "@").  None of the other history parameters seem
particularly suitable to the task?

>> Bart Schaefer wrote on Sat, 27 Aug 2022 02:24 +00:00:
>> >
>> > I haven't worked through all the details yet, but perhaps a zmodload
>> > module?
>>
>> If it's just this, then, s/zmodload module/$fpath function/, surely
>
> A shell function can't be static-linked to the base shell to guarantee
> it's availability.

A module can be left out of the compile; a shell function can be left
out of the $DESTDIR by 'make install'.  A module can be linked
statically; a function can be defined in /etc/zshenv.  Seems like six of
one, half a dozen of the other to me?  It all boils down to "configure and
make correctly", but one of the approaches is a lot easier for users to
edit to taste.

That's assuming what the module/function does is just set the three
parameters.  I'll be quiet for a bit so people have a chance to weigh in
on the idea of enabling history by assigning to a special parameter or
calling a builtin.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-27  3:52                           ` Lawrence Velázquez
  2022-08-27 15:44                             ` Daniel Shahaf
@ 2022-08-30 19:31                             ` Felipe Contreras
  2022-08-31 12:28                               ` Vincent Lefevre
  2022-08-31 21:57                               ` Mikael Magnusson
  1 sibling, 2 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-08-30 19:31 UTC (permalink / raw)
  To: Lawrence Velázquez; +Cc: Bart Schaefer, zsh-workers

On Fri, Aug 26, 2022 at 10:55 PM Lawrence Velázquez <larryv@zsh.org> wrote:
> On Fri, Aug 26, 2022, at 11:18 PM, Felipe Contreras wrote:
> > On Fri, Aug 26, 2022 at 7:31 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >> On Fri, Aug 26, 2022 at 5:23 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> >> >
> >> > Besides that, the whole thing is way too
> >> > disruptive just for you to save 2 lines in your .zshrc.
> >>
> >> Pretty much exactly that.  The argument FOR doing something has to be
> >> persuasive, rebutting specific counterpoints is only part of that.  I
> >> haven't seen anyone yet supporting your position without modification.
> >
> > I'm not sure what you mean. The argument in favor is right there: it
> > potentially reduces the number of options required in the
> > configuration.
>
> We know what your argument is.  Some of us just are not persuaded
> by it.

Yes, but "we" are zsh veterans. We don't need a simpler .zshrc, but
newcomers do.

There's a bias called "the curse of knowledge" [1] where individuals
assume other individuals have their same level of knowledge, therefore
certain explanations are not needed. For example an expert in calculus
might think there's no need to comment about the chain rule, because
"everybody" knows that, right? Or an expert in statistics presuming
everyone knows the CLT.

The truth is not everyone knows what you know.

We also forget how difficult it was to learn something, like writing,
driving a car, or using git.

You may think HISTFILE, SAVEHIST and HISTSIZE are self-explanatory,
but the fact is most people need to read the documentation, and even
then they end up confused. A few days ago I replied to a person on
reddit who had a configuration with HISTSIZE bigger than SAVEHIST.

> > But if you are an 18yo kid who just installed zsh, a configuration of
> > 3 lines vs. a configuration of 1 line makes a difference of 67%.
> > That's quite a lot.
>
> It's not a lot.  It's still two lines.  Using an impressive-looking
> percentage doesn't change this.

It's not a lot to you, because you already know what those two lines do.

Nobody is going to write those two lines for a newcomer, he will have
to read two entries in the manual to understand what those two lines
do, and even then might not necessarily get it.

7 lines of C code to print a "hello world" might not be a lot to you,
but a person who doesn't know C sees it differently.

> > A better experience for new users is just better. The
> > `zsh-newuser-install` script is a step in the right direction, but in
> > my view it shouldn't be necessary. Running zsh with no configuration
> > should do a decent job for most people by default.
> >
> > The ideal minimal configuration that does a good enough job for most
> > people should be *zero* lines. Even if we never get there, any line
> > saved is a step in the right direction.
>
> If we were starting from a blank slate, I'm sure more of us would
> be on board.  As it is, there are tradeoffs regarding compatibility
> and interactions with existing functionality.  You seem to not care
> about that and want "a better experience for new users" at all cost,
> but we don't have to agree.

The tradeoffs depend on the implementation, which is currently under discussion.

If I didn't care about tradeoffs why would I be exploring different options?

Plus, so far I haven't seen anybody mention any "tradeoff" to SAVEHIST=-1.

Cheers.

[1] https://en.wikipedia.org/wiki/Curse_of_knowledge

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-26  4:22               ` Felipe Contreras
@ 2022-08-31 11:43                 ` Vincent Lefevre
  0 siblings, 0 replies; 93+ messages in thread
From: Vincent Lefevre @ 2022-08-31 11:43 UTC (permalink / raw)
  To: zsh-workers

On 2022-08-25 23:22:13 -0500, Felipe Contreras wrote:
> This:
> 
>   sect(Why is my history not being saved?)
>   label(321)
> 
>     In zsh you need to specifically enable history:
>     verb(
>       setopt SAVE_HISTORY
>     )
> 
> Is simpler than this:
> 
>   sect(Why is my history not being saved?)
>   label(321)
> 
>     In zsh, you need to set three variables to make sure your history is
>     written out when the shell exits.  For example,
>     verb(
>       HISTSIZE=200
>       HISTFILE=~/.zsh_history
>       SAVEHIST=200
>     )
>     tt($HISTSIZE) tells the shell how many lines to keep internally,
>     tt($HISTFILE) tells it where to write the history, and tt($SAVEHIST),
>     the easiest one to forget, tells it how many to write out.  The
>     simplest possibility is to set it to the same as tt($HISTSIZE) as
>     above.  There are also various options affecting history; see the
>     manual.

The ability to choose the history filename and size is more important
than just having a single option for simplicity.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-30 19:31                             ` Felipe Contreras
@ 2022-08-31 12:28                               ` Vincent Lefevre
  2022-08-31 19:36                                 ` Bart Schaefer
  2022-09-02  9:20                                 ` [RFC PATCH 3/3] FAQ: sync newuser-install Daniel Shahaf
  2022-08-31 21:57                               ` Mikael Magnusson
  1 sibling, 2 replies; 93+ messages in thread
From: Vincent Lefevre @ 2022-08-31 12:28 UTC (permalink / raw)
  To: zsh-workers

On 2022-08-30 14:31:30 -0500, Felipe Contreras wrote:
> Yes, but "we" are zsh veterans. We don't need a simpler .zshrc, but
> newcomers do.

Having a too simple .zshrc file is not helping them. Rather than
hidden defaults, I think that it is better to have explicit values
in some default .zshrc file, so that it is easier to change them.
In particular, the default depends very much on the usage.

I currently use HISTSIZE=8000 SAVEHIST=8000, and while this value
is OK on some machines, I've noticed that I sometimes lose commands,
and indeed, after a look, this gives me only a 12-day history on my
main machine, while I would have thought that it would be several
weeks (I wish I could set a minimum time limit for the history).

And there's more than the history. I suspect that many users would
like "bindkey -e", a better prompt and better completions than the
default. But such things could only be in a default .zshrc file,
because there are no good hardcoded defaults.

> > It's not a lot.  It's still two lines.  Using an impressive-looking
> > percentage doesn't change this.
> 
> It's not a lot to you, because you already know what those two lines do.
> 
> Nobody is going to write those two lines for a newcomer, he will have
> to read two entries in the manual to understand what those two lines
> do, and even then might not necessarily get it.

Not if these lines are put in a default .zshrc file, with minimum
documentation (in case the user would want to change them without
having to read all the details in the manual).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-31 12:28                               ` Vincent Lefevre
@ 2022-08-31 19:36                                 ` Bart Schaefer
  2022-09-01  0:23                                   ` Vincent Lefevre
  2022-09-02  9:20                                 ` [RFC PATCH 3/3] FAQ: sync newuser-install Daniel Shahaf
  1 sibling, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-08-31 19:36 UTC (permalink / raw)
  To: zsh-workers

On Wed, Aug 31, 2022 at 5:34 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On 2022-08-30 14:31:30 -0500, Felipe Contreras wrote:
> > Yes, but "we" are zsh veterans. We don't need a simpler .zshrc, but
> > newcomers do.
>
> Having a too simple .zshrc file is not helping them. Rather than
> hidden defaults, I think that it is better to have explicit values
> in some default .zshrc file, so that it is easier to change them.

We've made several stabs at this without ever coming to a resolution.
The most recent attempt was in spring 2021 (search archives for
subject "Rewrite of zsh-newuser-install").

There have always been 3 problems:
 * Supplying a default file leads to package maintainers shoving it
into /etc, despite admonitions to the contrary
 * A small well-documented file is easy to understand and edit, but ...
 * ... others want the default file to enable and configure all the
cool/powerful features

Consequently we go round in circles and end up changing nothing.

> I currently use HISTSIZE=8000 SAVEHIST=8000, and while this value
> is OK on some machines, I've noticed that I sometimes lose commands,
> and indeed, after a look, this gives me only a 12-day history on my
> main machine, while I would have thought that it would be several
> weeks (I wish I could set a minimum time limit for the history).

That's actually not a bad idea, and would probably work well in
conjunction with HIST_SAVE_NO_DUPS.  Would require EXTENDED_HISTORY.

> And there's more than the history. I suspect that many users would
> like "bindkey -e", a better prompt and better completions than the
> default.

Cf. "all the cool/powerful features" ...

(Isn't "bindkey -e" already the default?  Is this just to overcome
having EDITOR=vim or some such?)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-30 19:31                             ` Felipe Contreras
  2022-08-31 12:28                               ` Vincent Lefevre
@ 2022-08-31 21:57                               ` Mikael Magnusson
  2022-08-31 22:28                                 ` Roman Perepelitsa
  1 sibling, 1 reply; 93+ messages in thread
From: Mikael Magnusson @ 2022-08-31 21:57 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Lawrence Velázquez, Bart Schaefer, zsh-workers

On 8/30/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
> You may think HISTFILE, SAVEHIST and HISTSIZE are self-explanatory,
> but the fact is most people need to read the documentation, and even
> then they end up confused. A few days ago I replied to a person on
> reddit who had a configuration with HISTSIZE bigger than SAVEHIST.

That is the correct configuration.

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-31 21:57                               ` Mikael Magnusson
@ 2022-08-31 22:28                                 ` Roman Perepelitsa
  2022-09-01  0:29                                   ` Bart Schaefer
  2022-09-01 22:45                                   ` Felipe Contreras
  0 siblings, 2 replies; 93+ messages in thread
From: Roman Perepelitsa @ 2022-08-31 22:28 UTC (permalink / raw)
  To: Mikael Magnusson
  Cc: Felipe Contreras, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Wed, Aug 31, 2022 at 11:57 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> On 8/30/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >
> > You may think HISTFILE, SAVEHIST and HISTSIZE are self-explanatory,
> > but the fact is most people need to read the documentation, and even
> > then they end up confused. A few days ago I replied to a person on
> > reddit who had a configuration with HISTSIZE bigger than SAVEHIST.
>
> That is the correct configuration.

This is my understanding as well. To be more specific, SAVEHIST
greater than HISTSIZE is equivalent to its being equal to HISTSIZE. It
was Oliver's point in the comment that, I believe, Felipe referred to:
https://www.reddit.com/r/zsh/comments/wy0sm6/what_is_your_history_configuration/im0yq3w/.
I don't understand Felipe's reply but I think he disagreed.

Roman.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-31 19:36                                 ` Bart Schaefer
@ 2022-09-01  0:23                                   ` Vincent Lefevre
  2022-09-01  0:35                                     ` Bart Schaefer
  0 siblings, 1 reply; 93+ messages in thread
From: Vincent Lefevre @ 2022-09-01  0:23 UTC (permalink / raw)
  To: zsh-workers

On 2022-08-31 12:36:06 -0700, Bart Schaefer wrote:
> On Wed, Aug 31, 2022 at 5:34 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > On 2022-08-30 14:31:30 -0500, Felipe Contreras wrote:
> > > Yes, but "we" are zsh veterans. We don't need a simpler .zshrc, but
> > > newcomers do.
> >
> > Having a too simple .zshrc file is not helping them. Rather than
> > hidden defaults, I think that it is better to have explicit values
> > in some default .zshrc file, so that it is easier to change them.
> 
> We've made several stabs at this without ever coming to a resolution.
> The most recent attempt was in spring 2021 (search archives for
> subject "Rewrite of zsh-newuser-install").
> 
> There have always been 3 problems:
>  * Supplying a default file leads to package maintainers shoving it
> into /etc, despite admonitions to the contrary

Perhaps it should first check that the owner of the file corresponds
to $UID.

>  * A small well-documented file is easy to understand and edit, but ...
>  * ... others want the default file to enable and configure all the
> cool/powerful features
> 
> Consequently we go round in circles and end up changing nothing.

Provide a minimal .zshrc and an additional .zshrc-extra, where
the .zshrc file ends with

# Uncomment to configure extra features (or copy such features here)
#source .zshrc-extra

> > I currently use HISTSIZE=8000 SAVEHIST=8000, and while this value
> > is OK on some machines, I've noticed that I sometimes lose commands,
> > and indeed, after a look, this gives me only a 12-day history on my
> > main machine, while I would have thought that it would be several
> > weeks (I wish I could set a minimum time limit for the history).
> 
> That's actually not a bad idea, and would probably work well in
> conjunction with HIST_SAVE_NO_DUPS.  Would require EXTENDED_HISTORY.

Or SHARE_HISTORY?

I do not use HIST_SAVE_NO_DUPS because it breaks
accept-line-and-down-history.

I use INC_APPEND_HISTORY (together with EXTENDED_HISTORY). So the
history lines are already sorted by time.

> > And there's more than the history. I suspect that many users would
> > like "bindkey -e", a better prompt and better completions than the
> > default.
> 
> Cf. "all the cool/powerful features" ...
> 
> (Isn't "bindkey -e" already the default?  Is this just to overcome
> having EDITOR=vim or some such?)

Unfortunately, it isn't (at least not with "zsh -f", for which the
only possibility is to type "bindkey -e").

BTW, the manual says:

  Emacs editing mode is probably more natural for beginners and
  can be selected explicitly with the command bindkey -e.

Since it is probably more natural for beginners, why isn't it the
default?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-31 22:28                                 ` Roman Perepelitsa
@ 2022-09-01  0:29                                   ` Bart Schaefer
  2022-09-01 22:45                                   ` Felipe Contreras
  1 sibling, 0 replies; 93+ messages in thread
From: Bart Schaefer @ 2022-09-01  0:29 UTC (permalink / raw)
  To: zsh-workers

On Wed, Aug 31, 2022 at 3:28 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Wed, Aug 31, 2022 at 11:57 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> >
> > On 8/30/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > >
> > > reddit who had a configuration with HISTSIZE bigger than SAVEHIST.
> >
> > That is the correct configuration.
>
> This is my understanding as well. To be more specific, SAVEHIST
> greater than HISTSIZE is equivalent to its being equal to HISTSIZE.

Although it is true that only the most recent HISTSIZE entries from
HISTFILE will remain in the interactive history when a new shell
starts, there are cases where a larger SAVEHIST makes sense, typically
if you are using INC_APPEND_HISTORY or SHARE_HISTORY.  For example,
SAVEHIST determines how often the file is rewritten.  Combined with
HIST_SAVE_NO_DUPS you might preserve some unique older entries when a
second shell is sharing the history.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-01  0:23                                   ` Vincent Lefevre
@ 2022-09-01  0:35                                     ` Bart Schaefer
  2022-09-01  1:21                                       ` Vincent Lefevre
  0 siblings, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-09-01  0:35 UTC (permalink / raw)
  To: zsh-workers

On Wed, Aug 31, 2022 at 5:28 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On 2022-08-31 12:36:06 -0700, Bart Schaefer wrote:
> > (Isn't "bindkey -e" already the default?  Is this just to overcome
> > having EDITOR=vim or some such?)
>
> Unfortunately, it isn't (at least not with "zsh -f", for which the
> only possibility is to type "bindkey -e").

Really?

Src/zsh -f
% echo $EDITOR $VISUAL

% bindkey > /tmp/zsh-default-bindkey
% bindkey -e
% bindkey > /tmp/zsh-emacs-bindkey
% diff /tmp/zsh*key
%

What then IS the default for zsh -f ?


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-01  0:35                                     ` Bart Schaefer
@ 2022-09-01  1:21                                       ` Vincent Lefevre
  2022-09-01  2:42                                         ` [PATCH] initialization of main keymap Bart Schaefer
  0 siblings, 1 reply; 93+ messages in thread
From: Vincent Lefevre @ 2022-09-01  1:21 UTC (permalink / raw)
  To: zsh-workers

On 2022-08-31 17:35:19 -0700, Bart Schaefer wrote:
> On Wed, Aug 31, 2022 at 5:28 PM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > On 2022-08-31 12:36:06 -0700, Bart Schaefer wrote:
> > > (Isn't "bindkey -e" already the default?  Is this just to overcome
> > > having EDITOR=vim or some such?)
> >
> > Unfortunately, it isn't (at least not with "zsh -f", for which the
> > only possibility is to type "bindkey -e").
> 
> Really?
> 
> Src/zsh -f
> % echo $EDITOR $VISUAL
> 
> % bindkey > /tmp/zsh-default-bindkey
> % bindkey -e
> % bindkey > /tmp/zsh-emacs-bindkey
> % diff /tmp/zsh*key
> %

I get differences. But they disappear if I unset EDITOR and VISUAL.

Well... I get the vi bindings only on some of my machines, despite
the same configuration.

       In  addition  to these names, either `emacs' or `viins' is
       also linked to the name `main'.  If one of the  VISUAL  or
       EDITOR  environment variables contain the string `vi' when
       the shell starts up then it will be `viins', otherwise  it
       will  be  `emacs'.  [...]

Really? This is silly! Just because my login name contains "vi"
on some machines, I get the vi bindings.

zira:~> echo $EDITOR
/home/vinc17/bin/eclient

I suppose that it should take the first word and get the tail (:t).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* [PATCH] initialization of main keymap
  2022-09-01  1:21                                       ` Vincent Lefevre
@ 2022-09-01  2:42                                         ` Bart Schaefer
  2022-09-01 21:58                                           ` Felipe Contreras
  2022-09-02  0:04                                           ` Vincent Lefevre
  0 siblings, 2 replies; 93+ messages in thread
From: Bart Schaefer @ 2022-09-01  2:42 UTC (permalink / raw)
  To: Zsh hackers list

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

On Wed, Aug 31, 2022 at 6:22 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> This is silly! Just because my login name contains "vi"
> on some machines, I get the vi bindings.

How about this?

[-- Attachment #2: initmainkeymap.txt --]
[-- Type: text/plain, Size: 627 bytes --]

diff --git a/Src/Zle/zle_keymap.c b/Src/Zle/zle_keymap.c
index d90838f03..8e5ad3fa2 100644
--- a/Src/Zle/zle_keymap.c
+++ b/Src/Zle/zle_keymap.c
@@ -1454,8 +1454,8 @@ default_bindings(void)
     linkkeymap(oppmap, "viopp", 0);
     linkkeymap(vismap, "visual", 0);
     linkkeymap(smap, ".safe", 1);
-    if (((ed = zgetenv("VISUAL")) && strstr(ed, "vi")) ||
-	((ed = zgetenv("EDITOR")) && strstr(ed, "vi")))
+    if (((ed = zgetenv("VISUAL")) && strstr(ed, "vi") > rindex(ed, '/')) ||
+	((ed = zgetenv("EDITOR")) && strstr(ed, "vi") > rindex(ed, '/')))
 	linkkeymap(vmap, "main", 0);
     else
 	linkkeymap(emap, "main", 0);


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-01  2:42                                         ` [PATCH] initialization of main keymap Bart Schaefer
@ 2022-09-01 21:58                                           ` Felipe Contreras
  2022-09-01 22:34                                             ` Bart Schaefer
  2022-09-02  8:51                                             ` Daniel Shahaf
  2022-09-02  0:04                                           ` Vincent Lefevre
  1 sibling, 2 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-09-01 21:58 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Wed, Aug 31, 2022 at 9:48 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Wed, Aug 31, 2022 at 6:22 PM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > This is silly! Just because my login name contains "vi"
> > on some machines, I get the vi bindings.
>
> How about this?

Now I understand why I always have to specify "bindkey -e" in my .zshrc.

This is assuming that vim users want to use vi bindings in the shell,
which is emphatically not true. The shell is not a text editor, the
flow is completely different, which is why most vim users use emacs
key bindings in the shell.

In my opinion the default should always be emacs bindings, no matter what.

As for the patch: it would miss gvim and nvim.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-01 21:58                                           ` Felipe Contreras
@ 2022-09-01 22:34                                             ` Bart Schaefer
  2022-09-01 22:54                                               ` Felipe Contreras
  2022-09-02  8:51                                             ` Daniel Shahaf
  1 sibling, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-09-01 22:34 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Zsh hackers list

On Thu, Sep 1, 2022 at 2:58 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> As for the patch: it would miss gvim and nvim.

I think you're wrong about that.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-31 22:28                                 ` Roman Perepelitsa
  2022-09-01  0:29                                   ` Bart Schaefer
@ 2022-09-01 22:45                                   ` Felipe Contreras
  2022-09-02  3:46                                     ` Mikael Magnusson
  1 sibling, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-09-01 22:45 UTC (permalink / raw)
  To: Roman Perepelitsa
  Cc: Mikael Magnusson, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Wed, Aug 31, 2022 at 5:28 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> On Wed, Aug 31, 2022 at 11:57 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> > On 8/30/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:

> > > You may think HISTFILE, SAVEHIST and HISTSIZE are self-explanatory,
> > > but the fact is most people need to read the documentation, and even
> > > then they end up confused. A few days ago I replied to a person on
> > > reddit who had a configuration with HISTSIZE bigger than SAVEHIST.
> >
> > That is the correct configuration.
>
> This is my understanding as well. To be more specific, SAVEHIST
> greater than HISTSIZE is equivalent to its being equal to HISTSIZE.

Only if you are not using APPEND_HISTORY.

Isn't this proof that zsh developers are projecting too much of their
*personal* workflow into the users? Not everyone uses zsh the way you
do.

If even veteran experts can't get right SAVEHIST and HISTSIZE, what
hope does a brand new newcomer have?

It is unreasonable to force absolutely every new user to set these
options just to get started.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-01 22:34                                             ` Bart Schaefer
@ 2022-09-01 22:54                                               ` Felipe Contreras
  0 siblings, 0 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-09-01 22:54 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Thu, Sep 1, 2022 at 5:34 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Thu, Sep 1, 2022 at 2:58 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > As for the patch: it would miss gvim and nvim.
>
> I think you're wrong about that.

Right, I only took a cursory look. If the search is starting from the
right, then I guess it should work.

I still don't think it's reasonable to assume vim users want to use vi mode.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-01  2:42                                         ` [PATCH] initialization of main keymap Bart Schaefer
  2022-09-01 21:58                                           ` Felipe Contreras
@ 2022-09-02  0:04                                           ` Vincent Lefevre
  2022-09-02  5:06                                             ` Bart Schaefer
  1 sibling, 1 reply; 93+ messages in thread
From: Vincent Lefevre @ 2022-09-02  0:04 UTC (permalink / raw)
  To: zsh-workers

On 2022-08-31 19:42:44 -0700, Bart Schaefer wrote:
> On Wed, Aug 31, 2022 at 6:22 PM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > This is silly! Just because my login name contains "vi"
> > on some machines, I get the vi bindings.
> 
> How about this?

Thanks. This solves the problem.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-01 22:45                                   ` Felipe Contreras
@ 2022-09-02  3:46                                     ` Mikael Magnusson
  2022-09-02  5:57                                       ` Felipe Contreras
                                                         ` (2 more replies)
  0 siblings, 3 replies; 93+ messages in thread
From: Mikael Magnusson @ 2022-09-02  3:46 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Roman Perepelitsa, Lawrence Velázquez, Bart Schaefer, zsh-workers

On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> On Wed, Aug 31, 2022 at 5:28 PM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
>> On Wed, Aug 31, 2022 at 11:57 PM Mikael Magnusson <mikachu@gmail.com>
>> wrote:
>> > On 8/30/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> > > You may think HISTFILE, SAVEHIST and HISTSIZE are self-explanatory,
>> > > but the fact is most people need to read the documentation, and even
>> > > then they end up confused. A few days ago I replied to a person on
>> > > reddit who had a configuration with HISTSIZE bigger than SAVEHIST.
>> >
>> > That is the correct configuration.
>>
>> This is my understanding as well. To be more specific, SAVEHIST
>> greater than HISTSIZE is equivalent to its being equal to HISTSIZE.
>
> Only if you are not using APPEND_HISTORY.

Still wrong. SAVEHIST greater than HISTSIZE is always equivalent to
its being equal to HISTSIZE as we have said repeatedly. If you
continue to argue otherwise it is surely trolling. If it is a mistake,
please read mails more carefully before making such firm assertions or
phrase them as a question if you are unsure.

> Isn't this proof that zsh developers are projecting too much of their
> *personal* workflow into the users? Not everyone uses zsh the way you
> do.
>
> If even veteran experts can't get right SAVEHIST and HISTSIZE, what
> hope does a brand new newcomer have?

The fact that you misunderstood something is not really proof of
anything, given how often you've made incorrect statements in the past
few days. I also don't think this could be clearer:

  You should be sure to set  the  value of HISTSIZE to a larger number
than SAVEHIST in order to give you some room for the duplicated
events, otherwise this  option  will  behave just like
HIST_IGNORE_ALL_DUPS once the history fills up with unique events.

Though admittedly the SAVEHIST entry could have references to the
APPEND_HISTORY and HIST_EXPIRE_DUPS_FIRST options (the HISTSIZE entry
already references the latter):

  If you use the  HIST_EXPIRE_DUPS_FIRST  option, setting this value
larger than the SAVEHIST size will give you the difference as a
cushion  for  saving  duplicated history events.

> It is unreasonable to force absolutely every new user to set these
> options just to get started.

"Paste these lines in .zshrc to enable history" is not more
complicated with 3 lines than 1, however much you want to argue that
it is. They still need to find the line(s) to copy in the first place
(or god forbid, read the documentation).

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-02  0:04                                           ` Vincent Lefevre
@ 2022-09-02  5:06                                             ` Bart Schaefer
  2022-09-02 13:15                                               ` Vincent Lefevre
  0 siblings, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-09-02  5:06 UTC (permalink / raw)
  To: zsh-workers

Upon further thought ...
1) It's a bit odd that if both VISUAL and EDITOR are set, and VISUAL
is not set to a variant of vi, but EDITOR is, then zsh prefers to use
the bindings corresponding to EDITOR.
2) As written the patch will always give Vincent the emacs bindings
because strstr() starts at the beginning and finds "vinc17" before
ever looking beyond the rindex().

Perhaps we should prefer VISUAL any time it is set?


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-02  3:46                                     ` Mikael Magnusson
@ 2022-09-02  5:57                                       ` Felipe Contreras
  2022-09-02 23:14                                         ` Mikael Magnusson
  2022-09-02  9:18                                       ` Daniel Shahaf
  2022-09-03 13:38                                       ` Roman Perepelitsa
  2 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-09-02  5:57 UTC (permalink / raw)
  To: Mikael Magnusson
  Cc: Roman Perepelitsa, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Thu, Sep 1, 2022 at 10:46 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > On Wed, Aug 31, 2022 at 5:28 PM Roman Perepelitsa
> > <roman.perepelitsa@gmail.com> wrote:
> >> On Wed, Aug 31, 2022 at 11:57 PM Mikael Magnusson <mikachu@gmail.com>
> >> wrote:
> >> > On 8/30/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:

> >> > > You may think HISTFILE, SAVEHIST and HISTSIZE are self-explanatory,
> >> > > but the fact is most people need to read the documentation, and even
> >> > > then they end up confused. A few days ago I replied to a person on
> >> > > reddit who had a configuration with HISTSIZE bigger than SAVEHIST.
> >> >
> >> > That is the correct configuration.
> >>
> >> This is my understanding as well. To be more specific, SAVEHIST
> >> greater than HISTSIZE is equivalent to its being equal to HISTSIZE.
> >
> > Only if you are not using APPEND_HISTORY.
>
> Still wrong. SAVEHIST greater than HISTSIZE is always equivalent to
> its being equal to HISTSIZE as we have said repeatedly. If you
> continue to argue otherwise it is surely trolling.

Really?

Please tell me the output of this script:

  #!/bin/zsh

  zmodload zsh/zpty

  export ZDOTDIR=/tmp/zsh
  export HISTFILE=$ZDOTDIR/.history
  export HISTSIZE=2
  export SAVEHIST=10

  mkdir -p $ZDOTDIR
  touch $ZDOTDIR/.zshrc

  for n in $(seq 10); do
  zpty $n zsh

  zpty -w $n <<-EOF
  echo one
  echo two
  exit
  EOF

  zpty -r $n _
  done

  wc -l $HISTFILE

I wonder if you will keep your derogatory tone towards me after running it.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-01 21:58                                           ` Felipe Contreras
  2022-09-01 22:34                                             ` Bart Schaefer
@ 2022-09-02  8:51                                             ` Daniel Shahaf
  2022-09-02 13:23                                               ` Vincent Lefevre
                                                                 ` (2 more replies)
  1 sibling, 3 replies; 93+ messages in thread
From: Daniel Shahaf @ 2022-09-02  8:51 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Zsh hackers list

Felipe Contreras wrote on Thu, Sep 01, 2022 at 16:58:05 -0500:
> most vim users use emacs key bindings in the shell.

Citation needed.

> In my opinion the default should always be emacs bindings, no matter what.

+1

If the default were /either/ vi or emacs, a patch making the default
depend on the value of $EDITOR would never have been accepted.  We'd
have pointed out that it was overloading an environment variable that
already has a well-defined meaning; that a dependency between that
envvar and zle violates the principle of least surprise; that assuming
strstr(…, "vi") means "Vi-like editor" is guesswork (cf. PEP20); that
the C code shouldn't presume Vi users necessarily prefer «bindkey -v»;
and that users can and should set their preferred Zsh Line Editor keymap
in zshrc.

Attached is a counterpatch for discussion.

Felipe: Should revisions to this patch be requested, feel free to beat
me to implementing them, if you wish.

Cheers,

Daniel

[[[
diff --git a/README b/README
index 21142e17c..f4821e0e1 100644
--- a/README
+++ b/README
@@ -31,6 +31,28 @@ Zsh is a shell with lots of features.  For a list of some of these, see the
 file FEATURES, and for the latest changes see NEWS.  For more
 details, see the documentation.
 
+Incompatibilities since 5.9
+---------------------------
+
+The line editor's default keymap is now the "emacs" keymap regardless of the
+value of the environment variables $VISUAL and $EDITOR.  This only affects you
+if your $VISUAL or $EDITOR environment variable is set to a value that
+contains the string "vi".  To get the previous behaviour, add
+.
+    bindkey -v
+.
+or, if your $VISUAL and $EDITOR environment variables vary,
+.
+    if [[ ${VISUAL:-${EDITOR:-emacs}} == *vi* ]]; then
+        bindkey -v
+    else
+        bindkey -e
+    fi
+.
+to your .zshrc file.  These snippets are compatible with previous
+versions of the shell.
+
 Incompatibilities since 5.8.1
 -----------------------------
 
diff --git a/Src/Zle/zle_keymap.c b/Src/Zle/zle_keymap.c
index d90838f03..67a5351fd 100644
--- a/Src/Zle/zle_keymap.c
+++ b/Src/Zle/zle_keymap.c
@@ -1445,20 +1445,14 @@ default_bindings(void)
 	}
 
     /* Put the keymaps in the right namespace.  The "main" keymap  *
-     * will be linked to the "emacs" keymap, except that if VISUAL *
-     * or EDITOR contain the string "vi" then it will be linked to *
-     * the "viins" keymap.                                         */
+     * will be linked to the "emacs" keymap.                       */
     linkkeymap(vmap, "viins", 0);
     linkkeymap(emap, "emacs", 0);
     linkkeymap(amap, "vicmd", 0);
     linkkeymap(oppmap, "viopp", 0);
     linkkeymap(vismap, "visual", 0);
     linkkeymap(smap, ".safe", 1);
-    if (((ed = zgetenv("VISUAL")) && strstr(ed, "vi")) ||
-	((ed = zgetenv("EDITOR")) && strstr(ed, "vi")))
-	linkkeymap(vmap, "main", 0);
-    else
-	linkkeymap(emap, "main", 0);
+    linkkeymap(emap, "main", 0);
 
     /* the .safe map cannot be modified or deleted */
     smap->flags |= KM_IMMUTABLE;
]]]


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-02  3:46                                     ` Mikael Magnusson
  2022-09-02  5:57                                       ` Felipe Contreras
@ 2022-09-02  9:18                                       ` Daniel Shahaf
  2022-09-02 12:50                                         ` Vincent Lefevre
  2022-09-03 13:38                                       ` Roman Perepelitsa
  2 siblings, 1 reply; 93+ messages in thread
From: Daniel Shahaf @ 2022-09-02  9:18 UTC (permalink / raw)
  To: zsh-workers

Mikael Magnusson wrote on Fri, Sep 02, 2022 at 05:46:12 +0200:
> On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > It is unreasonable to force absolutely every new user to set these
> > options just to get started.
> 
> "Paste these lines in .zshrc to enable history" is not more
> complicated with 3 lines than 1, however much you want to argue that
> it is. They still need to find the line(s) to copy in the first place
> (or god forbid, read the documentation).

Copy-pasting three lines is as easy as one, sure.  /Understanding/ them,
however, is a different kettle of fish.  If one has set three special
variables, then one needs to read three zshparam(1) entries rather than
one.

(That's basically why I suggested divorcing "enable history" from
"specify the history filename": to reduce the number of moving parts
that need to be grokked.)

As an attempt at a minimal example, imagine showing either of the
following lines, chosen at random by a fair coin, to someone who's just
learning to read, and asking them what the line prints:

    printf "%s plus %s is %s." "One" "one" "2"

    printf "%s plus %s is %d." "One" "one" "2"

If we did the experiment, I think we'd find non-C-programmers are more
likely to correctly guess the first line than the second.

HTH

Daniel


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-08-31 12:28                               ` Vincent Lefevre
  2022-08-31 19:36                                 ` Bart Schaefer
@ 2022-09-02  9:20                                 ` Daniel Shahaf
  2022-09-02 13:50                                   ` Vincent Lefevre
  1 sibling, 1 reply; 93+ messages in thread
From: Daniel Shahaf @ 2022-09-02  9:20 UTC (permalink / raw)
  To: zsh-workers

> > > It's not a lot.  It's still two lines.  Using an impressive-looking
> > > percentage doesn't change this.
> > 
> > It's not a lot to you, because you already know what those two lines do.
> > 
> > Nobody is going to write those two lines for a newcomer, he will have
> > to read two entries in the manual to understand what those two lines
> > do, and even then might not necessarily get it.
> 
> Not if these lines are put in a default .zshrc file, with minimum
> documentation (in case the user would want to change them without
> having to read all the details in the manual).

Like this?

https://gitlab.com/zsh-sensible/zsh-sensible/-/blob/master/zshrc


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-02  9:18                                       ` Daniel Shahaf
@ 2022-09-02 12:50                                         ` Vincent Lefevre
  2022-09-02 13:28                                           ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Vincent Lefevre @ 2022-09-02 12:50 UTC (permalink / raw)
  To: zsh-workers

On 2022-09-02 09:18:57 +0000, Daniel Shahaf wrote:
> Mikael Magnusson wrote on Fri, Sep 02, 2022 at 05:46:12 +0200:
> > On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > > It is unreasonable to force absolutely every new user to set these
> > > options just to get started.
> > 
> > "Paste these lines in .zshrc to enable history" is not more
> > complicated with 3 lines than 1, however much you want to argue that
> > it is. They still need to find the line(s) to copy in the first place
> > (or god forbid, read the documentation).
> 
> Copy-pasting three lines is as easy as one, sure.  /Understanding/ them,
> however, is a different kettle of fish.  If one has set three special
> variables, then one needs to read three zshparam(1) entries rather than
> one.

Isn't $SAVEHIST equal to $HISTSIZE in most configurations?

In such a case, couldn't a negative value for $SAVEHIST mean that
it should be regarded as SAVEHIST=$HISTSIZE (dynamically)?

Then I think that -1 could be the default value for SAVEHIST.
So only HISTFILE and HISTSIZE would be needed in the .zshrc,
and they are self-explanatory for the end user.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-02  5:06                                             ` Bart Schaefer
@ 2022-09-02 13:15                                               ` Vincent Lefevre
  2022-09-04  9:42                                                 ` ${EDITOR} with spaces (was: Re: [PATCH] initialization of main keymap) Daniel Shahaf
  0 siblings, 1 reply; 93+ messages in thread
From: Vincent Lefevre @ 2022-09-02 13:15 UTC (permalink / raw)
  To: zsh-workers

On 2022-09-01 22:06:03 -0700, Bart Schaefer wrote:
> Upon further thought ...
> 1) It's a bit odd that if both VISUAL and EDITOR are set, and VISUAL
> is not set to a variant of vi, but EDITOR is, then zsh prefers to use
> the bindings corresponding to EDITOR.
> 2) As written the patch will always give Vincent the emacs bindings
> because strstr() starts at the beginning and finds "vinc17" before
> ever looking beyond the rindex().
> 
> Perhaps we should prefer VISUAL any time it is set?

Yes, the current behavior (with or without the patch) is definitely
incorrect. For instance, https://unix.stackexchange.com/a/4861/74516
suggests to set VISUAL to the full-screen editor, and either leave
EDITOR unset or set it to "vi -e" (just in case a special line mode
would be needed in some context). So a user who would use VISUAL=emacs
and EDITOR="vi -e" would probably be annoyed by the current behavior.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-02  8:51                                             ` Daniel Shahaf
@ 2022-09-02 13:23                                               ` Vincent Lefevre
  2022-09-02 13:42                                                 ` Felipe Contreras
  2022-09-02 13:32                                               ` Felipe Contreras
  2022-09-02 16:48                                               ` Bart Schaefer
  2 siblings, 1 reply; 93+ messages in thread
From: Vincent Lefevre @ 2022-09-02 13:23 UTC (permalink / raw)
  To: zsh-workers

On 2022-09-02 08:51:10 +0000, Daniel Shahaf wrote:
> Felipe Contreras wrote on Thu, Sep 01, 2022 at 16:58:05 -0500:
> > most vim users use emacs key bindings in the shell.
> 
> Citation needed.
> 
> > In my opinion the default should always be emacs bindings, no matter what.
> 
> +1

I also think that this would be a better choice, in particular for
users with multiple accounts, sometimes on machines with limited
memory or basic installation, where Emacs is not installed. (In
my case, I need to know vi/vim because this is the only one that
is installed everywhere, and I don't want to learn to use another
editor than Emacs or vi.)

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-02 12:50                                         ` Vincent Lefevre
@ 2022-09-02 13:28                                           ` Felipe Contreras
  2022-09-02 13:47                                             ` Vincent Lefevre
  0 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-09-02 13:28 UTC (permalink / raw)
  To: zsh-workers

On Fri, Sep 2, 2022 at 7:50 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On 2022-09-02 09:18:57 +0000, Daniel Shahaf wrote:
> > Mikael Magnusson wrote on Fri, Sep 02, 2022 at 05:46:12 +0200:
> > > On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > > > It is unreasonable to force absolutely every new user to set these
> > > > options just to get started.
> > >
> > > "Paste these lines in .zshrc to enable history" is not more
> > > complicated with 3 lines than 1, however much you want to argue that
> > > it is. They still need to find the line(s) to copy in the first place
> > > (or god forbid, read the documentation).
> >
> > Copy-pasting three lines is as easy as one, sure.  /Understanding/ them,
> > however, is a different kettle of fish.  If one has set three special
> > variables, then one needs to read three zshparam(1) entries rather than
> > one.
>
> Isn't $SAVEHIST equal to $HISTSIZE in most configurations?
>
> In such a case, couldn't a negative value for $SAVEHIST mean that
> it should be regarded as SAVEHIST=$HISTSIZE (dynamically)?
>
> Then I think that -1 could be the default value for SAVEHIST.
> So only HISTFILE and HISTSIZE would be needed in the .zshrc,
> and they are self-explanatory for the end user.

This is precisely what I proposed in the previous patch:

https://www.zsh.org/mla/workers/2022/msg00830.html

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-02  8:51                                             ` Daniel Shahaf
  2022-09-02 13:23                                               ` Vincent Lefevre
@ 2022-09-02 13:32                                               ` Felipe Contreras
  2022-09-02 16:48                                               ` Bart Schaefer
  2 siblings, 0 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-09-02 13:32 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

On Fri, Sep 2, 2022 at 3:51 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Felipe Contreras wrote on Thu, Sep 01, 2022 at 16:58:05 -0500:

> > most vim users use emacs key bindings in the shell.
>
> Citation needed.

I ran a poll:

https://www.reddit.com/r/vim/comments/x3k06k/do_you_use_emacs_mode_in_the_shell/

I thought the result was going to be that more than 50% would choose
emacs mode for something that is clearly not a text editor, but
apparently only 30% do.

Of course this result cannot be relied upon because reddit users might
be biased, but it is data.

--
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-02 13:23                                               ` Vincent Lefevre
@ 2022-09-02 13:42                                                 ` Felipe Contreras
  2022-09-04  9:39                                                   ` Daniel Shahaf
  0 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-09-02 13:42 UTC (permalink / raw)
  To: zsh-workers

On Fri, Sep 2, 2022 at 8:23 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On 2022-09-02 08:51:10 +0000, Daniel Shahaf wrote:
> > Felipe Contreras wrote on Thu, Sep 01, 2022 at 16:58:05 -0500:
> > > most vim users use emacs key bindings in the shell.
> >
> > Citation needed.
> >
> > > In my opinion the default should always be emacs bindings, no matter what.
> >
> > +1
>
> I also think that this would be a better choice, in particular for
> users with multiple accounts, sometimes on machines with limited
> memory or basic installation, where Emacs is not installed. (In
> my case, I need to know vi/vim because this is the only one that
> is installed everywhere, and I don't want to learn to use another
> editor than Emacs or vi.)

There's also the fact that not everyone sets these variables.
Personally I never used the variable until I realized git used it and
could get rid of the core.editor configuration. A user who finds out
that EDITOR exists and sets it would certainly be surprised when
bindkeys in zsh suddenly don't work correctly.

Moreover, there's also the possibility that it's not the user the one
who set EDITOR, but the distribution or the system administrator, and
again, the user doesn't know about this variable.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-02 13:28                                           ` Felipe Contreras
@ 2022-09-02 13:47                                             ` Vincent Lefevre
  2022-09-02 13:54                                               ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Vincent Lefevre @ 2022-09-02 13:47 UTC (permalink / raw)
  To: zsh-workers

On 2022-09-02 08:28:01 -0500, Felipe Contreras wrote:
> On Fri, Sep 2, 2022 at 7:50 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > On 2022-09-02 09:18:57 +0000, Daniel Shahaf wrote:
> > > Mikael Magnusson wrote on Fri, Sep 02, 2022 at 05:46:12 +0200:
> > > > On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > > > > It is unreasonable to force absolutely every new user to set these
> > > > > options just to get started.
> > > >
> > > > "Paste these lines in .zshrc to enable history" is not more
> > > > complicated with 3 lines than 1, however much you want to argue that
> > > > it is. They still need to find the line(s) to copy in the first place
> > > > (or god forbid, read the documentation).
> > >
> > > Copy-pasting three lines is as easy as one, sure.  /Understanding/ them,
> > > however, is a different kettle of fish.  If one has set three special
> > > variables, then one needs to read three zshparam(1) entries rather than
> > > one.
> >
> > Isn't $SAVEHIST equal to $HISTSIZE in most configurations?
> >
> > In such a case, couldn't a negative value for $SAVEHIST mean that
> > it should be regarded as SAVEHIST=$HISTSIZE (dynamically)?
> >
> > Then I think that -1 could be the default value for SAVEHIST.
> > So only HISTFILE and HISTSIZE would be needed in the .zshrc,
> > and they are self-explanatory for the end user.
> 
> This is precisely what I proposed in the previous patch:
> 
> https://www.zsh.org/mla/workers/2022/msg00830.html

Perhaps, but then, I think that your patch description
"Make SAVEHIST default to HISTSIZE" is wrong, or at least
the patch lacks a multiline description. Moreover, an update
of the man pages would be necessary.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-02  9:20                                 ` [RFC PATCH 3/3] FAQ: sync newuser-install Daniel Shahaf
@ 2022-09-02 13:50                                   ` Vincent Lefevre
  0 siblings, 0 replies; 93+ messages in thread
From: Vincent Lefevre @ 2022-09-02 13:50 UTC (permalink / raw)
  To: zsh-workers

On 2022-09-02 09:20:55 +0000, Daniel Shahaf wrote:
> > Not if these lines are put in a default .zshrc file, with minimum
> > documentation (in case the user would want to change them without
> > having to read all the details in the manual).
> 
> Like this?
> 
> https://gitlab.com/zsh-sensible/zsh-sensible/-/blob/master/zshrc

Yes, this the TODO resolved, of course.

But for the "TODO man page reference", this should be more than just
a reference to the man page. What these settings do should also be
shortly described.

Also

HISTSIZE=1000
SAVEHIST=1000

should be changed to

HISTSIZE=1000
SAVEHIST=$HISTSIZE

so that the size could be changed by modifying a single value.
But see also the suggestion of make SAVEHIST behave as HISTSIZE,
so that setting SAVEHIST should be removed.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-02 13:47                                             ` Vincent Lefevre
@ 2022-09-02 13:54                                               ` Felipe Contreras
  0 siblings, 0 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-09-02 13:54 UTC (permalink / raw)
  To: zsh-workers

On Fri, Sep 2, 2022 at 8:47 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On 2022-09-02 08:28:01 -0500, Felipe Contreras wrote:
> > On Fri, Sep 2, 2022 at 7:50 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> > >
> > > On 2022-09-02 09:18:57 +0000, Daniel Shahaf wrote:
> > > > Mikael Magnusson wrote on Fri, Sep 02, 2022 at 05:46:12 +0200:
> > > > > On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > > > > > It is unreasonable to force absolutely every new user to set these
> > > > > > options just to get started.
> > > > >
> > > > > "Paste these lines in .zshrc to enable history" is not more
> > > > > complicated with 3 lines than 1, however much you want to argue that
> > > > > it is. They still need to find the line(s) to copy in the first place
> > > > > (or god forbid, read the documentation).
> > > >
> > > > Copy-pasting three lines is as easy as one, sure.  /Understanding/ them,
> > > > however, is a different kettle of fish.  If one has set three special
> > > > variables, then one needs to read three zshparam(1) entries rather than
> > > > one.
> > >
> > > Isn't $SAVEHIST equal to $HISTSIZE in most configurations?
> > >
> > > In such a case, couldn't a negative value for $SAVEHIST mean that
> > > it should be regarded as SAVEHIST=$HISTSIZE (dynamically)?
> > >
> > > Then I think that -1 could be the default value for SAVEHIST.
> > > So only HISTFILE and HISTSIZE would be needed in the .zshrc,
> > > and they are self-explanatory for the end user.
> >
> > This is precisely what I proposed in the previous patch:
> >
> > https://www.zsh.org/mla/workers/2022/msg00830.html
>
> Perhaps, but then, I think that your patch description
> "Make SAVEHIST default to HISTSIZE" is wrong, or at least
> the patch lacks a multiline description. Moreover, an update
> of the man pages would be necessary.

It wasn't a "true" patch, it was a Request for Comments patch. After
the comments it's clear doing this at this point creates too much
noise. That's why I decided to focus on increasing the default of
HISTFILE first.

I might send a true patch for this after that, but first things first.

--
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-02  8:51                                             ` Daniel Shahaf
  2022-09-02 13:23                                               ` Vincent Lefevre
  2022-09-02 13:32                                               ` Felipe Contreras
@ 2022-09-02 16:48                                               ` Bart Schaefer
  2022-09-04  9:35                                                 ` Daniel Shahaf
  2 siblings, 1 reply; 93+ messages in thread
From: Bart Schaefer @ 2022-09-02 16:48 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Felipe Contreras, Zsh hackers list

On Fri, Sep 2, 2022 at 1:56 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> If the default were /either/ vi or emacs, a patch making the default
> depend on the value of $EDITOR would never have been accepted.

Hm.  Given that this has been the behavior since before zsh was even
released to the public, I'm not sure how to interpret that.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-02  5:57                                       ` Felipe Contreras
@ 2022-09-02 23:14                                         ` Mikael Magnusson
  2022-09-02 23:56                                           ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Mikael Magnusson @ 2022-09-02 23:14 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Roman Perepelitsa, Lawrence Velázquez, Bart Schaefer, zsh-workers

On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> On Thu, Sep 1, 2022 at 10:46 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>> On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> > On Wed, Aug 31, 2022 at 5:28 PM Roman Perepelitsa
>> > <roman.perepelitsa@gmail.com> wrote:
>> >> On Wed, Aug 31, 2022 at 11:57 PM Mikael Magnusson <mikachu@gmail.com>
>> >> wrote:
>> >> > On 8/30/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> >> > > You may think HISTFILE, SAVEHIST and HISTSIZE are
>> >> > > self-explanatory,
>> >> > > but the fact is most people need to read the documentation, and
>> >> > > even
>> >> > > then they end up confused. A few days ago I replied to a person on
>> >> > > reddit who had a configuration with HISTSIZE bigger than SAVEHIST.
>> >> >
>> >> > That is the correct configuration.
>> >>
>> >> This is my understanding as well. To be more specific, SAVEHIST
>> >> greater than HISTSIZE is equivalent to its being equal to HISTSIZE.
>> >
>> > Only if you are not using APPEND_HISTORY.
>>
>> Still wrong. SAVEHIST greater than HISTSIZE is always equivalent to
>> its being equal to HISTSIZE as we have said repeatedly. If you
>> continue to argue otherwise it is surely trolling.
>
> Really?

Well, if you weren't as confident when you're wrong as when you're
right, I wouldn't have been so confident that you were wrong when you
were right. ;)

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-02 23:14                                         ` Mikael Magnusson
@ 2022-09-02 23:56                                           ` Felipe Contreras
  0 siblings, 0 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-09-02 23:56 UTC (permalink / raw)
  To: Mikael Magnusson
  Cc: Roman Perepelitsa, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Fri, Sep 2, 2022 at 6:14 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > On Thu, Sep 1, 2022 at 10:46 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> >> On 9/2/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >> > On Wed, Aug 31, 2022 at 5:28 PM Roman Perepelitsa
> >> > <roman.perepelitsa@gmail.com> wrote:
> >> >> On Wed, Aug 31, 2022 at 11:57 PM Mikael Magnusson <mikachu@gmail.com>
> >> >> wrote:
> >> >> > On 8/30/22, Felipe Contreras <felipe.contreras@gmail.com> wrote:

> >> >> > > You may think HISTFILE, SAVEHIST and HISTSIZE are
> >> >> > > self-explanatory,
> >> >> > > but the fact is most people need to read the documentation, and
> >> >> > > even
> >> >> > > then they end up confused. A few days ago I replied to a person on
> >> >> > > reddit who had a configuration with HISTSIZE bigger than SAVEHIST.
> >> >> >
> >> >> > That is the correct configuration.
> >> >>
> >> >> This is my understanding as well. To be more specific, SAVEHIST
> >> >> greater than HISTSIZE is equivalent to its being equal to HISTSIZE.
> >> >
> >> > Only if you are not using APPEND_HISTORY.
> >>
> >> Still wrong. SAVEHIST greater than HISTSIZE is always equivalent to
> >> its being equal to HISTSIZE as we have said repeatedly. If you
> >> continue to argue otherwise it is surely trolling.
> >
> > Really?
>
> Well, if you weren't as confident when you're wrong as when you're
> right, I wouldn't have been so confident that you were wrong when you
> were right. ;)

This is a typical ad hominem fallacy. Even people who are often wrong
can make valid arguments. You should focus on the argument, not the
person.

And of course I wasn't wrong before, just like I wasn't wrong now. You
*thought* I was wrong, which is very different.

The only difference between then and now is that this time there was a
100% objective way for me to prove that I'm right.

Either way it shouldn't matter: you have your opinions, I have mine.
It's OK to disagree. But past discussions have no bearing on present
arguments.

Also, I would like to point out that you said this "SAVEHIST greater
than HISTSIZE is always equivalent to its being equal to HISTSIZE as
we have said repeatedly", but you don't speak for everyone, and if you
look at the thread *nobody* agreed with what you said except one other
person, and *nobody* repeated anything. You made the claim once, and
Roman said the same claim once. No repeating.

And then you said "please read mails more carefully before making such
firm assertions".

Maybe you should follow your own advice and then you would realize
that nobody agreed with you in this thread, except one person.

My advice to you is focus on the ball, not the player. This is not a
competition, the objective is to improve zsh, not score points. If I'm
wrong, then I'm wrong, but I'm not wrong just because you say so.

And just for record since you didn't state it explicitly: are we in
agreement that SAVEHIST being bigger than HISTSIZE does have an
effect? In fact, this whole sidetrack reinforces my original point
that people do not necessarily understand SAVEHIST and HISTSIZE, even
zsh expert veterans.

Cheers.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-02  3:46                                     ` Mikael Magnusson
  2022-09-02  5:57                                       ` Felipe Contreras
  2022-09-02  9:18                                       ` Daniel Shahaf
@ 2022-09-03 13:38                                       ` Roman Perepelitsa
  2022-09-03 19:07                                         ` Felipe Contreras
  2 siblings, 1 reply; 93+ messages in thread
From: Roman Perepelitsa @ 2022-09-03 13:38 UTC (permalink / raw)
  To: Mikael Magnusson
  Cc: Felipe Contreras, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Fri, Sep 2, 2022 at 5:46 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> SAVEHIST greater than HISTSIZE is always equivalent to
> its being equal to HISTSIZE [...]

I believe this is the case as far as using history from within zsh is
concerned. If I understand correctly, Felipe wants to have fewer
commands available in history when using zsh than what is stored in
HISTFILE. I'm not sure under which circumstances this can be desired.
Perhaps when working on a system with very little RAM, plenty of disk
space and no swap? In any case, I wouldn't recommend using such a
configuration to beginners because it's bound to cause confusion. It
can be surprising when some lines from HISTFILE aren't available when
searching or printing history from within zsh.

Roman.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-03 23:12                                                   ` Roman Perepelitsa
@ 2022-09-03 18:59                                                     ` Felipe Contreras
  2022-09-04  0:08                                                       ` Roman Perepelitsa
  0 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-09-03 18:59 UTC (permalink / raw)
  To: Roman Perepelitsa
  Cc: Mikael Magnusson, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Sat, Sep 3, 2022 at 6:13 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> On Sat, Sep 3, 2022 at 10:49 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:

> > For starters this patch:
> >
> > https://www.zsh.org/mla/workers/2022/msg00875.html
>
> If I understand correctly, you propose to change this snipped in the guide:

It's not a guide, it's a FAQ, and the entry in the FAQ is "Why is my
history not being saved?", plus a change in zsh-newuser-install as
well.

>     HISTSIZE=200
>     SAVEHIST=200
>
> With this:
>
>     HISTSIZE=200
>     SAVEHIST=$HISTSIZE
>
> To me the original snippet looks better because it makes it clear that
> the two parameters are independent.

The user does not *need* to know that at this point, all he/she needs
is an example that turns history save on. That's it.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-03 13:38                                       ` Roman Perepelitsa
@ 2022-09-03 19:07                                         ` Felipe Contreras
  2022-09-03 19:27                                           ` Roman Perepelitsa
  0 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-09-03 19:07 UTC (permalink / raw)
  To: Roman Perepelitsa
  Cc: Mikael Magnusson, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Sat, Sep 3, 2022 at 8:39 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Fri, Sep 2, 2022 at 5:46 AM Mikael Magnusson <mikachu@gmail.com> wrote:
> >
> > SAVEHIST greater than HISTSIZE is always equivalent to
> > its being equal to HISTSIZE [...]
>
> I believe this is the case as far as using history from within zsh is
> concerned. If I understand correctly, Felipe wants to have fewer
> commands available in history when using zsh than what is stored in
> HISTFILE. I'm not sure under which circumstances this can be desired.
> Perhaps when working on a system with very little RAM, plenty of disk
> space and no swap? In any case, I wouldn't recommend using such a
> configuration to beginners because it's bound to cause confusion. It
> can be surprising when some lines from HISTFILE aren't available when
> searching or printing history from within zsh.

No, this is not what I want. It doesn't matter what I want.

My point is that new users do not necessarily understand what HISTSIZE
and SAVEHIST mean, and they don't have to.

SAVEHIST was created for a reason, and my script demonstrated that
reason. If it was true that SAVEHIST should *always* be the same and
HISTSIZE, then SAVEHIST wouldn't exist, as the code simply could use
HISTSIZE.

This is not something new users should be burdened with, they don't
need to know what SAVEHIST means, just that it should be set to
$HISTSIZE.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-04  0:08                                                       ` Roman Perepelitsa
@ 2022-09-03 19:24                                                         ` Felipe Contreras
  0 siblings, 0 replies; 93+ messages in thread
From: Felipe Contreras @ 2022-09-03 19:24 UTC (permalink / raw)
  To: Roman Perepelitsa
  Cc: Mikael Magnusson, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Sat, Sep 3, 2022 at 7:09 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> On Sun, Sep 4, 2022 at 2:00 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > On Sat, Sep 3, 2022 at 6:13 PM Roman Perepelitsa
> > <roman.perepelitsa@gmail.com> wrote:
> > > On Sat, Sep 3, 2022 at 10:49 PM Felipe Contreras
> > > <felipe.contreras@gmail.com> wrote:

> > > > For starters this patch:
> > > >
> > > > https://www.zsh.org/mla/workers/2022/msg00875.html

> > [...] the entry in the FAQ is "Why is my history not being saved?"
>
> Do you believe that your change makes the answer better? If so, why?

As I explained in the thread [1]:

  1. If HISTFILE is changed in the example, SAVEHIST doesn't need to
     change.
  2. If HISTFILE is removed in the example, SAVEHIST doesn't need to
     change.
  3. If HISTFILE is removed from the example and the default is changed,
     SAVEHIST doesn't need to change.
  4. It lessens the cognitive burden of the user so he/she doesn't have
     to specify a value that comes from something that a) can change in
     the example, b) can change in the defaults, and c) can change in
     the user's own configuration.

And it is even more clear in the next patch, where HISTFILE is increased
and removed from the example.

[1] https://www.zsh.org/mla/workers/2022/msg00910.html

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-03 19:07                                         ` Felipe Contreras
@ 2022-09-03 19:27                                           ` Roman Perepelitsa
  2022-09-03 20:08                                             ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Roman Perepelitsa @ 2022-09-03 19:27 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Mikael Magnusson, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Sat, Sep 3, 2022 at 9:07 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Sat, Sep 3, 2022 at 8:39 AM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > On Fri, Sep 2, 2022 at 5:46 AM Mikael Magnusson <mikachu@gmail.com> wrote:
> > >
> > > SAVEHIST greater than HISTSIZE is always equivalent to
> > > its being equal to HISTSIZE [...]
> >
> > I believe this is the case as far as using history from within zsh is
> > concerned. If I understand correctly, Felipe wants to have fewer
> > commands available in history when using zsh than what is stored in
> > HISTFILE. I'm not sure under which circumstances this can be desired.
> > Perhaps when working on a system with very little RAM, plenty of disk
> > space and no swap? In any case, I wouldn't recommend using such a
> > configuration to beginners because it's bound to cause confusion. It
> > can be surprising when some lines from HISTFILE aren't available when
> > searching or printing history from within zsh.
>
> No, this is not what I want.

My apologies. I thought this was what you wanted based on [1] where
you mentioned that you set history parameters thus:

    HISTFILE=~/.history
    HISTSIZE=10000
    SAVEHIST=50000

> SAVEHIST was created for a reason, and my script demonstrated that
> reason.

I don't think your script does that.

>  If it was true that SAVEHIST should *always* be the same and
> HISTSIZE

Does anyone claim that?

> This is not something new users should be burdened with, they don't
> need to know what SAVEHIST means, just that it should be set to
> $HISTSIZE.

Can you clarify what you mean here? Are you saying that there are no
use cases for setting SAVEHIST and HISTSIZE to different (unequal)
values? Or perhaps that the vast majority of users would be best
served by setting these parameters to the same value? I think both of
these statements are false.

Roman.

[1] https://www.reddit.com/r/zsh/comments/wy0sm6/what_is_your_history_configuration/


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-03 19:27                                           ` Roman Perepelitsa
@ 2022-09-03 20:08                                             ` Felipe Contreras
  2022-09-03 20:23                                               ` Roman Perepelitsa
  0 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-09-03 20:08 UTC (permalink / raw)
  To: Roman Perepelitsa
  Cc: Mikael Magnusson, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Sat, Sep 3, 2022 at 2:27 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> On Sat, Sep 3, 2022 at 9:07 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > On Sat, Sep 3, 2022 at 8:39 AM Roman Perepelitsa
> > <roman.perepelitsa@gmail.com> wrote:
> > > On Fri, Sep 2, 2022 at 5:46 AM Mikael Magnusson <mikachu@gmail.com> wrote:

> > > > SAVEHIST greater than HISTSIZE is always equivalent to
> > > > its being equal to HISTSIZE [...]
> > >
> > > I believe this is the case as far as using history from within zsh is
> > > concerned. If I understand correctly, Felipe wants to have fewer
> > > commands available in history when using zsh than what is stored in
> > > HISTFILE. I'm not sure under which circumstances this can be desired.
> > > Perhaps when working on a system with very little RAM, plenty of disk
> > > space and no swap? In any case, I wouldn't recommend using such a
> > > configuration to beginners because it's bound to cause confusion. It
> > > can be surprising when some lines from HISTFILE aren't available when
> > > searching or printing history from within zsh.
> >
> > No, this is not what I want.
>
> My apologies. I thought this was what you wanted based on [1] where
> you mentioned that you set history parameters thus:

My configuration at any particular point in time is not relevant to
the discussion of defaults.

And you omitted the very next sentence I said:

I don't have any particularly good reason for the numbers, I just want
my history saved.

If you really want to know 2 of those 3 values are different now, and
they will probably be different tomorrow. Again, this is irrelevant.

> > This is not something new users should be burdened with, they don't
> > need to know what SAVEHIST means, just that it should be set to
> > $HISTSIZE.
>
> Can you clarify what you mean here? Are you saying that there are no
> use cases for setting SAVEHIST and HISTSIZE to different (unequal)
> values?

Of course I'm not saying that. Absolutely nobody is suggesting to
remove SAVEHIST, so this is a smoke screen.

We are talking about the *defaults*, and what makes sense for new users.

> Or perhaps that the vast majority of users would be best
> served by setting these parameters to the same value?

Not the vast majority, the majority.

And the current documentation already presupposes that.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-03 20:08                                             ` Felipe Contreras
@ 2022-09-03 20:23                                               ` Roman Perepelitsa
  2022-09-03 20:49                                                 ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Roman Perepelitsa @ 2022-09-03 20:23 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Mikael Magnusson, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Sat, Sep 3, 2022 at 10:08 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Sat, Sep 3, 2022 at 2:27 PM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > Can you clarify what you mean here? Are you saying that there are no
> > use cases for setting SAVEHIST and HISTSIZE to different (unequal)
> > values?
>
> Of course I'm not saying that. Absolutely nobody is suggesting to
> remove SAVEHIST, so this is a smoke screen.

It may appear to you that it's clear what point you are trying to
make. I can assure you this is not the case. To *me* it appears as if
your point changes not only from one post to the next but even between
a single post. So I hope you can forgive me for trying to put my
understanding of your point in writing in the hope that we can both
agree on what exactly we are arguing about.

> We are talking about the *defaults*, and what makes sense for new users.

OK.

> > Or perhaps that the vast majority of users would be best
> > served by setting these parameters to the same value?
>
> Not the vast majority, the majority.
> And the current documentation already presupposes that.

Is your point that the current recommendation in the documentation is
good? Or that it's bad? If the latter, what is in your opinion a
better recommendation and why?

Roman.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-03 20:23                                               ` Roman Perepelitsa
@ 2022-09-03 20:49                                                 ` Felipe Contreras
  2022-09-03 23:12                                                   ` Roman Perepelitsa
  0 siblings, 1 reply; 93+ messages in thread
From: Felipe Contreras @ 2022-09-03 20:49 UTC (permalink / raw)
  To: Roman Perepelitsa
  Cc: Mikael Magnusson, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Sat, Sep 3, 2022 at 3:23 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> On Sat, Sep 3, 2022 at 10:08 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > On Sat, Sep 3, 2022 at 2:27 PM Roman Perepelitsa
> > <roman.perepelitsa@gmail.com> wrote:

> > > Or perhaps that the vast majority of users would be best
> > > served by setting these parameters to the same value?
> >
> > Not the vast majority, the majority.
> > And the current documentation already presupposes that.
>
> Is your point that the current recommendation in the documentation is
> good?

No.

> Or that it's bad?

No.

But it can be better.

> If the latter, what is in your opinion a better recommendation and why?

For starters this patch:

https://www.zsh.org/mla/workers/2022/msg00875.html

The patch speaks for itself.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-03 20:49                                                 ` Felipe Contreras
@ 2022-09-03 23:12                                                   ` Roman Perepelitsa
  2022-09-03 18:59                                                     ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Roman Perepelitsa @ 2022-09-03 23:12 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Mikael Magnusson, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Sat, Sep 3, 2022 at 10:49 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> For starters this patch:
>
> https://www.zsh.org/mla/workers/2022/msg00875.html

If I understand correctly, you propose to change this snipped in the guide:

    HISTSIZE=200
    SAVEHIST=200

With this:

    HISTSIZE=200
    SAVEHIST=$HISTSIZE

To me the original snippet looks better because it makes it clear that
the two parameters are independent. The proposed snippet is more
complex due to an additional indirection and a misleading suggestion
that the two parameters must (or should) be set to the same value.

Roman.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [RFC PATCH 3/3] FAQ: sync newuser-install
  2022-09-03 18:59                                                     ` Felipe Contreras
@ 2022-09-04  0:08                                                       ` Roman Perepelitsa
  2022-09-03 19:24                                                         ` Felipe Contreras
  0 siblings, 1 reply; 93+ messages in thread
From: Roman Perepelitsa @ 2022-09-04  0:08 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Mikael Magnusson, Lawrence Velázquez, Bart Schaefer, zsh-workers

On Sun, Sep 4, 2022 at 2:00 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Sat, Sep 3, 2022 at 6:13 PM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> > On Sat, Sep 3, 2022 at 10:49 PM Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
>
> > > For starters this patch:
> > >
> > > https://www.zsh.org/mla/workers/2022/msg00875.html
> >
> > If I understand correctly, you propose to change this snipped in the guide:
>
> It's not a guide, it's a FAQ

Mea culpa.

> [...] the entry in the FAQ is "Why is my history not being saved?"

Do you believe that your change makes the answer better? If so, why?

I do not think it makes it better.

> >     HISTSIZE=200
> >     SAVEHIST=200
> >
> > With this:
> >
> >     HISTSIZE=200
> >     SAVEHIST=$HISTSIZE
> >
> > To me the original snippet looks better because it makes it clear that
> > the two parameters are independent.
>
> The user does not *need* to know that at this point, all he/she needs
> is an example that turns history save on. That's it.

Do you believe that from this it follows that your change is making
things better? Why?

I do not think that it follows.

Roman.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-02 16:48                                               ` Bart Schaefer
@ 2022-09-04  9:35                                                 ` Daniel Shahaf
  0 siblings, 0 replies; 93+ messages in thread
From: Daniel Shahaf @ 2022-09-04  9:35 UTC (permalink / raw)
  To: zsh-workers

Bart Schaefer wrote on Fri, Sep 02, 2022 at 09:48:31 -0700:
> On Fri, Sep 2, 2022 at 1:56 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > If the default were /either/ vi or emacs, a patch making the default
> > depend on the value of $EDITOR would never have been accepted.
> 
> Hm.  Given that this has been the behavior since before zsh was even
> released to the public, I'm not sure how to interpret that.

I'm saying that /if/ we were in an alternative universe in which zsh's
behaviour was "default to emacs regardless of envvars", and in that
universe someone proposed a patch to change the behaviour to this
universe's behaviour, that universe's maintainers would have rejected
the patch.

That's meant as an argument in favour of changing the behaviour: if we
could have chosen between the incumbent behaviour and the proposed
behaviour /a priori/, we would have preferred the proposed to the
incumbent.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-02 13:42                                                 ` Felipe Contreras
@ 2022-09-04  9:39                                                   ` Daniel Shahaf
  2022-09-05  8:55                                                     ` Vincent Lefevre
  0 siblings, 1 reply; 93+ messages in thread
From: Daniel Shahaf @ 2022-09-04  9:39 UTC (permalink / raw)
  To: zsh-workers

Felipe Contreras wrote on Fri, Sep 02, 2022 at 08:42:11 -0500:
> Moreover, there's also the possibility that it's not the user the one
> who set EDITOR, but the distribution or the system administrator, and
> again, the user doesn't know about this variable.

I don't think that's a strong argument.  The distribution or sysadmin
might append a «bindkey» to /etc/zshrc just like they might append an
«export EDITOR=…» to /etc/zprofile.

Or are you saying that they're more likely to change the value of EDITOR
than to change the default keymap?


^ permalink raw reply	[flat|nested] 93+ messages in thread

* ${EDITOR} with spaces (was: Re: [PATCH] initialization of main keymap)
  2022-09-02 13:15                                               ` Vincent Lefevre
@ 2022-09-04  9:42                                                 ` Daniel Shahaf
  2022-09-04 10:48                                                   ` Mikael Magnusson
  0 siblings, 1 reply; 93+ messages in thread
From: Daniel Shahaf @ 2022-09-04  9:42 UTC (permalink / raw)
  To: zsh-workers

Vincent Lefevre wrote on Fri, Sep 02, 2022 at 15:15:33 +0200:
> On 2022-09-01 22:06:03 -0700, Bart Schaefer wrote:
> > Upon further thought ...
> > 1) It's a bit odd that if both VISUAL and EDITOR are set, and VISUAL
> > is not set to a variant of vi, but EDITOR is, then zsh prefers to use
> > the bindings corresponding to EDITOR.
> > 2) As written the patch will always give Vincent the emacs bindings
> > because strstr() starts at the beginning and finds "vinc17" before
> > ever looking beyond the rindex().
> > 
> > Perhaps we should prefer VISUAL any time it is set?
> 
> Yes, the current behavior (with or without the patch) is definitely
> incorrect. For instance, https://unix.stackexchange.com/a/4861/74516
> suggests to set VISUAL to the full-screen editor, and either leave
> EDITOR unset or set it to "vi -e" (just in case a special line mode
> would be needed in some context). So a user who would use VISUAL=emacs
> and EDITOR="vi -e" would probably be annoyed by the current behavior.

Is $EDITOR meant to be used in a system(3) manner, as «system("${EDITOR} ${(q-)filename}")»,
or in an execve(2) manner, as «execl($EDITOR, $EDITOR, $filename)»?
(plus or minus a «--» guard in both cases)

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: ${EDITOR} with spaces (was: Re: [PATCH] initialization of main keymap)
  2022-09-04  9:42                                                 ` ${EDITOR} with spaces (was: Re: [PATCH] initialization of main keymap) Daniel Shahaf
@ 2022-09-04 10:48                                                   ` Mikael Magnusson
  2022-09-05  9:15                                                     ` Vincent Lefevre
  0 siblings, 1 reply; 93+ messages in thread
From: Mikael Magnusson @ 2022-09-04 10:48 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On 9/4/22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Vincent Lefevre wrote on Fri, Sep 02, 2022 at 15:15:33 +0200:
>> On 2022-09-01 22:06:03 -0700, Bart Schaefer wrote:
>> > Upon further thought ...
>> > 1) It's a bit odd that if both VISUAL and EDITOR are set, and VISUAL
>> > is not set to a variant of vi, but EDITOR is, then zsh prefers to use
>> > the bindings corresponding to EDITOR.
>> > 2) As written the patch will always give Vincent the emacs bindings
>> > because strstr() starts at the beginning and finds "vinc17" before
>> > ever looking beyond the rindex().
>> >
>> > Perhaps we should prefer VISUAL any time it is set?
>>
>> Yes, the current behavior (with or without the patch) is definitely
>> incorrect. For instance, https://unix.stackexchange.com/a/4861/74516
>> suggests to set VISUAL to the full-screen editor, and either leave
>> EDITOR unset or set it to "vi -e" (just in case a special line mode
>> would be needed in some context). So a user who would use VISUAL=emacs
>> and EDITOR="vi -e" would probably be annoyed by the current behavior.
>
> Is $EDITOR meant to be used in a system(3) manner, as «system("${EDITOR}
> ${(q-)filename}")»,
> or in an execve(2) manner, as «execl($EDITOR, $EDITOR, $filename)»?
> (plus or minus a «--» guard in both cases)

In practice, if you want $EDITOR to contain options to your editor,
you have to make a wrapper script and put it in a path without spaces,
because programs all assume different answers to your question.

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] initialization of main keymap
  2022-09-04  9:39                                                   ` Daniel Shahaf
@ 2022-09-05  8:55                                                     ` Vincent Lefevre
  0 siblings, 0 replies; 93+ messages in thread
From: Vincent Lefevre @ 2022-09-05  8:55 UTC (permalink / raw)
  To: zsh-workers

On 2022-09-04 09:39:06 +0000, Daniel Shahaf wrote:
> Felipe Contreras wrote on Fri, Sep 02, 2022 at 08:42:11 -0500:
> > Moreover, there's also the possibility that it's not the user the one
> > who set EDITOR, but the distribution or the system administrator, and
> > again, the user doesn't know about this variable.
> 
> I don't think that's a strong argument.  The distribution or sysadmin
> might append a «bindkey» to /etc/zshrc just like they might append an
> «export EDITOR=…» to /etc/zprofile.
> 
> Or are you saying that they're more likely to change the value of EDITOR
> than to change the default keymap?

I would say that they are. First, the zsh bindings are specific
to zsh, while EDITOR (or VISUAL) is global to the system (used
by various utilities) and standardized, thus more visible and
more likely to be changed by the system administrator. Moreover,
the zsh bindings are not linked to the system, while the choice
of $EDITOR may reflect what the system administrator installed
on the system. For instance, he may have installed a better
editor or one with a more recent version in some non-standard
place, which the end user may not know, so that the system
administrator may be tempted to change EDITOR to use this editor
as being a better default.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: ${EDITOR} with spaces (was: Re: [PATCH] initialization of main keymap)
  2022-09-04 10:48                                                   ` Mikael Magnusson
@ 2022-09-05  9:15                                                     ` Vincent Lefevre
  2022-09-05 21:17                                                       ` Lawrence Velázquez
  0 siblings, 1 reply; 93+ messages in thread
From: Vincent Lefevre @ 2022-09-05  9:15 UTC (permalink / raw)
  To: zsh-workers

On 2022-09-04 12:48:20 +0200, Mikael Magnusson wrote:
> On 9/4/22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > Vincent Lefevre wrote on Fri, Sep 02, 2022 at 15:15:33 +0200:
> >> Yes, the current behavior (with or without the patch) is definitely
> >> incorrect. For instance, https://unix.stackexchange.com/a/4861/74516
> >> suggests to set VISUAL to the full-screen editor, and either leave
> >> EDITOR unset or set it to "vi -e" (just in case a special line mode
> >> would be needed in some context). So a user who would use VISUAL=emacs
> >> and EDITOR="vi -e" would probably be annoyed by the current behavior.
> >
> > Is $EDITOR meant to be used in a system(3) manner, as «system("${EDITOR}
> > ${(q-)filename}")»,
> > or in an execve(2) manner, as «execl($EDITOR, $EDITOR, $filename)»?
> > (plus or minus a «--» guard in both cases)
> 
> In practice, if you want $EDITOR to contain options to your editor,
> you have to make a wrapper script and put it in a path without spaces,
> because programs all assume different answers to your question.

Indeed, for EDITOR, under "mailx", POSIX says "name of a utility"
and not "command". This is a bit unclear about the possibility of
full pathnames, but under "more", POSIX says "If the last pathname
component in EDITOR is either vi or ex, [...]" so it is now clear
that EDITOR may contain a full pathname (there wasn't any practical
reason for a restriction).

For VISUAL, POSIX says "pathname of a utility".

So, in both cases, options should not be accepted, i.e. spaces
should be regarded as part of the name (though I wonder whether
this is portable in practice).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: ${EDITOR} with spaces (was: Re: [PATCH] initialization of main keymap)
  2022-09-05  9:15                                                     ` Vincent Lefevre
@ 2022-09-05 21:17                                                       ` Lawrence Velázquez
  0 siblings, 0 replies; 93+ messages in thread
From: Lawrence Velázquez @ 2022-09-05 21:17 UTC (permalink / raw)
  To: Vincent Lefevre; +Cc: zsh-workers

On Mon, Sep 5, 2022, at 5:15 AM, Vincent Lefevre wrote:
> Indeed, for EDITOR, under "mailx", POSIX says "name of a utility"
> and not "command". This is a bit unclear about the possibility of
> full pathnames, but under "more", POSIX says "If the last pathname
> component in EDITOR is either vi or ex, [...]" so it is now clear
> that EDITOR may contain a full pathname (there wasn't any practical
> reason for a restriction).
>
> For VISUAL, POSIX says "pathname of a utility".
>
> So, in both cases, options should not be accepted, i.e. spaces
> should be regarded as part of the name (though I wonder whether
> this is portable in practice).

It isn't.  As far as I'm aware, POSIX only addresses EDITOR and
VISUAL as used by a handful of specific utilities (mailx, more, and
so on).  Even you assume that these discrete descriptions imply a
global specification, nonstandardized tools can do whatever they
please.  For instance, Git shell-evaluates the contents of EDITOR
and VISUAL.

https://git-scm.com/docs/git-var#Documentation/git-var.txt-GITEDITOR

-- 
vq


^ permalink raw reply	[flat|nested] 93+ messages in thread

end of thread, other threads:[~2022-09-05 21:23 UTC | newest]

Thread overview: 93+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-24  4:31 [RFC PATCH 0/3] Improve defaults Felipe Contreras
2022-08-24  4:31 ` [RFC PATCH 1/3] Make SAVEHIST default to HISTSIZE Felipe Contreras
2022-08-24  4:31 ` [RFC PATCH 2/3] Increase default HISTSIZE to 1000 Felipe Contreras
2022-08-24  4:31 ` [RFC PATCH 3/3] FAQ: sync newuser-install Felipe Contreras
2022-08-24  9:06   ` Daniel Shahaf
2022-08-24 17:32     ` Felipe Contreras
2022-08-24 18:28       ` Eric Cook
2022-08-24 19:11         ` Felipe Contreras
2022-08-24 19:24           ` Matthew Martin
2022-08-24 19:25           ` Eric Cook
2022-08-24 19:40             ` Eric Cook
2022-08-24 20:03             ` Felipe Contreras
2022-08-24 20:11               ` Eric Cook
2022-08-24 20:27                 ` Felipe Contreras
2022-08-24 20:53                   ` Eric Cook
2022-08-25  8:04       ` Daniel Shahaf
2022-08-25 22:22         ` Bart Schaefer
2022-08-25 22:44           ` Felipe Contreras
2022-08-25 23:08             ` Bart Schaefer
2022-08-26  4:22               ` Felipe Contreras
2022-08-31 11:43                 ` Vincent Lefevre
2022-08-26  5:20               ` Daniel Shahaf
2022-08-26 13:57                 ` Mikael Magnusson
2022-08-26 14:04                   ` Roman Perepelitsa
2022-08-26 23:43                     ` Lawrence Velázquez
2022-08-27 15:17                       ` Daniel Shahaf
2022-08-27 15:34                         ` Roman Perepelitsa
2022-08-26 18:44                   ` Felipe Contreras
2022-08-27  0:23                     ` Mikael Magnusson
2022-08-27  0:31                       ` Bart Schaefer
2022-08-27  3:18                         ` Felipe Contreras
2022-08-27  3:52                           ` Lawrence Velázquez
2022-08-27 15:44                             ` Daniel Shahaf
2022-08-30 19:31                             ` Felipe Contreras
2022-08-31 12:28                               ` Vincent Lefevre
2022-08-31 19:36                                 ` Bart Schaefer
2022-09-01  0:23                                   ` Vincent Lefevre
2022-09-01  0:35                                     ` Bart Schaefer
2022-09-01  1:21                                       ` Vincent Lefevre
2022-09-01  2:42                                         ` [PATCH] initialization of main keymap Bart Schaefer
2022-09-01 21:58                                           ` Felipe Contreras
2022-09-01 22:34                                             ` Bart Schaefer
2022-09-01 22:54                                               ` Felipe Contreras
2022-09-02  8:51                                             ` Daniel Shahaf
2022-09-02 13:23                                               ` Vincent Lefevre
2022-09-02 13:42                                                 ` Felipe Contreras
2022-09-04  9:39                                                   ` Daniel Shahaf
2022-09-05  8:55                                                     ` Vincent Lefevre
2022-09-02 13:32                                               ` Felipe Contreras
2022-09-02 16:48                                               ` Bart Schaefer
2022-09-04  9:35                                                 ` Daniel Shahaf
2022-09-02  0:04                                           ` Vincent Lefevre
2022-09-02  5:06                                             ` Bart Schaefer
2022-09-02 13:15                                               ` Vincent Lefevre
2022-09-04  9:42                                                 ` ${EDITOR} with spaces (was: Re: [PATCH] initialization of main keymap) Daniel Shahaf
2022-09-04 10:48                                                   ` Mikael Magnusson
2022-09-05  9:15                                                     ` Vincent Lefevre
2022-09-05 21:17                                                       ` Lawrence Velázquez
2022-09-02  9:20                                 ` [RFC PATCH 3/3] FAQ: sync newuser-install Daniel Shahaf
2022-09-02 13:50                                   ` Vincent Lefevre
2022-08-31 21:57                               ` Mikael Magnusson
2022-08-31 22:28                                 ` Roman Perepelitsa
2022-09-01  0:29                                   ` Bart Schaefer
2022-09-01 22:45                                   ` Felipe Contreras
2022-09-02  3:46                                     ` Mikael Magnusson
2022-09-02  5:57                                       ` Felipe Contreras
2022-09-02 23:14                                         ` Mikael Magnusson
2022-09-02 23:56                                           ` Felipe Contreras
2022-09-02  9:18                                       ` Daniel Shahaf
2022-09-02 12:50                                         ` Vincent Lefevre
2022-09-02 13:28                                           ` Felipe Contreras
2022-09-02 13:47                                             ` Vincent Lefevre
2022-09-02 13:54                                               ` Felipe Contreras
2022-09-03 13:38                                       ` Roman Perepelitsa
2022-09-03 19:07                                         ` Felipe Contreras
2022-09-03 19:27                                           ` Roman Perepelitsa
2022-09-03 20:08                                             ` Felipe Contreras
2022-09-03 20:23                                               ` Roman Perepelitsa
2022-09-03 20:49                                                 ` Felipe Contreras
2022-09-03 23:12                                                   ` Roman Perepelitsa
2022-09-03 18:59                                                     ` Felipe Contreras
2022-09-04  0:08                                                       ` Roman Perepelitsa
2022-09-03 19:24                                                         ` Felipe Contreras
2022-08-27  0:35                       ` Felipe Contreras
2022-08-27  2:24                 ` Bart Schaefer
2022-08-27 15:40                   ` Daniel Shahaf
2022-08-27 15:55                     ` Bart Schaefer
2022-08-27 17:53                       ` Daniel Shahaf
2022-08-24 20:58 ` [RFC PATCH 0/3] Improve defaults Bart Schaefer
2022-08-24 21:50   ` Felipe Contreras
2022-08-24 22:18     ` Bart Schaefer
2022-08-24 22:54       ` Felipe Contreras
2022-08-24 21:39 ` Mikael Magnusson

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).