vi mode reset

vi mode reset

[Christian Brabandt]

Hi,
I have recently upgraded from Debian stable to Debian stretch (well, it 
is a couple of months ago and I have lived with the problem for so 
long):

,----
| term.log.3.gz:Unpacking zsh (5.2-5) over (5.0.7-5)
`----

I run zsh in vi mode (using set -o vi)

However, since the upgrade I noticed that my zsh resets vi mode, on 
various occasions, but I cannot reproduce exactly when exactly this 
happens. I think this usually happens either if I am pasting something 
into the terminal (using putty from Windows and pasting using 
<shift><insert> keys) or running Vim.

What could be the cause for it and even more importantly, how can I make 
sure, this does not happen anymore? This is driving me crazy...

Best,
Christian
-- 
Sechs Stunden sind genug für die Arbeit. Die anderen Stunden sagen zum
Menschen: Lebe!
		-- Lukian (120-180 n.Chr.)

Re: vi mode reset

[Ray Andrews]

On 12/09/2016 04:29 AM, Christian Brabandt wrote:
> What could be the cause for it and even more importantly, how can I make
> sure, this does not happen anymore? This is driving me crazy...
>
> Best,
> Christian
This won't help, but to commiserate, I had to abort my last Debian 
upgrade because, among other things, the HOME and END keys stopped 
working and I didn't have the cojones to bother figuring out why.

Re: vi mode reset

[Peter Stephenson]

On Fri, 9 Dec 2016 13:29:58 +0100
Christian Brabandt <cb@256bit.org> wrote:
> However, since the upgrade I noticed that my zsh resets vi mode, on 
> various occasions, but I cannot reproduce exactly when exactly this 
> happens.

Maybe this is already obvious to vi experts, but for the rest of us,
what does "zsh resets vi mode" mean?  Do you mean it goes back from
insert to command mode, or vice versa, or that the keymap goes to Emacs
mode, or some set of bindings is removed, or a certain ZLE function gets
executed, or the display changes in some way, or ... ?

pws

Re: vi mode reset

[Oliver Kiddle]

Christian Brabandt wrote:
> However, since the upgrade I noticed that my zsh resets vi mode, on 
> various occasions, but I cannot reproduce exactly when exactly this 

What exactly do you mean by "resets vi mode". Switches to command/normal
mode without your having pressed escape, perhaps? Many key combinations
send a sequence of characters starting with an escape so zsh may be
mis-interpreting that.

> happens. I think this usually happens either if I am pasting something 
> into the terminal (using putty from Windows and pasting using 
> <shift><insert> keys) or running Vim.

Sounds like possibly an effect of the bracketed paste feature. You can
disable that with: unset zle_bracketed_paste

It'd be better to understand how it is coming to fail for you. Perhaps
your terminal has a different bracketed paste mode. Or perhaps you've
removed the key binding for it. Do you perhaps clear a range of key
bindings in your .zshrc? What does this show?:
  bindkey -L |grep 200 

What do you see if you press Ctrl-V before pasting text?

Do you perhaps have some other safe-paste or bracketed-paste plugin from
elsewhere. Are you using something like oh-my-zsh or prezto?

Oliver

off topic

[Ray Andrews]

On 12/09/2016 06:44 AM, Oliver Kiddle wrote:
> Do you perhaps have some other safe-paste or bracketed-paste plugin 
> from elsewhere. Are you using something like oh-my-zsh or prezto? Oliver 

Ignore this as appropriate gentlemen, but for anyone who feels like 
answering, what is the culture vis. oh-my-zsh?  I get a vague feeling 
that the members of this list view is as something strange and alien or 
even heretical.  It seems to be something 'else' -- oh-my-zsh users 
never come here and we never go there.  As for me, when I was first 
getting involved I tried it and, notwithstanding that I had no idea what 
I was doing, I found it to be a candy store sort of thing and preferred 
the honest brutality of trying to get plain vanilla zsh working.  Thoughts?

Re: vi mode reset

[Christian Brabandt]

Hi Oliver!

On Fr, 09 Dez 2016, Oliver Kiddle wrote:

> Christian Brabandt wrote:
> > However, since the upgrade I noticed that my zsh resets vi mode, on 
> > various occasions, but I cannot reproduce exactly when exactly this 
> 
> What exactly do you mean by "resets vi mode". Switches to command/normal
> mode without your having pressed escape, perhaps? Many key combinations
> send a sequence of characters starting with an escape so zsh may be
> mis-interpreting that.

It is reset to emacs mode I believe. I have to hit set -o vi again.

> > happens. I think this usually happens either if I am pasting something 
> > into the terminal (using putty from Windows and pasting using 
> > <shift><insert> keys) or running Vim.
> 
> Sounds like possibly an effect of the bracketed paste feature. You can
> disable that with: unset zle_bracketed_paste

I'll try that, thanks. However I always thought, bracket paste mode is 
useful...

> It'd be better to understand how it is coming to fail for you. Perhaps
> your terminal has a different bracketed paste mode. Or perhaps you've
> removed the key binding for it. Do you perhaps clear a range of key
> bindings in your .zshrc? What does this show?:
>   bindkey -L |grep 200 
> 
> What do you see if you press Ctrl-V before pasting text?
> 
> Do you perhaps have some other safe-paste or bracketed-paste plugin from
> elsewhere. Are you using something like oh-my-zsh or prezto?

I don't use any distribution.

Here is an example:
0 59928 chrisbra@debian ~ % bindkey -L |grep 200
bindkey "^X^[[200~" _start_quoted_paste
bindkey "^[[200~" _start_paste

# Here I pasted the string zsh using Ctrl-V:
0 59929 chrisbra@debian ~ % ^[[200~zshG

# Here I pasted the usual way hitting <shift><insert>, then pressing 
# <esc> stops working:
1 59929 chrisbra@debian ~ % wget -c 'https://github.com/vim/vim/issues/1204'
--2016-12-09 14:14:10--  https://github.com/vim/vim/issues/1204
Resolving github.com (github.com)... 192.30.253.113, 192.30.253.112
[...]
2016-12-09 14:14:12 (284 KB/s) - ‘1204’ saved [76470]

# Now hitting esc won't go back into command mode.
2 59933 chrisbra@debian ~ % set -o |grep "^vi"
vi                    on
# Looks like it is still on. Hm, that is strange. However when I press 
# <esc> it won't go back into normal mode but keeps entering keys. 
# Entering set -o vi fixes that.

Best,
Christian
-- 
Linux wird nie das meistinstallierte Betriebssystem sein.
Bedenken Sie nur, wie oft man Windows neu installieren muß.

Re: off topic

[Oliver Kiddle]

Ray Andrews wrote:
> Ignore this as appropriate gentlemen, but for anyone who feels like 
> answering, what is the culture vis. oh-my-zsh?  I get a vague feeling 
> that the members of this list view is as something strange and alien or 
> even heretical.  It seems to be something 'else' -- oh-my-zsh users 

It hasn't really been discussed so I can only give my own perspective.

They've done a great job of promoting zsh and making some of the nicer
features available to people who don't want to work out how to configure
them. Those are perhaps areas where we've been weak.

If someone posts here with a problem, it can make it a lot harder to
determine the cause. It means they have a complex setup which they don't
understand themself and some combination of plugins could be interacting
in odd ways. So to some extent it is something 'else' but that something
else is still a layer on top of zsh so not removed from us.

> never come here and we never go there.  As for me, when I was first 
> getting involved I tried it and, notwithstanding that I had no idea what 
> I was doing, I found it to be a candy store sort of thing and preferred 
> the honest brutality of trying to get plain vanilla zsh working.  Thoughts?

Run zsh -f without reading any documentation (just some bash/tcsh
experience) and there's little apart from perhaps alwayslastprompt that
will stand out as different and clearly better than bash. oh-my-zsh just
adding compinit, vcs_info, syntax highlighting and the small collection
of styles for descriptions and grouping in completion listings makes a
big difference to people's impressions.

If I look beyond that and the zillions of prompt themes, it surprises me
how little there is there that looks interesting. Many of the plugins
are just aliases which are no good to you if you don't actually learn
them. Or if you don't use the software they cover - e.g. they seem to
have a lot of stuff for ruby on rails developers.

There's clear advantages to having a powerful setup that you understand
well. If that process now involves "brutality" then you can understand
why people might be be happy to just take what they get with oh-my-zsh:
and I don't view that as heresy.

Oliver

Re: vi mode reset

[Oliver Kiddle]

Christian Brabandt wrote:
> It is reset to emacs mode I believe. I have to hit set -o vi again.

> > disable that with: unset zle_bracketed_paste
> I'll try that, thanks. However I always thought, bracket paste mode is 
> useful...

It is useful.

> I don't use any distribution.
>
> Here is an example:
> 0 59928 chrisbra@debian ~ % bindkey -L |grep 200
> bindkey "^X^[[200~" _start_quoted_paste
> bindkey "^[[200~" _start_paste

Maybe not from a distribution but those are custom functions, however.
Somewhere or other, you've got some configuration that is defining
those functions and binding the keys. Given that you started having
problems when upgrading zsh, you probably didn't have the necessary
configuration to turn your terminal's bracketed paste mode on and off.
The newer zsh is turning it on for you because it has an internal widget
for bracketed paste.

I would guess that _start_paste switches you to a custom keymap where
the end of bracketed paste is setup to switch you "back" to the emacs
keymap.

You want to get rid of all that: the _start_quoted_paste and
_start_paste functions and any additional keymap.
Then you should see:
  % bindkey -L |grep 200
  bindkey "^[[200~" bracketed-paste
To check for odd keymaps, run bindkey -l

Oliver

Re: off topic

[Ray Andrews]

On 12/09/2016 08:28 AM, Oliver Kiddle wrote:

Thanks Oliver:
> There's clear advantages to having a powerful setup that you 
> understand well. If that process now involves "brutality" then you can 
> understand why people might be be happy to just take what they get 
> with oh-my-zsh: and I don't view that as heresy. Oliver 

I know I've ranted about this before, but I sure wish there was 
something in between.  That is, that the standard install would not be 
so raw out of the box.  As you say, bash is worse but both are brutal.  
Coming as I did from 4DOS to linux and facing my first bash prompt 
without current directory showing or even command recall, it was so 
horrible that I ran back to the power and elegance of 4DOS and this put 
off my migration to linux for several years.  I suppose I was the very 
last person to  leave DOS and there's now really no reason to spend 
effort making the newbie experience a little less Spartan, but man! if 
zsh only came out of the box with just some basic stuff that almost 
everyone will want, that sure would have been appreciated at the time.  
It would give folks less of a reason to go to oh-my-zsh just to get 
something happening which might make the community a bit more cohesive.

Re: off topic

[Daniel Shahaf]

Ray Andrews wrote on Fri, Dec 09, 2016 at 09:45:35 -0800:
> if zsh only came out of the box with just some basic stuff that almost
> everyone will want, that sure would have been appreciated at the time.

Actually, I think that already exists, in a way:

    % env -i ZDOTDIR=$(mktemp -d) zsh
    This is the Z Shell configuration function for new users,
    zsh-newuser-install.
    ⋮
    (2)  Populate your /tmp/tmp.Z4bUNG8Gz5/.zshrc with the configuration recommended
         by the system administrator and exit (you will need to edit
         the file by hand, if so desired).
    
    --- Type one of the keys in parentheses --- 

Typing "2" creates a .zshrc with reasonable default settings, and drops
the user to the prompt; no further menu choices.  The catch is that that
check is hardcoded to inspect /etc/zsh/newuser.zshrc.recommended; that
is, it ignores configure's --prefix.

So if we could make that check honour @PREFIX@, and ship a "recommended
zshrc" that is less minimal than the default no-zshrc behaviour...
I think that'd be a good step forward.

Re: vi mode reset

[Christian Brabandt]

Hi Oliver!

On Fr, 09 Dez 2016, Oliver Kiddle wrote:

> You want to get rid of all that: the _start_quoted_paste and
> _start_paste functions and any additional keymap.
> Then you should see:
>   % bindkey -L |grep 200
>   bindkey "^[[200~" bracketed-paste
> To check for odd keymaps, run bindkey -l

That helped. I feel embarrassed now ;)

I have disabled those maps now. I think I got them from here sometimes. 
I disabled those now in my .zshrc and use the default bracked-paste keys 
now (as shown in your example). Will see how good this works.

Thanks.

Best,
Christian

Re: off topic

[Ray Andrews]

On 12/09/2016 11:24 AM, Daniel Shahaf wrote:
> Actually, I think that already exists, in a way: 

Nuts, I've forgotten most of my own experience, but I do  remember that 
somewhat -- IIRC it was a sort of 'close but no cigar' sort of thing -- 
you had to know what you were doing to use it, and of course the whole 
idea is that at that point the newbie has no idea. Seems to me that what 
I wanted was a sort of simple '1, 2, 3' set of choices for 'minimal 
setup (masochistic)', 'normal setup (sane)', and 'lots of bells and 
whistles setup (rococo)' with a friendly reminder that one can always 
rerun 'xxx' to change to something else if one wants to experiment.  I 
remember being terrified of the installer, now that I recall.

Re: off topic

[Daniel Shahaf]

Ray Andrews wrote on Fri, Dec 09, 2016 at 12:25:09 -0800:
> On 12/09/2016 11:24 AM, Daniel Shahaf wrote:
> >Actually, I think that already exists, in a way:
> 
> Nuts, I've forgotten most of my own experience, but I do  remember that
> somewhat -- IIRC it was a sort of 'close but no cigar' sort of thing -- you
> had to know what you were doing to use it, and of course the whole idea is
> that at that point the newbie has no idea. Seems to me that what I wanted
> was a sort of simple '1, 2, 3' set of choices for 'minimal setup
> (masochistic)', 'normal setup (sane)', and 'lots of bells and whistles setup
> (rococo)' with a friendly reminder that one can always rerun 'xxx' to change
> to something else if one wants to experiment.  I remember being terrified of
> the installer, now that I recall.

You may have missed my point.  That option which I quoted is offered by
the very first zsh-newuser-install prompt (NOT by a submenu), and is NOT
offered by any further prompts, either.  Therefore the user experience,
if choosing this option, is very different to the "browse through
submenus" experience that zsh-newuser-install also offers.

Cheers,

Daniel

Re: off topic

[Ray Andrews]

On 12/09/2016 04:14 PM, Daniel Shahaf wrote:
> You may have missed my point. That option which I quoted is offered by 
> the very first zsh-newuser-install prompt (NOT by a submenu), and is 
> NOT offered by any further prompts, either. Therefore the user 
> experience, if choosing this option, is very different to the "browse 
> through submenus" experience that zsh-newuser-install also offers. 
> Cheers, Daniel 

I honestly can't remember.  All I can say is that at the time whatever 
was there was not intuitive, but of course that's rather subjective.  
I'll run it again with Peter's latest.

Re: off topic

[Bart Schaefer]

On Dec 9,  9:45am, Ray Andrews wrote:
} Subject: Re: off topic
}
} On 12/09/2016 08:28 AM, Oliver Kiddle wrote:
} 
} Thanks Oliver:
} > There's clear advantages to having a powerful setup that you 
} > understand well. If that process now involves "brutality" then you can 
} > understand why people might be be happy to just take what they get 
} > with oh-my-zsh: and I don't view that as heresy. Oliver 
} 
} I know I've ranted about this before, but I sure wish there was 
} something in between.

I've had the below kicking around for a while, was planning to post it
after 5.3 was out but might as well offer it for comments.  This is
mostly specific to completion; it collects what I think are a set of
sensible default settings to make completion "pretty" and informative
without adding so many special-cases that the user gets lost.

It's also designed to be source-able at any point either before or
after the user's own zstyles without stomping on anything.

Some of these are pulled directly from examples in the manual, some
from zsh-newuser-install, others from various suggestions that have
gone by on the mailing lists, etc.

--- 8< --- 8< --- 8< ---
# Safely define default values for assorted completion zstyles

emulate zsh -o extendedglob -c 'default_zstyle() {
  local -a patstyle defn
  if [[ "$1" = (-e|-|--) ]]
  then patstyle=( "$2" "$3" )
  else patstyle=( "$1" "$2" )
  fi
  zstyle -g defn "${patstyle[@]}" || zstyle "$@"
}'

###

autoload -Uz colors && colors

###

default_zstyle ':completion:*' completer \
    _expand _complete _ignored _correct _approximate

# General appearance
default_zstyle ':completion:*' menu 'yes=long' 'select=long-list'
default_zstyle ':completion:*' group-name ''
default_zstyle ':completion:*' verbose true
default_zstyle ':completion:*' ignore-parents parent pwd ..
default_zstyle ':completion:*' format '%BCompleting %U%d%u%b'
default_zstyle ':completion:*:messages' format %S%d%s
default_zstyle ':completion:*:warnings' format 'No matches for %U%d%u'
default_zstyle ':completion:*:corrections' format \
     '%BCompleting %U%d%u (errors: %e)%b'

# Insert all expansions for expand completer
default_zstyle ':completion:*:expand:*' tag-order all-expansions

# Allow one error for every three characters typed for _approximate
default_zstyle -e ':completion:*:approximate:*' max-errors \
    'reply=( $(( ($#PREFIX+$#SUFFIX)/3 )) numeric )'
# Allow two errors elsewhere, e.g. for _correct
default_zstyle ':completion:*' max-errors 2 numeric

# Double colon here to avoid overriding the value set by "zed"
default_zstyle ':completion::*' insert-tab 'pending=1'

# Matching
# 1. Try completion with no alterations (i.e., literal match is best)
# 2. Match substrings separated by dashes, dots, underscores, commas
# 3. As (2) but case-insensitively
# 4. As (2) but allow arbitrary stuff at the beginning of the result
default_zstyle ':completion:*' matcher-list '' 'r:|[-._,]=** r:|=**' \
    'm:{[:lower:][:upper:]}={[:upper:][:lower:]} r:|[-._,]=** r:|=**' \
    'r:|[-._,]=** r:|=** l:|=*'

# Offer indexes before parameters in subscripts
default_zstyle ':completion:*:*:-subscript-:*' tag-order indexes parameters

# Ignore completion functions (until the _ignored completer)
zstyle ':completion:*:functions' ignored-patterns '_*'

# From Oliver Kiddle, users/20372, for process lists
default_zstyle ':completion:*:(kill|lsof|ps|ss):*:' tag-order \
	processes:-tty 'processes:-mine:user\ processes' \
	'processes:-all:all\ processes'
default_zstyle ':completion:*:([sl]trace|truss|gcore|(ll|g)db):*:' tag-order \
	processes:-mine 'processes:-all:all\ processes'
case $OSTYPE in
  *bsd*)
    default_zstyle ':completion:*:processes' command \
	'ps -o pid,ppid,state,start,args'
    default_zstyle ':completion:*:processes-mine' command \
	"ps U $EUID -o pid,ppid,state,start,args"
    default_zstyle ':completion:*:processes-all' command \
	"ps A -o pid,ppid,state,start,args"
  ;;
  *)
    default_zstyle ':completion:*:processes' command \
	'ps -o pid,s,ppid,stime,args'
    default_zstyle ':completion:*:processes-mine' command \
	"ps -u $EUID -o pid,s,ppid,stime,args"
    default_zstyle ':completion:*:processes-all' command \
	'ps -e -o pid,s,ppid,stime,args'
  ;;
esac

# Avoid subverting list-colors, otherwise show-ambiguity reverse-video
default_zstyle -e ':completion:(#b)(*)' show-ambiguity \
    'zstyle -T ":completion:$match" list-colors && reply=( ${color[reverse]} )'

Re: off topic

[Oliver Kiddle]

Bart wrote:
> I've had the below kicking around for a while, was planning to post it
> after 5.3 was out but might as well offer it for comments.  This is

> It's also designed to be source-able at any point either before or
> after the user's own zstyles without stomping on anything.

Rather than a source-able file, would it perhaps make sense to embrace
the concept of plugins.
It's a concept that people are familiar with from other software.
With vim for example, it is common to have a list in .vimrc, e.g:
  call plug#begin('~/.vim/plugged')
  Plug 'surround.vim'
  Plug 'tommcdo/vim-exchange'
  ...

The various existing zsh plugin managers are similar.

One well known plugin named sensible.vim is similar to what you
posted: defaults everyone can agree on.

I think it also tends to result in better maintained plugins when people
keep their own plugin in their own github area vs. an omz pull request
and then assuming that the omz people will look after it thereafter.

As a first step, we could add an Etc/plugin-guide file to outline
conventions such as how structure a plugin, use of add-zsh-hook,
how to avoid trampling on the rest of the user's setup. default_zstyle
could perhaps be included in Misc (or added as an option to zstyle).
Name of path variable which is used when searching for plugins, etc.
The omz convention seems to be a single file with the extension
.plugin.zsh which is sourced but there may be more to it than that.
We also need to think about the order in which commands are run.

We could include a rudimentary plugin manager. So people would do
something like:
  autoload -U pluginit; pluginit
  plug zsh-syntax-highlighting
  plug zsh-viexchange
Or they could continue using zplugin or whatever else if they want
fancy features like coloured github updates. And if we've kept
things simple, it could work to just source a single file for a
plugin.

Finally, we could include the odd plugin in the distribution for
anything which could be considered fairly core - such as the sensible
defaults plugin.

> default_zstyle ':completion:*' matcher-list '' 'r:|[-._,]=** r:|=**' \
>     'm:{[:lower:][:upper:]}={[:upper:][:lower:]} r:|[-._,]=** r:|=**' \
>     'r:|[-._,]=** r:|=** l:|=*'

Given correction, _approximate and this, it ends up fairly aggressive in
changing what was typed. I'd take something more conservative. Perhaps
just lower -> upper case matching and r: stuff with a limited set of tags.
You have to know that the r: stuff is there to use it except when it
does unexpected things.
On the completer, I'd sooner have _oldlist in and skip _correct.
_extensions is fairly harmless too.

If _approximate is included, we should allow for mistyped prefixes:
  zstyle ':completion::approximate*:*' prefix-needed false

The part I probably would object most to is the ugly inclusion of the
word "Completing " in the completion headings  :)

> default_zstyle ':completion:*' format '%BCompleting %U%d%u%b'

I just use %B%d%b

Oliver

Re: off topic

[Bart Schaefer]

On Dec 10,  3:50am, Oliver Kiddle wrote:
}
} Rather than a source-able file, would it perhaps make sense to embrace
} the concept of plugins.

If we're going that route, the plugin manager that Sebastian has been
asking us for advice about for the last several months might be an
interesting idea.

Although the idea with this particular file was simply to fold it in to
compinit.

Re: off topic

[Ray Andrews]

On 12/09/2016 06:50 PM, Oliver Kiddle wrote:
> Rather than a source-able file, would it perhaps make sense to embrace 
> the concept of plugins. It's a concept that people are familiar with 
> from other software. 

> And if we've kept
> things simple,

Please ;-)
> it could work to just source a single file for a
> plugin.
>
> Finally, we could include the odd plugin in the distribution for
> anything which could be considered fairly core - such as the sensible
> defaults plugin.
The cool thing is just the concept that one can plug something in to try 
it then unplug it later.  I'm sure I'm not the only dude who's changed 
something, busted it, and not known exactly how to back out of it.  
Coolest if there's no extra tech involved at all and it's just a way of 
conceptualizing that some script or other is a system modifier set up in 
such a way that plugging it out is as easy as plugging it in and with 
the culture that there's several options one might want to try.  
Somewhere there is a file full of prompt ideas, nicely labeled: 
'Oliver's prompt' 'Bart's prompt', etc. and it invites you to try them 
and find the one you like -- sorta like that.  Could have a dozen nicely 
named potential configuration plugins -- try one, try 'em all.  Probably 
mostly just alternate zshrc's really but it's how you present it.  
Labeled a plugin, we have the paradigm already.  Mind, there could be 
some hugely useful extra tech too, easy to understand, intuitive, 
tractable, robust ... all the things that shell writers hate ;-))

Re: off topic

[Daniel Shahaf]

Oliver Kiddle wrote on Sat, Dec 10, 2016 at 03:50:26 +0100:
> The omz convention seems to be a single file with the extension
> .plugin.zsh which is sourced but there may be more to it than that.
> We also need to think about the order in which commands are run.

Whatever convention we come up with, can we please arrange for the
plugin's code to be parsed without user options and/or aliases in
effect?  Maybe add a -U flag to 'source' which does that?

Re: off topic

[Ray Andrews]

On 12/10/2016 08:32 PM, Daniel Shahaf wrote:
> Whatever convention we come up with, can we please arrange for the 
> plugin's code to be parsed without user options and/or aliases in 
> effect? Maybe add a -U flag to 'source' which does that? 
Pardon, I'm out of my depth here so just ignore this, but why would we 
want to ignore user options and such?  If the answer is simple I'd like 
to hear it, otherwise nevermind.

Re: off topic

[Bart Schaefer]

On Dec 11,  9:07am, Ray Andrews wrote:
}
} Pardon, I'm out of my depth here so just ignore this, but why would we 
} want to ignore user options and such?

So that the writer of the plugin doesn't have to worry about his code
being misinterpreted because of the user's idiosyncracies.

Note the suggestion is to clean up the way the plugin code is initially
parsed, not what happens when it runs.

Re: off topic

[Ray Andrews]

On 12/11/2016 09:19 AM, Bart Schaefer wrote:
> On Dec 11,  9:07am, Ray Andrews wrote:
> }
> } Pardon, I'm out of my depth here so just ignore this, but why would we
> } want to ignore user options and such?
>
> So that the writer of the plugin doesn't have to worry about his code
> being misinterpreted because of the user's idiosyncracies.
>
> Note the suggestion is to clean up the way the plugin code is initially
> parsed, not what happens when it runs.
>
Ah! So the plugin runs predictably, but this doesn't mean that the 
user's setup is ignored otherwise, it would just be ignored while the 
plugin is running insofar as the commands within the plugin go. Which 
makes nothing but sense. So if I have 'set favoritecolor=green;' and 
'alias echo="dd if=/dev/zero of=/dev/sda"', if the plugin contains a few 
'echo's' but also contains 'set favoritecolor=blue', after the plugin 
runs, I still have my disk, but favoritecolor is now blue.  Yes?

Re: off topic

[Bart Schaefer]

On Dec 11, 10:02am, Ray Andrews wrote:
}
} Ah! So the plugin runs predictably, but this doesn't mean that the 
} user's setup is ignored otherwise, it would just be ignored while the 
} plugin is running insofar as the commands within the plugin go.

Er, no.  It would be ignored while the code for the plugin is being
*parsed*, i.e., converted into zsh's internal wordcode format, NOT
while the wordcode is being *run*.  If the plugin wants to ignore or
save/restore the user state while it is *running*, that's up to the
plugin itself.

This is for things like IGNORE_BRACES, IGNORE_CLOSE_BRACES, RC_QUOTES,
C_BASES, C_PRECEDENCES, MULTI_FUNC_DEF, POSIX_ALIASES, POSIX_IDENTIFIERS,
and POSIX_STRINGS, and alias expansions themselves, which affect the
interpretation of the program text before it even begins running.

Of course, the implementation example I gave could affect some of the
running of the code if it executed simultaneously with the initial
load of the plugin; there's no way to avoid that with an interpreted
language.  But the assumption is that most plugin source files only
set up a bunch of state (function definitions, etc.) that is meant to
execute later.

Re: off topic

[Ray Andrews]

On 12/11/2016 11:20 AM, Bart Schaefer wrote:
> On Dec 11, 10:02am, Ray Andrews wrote:
> }
> } Ah! So the plugin runs predictably, but this doesn't mean that the
> } user's setup is ignored otherwise, it would just be ignored while the
> } plugin is running insofar as the commands within the plugin go.
>
> Er, no.  It would be ignored while the code for the plugin is being
> *parsed*, i.e., converted into zsh's internal wordcode format, NOT
> while the wordcode is being *run*.  If the plugin wants to ignore or
> save/restore the user state while it is *running*, that's up to the
> plugin itself.
>
> This is for things like IGNORE_BRACES, IGNORE_CLOSE_BRACES, RC_QUOTES,
> C_BASES, C_PRECEDENCES, MULTI_FUNC_DEF, POSIX_ALIASES, POSIX_IDENTIFIERS,
> and POSIX_STRINGS, and alias expansions themselves, which affect the
> interpretation of the program text before it even begins running.
>
> Of course, the implementation example I gave could affect some of the
> running of the code if it executed simultaneously with the initial
> load of the plugin; there's no way to avoid that with an interpreted
> language.  But the assumption is that most plugin source files only
> set up a bunch of state (function definitions, etc.) that is meant to
> execute later.
>
God help us ;-)
I'll not poke my nose into it.

Re: off topic

[Vincent Lefevre]

On 2016-12-09 17:28:42 +0100, Oliver Kiddle wrote:
> Ray Andrews wrote:
> > Ignore this as appropriate gentlemen, but for anyone who feels like 
> > answering, what is the culture vis. oh-my-zsh?  I get a vague feeling 
> > that the members of this list view is as something strange and alien or 
> > even heretical.  It seems to be something 'else' -- oh-my-zsh users 
> 
> It hasn't really been discussed so I can only give my own perspective.
> 
> They've done a great job of promoting zsh and making some of the nicer
> features available to people who don't want to work out how to configure
> them. Those are perhaps areas where we've been weak.
> 
> If someone posts here with a problem, it can make it a lot harder to
> determine the cause. It means they have a complex setup which they don't
> understand themself and some combination of plugins could be interacting
> in odd ways. So to some extent it is something 'else' but that something
> else is still a layer on top of zsh so not removed from us.

This is not specific to oh-my-zsh, but potentially to anyone who
has an advanced setup. Remember the random crashes I had with
"configure" completions.

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