Re: Pluma's syntax highlighting
On Mon, 13 Jan 2020, at 13:03, Richard Owlett wrote:
> On 01/13/2020 06:13 AM, Jeremy Nicoll wrote:
> > On Mon, 13 Jan 2020, at 11:52, Richard Owlett wrote:
> >
> >> I was looking for a description of what Pluma was trying to accomplish
> >> by their highlighting rules.
> >
> > Do you understand the purpose of syntax highlighting (in general)?
>
> Yes. Its specific goal is to aid a programmer WHILE coding.
> However, I'm trying to understand a vendor supplied bash script.
A programmer coding, is the same thing as a programmer (albeit a
different one, you) looking at a script written by someone else. The
colouring should, hmm, emphasise the role played by different
character sequences on the screen. Eg it may allow you to determine
the difference between
arrayname(expression) and functioncall(expression)
But it won't teach you the semantics of the programming language.
YOU still have to know how bash scripts work.
If the colouring distracts you, turn it off, and see if you find the
uncoloured script easier to understand.
> One reference explicitly said that Pluma associates a "sh" extension
> with the text being a bash script {matches my use case}.
>
> > [snip]
> > That apart, it would help enormously if you posted a screenshot of what
> > you're seeing, and some explanation of why you think the colouring is
> > wrong.
> There are cases where I would expect different keywords to have the same
> highlighting -- they didn't.
That may simply be because the logic driving the colouring process only has
a very small grasp of what the overall code does. If you like, for some reason
- maybe this specific editor's colouriser isn't as powerful as you'd like - it
can't tell the difference between
array(23) and function(23)
> The implication is that Pluma's highlighting is attempting to convey
> information that I am not receiving.
>
> Therefore I need to know what Pluma's goal was.
Its goal will be to /aid/ understanding. But I emphasis, these things very
rarely have the level of understanding of a full parser.
You should somewhere be able to look at the definitions that drive each
aspect of the colouriser's logic, and the colours assigned to each such
element. If you see elements with an unexpected colour, look up the defs
to see what the colours you are seeing represent, and then have a think
about how a program - that more than likely has analysed a specific line
of the script without knowing much or anything about the rest of the script
- might view just that line all by itself, & reach the conclusions it must have
done about those elements.
Put it another way, if you put just a handful of lines in a separate file, does
that file get coloured the same way?
--
Jeremy Nicoll - my opinions are my own.
Reply to: