## UDL help

2. Help
kanke
2013-04-04
2014-04-09

• kanke
2013-04-04

I did a quick search and didn't find it. Is there any detailed help or tutorial on UDL2?

Thanks.

• Loreia2
2013-04-04

Hi,

help site is here: http://udl20.weebly.com/

BR,
Loreia

• kanke
2013-04-04

Thanks!

• kanke
2013-04-05

I briefly check over the help site and seems there are quite some stuff to do in order to make a UDL.

Is it possible to copy one of existing language(for example Java) and then I can start make small modification?

Or how can I modify one of the existing language?

Thanks.

• Loreia2
2013-04-05

Hi,

you can't do that. You must make UDL from scratch.

BR,
Loreia

• kanke
2013-04-05

You mean I can't do neither of the two in my question? Or just the first one?

If I can't copy out existing language, at least I should be able to make modification on existing language somewhere(for example, just change the styler for comments)?

Thanks!

• Loreia2
2013-04-05

Hi,

you can modify existing UDL definition, just import them and modify them as you like. But you can't modify existing Scintilla definitions (predefined languages that come built-in with Notepad++, stuff like Java, C, C++ or any other language above "Define your language..." entry in Languages menu)

BR,
Loreia

• Malako
2014-04-04

Hi,

I'm doing some LaTeX work and using a UDL for highlighting. I'm trying to highlight keywords without whitespace in front of them (as is quite common in LaTeX), for instance:
" Lorem ipsum dolor sit amet\cite{Lorem} "
I have "\" as a prefix mode keyword and it works fine as long as there is a space in front of the "\". The only problem is, without a space it does not highlight and " Lorem ipsum dolor sit amet \cite{Lorem} " (with a space) creates a different output. Is there a way to do this? If not, where is the right place to request this as a feature? ;)

• Loreia2
2014-04-04

Hi Malako,

Keywords that don't require spaces around them are Folder in code1, Operator1, Comments, Line comments and Delimiters. So, you should use Operator1 style, but that won't work for you because there is no "prefix" option for Operator1 type.

