XNEdit Activity
Modernized fork of NEdit, with unicode support and AA text rendering
Brought to you by:
pyrphoros
Activity for XNEdit
-
Pyrphoros committed [490317] on Code
replace usage of ParseXftColor with AllocXftColor2
-
adjust lib flags order in generic makefile
-
SweetTyler posted a comment on ticket #50
Thank you for the quick fix.
-
Compilation error
-
Thanks for the info. The issue is fixed now.
-
fix compilation error when building with -DREPLACE_SCOPE
-
The error has nothing to do with my Makefile. As soon as I add "-DREPLACE_SCOPE" to the original Makefile, the error appears.
-
Here is my Makefile.linux: # $Id: Makefile.linux,v 1.14 2006/10/26 02:20:16 tringali Exp $ CC = gcc AR = gcc-ar # For editres, add -DEDITRES to CFLAGS and -lXmu to LIBS # If using a Motif 2.1 compatible library (LessTif, OM) add # a '-lXp' in front of the -lXext in LIBS. You also drop the # -lXpm from that list. # Ensure that the Motif/LessTif headers and libs are found! # e.g. you may have to add something like # -I/usr/lesstif/include to CFLAGS and # -L/usr/lesstif/lib to LIBS # # To evaluate an...
-
Compilation error
-
fix compilation in C23 mode
-
My system is Fedora 43. Xnedit source code is the latest version downloaded from GitHub.
-
Here is the snapshot.
-
unexpected highlighting/selection
-
fix buffer overflow when inserting large text in the XNETextField
-
fix redisplay of text widget edges after changing colors
-
encoding at Save As
-
Then please close this report.
-
Thank you. The compiler is gcc (GCC) 15.2.1 20260123 on Fedora 43.
-
enable Right Margin
-
fix redraw of textwidget edges after resize if right margin is enabled
-
I think both warnings are not an issue, especially the first one. Which compiler version is this?
-
fix misleading types in XmStringTable allocations
-
The correct order is: LIBS = $(LD_OPT_FLAGS) -lXm -lXrender -lm -lpthread $(shell pkg-config --libs $(PKG_DEPS))
-
The tile is wrong. I don't know how I made the mistake. for your reference, the following is the Makefile.linux I tried with: CC ?= gcc AR ?= gcc-ar PKG_DEPS = x11 xt xft fontconfig C_OPT_FLAGS ?= -O3 -flto -fno-semantic-interposition C_ARCH_FLAGS ?= -march=native C_VIS_FLAGS ?= -fvisibility=hidden LD_OPT_FLAGS ?= -flto CFLAGS = $(C_OPT_FLAGS) $(C_ARCH_FLAGS) $(C_VIS_FLAGS) \ -std=gnu99 -DREPLACE_SCOPE -DUSE_LPR_PRINT_CMD \ $(shell pkg-config --cflags $(PKG_DEPS)) ARFLAGS = -urs LIBS = $(LD_OPT_FLAGS)...
-
encoding at Save As
-
make grid header arrows etched out by default
-
add Microline Grid arrowEtchedIn resource
-
fix shading of sort direction arrow in Fsb in detail view
-
fix incorrect type in textfield renderTable XtResource definition
-
Yes this is possible and makes a lot of sense. I will try to implement this.
-
Phil Stracchino posted a comment on discussion General Discussion
That could probably best be achieved by a naïve file-size check before even TRYING to load the file. "Directory listing says this file is 2.8GB in size. It is too large to be loaded into xnedit."
-
use filter when opening files with open-selected
-
use dummy stdin/out/err in background mode
-
I think it would be better to have a warning (like the encoding warning) if the file is not completely loaded.
-
Thank both of you for your comments. it's true that I rarely need to deal with a text file with such large size.
-
Honestly it doesn't seem like a limitation one would hit very often, but I suppose the ticket indicates the use case does actually exist. My short-term workaround would be to split the log file into managable-size chunks using a cli tool. 'split -l 10000000 $FILE' seems a good first step.
-
Honestly it doesn't seem like a limitation one would hit very often, but I suppose the ticket indicates the use case does actually exist. My short-term workaround would be to split the log file into managable-size chunks using a cli tool. 'split -l 10000000 <file>' seems a good first step.</file>
-
Yes, xnedit uses signed 32 bit integers internally and can only open files up to 2gb. This is something I'm more or less working on, but there is no easy fix
-
Is there a file size limitation for xnedit? I have a log file that is 4,374,493,362 bytes in size (50,062,082 lines). When I try to open it with xnedit, it does not load the entire file. The status bar eventually shows “byte 79,522,952 of 79,526,066”, indicating that only part of the file (only 921,610 lines) was loaded.
-
add right margin colors to default color profiles
-
add dialog for changing the right margin
-
implement menu items for setting showRightMargin
-
add UI for setting the right margin colors
-
enable text bg2 drawing beyond right margin
-
implement functions for changing right margin in the text widget
-
rename preference rborderColor to rightMarginColor
-
implement preferences for right margin
-
draw vertical line in the text widget after 80 characters
-
GitHub committed [3e7445] on Code
switch from ubuntu-latest to ubuntu-22.04 in github action (#184)
-
add link to sourcehut
-
update libs in macos build-dependencies script
-
fix fix checkAutoShowInsertPos/callCursorMovementCBs order when moving the cursor
-
On 12/14/25 14:46, Pyrphoros wrote: No, there is no mailing list. Would a rss/atom feed just for releases help? That would be something I could create. That would be helpful, yes. I just installed an RSS reader extension in my browser. -- Phil Stracchino Fenian House Publishing phils@caerllewys.net phil@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
-
No, there is no mailing list. Would a rss/atom feed just for releases help? That would be something I could create.
-
On 12/14/25 13:32, SweetTyler wrote: Thank you. Everything is working as expected now. About file encoding https://sourceforge.net/p/xnedit/discussion/ general/thread/ed86aa6386/?limit=25#6e0a Quickie question: I maintain an ebuild for xnedit in my unofficial Gentoo overlay. Is there an -announce list I can join to get timely notification of new upstream releases? I didn't realize until today that I was a minor version behind. (It's up-to-date now.) -- Phil Stracchino Fenian House Publishing phils@caerllewys.net...
-
Thank you. Everything is working as expected now.
-
It is a bug. The newest commit should fix this issue.
-
fix DetectEncoding misses some utf8 encoding errors
-
I have an attached file that is encoded in ISO-8859-1, as confirmed by the Linux file command. However, when I open it with xnedit, xnedit always reports: “4 non-convertible characters skipped …” If I manually select ISO8859-1 and click the Reload button, the file loads correctly. I also tried changing the following settings in nedit.rc: nedit.editorConfig: False nedit.defaultCharset: ISO8859-1 nedit.fallbackCharset: ISO8859-1 but they did not help—xnedit still reports the same error every time....
-
Paste using the middle mouse button
-
Thank you! Yes! I confirm it works now.
-
It should work now. I think it only affected Gnome Wayland or other Wayland based desktops.
-
fix textfield primary selection insertion on some platforms
-
The terminal emulator is the default in Fedora 43 Gnome, Ptyxis.
-
it's Fedora 43 Gnome running on VMware workstaion pro.
-
fix build when using the DISABLE_XNE_TEXTFIELD option
-
Which desktop environment and terminal emulator are you using?
-
Paste using the middle mouse button
-
fix C/C++ character constant highlighting pattern
-
Fedora 42/43: imDefLkup.c,399: The key event is already unfabricated.
-
No problem - just report what I saw. Thank you for your reply and please close it.
-
I have seen this before, not only in xnedit, but also in other applications. The message itself is from xlib. I was not able to pin this to a specific line in the xnedit source, it happens somewhere in the event loop (XtAppMainLoop).
-
fix missing colorDialog initialization
-
Fedora 42/43: imDefLkup.c,399: The key event is already unfabricated.
-
disable buttons when no item in the color profile list is selected
-
add dialog for managing the color profile list
-
GitHub committed [7bfa3c] on Code
CI build AppImage on push (#179)
-
treat windows without _NET_WM_DESKTOP as on the current desktop
-
parent process with bgrun option waits until the first window is mapped
-
find /replace caused xnedit crash
-
Thank you for the fix! Xnedit works as expected now.
-
Thanks, I was able to reproduce the bug. The newest commit should fix this issue.
-
fix potential crash when deleting text in case highlight cursor line is enabled
-
fix statline update when deleting text in splitpane mode
-
I just found I don't have to modify "nedit.rc" - "highlightCursorLine" setting can be enabled/disabled in "Preferences" menu.
-
It appears that enabling the nedit.highlightCursorLine: True setting may be responsible for the crash. Below are the steps I followed to reproduce the issue: Downloaded the latest version of xnedit from GitHub and compiled it from source. Renamed the nedit.rc file in the .xnedit directory to back it up. Launched the compiled xnedit executable and saved preferences via Preferences → Save Defaults.... Closed xnedit. Launched xnedit again using the command: xnedit aa where aa is a large text file (mentioned...
-
It appears that enabling the nedit.highlightCursorLine: True setting may be responsible for a crash. Below are the steps I followed to reproduce the issue: Downloaded the latest version of xnedit from GitHub and compiled it from source. Renamed the nedit.rc file in the .xnedit directory to back it up. Launched the compiled xnedit executable and saved preferences via Preferences → Save Defaults.... Closed xnedit. Launched xnedit again using the command: xnedit aa where aa is a large text file (mentioned...
-
I used the default "Find/Replace" dialog layout.
-
Yes, "Segmentation fault" happened after the third "Replace All in:" "Window".
-
Does this happen after the third "Replace All" or did you try a fourth replace?
-
Let me know if you need me try anything else.
-
Here is the output: BufReplace(0x7fdc35bf5010, 0, 14088466, 0x3aa0fd30) BufReplace(0x7fdc35bf5010, 0, 12955507, 0x3aa0fd30) BufReplace(0x7fdc35bf5010, 3, 11810191, 0x3aa0fd30) Segmentation fault (core dumped) where I downloaded the latest source code, and replaced textBuf.c with the attached one. I didn't modified any setting in the makefile.
-
Can you replace source/textBuf.c with the attached file? It prints some debug infos on stdout. Also you can remove the -fsanitize=address option.
-
Please don't hesitate to let me know if you need any further information or tests.
-
revert unnecessary change in scanCTagsLine
-
update contributors list
-
fix parse error when reading ctags files that contain lines ending with / or ?
-
improve file sorting
-
xxxxxxx@fedora:~/workspace/temp$ export ASAN_OPTIONS=verbosity=1:malloc_context_size=30 xxxxxxx@fedora:~/workspace/temp$ ~/Downloads/xnedit-master/source/xnedit aa ==5342==AddressSanitizer: failed to intercept 'strcmp' ==5342==AddressSanitizer: failed to intercept 'strcasecmp' ==5342==Registered root region at 0x7fe227600f40 of size 64 ==5342==Registered root region at 0x7fe2272007a0 of size 32 ==5342==Unregistered root region at 0x7fe227600f40 of size 64 ==5342==Unregistered root region at 0x7fe2272007a0...
1 >
