Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #64806 > unrolled thread

Highlighting program variables instead of keywords?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Highlighting program variables instead of keywords? Skip Montanaro <skip@pobox.com> - 2014-01-26 18:31 -0600
    Re: Highlighting program variables instead of keywords? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-27 01:29 +0000
      Re: Highlighting program variables instead of keywords? Chris Angelico <rosuav@gmail.com> - 2014-01-27 12:51 +1100
      Re: Highlighting program variables instead of keywords? Ben Finney <ben+python@benfinney.id.au> - 2014-01-27 13:08 +1100
      Re: Highlighting program variables instead of keywords? Terry Reedy <tjreedy@udel.edu> - 2014-01-27 01:30 -0500

#64806 — Highlighting program variables instead of keywords?

[Multipart message — attachments visible in raw view] — view raw

My son sent me a link to an essay about highlighting program data instead
of keywords:

https://medium.com/p/3a6db2743a1e/

I think this might have value, especially if to could bounce back and forth
between both schemes. Is anyone aware of tools like this for Python? Bonus
points for pointers to an Emacs implementation.

Thanks,

Skip

[toc] | [next] | [standalone]

#64812

On Sun, 26 Jan 2014 18:31:49 -0600, Skip Montanaro wrote:

> My son sent me a link to an essay about highlighting program data
> instead of keywords:
> 
> https://medium.com/p/3a6db2743a1e/
> 
> I think this might have value, especially if to could bounce back and
> forth between both schemes.

Hmmm, I'm not convinced, but then I wasn't convinced by syntax 
highlighting either until I had used it for a while. (I still think it's 
a nice-to-have rather than a must-have.)

Seems to me that beyond a dozen or so variables, the colours won't be 
distinctive enough to get much benefit. Especially if similar names get 
similar colours, e.g. the name "handle_process" and the typo 
"handle_prosess" will be barely distinguishable. In a well-designed 
program, most variables will appear in a fairly limited number of places, 
possibly in only a single function or method, so in even a fairly small 
project you might have a few dozen distinct variables, each of which 
might appear only three or five times.



> Is anyone aware of tools like this for
> Python? Bonus points for pointers to an Emacs implementation.

Sorry, can't help you.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#64813

On Mon, Jan 27, 2014 at 12:29 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Hmmm, I'm not convinced, but then I wasn't convinced by syntax
> highlighting either until I had used it for a while. (I still think it's
> a nice-to-have rather than a must-have.)

It's definitely just a nice-to-have. I've built miniature text editors
into various programs (including two MUD clients, for the purpose of
editing files on the server), and haven't bothered with the level of
sophistication required for smart-indent, much less syntax
highlighting. (I'll occasionally put in an auto-indent - hit enter and
it indents to the same level as the previous line - but not even
always that, and definitely not "hey, that line has more ( than ) so
I'll indent an extra level", which is a *hugely* helpful feature when
I'm doing main coding (it catches errors, as well as saving time on
indentation), but one I can do without if it means I can knock
together an editor in a tenth the time.)

> Seems to me that beyond a dozen or so variables, the colours won't be
> distinctive enough to get much benefit. Especially if similar names get
> similar colours, e.g. the name "handle_process" and the typo
> "handle_prosess" will be barely distinguishable. In a well-designed
> program, most variables will appear in a fairly limited number of places,
> possibly in only a single function or method, so in even a fairly small
> project you might have a few dozen distinct variables, each of which
> might appear only three or five times.

Hmm. Would similar names get similar colours? I would guess that a
naive approach would just go sequentially through the file, but if
it's smart enough to recognize similarity, it'd be nice if it could
then be smart enough to make them contrast. The more similar the
words, the less similar the colours, and vice versa. Or at very least,
sort all the words alphabetically, and then distribute them in some
binary flip-flop method that will tend to put the ones with the same
start further apart. (That would catch typos anywhere other than the
beginning of the name.)

Oh. Yes, they will get similar colours. Just re-read the page:
"""
Variable names with similar prefixes will be assigned similar colors.
We collect all the custom names and order them alphabetically, then
distributing them evenly along a spectrum. This way we make sure we
use as distinct colors as possible.
"""
IMO this is a flawed design decision. The purpose of the color is to
add information, not to replicate what's already there. (And it's
using the simplistic method I described, of simply sorting
alphabetically to determine similarity. There are other ways of
distinguishing, but they're a lot more complicated.)

If it's smart enough to recognize the difference between local and
global names, that would be useful. Might not be so useful in JS, but
definitely in Python. It would take a bit of smartness, but most
editors these days have to be able to fully parse the language anyway.
Hmm. Actually, this might be a plausible idea just on its own: never
mind about distinguishing specific names, just create a highlight
class for each of "local name" (including function parameters),
"global name, read-only", and "global name, assigned to in this
function", and possibly non-local (read-only and assigned) as well. If
you suddenly see that the name 'len' has changed from being "global
name, read-only" to "local name", you'll know instantly that you just
shadowed a built-in (probably unintentionally and in a way likely to
cause bugs). Do any editors currently offer this?

ChrisA

[toc] | [prev] | [next] | [standalone]

#64818

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> Hmmm, I'm not convinced, but then I wasn't convinced by syntax
> highlighting either until I had used it for a while. (I still think
> it's a nice-to-have rather than a must-have.)

I wouldn't rate syntax highlighting a must-have. But I do think it's
significantly more difficult to work with an editor that doesn't
highlight the syntax of the code.

> Seems to me that beyond a dozen or so variables, the colours won't be 
> distinctive enough to get much benefit.

A more severe problem with the suggestion is that human cognition is
only capable of attending to a limited number of differences at once,
and so this kind of attention-drawing is a limited resource. Drawing
attention to some aspects is at the expense of reduced attention to
other aspects.

The significant benefit of syntax highlighting is that it reduces the
difficulty to read the text and see what will be obvious to the
compiler: the structure of each statement and block. So spending the
limited resource of differential attention to colours is valuable to
help with this difficult aspect of reading code.

So I strongly disagree with the statement “But as it stands, we
highlight the obvious (like the word function) and leave most of the
content in black.”

Once you have attention on it, the word “function” is obvious. But the
whole motivation of highlighting syntax using different colours is to
get that differential attention in the first place. The difference
between tokens *isn't* so obvious when glancing at the code without
those colours.

That said, the motivation in highlighting different names differently is
a good one, too. I would like to have the benefit described in the
article: having different names easily distinguished in the code. But I
don't think that should come at the expense of significantly reducing
the ease of quickly distinguishing the syntactical structure.

-- 
 \       “We must find our way to a time when faith, without evidence, |
  `\    disgraces anyone who would claim it.” —Sam Harris, _The End of |
_o__)                                                     Faith_, 2004 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#64832

On 1/26/2014 8:29 PM, Steven D'Aprano wrote:
> On Sun, 26 Jan 2014 18:31:49 -0600, Skip Montanaro wrote:
>
>> My son sent me a link to an essay about highlighting program data
>> instead of keywords:
>>
>> https://medium.com/p/3a6db2743a1e/
>>
>> I think this might have value, especially if to could bounce back and
>> forth between both schemes.
>
> Hmmm, I'm not convinced, but then I wasn't convinced by syntax
> highlighting either until I had used it for a while. (I still think it's
> a nice-to-have rather than a must-have.)

When my fingers get a bit fumbly, I find it more useful. When I do not 
hit ' or " solidly, or  type a mismatch 'something", having the string 
literal color continue is a handy clue. So is 'it' not getting the 
keyword color that if would.

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web