[QUESTION] improve how xnedit looks

[Veraellyunjie]

It is highly subjective topic and a matter of preference, of course.

I understand Motif is old and carries the aesthetics of that era.

Personally, I can't stand that era look, I find it ugly and being an eyesore.
Which puts me off xnedit despite all its merits.
Can something be done?
I tried to convince myself that I use software not for its looks but for its capabilities, speed and other technical factors,
yet it doesn't work for me. I can't be fixed.
Can xnedit be "fixed"?
Whether in xnedit distribution or in local user configuration?
Not asking for - IMHO best - Windows Vista look.
Perhaps at least plain flat look would be OK,
where bars, menus, buttons, checkboxes etc. don't try to look 3D.

Funny enough, lite and lite-xl editors manage to look nice without even using a GUI toolkit (they use SDL)

Thank you for all your hard work.

[unixwork]

That is actually a very good question.

The short answer is, it can be fixed to some degree. With Motif, all colors and border thickness can be adjusted. The classic Motif 3D look is just a border with a top color and a bottom shadow color. You can set the top shadow color and the bottom shadow color to the same value and have a non-3D border. You could also set the border thickness to 0 for a flat look.

Some aspects are not as easy (or are impossible) to adjust, for example the triangle in the scrollbar or the tabs.

All these adjustments can be done via X resources. If you want to try xnedit with a flatter look, I have attached a low efford X resource file with 0 borders. You can load it with

xrdb -merge flat.txt

flat.txt

In general I agree that the default look is not great, but I think it can be vastly improved by some adjustments. I have put the X resources, that I personally use, in the repository in the file resources/xresources/light. It has lighter colors and the 3D look is more subtle.

I can fully understand, that these days not many people like how Motif applications look, however I also don't know how many people like xnedit, because of it's old school look and feel. At some point in the future, some modernisations are required, but switching to another toolkit like GTK would also have some downsides, like higher memory and CPU usage and slower startup time. This is something where I would like a lot of user input before making any big decision.

Btw, I'm curious, why do you want to use xnedit if you don't like Motif 😀

[unixwork]

This article compares the startup time of text editors, and xnedit was by far the fasted. I don't know if it's because of Motif or other reasons.

But as you said, performance of GTK and Qt is fine, and once running the rendering is probably faster than Motif.

[promindsd]

I second @eteran on this and his efforts in porting Nedit to Qt certainly is a very good job, certainly useful in a modern system in case you do not want to have motif in your computer or is not available. I tried it and I like it, but - like I said - it is because I love NEdit and its immediate and very functional purpose.
Furthermore, I guess we all here love NEdit and know very well its huge potentials as a text editor, after all, it comes from an era where text editors were a very huge part of any operating systems, not to mention my beloved Unix, and the choices were many, although not all of them being good.
I would certainly appreciate the development of both XNedit and NEdit-ng to focus on functionality and tools intended for this very specific purpose. For all those who want or prefer a different basic look than Motif (which is still alive and kicking, no matter time goes by and there are a lot more toolkits/frameworks around) can certainly be happy with other text editors and, as opposed to 30 years ago, there is now a huge availability of them and with very good functionality, either using GTK or Qt or "you mention that framework/toolkit".
XNedit, moreover, led NEdit to a great step forward with the implementation of UTF-8 and all the related support for different encodings, which is something - at least for me - very appreciated and certainly making NEdit compete with other modern text editors and with no fear. In case @unixwork would have focused on porting to other GUI frameworks, I am sure he would have still been so far from the current result in terms of new functionalities and support for modern encodings and fonts.
Like I already said, one of the things I appreciate about NEdit is its straight and "lean" look: just a menu on the top and a big editing window. In a sense, this is the approach I have always loved in my "computer career", which is mainly based on Unix philosophy: you have many tools, either simple or complex, each one specialized for one job and the possibility to connect them all in a straight and functional way in order to exactly get your job done. Finally, it is the same idea which makes me love TeX and LaTeX for typesetting any document: when I write a text, I want to focus on the "essence of that job", that is writing. As for the formatting and to see how the final output looks like while I am typing, it is not something nor useful or essential to the very creation of the process. It is just TeX's job, which was excellently created by Donald J. Knuth for this purpose! (And which can be wonderfully edited with any text editor, like NEdit, of course! :-) )

[unixwork]

The best short term solution is probably rewriting some Motif widgets. I have actually already replaced most textfields with my own textfield widget, that looks identical, but has better unicode support. Rewriting other widgets like buttons would be much easier. This could also be made optional, so users could choose what they prefer.

In general I am cautious with big changes, because I think the userbase is probably more on the conversative side. Long before xnedit there was already a patch for Unicode and XFT text rendering but somehow people disliked it. Therefore, my approach is to avoid major changes or to provide options to disable them.

[Veraellyunjie]

The best short term solution is probably rewriting some Motif widgets

I appreciate the idea and how balanced your approach is.

In general I am cautious with big changes, because I think the userbase is probably more on the conversative side. Long before xnedit there was already a patch for Unicode and XFT text rendering but somehow people disliked it. Therefore, my approach is to avoid major changes or to provide options to disable them.

Given that, and since you have already done certain replacements and maybe there will be more,
what is your stance on suckless-like patchable sources?
The approach is that the user is a programmer himself, so he edits source to his liking and then recompiles.
I feel it has something in common with what I get from this discussion:

