[Pkg-zsh-devel] [PATCH 1/3…3/3] Several tweaks to d/zshrc's new completion enablement

[Daniel Shahaf]

Axel Beckert wrote on Mon, 17 Feb 2020 12:39 +0100:
> Hi Daniel,
> 
> thanks for the patches! (Some comments on them below.)
> 

Thanks for the reviews.

> Daniel Shahaf wrote:
> > I'm not sure I understand why the Debian package has code that will only
> > run on Ubuntu.  
> 
> Because it is preferred if Debian and Ubuntu source packages don't
> differ, but Ubuntu insists on enabling completion by default while we
> at some point decided that we IIRC want the default to be rather
> minimal and not even contain autocompletion.

I don't know that having identical sources with runtime differences
is better than having differences in both source code and runtime
behaviour, but *shrug*.  TIMTOWDI.

> > It requires the Ubuntu maintainers to go through Debian
> > whenever they want to make Ubuntu-specific changes.  
> 
> No, it's more the opposite way round: [...]

Thanks for explaining!

> > Wouldn't it be better to have a standard way for downstream distros
> > to add their hooks?  
> 
> Sure. But unless these files come from a separate package, we're at
> the same situation as before (respectively now): The Ubuntu guys would
> need to find time, to merge zsh manually from Debian. I really want to
> avoid that.

Sounds like the better fix here is for Ubuntu to automate migrating
packages with Ubuntu-specific changes.  That's just a diff3; every «git
merge» does this.

> > For example, «() { [[ -e $1 ]] && source $1 }
> > /etc/zsh/zshrc.$(lsb_release -si)»?  
> 
> No, at least not with lsb_release. I deliberately used /etc/os-release
> as that is coming from the package base-files which is "Essential" and
> hence guaranteed to exist. I don't want to pull in lsb-release and
> with it python3 if I can avoid it.

My use of lsb_release was just for sake of pseudocode.  A real
implementation could use /etc/os-release or whatever else may float
its boat.

> > Subject: [PATCH 2/3] Rearrange condition to take advantage of
> >  short-circuiting.  
> 
> Not sure what you mean with "short-circuiting" here.

"Short-circuit" is the property of «&&» and «||» operators in many
languages, including zsh, that their right operand isn't evaluated if
the left operand determines the overall result:

% false && pwd
% true || pwd
% 

(«pwd» didn't run.)

So, the thinking was to check first the condition that's cheaper to evaluate.

> > -if grep -q 'ID.*=.*ubuntu' /etc/os-release && [[ -z "$skip_global_compinit" ]]; then
> > +if [[ -z "$skip_global_compinit" ]] && grep -q 'ID.*=.*ubuntu' /etc/os-release; then
> >    autoload -U compinit
> >    compinit
> >  fi  
> 
> So the difference seems, that if someone (on Ubuntu or elsewhere)
> doesn't want autocompletion initialised, we save checking if it's on
> Ubuntu or not?
> 

Yes.

> Do we want to make $skip_global_compinit a difference (in startup
> performance) anywhere else, too?

What does it mean to 'make $foo a difference'?

Cheers,

Daniel