Or you could make a Delimiter that starts with a backslash, and ends with { . If you have more that one possible ending of delimiter you can specify them like this: (( space separated list of delimiter end strings ))

Can you share some characteristic code samples?

BR,
Loreia

• Malako
2014-04-04

Hi Loreia,

Thanks for the tip about (( space separated list )), this almost solves the problem... Almost, because sadly the matter is more complicated than that, although an option to specify ranges like "from A to Z" for example would solve the problem for most "normal" cases. Below are some code samples, I've added a valid .tex file with the same commands, the standard TeX highlighter in NPP works pretty good, but I miss the option to change the color of comments, and hence I use a UDL.

LaTeX has many options, I will try to summarize some important features of commands. First of all, a double backslash is used to insert a line break "\"

LaTeX commands are terminated by a space, a number or any other "non-letter". The general syntax is:
\commandname[option1,option2,...]{argument1}{argument2}...

It is legal for a command to have no options or arguments e.g.:
\bf This is bold.

A command can have another command as an argument:
\renewcommand{\contentsname}{New name for the contents section}

An option of a command can have arguments of it's own:
\usepackage[pdfborder={0 0 0}]{hyperref}

A command can have line breaks in an argument:
\author{John Doe\JohnDoeInc.\Some contact info}

Last but not least, a special character like an "é" (acute accented e) can be inserted with \'{e} in which case the single quote does not terminate the keyword. And in cases like the "i" you need to "replace" the dot on the i which is done by \"\i

(For all the info see http://en.wikibooks.org/wiki/LaTeX)

Cheers,
Malako

Attachments

• Malako
2014-04-07

Hello Loreia,

I've thought about the problem over the weekend, a simple solution would be to close a delimiter, but have an option to highlight and start a new search at index-1.
i.e. delimiter opens with a \ and is terminated by a list of characters (we'll take "{" for this example). Normally the found instance of "{" will close the search, be part of the delimiter, and will be highlighted as such. An option like "Index -1" would do the same search, but on a match, the "{" will not be highlighted, and a new search will start form the "{" position. This would solve all the problems, with minimal programming effort :)

Cheers,

Malako

• Loreia2
2014-04-07

Hi Malako,

good thing you posted again because I missed your previous post with LATEX examples. I will look into it next weekend.

An option like "Index -1" would do the same search, but on a match, the "{" will not be highlighted, and a new search will start form the "{" position. This would solve all the problems, with minimal programming effort :)

"Index-1" works only if you expect end string to be 1 character long. Generic case would have to support strings not chars. Anyway, Scintilla does not allow going back, so it would not be a minimal effort. I will try to think of some other way to solve this problem.

BR,
Loreia

• Loreia2
2014-04-07

Hi Malako,

I have a question.

A command can have another command as an argument:
\renewcommand{\contentsname}{New name for the contents section}
An option of a command can have arguments of it's own:
\usepackage[pdfborder={0 0 0}]{hyperref}
A command can have line breaks in an argument:
\author{John Doe\JohnDoeInc.\Some contact info}

This format can be easily solved by UDL if list of keywords is predefined, not user supplied. This is what I mean. General format is:

\some_command{}
\another_command[]

You could define backslash as Operator1 type, "some_command" and "another_command" as Keyword1 type, Delimiter1 as
open: {
close: }
Delimiter2 as
open: [
close: ]

Then it would work.
If "some_command" is not a reserved keyword, but instead some random string user can supply, than this wouldn't work too well (you would have to constantly add new strings to Keyword1 type)

BR,
Loreia

Last edit: Loreia2 2014-04-07

• Malako
2014-04-08

Hello Loreia,

Scintilla does not allow going back, so it would not be a minimal effort. I will try to think of some other way to solve this problem.

Shame :/ that would have been an easy fix.
I don't know much about how the plug-in is written sadly and I'm not saying you are wrong, I just want to understand it myself.
But usually with strings, which are just pointers to an array's of chars, you can move the index around. And what I understand from the UDL websie:

1. identification starts in position 0, so first "search start point" is set to 0
2. when first space char is reached (in position 5), UDL 1.0 detects new "word" (characters from position 0 through position 5), and tries to compare string that consists of characters on positions from 0 to 5 (in this case word is "first"), with UDL's own keyword list.
3. if it detects a keyword, it sets appropriate styler (in this case keyword1 styler), and sets new "search start point" one char after space, i.e. position 6.
4. Now it repeats the process for other keywords.

This is what you said, as it starts a new search one char after space, but the space is not highlighted (visible with the "underlined" option). Replication of this behavior on a char that is not whitespace (e.g. "{" ) would leave the char "{" un-highlighted. And there is no way to perform a "search start point" on the position of char "{" if it is not white space?

If "some_command" is not a reserved keyword, but instead some random string user can supply, than this wouldn't work too well (you would have to constantly add new strings to Keyword1 type)

That is, sadly, exactly the case. Some commands are widely used and "standard" but all existing commands can be renamed, and new ones created with \newcommand{name}[num]{definition} . Note that the curly braces around name are optional.

Basically, this is the idea behind LaTeX, a bunch of TeX commands in macro form, so that the same typesetting and layout can be re-created over and over again.

P.S. Here is a link to a document that lists 5913 symbol commands, as an argument that adding (at least) 5913 entry's to the keyword list for full support is bogus :)
http://www.tex.ac.uk/tex-archive/info/symbols/comprehensive/symbols-a4.pdf

Last edit: Malako 2014-04-08

• Loreia2
2014-04-08

Hi Malako,

This is what you said, as it starts a new search one char after space, but the space is not highlighted (visible with the "underlined" option). Replication of this behavior on a char that is not whitespace (e.g. "{" ) would leave the char "{" un-highlighted. And there is no way to perform a "search start point" on the position of char "{" if it is not white space?

Spaces are easy because they are hardcoded values. Some char is (or is not) a whitespace (space, tab, newline), that is really easy, but it is a different story when another keyword needs to be detected. Things can get complicated really fast :-)

I believe this can be solved by creating special kind of Delimiter that has only a start string, but has no closing string. In this case backslash would indicate start of delimiter sequence, and whitespace or another forward type, like start of another Delimiter, would close this new "semi-delimiter".

So, user would have to define open string, say a backslash,
and then tick check box in options: "semi-delimiter" (close string input box would get grayed out as a consequence of this action)
and then set nesting keywords, in this case "nesting" would define which keyword types serve as closing string. Only forward types would be allowed for "nesting".
Obviously that would make real nesting impossible in semi-delimiters.

And I am not sure if I should keep "escape" and "continue" options for semi-delimiters.

On source code level I would have to see how to do closing of parent Delimiter.

\Delimiter1{Delimiter2}


In this case backslash starts Delimiter1, open curly brace starts a nested Delimiter2, and closing curly brace closes both Delimiter1 and Delimiter2. This logic would require less code changes.

Another option would be to close Delimiter1 right before open curly brace. But that would require bigger code refactoring because current implementation expects close string unconditionally.

And what happens if users want to have spaces in Delimiter1?
I would have to add another check box in "nesting": Whitespace
Support for Whitespace option, would automatically require support for "continue" option, so multiline semi-delimiters would be supported. I guess than escaping makes sense too. That answers my own question few paragraphs back.

I am bothered by lack of nesting (I mean real nesting) ability. I need to work it in somehow. GUI would have to support both "nesting" and "closing" keyword types.

This is just my first take on the problem, I really need to spend few hours designing this feature, both from user and source code perspective.

Anyway, thanks for revealing a new keyword type. I was not aware of this semi-delimiter concept. I think it will be a great addition to UDL 3 in case I manage to squeeze it in.

BR,
Loreia

• Malako
2014-04-09

Hello Loreia,

Anyway, thanks for revealing a new keyword type. I was not aware of this semi-delimiter concept. I think it will be a great addition to UDL 3 in case I manage to squeeze it in.

Glad to help :) Love using and improving open source software.

And what happens if users want to have spaces in Delimiter1?

As far as LaTeX goes, spaces in delimiters (keywords starting with a "\") are forbidden, as whitespace ends a command keyword. but, it would be nice to have the option, possibly for other languages.

Having said that, the second option, closing the Delimiter before the curly brace would be best, because the curly braces (or other braces) can be highlighted a different colour than the keywords, and be "matched" with their closing brace. Handy because some commands take lots of arguments (and or options), which are usually spread across multiple lines:
 \SomeRandomCommand{ argument1, argument2, ... argumentN } 

Thanks for taking the time to look at this issue. If you have any questions, feel free to contact me. Have fun designing and coding :)

Cheers,
Malako