Author Topic: c++ raw string literals  (Read 1059 times)

bunbun

  • Community Member
  • Posts: 28
  • Hero Points: 2
c++ raw string literals
« on: January 28, 2016, 03:45:43 pm »
C++11 and later support raw string literals where there is no escaping and the terminal delimiters can be specified.
Does slickedit already support colour coding such literals, for example, (and I am missing some checkbox in Tools|Options) or is this c++ feature just
too hard to parse?
(See http://en.cppreference.com/w/cpp/language/string_literal #6)
Leo

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1067
  • Hero Points: 90
Re: c++ raw string literals
« Reply #1 on: January 28, 2016, 04:31:24 pm »
Currently, there is no support for C++11 raw string literals in SlickEdit.  I will file a feature request for that for consideration in a future release.  We should be able to make sure the tagging engine can handle those and not get lost, but it might be difficult in the current color coding engine.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3941
  • Hero Points: 256
Re: c++ raw string literals
« Reply #2 on: January 29, 2016, 02:36:42 am »
I happened to be in the middle of the color coding engine at the moment so I will have a go at this after I finish what I'm working on.

Worst case, we are planning to enhance the color coding engine (probably for v22 and not v21) and this would be pretty easy to add given the design enhancements we have planned. User's will have the ability to add prefixes and suffixes without them being built-in (and a ton of other capabilities too).
« Last Edit: January 29, 2016, 01:46:58 pm by Clark »

bunbun

  • Community Member
  • Posts: 28
  • Hero Points: 2
Re: c++ raw string literals
« Reply #3 on: January 29, 2016, 10:46:48 am »
Thanks.
While you are at it, it would be nice to have better color coding support for embedded sections (Here documents).
In this modern day and age where we often have to script out to different processes or make notes on original
spec-ed implementations, being able to support multiple programming languages in a single file is such a boon.
In many ways, slickedit is already 90% of the way there. It is just sometimes very difficult to reliably indicate
to the parser when we are entering a "here document" and what language specific parser should be applied to
that section.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3941
  • Hero Points: 256
Re: c++ raw string literals
« Reply #4 on: January 29, 2016, 01:45:07 pm »
Configurable embedded color coding is REALLY HARD.  Can't promise anything there yet. If you have a specific pattern in mind, please post it.

guth

  • Community Member
  • Posts: 41
  • Hero Points: 2
Re: c++ raw string literals
« Reply #5 on: January 31, 2016, 08:20:02 am »
One scenario is having HTML in strings that are then used in one of all available micro frameworks for the web. I have HTML, with embedded javascript, as a tripple quoted string in Python using the bottle framework, I have a similar example in C++11 using the Crow framework.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3941
  • Hero Points: 256
Re: c++ raw string literals
« Reply #6 on: January 31, 2016, 12:31:39 pm »
What can be done is adding user configurable pattern matching which works in certain contexts only. One context could be a string but you'd have to provide a regex which determines the string is HTML or just define all tripple quoted strings to be HTML. In many other context's (like Here Documents in Perl where a name is provided), were already do built-in pattern matching mapping which could be user configurable.

bunbun

  • Community Member
  • Posts: 28
  • Hero Points: 2
Re: c++ raw string literals
« Reply #7 on: February 02, 2016, 01:24:25 am »
I would be quite happy with that, even to the point of "defacing" my code with comments to help the parser