• keep original program in its canonical shape
• make changes unobtrusive
• simplify architecture by not devising machinery that handles configuration.
  Xnedit has already configuration machinery, but that is legacy so apply rule of canonical shape.
  Regarding newer additions/modifications, those could be source patches without forcing them onto the end users and without introducing them into the main configuration system.

one of the things I appreciate about NEdit is its straight and "lean" look: just a menu on the top and a big editing window

Agree.

Here by "look" you probably mean "layout", whereas I mean "unsightly..attractive".

Speaking layout there are aspects that go against being straight and "lean":

1. when you open any Help topic, you get a window with 8 buttons over two rows at the bottom. Those buttons

• Occupy two rows while 8 buttons could easily fit on one
• Gaps/margins/paddings/whatever between buttons are so large you could fit 3rd row in the same vertical space would gaps be 0.

2. Detach --- row-button in menus is at the top of the menu, so you need to move your mouse farther than without the detach row-button or with it at the bottom.
3. There is a dead line of 1px at the very top of the window, so you can't press any menu button with your mouse by sliding along the top of your screen. You need to make additional top-down movement. This applies when your window manager doesn't draw the title bar or other borders.
4. Etc

[unixwork]

what is your stance on suckless-like patchable sources?

I don't think many people like to patch source code. Most linux users are absolutely happy with getting binaries from their package manager.

And adding new features and "forcing" them onto the end users is usually fine, as long as it doesn't break stuff. Usually with bigger changes, I guard the code with #ifdef so people could enable/disable it. At some point I enable it by default.

[yannnnnnnnnnnnnnnn]

Just a simple question
Why not merging the dev of xnedit and nedit-ng
It will help to speed up all improvement
And why not using tchat GPT for reviewing the bug

[eteran]

Yeah, I'm using Qt's Unicode support already in a LOT of places. Just not the main text area code. So i could definitely leverage some of that more for sure.

For me, the main hold up is I want to make the regex engine fully Unicode aware.

Beyond that I think it would actually be pretty easy in the big picture (if we ignore things like RTL text ...).

Out of curiosity, have you documented all the new features? I may be inspired by your work a bit 😉.

[unixwork]

I have not touched the regex engine that much and no one complained yet 😀. For me the Unicode support is more of an iterative process.

But I'm wondering, is it actually worth keeping the old regex engine? I don't think people have tons of nedit regex patterns lying around, so the only thing that really needs to be rewritten are the language highlighting patterns. Maybe that is easier. Or implement an compatibility mode, where old syntax highlighting patterns use the old regex engine, but everything else uses the newer regex.

XNEdit's new features (and other changes) are documented in the changelog file. Some new features are also documented in the help text. A quick summary:

Text Widget:

• Highlight Cursor Line
• Indent Rainbow
• Multicursor Mode
• ANSI Escape Sequence Rendering

Other relevant features:

• Editorconfig (I stole the idea from a nedit-ng dicsussions)
• IO filters (instead of loading a file directly, you can configure filter programs like gzip)

And my personally favourite feature, that I copied from gedit: when you close xnedit you have only one "Save Files" dialog, where you can select which files should be saved (or not saved) in a single dialog.

[eteran]

@unixwork So I looked into replacing the Regex engine with just using the one from Qt a while ago , where I would just re-write the user provided regex's from NEdit's format to the Qt format since they're actually almost identical. I think the notation for word boundaries is the only notable difference that I can recall.

Here's the main issue:

NEdit does something clever!

(I'm going to over-explain here, since there's more than just you and me in the discussion so other people can follow along). Let's say you have a language that has three simple highlighting rules:

type: (int|char|float)
string: ".+"
identifier: [A-Za-z0-9]+

What NEdit does is compile these regex's into a sort of "meta-regex" which look like this:

(((int|char|float))|(".+")|([A-Za-z0-9]+))

And then when it's trying to determine if there's a highlight match, it runs only the single meta-regex. The regex engine then has a feature that I've never seen implemented in any other regex engine. So, when we have a match, we can ask it "what was the index of the top-level group that matched".

So int would match top level group 1, "hello" would match top level group 2, etc...

That group is then mapped to the appropriate style and highlighting does its thing. It was very clever of the original NEdit folks since it allows running the regex engine once regardless of how many styles are there.

I can emulate this feature, but it would result in replacing an O(1) feature with an O(n) feature, all while adding some more complexity. Which is... not great.

As for your features, thanks for the list, I kinda love them ;-). I may do my own implementations of some of them too!

I was originally very focused on making nedit-ng "NEdit 6.0" and wanting it to avoid too much that was new. But At this point, I've tagged 2025.1 (after too long of a pause), I think it's time to introduce a little bit more so long as it's not breaking from the spirit of NEdit too much.

[eteran]

Oh and I haven't looked at XNedit's sources in a while, but IIRC. The change from ASCII to UTF-8 internal representation likely means that a bunch of indexing operations in the text rendering have to be replaces with some iterative approaches. Because buf[n] is no longer guaranteed to be the nth character since UTF-8 is a variable width encoding. Is that correct, or is there a particularly clever way to do this?

I don't think that's a huge cost regardless because we already iteratively break things into lines by searching for newline chars, so at worst the indexing already starts and ends withing a given line which has known offsets within the buffer.

[unixwork]

Correct, but I think there is rarely a case where you want the nth character in a line or something like that. I most cases there was already an iteration, because of the buffer expansion (tabs to spaces or ascii control codes).