nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: add a Verilog HDL syntax highlighting file


From: Jorge Juan
Subject: Re: add a Verilog HDL syntax highlighting file
Date: Mon, 11 Jan 2021 10:17:29 +0100

El dom, 10 ene 2021 a las 21:14, Jorge Juan (<jjchico@gmail.com>) escribió:
>
> El dom, 10 ene 2021 a las 20:11, Benno Schulenberg
> (<bensberg@telfort.nl>) escribió:
> >
> >
> > Op 08-01-2021 om 19:35 schreef Jorge Juan:
> > > https://packages.debian.org/sid/iverilog
> > > https://packages.debian.org/sid/verilator
> > > https://packages.debian.org/sid/yosys
> >
> > Okay.
> >
> > >> Wouldn't it make more sense to include a Verilog syntax file for nano 
> > >> with
> > >> some major Verilog package?
> > >
> > > I do not think it can be compared. Would you expect ruby, python or
> > > gcc include syntax highlighting configuration for many text editors?
> >
> > Python and Gcc are not comparable to Verilog: the first two are at least
> > two orders of magnitude more used than Verilog.  Why include a syntax in
> > nano by default for something that less than a percent of the users use?
>
> I meant Verilog is not a niche language, it is the most used hardware
> description language in the world (VHDL may be close) and more than
> 90% of digital hardware today is designed using hardware description
> languages. It is normal that people write more software than hardware:
> hardware typically can execute many software programs. Software is
> probably less than 1% of the text people write using computers if you
> include plain English, Spanish or German; but we still want text
> editors to support programming (and hardware description) languages :)
>
> >
> > > I understand that you may find Verilog not interesting enough to be
> > > included with nano. It is ok. I will probably publish the syntax as a
> > > gitlab snippet so it can be easily reached by interested users.
> >
> > Unfortunately the Gitlab snippet (https://gitlab.com/-/snippets/2058705)
> > is unrechable without Javascript.  You may want to publish it in a place
> > that is more freely accessible.  Maybe on Savannah?
> >
> >   https://savannah.gnu.org/patch/?group=nano
> >
> > (It doesn't have to be a patch.  You can attach plain syntax files there.)
>
> I'll explore that option.

Ok. Now you have it in Savannah for easier access.

> >
> > > In the
> > > meantime, I decided to rework the syntax file a bit more and I have a
> > > new version now supporting both Verilog and SystemVerilog.
> >
> > Oh.  I wouldn't have done that.  I would have kept the two separated.
>
> Yes, I am not fully happy with the solution. Since SystemVerilog is a
> superset of Verilog it is just a matter of removing the keywords that
> are not part of the legacy Verilog standard. It would be nice if nano
> had a mean to define a new syntax as an extension of an already
> defined syntax, but it is not possible AFAIK. That way, the
> SystemVerilog syntax would be something like: "if file ends in ".sv"
> load the Verilog syntax and add these additional keywords."
>
> Having two different syntaxes that share most of the code look a
> little weird to me but may be the best option in the end.

There are now two versions, one for Verilog (.v, .vh) and another one
for SystemVerilog (.sv, .svh).

>
> >
> > > In this version I use very long regular expressions to match the whole
> > > list of standard keywords. It make very long lines, which I do not
> > > really like, but it is easier to maintain and probably more efficient
> > > to parse.
> > Maybe more efficient for the regex coloring code, but in my opinion
> > /less/ maintainable because harder to read.
>
> Believe me, I am not friend of long (more than 79 chars) lines but
> reformatting 10+ lines only because you forgot to include or added an
> extra keyword is a pain. Here, activating line wrapping for a few
> minutes may help. But I agree splitting lines may be an option once
> the syntax is finished and stable. (If I decide to trim the
> SystemVerilog syntax to have a plain Verilog one, having all the
> keywords in one line is going to simplify the task quite a lot :)

Ok. Long regular expressions are now splitted in several lines. The
number of regular expressions to parse has multiplied by 5 or 6
(Verilog has lots of keywords) but who cares...

I hope it helps.

Best.

> >
> > Benno
> >
> Thanks for your thorough review.
>
>
> jorge.
>
>
> --
> Jorge Juan



-- 
Jorge Juan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]