UVviewsoft forums

Hello,
I am looking for a good editor with specific features.
Can you provide some info about support for those features in CudaText editor?

I've posted a request on Software recommendation SE:
https://softwarerecs.stackexchange.com/q/52682/40949

As I see there is support for e.g. Python scripting. But I am unsure
about other features. So can you comment on these points please.

Here is the text, in case the link dont work:

--------------

### List of required features:

1. The editor should be **language-agnostic**, and language-aware features should be customizable
and importable/exportable via external definitions, transparent to the user if possible.
So for example if I create my custom language, I can create custom lexer and highlighting schemes,
etc. Ability to use or create advanced features for any language (e.g. grammar checkers,
variable/function lists, etc.) obviously would be great.

2. **Scriptable/programmable**: must have support for scripting (ideally with Python) with access
to the text, caret, other internal editor features, so I can program editing features and bind them
to shortcuts. Ideally with possibility to use GUI of the editor (e.g. show some list in a side-panel etc.).

3. Highly customizable syntax highlighting features. I.e. not only basic things, but with ability to define
the styling for *individual characters and sequences* (e.g. regex matching) and so that it
can be set to different **font**, **size** and color for the match. (please note the emphasis). [*]

4. **Lines** can be of **different height**. For example if I set the styler to 5pt font, and it matches
the whole line - the line will have 50% height compared to the height lines with 10pt size.

5. Ideally with support for line **indents** (tree-like editing). Indentation level (nesting level) must
be accessible via scripting (e.g. to generate runnable Python code).
(*Note*: please don't confuse indentation with inserting space or tabs character!
Indents here = non-editable horizontal space).


[*] Important note on the requirement no.3:
Even though some editors have extra rich formatting options, the common problem is that those
are only applicable to the so-called 'tokens' (e.g. keywords, functions). So please note, that it is not enough.

To better understand what I mean, here are concrete examples what I need to do:

- set the font/size for cyrillic letters inside strings only;
- set the font/size for numbers inside identifiers only;
- set the font/size for the hyphen character which is surrounded with spaces.


### Further criteria (less important):

- it should be fast and responsive, without much bloat;
- it would be great if it is actively developed so at least there is a chance that some useful features will be added;
- advanced scripting API for interactive features, for example ability to read mouse coordinates and detect the character index or line number under the mouse cursor;
- adequate tabulation support (indent-aware);
- no intrusive annoying features like something blinking, animations, switching focus, hogging the CPU&HDD etc.

I have started testing the Cudatext editor and ran into problem - I cannot
set any font, only monospaced fonts like Consolas or Courier New worked
Is it limitation or I am doing something wrong?
If it is by design so - why and do you plan to support normal fonts?

I can set non monospaced font via "Options - Fonts", e.g. Arial, so no limitation in app. (but font looks badly in the text.)

1. The editor should be **language-agnostic**
Checked

2. **Scriptable/programmable**: must have support for scripting (ideally with Python)
Checked, with Python

3. Highly customizable syntax highlighting

Partly supported, see http://wiki.freepascal.org/CudaText#Lexers_editing
Lexers apply styles to 'tokens'.
Plugins can apply styles to any chars over tokens.
viewtopic.php?f=19&t=2105

Lexers cannot change _font name/size_ though.

4. **Lines** can be of **different height**
Cannot do this (limitation)

5. Ideally with support for line **indents** (tree-like editing). Indentation level (nesting level) must
be accessible via scripting (e.g. to generate runnable Python code).

Indents are just space text, supported.
Scripts can read/write all text, and Python lexer makes folding from indents.
Indents are editable in app.

- it should be fast and responsive
Checked
- it would be great if it is actively developed
Checked
- advanced scripting API for interactive features
Checked (for mouse too)
- adequate tabulation support (indent-aware);
?
- no intrusive annoying features
Checked

Alexey, thanks for answers.
Cool, many strong features you have. And I really like
your editor and the GUI looks great.

But what's up with proportional fonts?
It's a big spoiler I must say, any plans to support them?
Without them life is gona be hard.
I quit using gVIM only because of this limitation.

And making stylers with different fonts is also a must-have feauture.

Just saying, I know it's not simple to support it, but in the end
that's what really matters for a user and future development.
If something, you can ask - I understand something about fonts and
programming.

Alexey wrote: - adequate tabulation support (indent-aware);
?

Forget about it, I dream too much
What I want is actually tabstops that I can save alongside with the
code files, and so that when I open files - they are applied again and
I see well formatted code again. But it's not so important , and anyway
that is not possible with current text-only model.

>But what's up with proportional fonts? It's a big spoiler I must say, any plans to support them?

nope, sorry. Problem is this: code is optimized for fact that ASCII chars have the same width. it is used when going over huge (4M) lines. Unicode chars can have any width, e.g. 180%, see opt "unicode_proportional".

>And making stylers with different fonts is also a must-have feauture.
it's supported only via options:
font_name_i
font_name_b
font_name_bi
font_size_i
font_size_b
font_size_bi

Alexey wrote:>But what's up with proportional fonts? It's a big spoiler I must say, any plans to support them?
nope, sorry. Problem is this: code is optimized for fact that ASCII chars have the same width. it is used when going over huge (4M) lines. Unicode chars can have any width, e.g. 180%, see opt "unicode_proportional".

Ok, I see - so you make use of monospaced to optimize something
Though I can't see what it has to do with the filesize -
anyway only the visible part of text should be processed.

Anyway, it's ok, was just an advise to make the editor even better.