zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>,
	Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [BUG] region_highlight+=( "$start $end standout" ) doesn't work as expected
Date: Sun, 09 Dec 2018 18:49:03 +0000	[thread overview]
Message-ID: <53005dd0750e99fb654f5708a6e256dbea6f899a.camel@ntlworld.com> (raw)
In-Reply-To: <CAKc7PVChj1t0sP1TesDPzuMo_hUR2e_nwWugXVoxb1S=dYROhw@mail.gmail.com>

> Could the problem be fixed, .. ASAP?

I won't be working on this, but I can give some poiners.

You'll need to look in Src/Zle/zle_refresh.c.  You'll see the
region_highlights variable that contains the information.  There are 4
special regions at the start --- see definition of
N_SPECIAL_HIGHLIGHTS.

There are two key points in turning this information into the output.
One is following the comment "Calculate attribute based on region". 
That's where the information gets encoded into the array of characters
to output, which remembers the attributes associated with the character
based on the last thing to change.

The other is inside settextattributes(), where the appropriate sequences
are output.  That's called at various points during the output, but only
if we detect something has changed in them: zwcputc() is the key
location, but you'll see there are others.

The big issue here is that the shell is turning structured information
into a sequence to output --- it's not outputing a character with
particular attributes at a particular location, it's outputing a stream
consisting of a mix of characters and instructions to change
attributes.  So, for example, if two changes logically occur at the some
point which one actually happens is, while supposedly well-defined
(can't remember the rules but I think they're documented, not
necessarily in full detail), is bug-prone.

If you're problem has got to do with line wrap, that's even worse ---
as widely noted in earlier threads, you're then fighting various
terminals and their definitions, too.

Good luck.

pws


  reply	other threads:[~2018-12-09 19:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06  7:03 Sebastian Gniazdowski
2018-12-07  1:42 ` Sebastian Gniazdowski
2018-12-07  7:45   ` Daniel Shahaf
2018-12-07 15:04     ` Sebastian Gniazdowski
2018-12-09 18:49       ` Peter Stephenson [this message]
2018-12-09 19:20         ` Sebastian Gniazdowski
2018-12-09 19:48           ` Peter Stephenson
2018-12-09 20:19             ` Sebastian Gniazdowski
2018-12-09 20:56               ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53005dd0750e99fb654f5708a6e256dbea6f899a.camel@ntlworld.com \
    --to=p.w.stephenson@ntlworld.com \
    --cc=d.s@daniel.shahaf.name \
    --cc=sgniazdowski@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).