XNEdit Activity
Modernized fork of NEdit, with unicode support and AA text rendering
Brought to you by:
pyrphoros
Activity for XNEdit
-
SweetTyler posted a comment on ticket #48
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
-
Pyrphoros committed [225a70] on Code
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...
-
Thanks, can you set the this environment variable and try again? export ASAN_OPTIONS=verbosity=1:malloc_context_size=30
-
OK. with many errors I have the executable, run it and load that large text file I have: ================================================================= ==4985==ERROR: AddressSanitizer: heap-use-after-free on address 0x7be29849d0da at pc 0x000000503959 bp 0x7ffdc816a490 sp 0x7ffdc816a488 READ of size 1 at 0x7be29849d0da thread T0 #0 0x000000503958 in BufStartOfLine (/home/xxxxxxx/Downloads/xnedit-master/source/xnedit+0x503958) (BuildId: 657c97aa2c67d48f45d92f272fe9fb8e5125a254) #1 0x0000004f637f...
-
Hi, I added "-fsanitize=address" to CLAGS in makefiles/Makefile.linux: CFLAGS=$(C_OPT_FLAGS) -std=gnu99 -fsanitize=address -I/usr/X11R6/include -I/usr/include/X11 -DUSE_LPR_PRINT_CMD $(shell pkg-config --cflags xft fontconfig) However, I cannot compile the source code successfully- there are many errors like: Indirect leak of 448 byte(s) in 14 object(s) allocated from: ........
-
Can you add -fsanitize=address to the CFLAGS/LDFLAGS and test again?
-
fix incorrect initial window size, when the statsline is enabled by default
-
always save backlightCharTypes setting
-
Thanks for the reply. Please let me know if you need any more info.
-
No it didn't get lost, but I'm not sure when I have time for it. Maybe in a few weeks. I looked a bit into this, but I wasn't able to reproduce it yet. The error is probably not in searchBackward (textBuf.c:2830), it looks like the internal text buffer is in a corrupt state at this point.
-
Just wondering if you’ve had a chance to try reproducing it with the text file I provided, or if there’s anything else I can share to help. Totally understand if you're busy—just wanted to make sure it didn’t get lost in the shuffle.
-
Merge branch 'master' of https://github.com/unixwork/xnedit
-
GitHub committed [c9de54] on Code
Adds support to both page and zoom using the mouse scroll wheel — resolves #170 (#171)
-
update contributors list
-
add light/dark color profiles
-
I recompiled the source with "-g" and ran xnedit under "gdb" and I got Program received signal SIGSEGV, Segmentation fault. 0x00000000004929a8 in searchBackward (buf=0x9fbfe0, startPos=11822547, searchChar=10 '\n', foundPos=0x7fffffff889c) at textBuf.c:2830 2830 if (buf->buf[pos + gapLen] == searchChar) {
-
this file is not what I used yesterday - the size and lines are doubled. BTW when I compiled the source code I use the flag "-DREPLACE_SCOPE".
-
Please try this. I could repeat it even after a system reboot. if you still cannot reproduce it, just stop.
-
Please try this. I could repeat it even after a system reboot. if you still cannot reproduce it. Just stop.
-
No problem at all, thank you for reporting it in the first place. Please don’t hesitate to reach out again if you encounter any bugs or unexpected behavior.
-
I am very sorry that today I couldn't reproduce the crash either, even with original text file I used yesterday. I could reproduce it yesterday. What I did after submitting the report was just a reboot of my system (Fedora 42 on VMWare workstation). So please discard this bug report and sorry again for wasting your time.
-
Never mind, I can actually edit your post and see the correct format. However I still can't reproduce the crash.
-
Never mind, I can actually edit your post and see the correct format. 0 88 -84.986877 -39.104391 86.111804 230.788086 However I still can't reproduce the crash.
-
So far I had no luck reproducing this issue. Maybe you can attach a (partial) txt file with the correct formating.
1 >