* vi mode reset @ 2016-12-09 12:29 ` Christian Brabandt 2016-12-09 14:33 ` Ray Andrews ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Christian Brabandt @ 2016-12-09 12:29 UTC (permalink / raw) To: zsh-users 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.) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: vi mode reset 2016-12-09 12:29 ` vi mode reset Christian Brabandt @ 2016-12-09 14:33 ` Ray Andrews 2016-12-09 14:41 ` Peter Stephenson 2016-12-09 14:44 ` Oliver Kiddle 2 siblings, 0 replies; 25+ messages in thread From: Ray Andrews @ 2016-12-09 14:33 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: vi mode reset 2016-12-09 12:29 ` vi mode reset Christian Brabandt 2016-12-09 14:33 ` Ray Andrews @ 2016-12-09 14:41 ` Peter Stephenson 2016-12-09 14:44 ` Oliver Kiddle 2 siblings, 0 replies; 25+ messages in thread From: Peter Stephenson @ 2016-12-09 14:41 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: vi mode reset 2016-12-09 12:29 ` vi mode reset Christian Brabandt 2016-12-09 14:33 ` Ray Andrews 2016-12-09 14:41 ` Peter Stephenson @ 2016-12-09 14:44 ` Oliver Kiddle 2016-12-09 15:07 ` off topic Ray Andrews 2016-12-09 15:48 ` vi mode reset Christian Brabandt 2 siblings, 2 replies; 25+ messages in thread From: Oliver Kiddle @ 2016-12-09 14:44 UTC (permalink / raw) To: Christian Brabandt; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* off topic 2016-12-09 14:44 ` Oliver Kiddle @ 2016-12-09 15:07 ` Ray Andrews 2016-12-09 16:28 ` Oliver Kiddle 2016-12-09 15:48 ` vi mode reset Christian Brabandt 1 sibling, 1 reply; 25+ messages in thread From: Ray Andrews @ 2016-12-09 15:07 UTC (permalink / raw) To: zsh-users 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-09 15:07 ` off topic Ray Andrews @ 2016-12-09 16:28 ` Oliver Kiddle 2016-12-09 17:45 ` Ray Andrews ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Oliver Kiddle @ 2016-12-09 16:28 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-09 16:28 ` Oliver Kiddle @ 2016-12-09 17:45 ` Ray Andrews 2016-12-10 0:54 ` Bart Schaefer [not found] ` <584AEDBF.2050402__19991.0537027337$1481307418$gmane$org@eastlink.ca> 2016-12-12 13:11 ` Vincent Lefevre 2 siblings, 1 reply; 25+ messages in thread From: Ray Andrews @ 2016-12-09 17:45 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-09 17:45 ` Ray Andrews @ 2016-12-10 0:54 ` Bart Schaefer 2016-12-10 2:50 ` Oliver Kiddle [not found] ` <95362.1481338226__15466.9970310808$1481338718$gmane$org@hydra.kiddle.eu> 0 siblings, 2 replies; 25+ messages in thread From: Bart Schaefer @ 2016-12-10 0:54 UTC (permalink / raw) To: zsh-users 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]} )' ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-10 0:54 ` Bart Schaefer @ 2016-12-10 2:50 ` Oliver Kiddle 2016-12-10 3:13 ` Bart Schaefer 2016-12-10 3:31 ` Ray Andrews [not found] ` <95362.1481338226__15466.9970310808$1481338718$gmane$org@hydra.kiddle.eu> 1 sibling, 2 replies; 25+ messages in thread From: Oliver Kiddle @ 2016-12-10 2:50 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-10 2:50 ` Oliver Kiddle @ 2016-12-10 3:13 ` Bart Schaefer 2016-12-10 3:31 ` Ray Andrews 1 sibling, 0 replies; 25+ messages in thread From: Bart Schaefer @ 2016-12-10 3:13 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-10 2:50 ` Oliver Kiddle 2016-12-10 3:13 ` Bart Schaefer @ 2016-12-10 3:31 ` Ray Andrews 1 sibling, 0 replies; 25+ messages in thread From: Ray Andrews @ 2016-12-10 3:31 UTC (permalink / raw) To: zsh-users 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 ;-)) ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <95362.1481338226__15466.9970310808$1481338718$gmane$org@hydra.kiddle.eu>]
* Re: off topic [not found] ` <95362.1481338226__15466.9970310808$1481338718$gmane$org@hydra.kiddle.eu> @ 2016-12-11 4:32 ` Daniel Shahaf 2016-12-11 17:07 ` Ray Andrews 0 siblings, 1 reply; 25+ messages in thread From: Daniel Shahaf @ 2016-12-11 4:32 UTC (permalink / raw) To: zsh-users 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-11 4:32 ` Daniel Shahaf @ 2016-12-11 17:07 ` Ray Andrews 2016-12-11 17:19 ` Bart Schaefer 0 siblings, 1 reply; 25+ messages in thread From: Ray Andrews @ 2016-12-11 17:07 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-11 17:07 ` Ray Andrews @ 2016-12-11 17:19 ` Bart Schaefer 2016-12-11 18:02 ` Ray Andrews 0 siblings, 1 reply; 25+ messages in thread From: Bart Schaefer @ 2016-12-11 17:19 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-11 17:19 ` Bart Schaefer @ 2016-12-11 18:02 ` Ray Andrews 2016-12-11 19:20 ` Bart Schaefer 0 siblings, 1 reply; 25+ messages in thread From: Ray Andrews @ 2016-12-11 18:02 UTC (permalink / raw) To: zsh-users 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-11 18:02 ` Ray Andrews @ 2016-12-11 19:20 ` Bart Schaefer 2016-12-11 20:23 ` Ray Andrews 0 siblings, 1 reply; 25+ messages in thread From: Bart Schaefer @ 2016-12-11 19:20 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-11 19:20 ` Bart Schaefer @ 2016-12-11 20:23 ` Ray Andrews 0 siblings, 0 replies; 25+ messages in thread From: Ray Andrews @ 2016-12-11 20:23 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <584AEDBF.2050402__19991.0537027337$1481307418$gmane$org@eastlink.ca>]
* Re: off topic [not found] ` <584AEDBF.2050402__19991.0537027337$1481307418$gmane$org@eastlink.ca> @ 2016-12-09 19:24 ` Daniel Shahaf 2016-12-09 20:25 ` Ray Andrews [not found] ` <584B1325.1010907__10266.7204490446$1481316980$gmane$org@eastlink.ca> 0 siblings, 2 replies; 25+ messages in thread From: Daniel Shahaf @ 2016-12-09 19:24 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-09 19:24 ` Daniel Shahaf @ 2016-12-09 20:25 ` Ray Andrews [not found] ` <584B1325.1010907__10266.7204490446$1481316980$gmane$org@eastlink.ca> 1 sibling, 0 replies; 25+ messages in thread From: Ray Andrews @ 2016-12-09 20:25 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <584B1325.1010907__10266.7204490446$1481316980$gmane$org@eastlink.ca>]
* Re: off topic [not found] ` <584B1325.1010907__10266.7204490446$1481316980$gmane$org@eastlink.ca> @ 2016-12-10 0:14 ` Daniel Shahaf 2016-12-10 0:21 ` Ray Andrews 0 siblings, 1 reply; 25+ messages in thread From: Daniel Shahaf @ 2016-12-10 0:14 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-10 0:14 ` Daniel Shahaf @ 2016-12-10 0:21 ` Ray Andrews 0 siblings, 0 replies; 25+ messages in thread From: Ray Andrews @ 2016-12-10 0:21 UTC (permalink / raw) To: Daniel Shahaf; +Cc: zsh-users 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: off topic 2016-12-09 16:28 ` Oliver Kiddle 2016-12-09 17:45 ` Ray Andrews [not found] ` <584AEDBF.2050402__19991.0537027337$1481307418$gmane$org@eastlink.ca> @ 2016-12-12 13:11 ` Vincent Lefevre 2 siblings, 0 replies; 25+ messages in thread From: Vincent Lefevre @ 2016-12-12 13:11 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: vi mode reset 2016-12-09 14:44 ` Oliver Kiddle 2016-12-09 15:07 ` off topic Ray Andrews @ 2016-12-09 15:48 ` Christian Brabandt 2016-12-09 16:46 ` Oliver Kiddle 1 sibling, 1 reply; 25+ messages in thread From: Christian Brabandt @ 2016-12-09 15:48 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zsh-users 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ß. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: vi mode reset 2016-12-09 15:48 ` vi mode reset Christian Brabandt @ 2016-12-09 16:46 ` Oliver Kiddle 2016-12-09 20:24 ` Christian Brabandt 0 siblings, 1 reply; 25+ messages in thread From: Oliver Kiddle @ 2016-12-09 16:46 UTC (permalink / raw) To: Christian Brabandt; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: vi mode reset 2016-12-09 16:46 ` Oliver Kiddle @ 2016-12-09 20:24 ` Christian Brabandt 0 siblings, 0 replies; 25+ messages in thread From: Christian Brabandt @ 2016-12-09 20:24 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2016-12-12 13:20 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20161209130109epcas2p1fd786d46827852a8cf1badcb5d003ec9@epcas2p1.samsung.com> 2016-12-09 12:29 ` vi mode reset Christian Brabandt 2016-12-09 14:33 ` Ray Andrews 2016-12-09 14:41 ` Peter Stephenson 2016-12-09 14:44 ` Oliver Kiddle 2016-12-09 15:07 ` off topic Ray Andrews 2016-12-09 16:28 ` Oliver Kiddle 2016-12-09 17:45 ` Ray Andrews 2016-12-10 0:54 ` Bart Schaefer 2016-12-10 2:50 ` Oliver Kiddle 2016-12-10 3:13 ` Bart Schaefer 2016-12-10 3:31 ` Ray Andrews [not found] ` <95362.1481338226__15466.9970310808$1481338718$gmane$org@hydra.kiddle.eu> 2016-12-11 4:32 ` Daniel Shahaf 2016-12-11 17:07 ` Ray Andrews 2016-12-11 17:19 ` Bart Schaefer 2016-12-11 18:02 ` Ray Andrews 2016-12-11 19:20 ` Bart Schaefer 2016-12-11 20:23 ` Ray Andrews [not found] ` <584AEDBF.2050402__19991.0537027337$1481307418$gmane$org@eastlink.ca> 2016-12-09 19:24 ` Daniel Shahaf 2016-12-09 20:25 ` Ray Andrews [not found] ` <584B1325.1010907__10266.7204490446$1481316980$gmane$org@eastlink.ca> 2016-12-10 0:14 ` Daniel Shahaf 2016-12-10 0:21 ` Ray Andrews 2016-12-12 13:11 ` Vincent Lefevre 2016-12-09 15:48 ` vi mode reset Christian Brabandt 2016-12-09 16:46 ` Oliver Kiddle 2016-12-09 20:24 ` Christian Brabandt
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).