JOE 4.8 Released!
Fixing this here: https://github.com/joe-editor/joe/pull/106
Fixing this here: https://github.com/joe-editor/joe/pull/106
Packaged for Debian stable & Devuan stable here. (codeberg.org) – amd64 only. Likely to work on Ubunu 25.10 and 26.04 and other reasonably recent Debian-likes too: it needs only libc6 2.34 or later and libtinfo6.
Packaged for Debian stable & Devuan stable here. (codeberg.org) Likely to work on Ubunu 25.10 and 26.04 and other reasonably recent Debian-likes too: it needs only libc6 2.34 or later and libtinfo6.
Packaged for Debian stable & Devuan stable here. (codeberg.org) Likely to work on Ubunu 25.10 and 26.04 and other reasonably recent Debian-likes too: it needs only libc6 2.34 or later and libtinfo6.
Build failure due to implicit declaration of functions
joe ignores fractional part of numeric literals in some locales
JOE 4.7 Released!
I meant: see bug #308.
On the alternate screen, Konsole does send Shift+Up/Down keyboard events. See feature request #33 that I've just filed.
Consider switching to the alternate screen
Konsole (KDE) and mintty (Cygwin) do not work correctly. Shift-cursor keys cause them to scrollback line at a time. There is an option to turn this off, but then you lose Shift-PgUP and Shift-PgDn scrollback, which I think is bad. Rxvt has non-standard keys, but they are workable. PuTTY's defaults are bad, but at least it now has xterm mode. TeraTerm does nothing with modified cursor keys. Anyway, for 4.7 I've added the standard keys, but also immediately override them with JOE's old bindings for...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698077 is related. sh.jsf just doesn't handle $(…), $((…)) etc. well, and there's at least one off-by-one colouring bug which doesn't show up with default colours. The other fun bit there is that the 'here' doc which would otherwise be introduced by that<< is handled correctly… There are related problems too with [ … ] and [[…]].
A key or two for copy to clipboard (or X primary selection) would definitely be useful. https://github.com/joe-editor/joe/issues/73
nextword / prevword are not symmetrical
Highlighting next / prev word skips some characters
nextword / prevword are not symmetrical
Turned out to be our issue. This is fixed in main now https://github.com/joe-editor/joe
This is fixed in main now https://github.com/joe-editor/joe
Funny you mention this https://github.com/joe-editor/joe/issues/37 because I hit this all the time on my Mac. I think it is an upstream issue and I might bother them about it. You may also be interested in the workaround for the ^I and ^M issues: https://github.com/joe-editor/joe/issues/36
Bracketed paste in ghostty not preserving newlines
Put it on F5? retype ^[ [ 1 5 ~ Refresh screen
I've removed %t from other rc files. I think xfce-terminal has also been fixed so that the notification only happens if the screen contents actually changes, a refresh with same text no longer triggers it.
I've included this fix in JOE github repo. But should I be taking anything else from https://github.com/cmur2/joe-syntax ?
OK, this is now fixed in the github repo. I ended up using your code to find the locale decimal point character. So now: Calculator always expects '.' for decimal point on input. It ignores underscores on input. It no longer prints underscores on output, it uses locale characters instead. Calculator prints numbers in the locale format on the status line. "ins" inserts numbers with '.' for decimal point. This is almost always what you want. New command "insf" inserts numbers formatted in the locale....
File position reverted by other joe instances
Joe, you are incredible... you keep disappearing for ~10 years and then come back and do another batch of work. I can hardly wait for an improved 4.7 (or 5.0?) release :) I personally hate bash's shared command line idea, and would similarly hate it in joe. I expect the Up arrow to bring up the previous entries of that joe instance. Shared history just isn't a good match for my workflow. So my bugfixing request is simply: When joe writes .joe_state, it should read the most recent state of things...
Joe, you are incredible... you keep disappearing for ~10 years and then come back and do another batch of work. I can hardly wait for an improved 4.7 (or 5.0?) release :) I personally hate bash's shared command line idea, and would similarly hate it in joe. I expect the Up arrow to bring up the previous entries of that joe instance. Shared history just isn't a good match for my workflow. So my bugfixing request is simply: When joe writes .joe_states, it should read the most recent state of things...
Another bump :) PuTTY has added a config option (apparently in v0.77 in 2022) "Shift/Ctrl/Alt with the arrow keys", with the possible value of "xterm-style bitmap". It's not the default, but it can easily be enabled. With this, I really don't think PuTTY (or anything else) should hold back joe from switching to the standard modifiers: Ctrl jumps in larger steps, Shift highlights, Ctrl+Shift does both at the same time.
Joe, you are incredible... you keep disappearing for ~10 years and then come back and do another batch of work. I can hardly wait for an improved 4.7 (or 5.0?) release :) I personally hate bash's shared command line idea, and would similarly hate it in joe. I expect the Up arrow to bring up the previous entries of that joe instance, it just isn't a good match for my workflow. So my bugfixing request is simply: When joe writes .joe_states, it should read the most recent state of things and only updates...
I can confirm this compiles properly on my macbook with Sequoia 15.7.4.
Right now there is an in-core database of file positions which is loaded at startup and then updated whenever someone closes a window. So one way to fix this problem is to update the file position part of the state file whenever someone closes a window- basically eliminate the in-core clone of the file positions and have only one global copy of this information. Likewise, when you open a file, the editor would get the most recent file position instead of what it was when the editor was invoked. I'm...
This is now fixed in the github repo.
This should now be fixed in the github repo. Need someone with MAC OS to verify it.
See https://github.com/joe-editor/joe/pull/29
https://github.com/joe-editor/joe/pull/34 fixes this and related problems (back, forward and other extra buttons are also being mishandled). I do agree that horizontal scrolling via the mouse would be useful to have implemented.
https://github.com/joe-editor/joe/pull/34 fixes this and related problems (back, forward and other extra buttons are also being mishandled).
Select in JOE the line(s) you want to comment out by pressing Ctrl + down/up arrow key. This will highlight the line(s). Press Ctrl+K then C (keep Ctrl pressed). The comment sign (#) should appear at the front of each highlighted line. To uncomment, follow the same procedure, with the key combinations Ctrl+K then U (keep Ctrl pressed)!
Can you show how with sed/awk please!
This reply is somewhat late as well. :) I tried your macro using joe' instead ofjmacs'. Your macro seems to only highlight a block, but I may not be using the macro correctly. Would you explain how you use the macro - step-by-step - please. TIA ....
Add a commands "fprev" : reversely repeat previous search
File position reverted by other joe instances
Sorry, double post due to network error.
File position reverted by other joe instances
File position reverted by other joe instances
I tried a installation for Venus what is the Victron Energy Linux System running on ARM Hardware. Configure and make install went through without complaints and jstar starts as normal. Terminal seems not recognizing line wraps cr/lf an there seems other ASCII incompability. Attached is a screendump on what I see. Any idea what went wrong and where to configure?
Ah, OK, read too fast. Also, reproducing the bug didn't work for me initially (in Ubuntu 22.04)- I had to run "locale-gen de_DE.UTF-8" first (then it shows up in "locale -k LC_NUMERIC"). Anyway, I see some solutions involving uselocale, but unfortunately it's not universally available. For the number format in the edit buffer, we probably need Ctrl-T options. What often happens with me is that inserted numbers with underscores are not often acceptable. Also, comma is bad news because it's often a...
I'm trying to figure out if using "," in place of "." is a good idea even in locales where that's the norm. I don't think so. This is why my patch does the opposite and allows to use "." as decimal point even in locales where "," is normally the decimal point. The problem is that without the patch, the "." does not work as a decimal point. In order to demonstrate what I mean, invoke joe as follows: $ echo 3.13 0.01 | LC_ALL= LC_NUMERIC=de_DE.UTF-8 joe - Once joe has launched, press [Alt]+[m] to enter...
I'm trying to figure out if using "," in place of "." is a good idea even in locales where that's the norm. I guess the problem I have with it is that this is not done in programming languages so I'm not sure it's a good idea in JOE's "math". Hmm.. well I just tried it in Libre Office and it does use "," in de_DE.utf-8.
Confirmed. There is a bug in usave.c:saver(). Note the comment: / Last UNDOREC which wasn't modified will be changed * to modified. And because this block is * executed after each 'save', there can't be more * than one record which is not modified * 24 Apr 2001, Marx / What the code should do is set the "changed" flag in all undo records, so if you undo after the save it counts as a change. The assumption in the above comment is wrong- there can be multiple "not modified" points in the undo reco...
Undo history weirdness; ^C drops changes without asking for confirmation
joe ignores fractional part of numeric literals in some locales
Sorry for the very late reply! I don't use emacs, so I am afraid that I won't be able to help you.
nmark,abort has side effects
To get the old behavior, comment this out: https://github.com/joe-editor/joe/blob/main/joe/tw.c#L826C2-L831C3 I know that [@jhallen] was debating removing this in a future (?) version.
Sorry for spamming this unrelated bug but I've been googling for a while already after trying ChatGPT to get the Ctrl-C behavior fixed and the above comment from years ago is the only thing I found. I NEED CTRL-C TO EXIT EVEN WHEN THERE IS A MARK. I just upgraded from Ubuntu Focal to Noble and this behavior change is KILLING ME. I tried changing the definition of ^C to "nmark,abort" but while that works in the main text screen it breaks Ctrl-C for instance in the "Lose changes to this file (y,n,^C)"...
Sorry for spamming this unrelated bug but I've been googling for a while already after trying ChatGPT to get the Ctrl-C behavior fixed and the above comment from years ago is the only thing I found. I NEED CTRL-C TO EXIT EVEN WHEN THERE IS A MARK. I just upgraded from Ubuntu Focal to Noble and this behavior change is KILLING ME. I tried changing the definition of ^C to "nmark,abort" but while that works in the main text screen it breaks Ctrl-C for instance in the "Lose changes to this file (y,n,^C)"...
This patch is missing at least one C99 keyword, restrict. (I think that this one should be handled as a storage keyword.)
What is dumped into DEADJOE is the contents of all buffers that are not marked as saved. This includes the "yank buffer" as well as histories for file prompts, which are implemented as buffers under-the-hood. It should contain the file contents if the file was modified. If joe crashes or is killed but an open file is not in a dirty state, it won't write out the contents. Is that confirmed to be the case here? And, no none of this is necessarily obvious. Those buffers should probably have better names...
DEADJOE does not represent the file in the editor when it's killed
For some time joe's DEADJOE, which used to write out the contents of the file I had in the editor when I, say, lost an ssh connection, no longer does that. Since like Debian 8 or so - whatever joe version that was. Now, it seems to write out a bunch of useless stuff. It says it's stuff that were in in joe, but it appears to be: 1) Unknown users 2) A list of the last 11 files joe was used on 3) A startup log I can find no reference anywhere on what DEADJOE's current behaviour is supposed to be or...
Quick open
+1 for saving and reloading the list of files in buffers. DEADJOE would be cool too.
... (nitpicking) or maybe clear all the bits using Cb &= ~0xC3 and then set the two low ones with Cb |= 3. This is more consistent in the sense that the same bitmask 0xC3 is used throughout the method. Also, I didn't mention it explicitly, but this last paragraph of my previous post explains why "release" events of left scrolling become right scrolling instead, resulting in back-n-forth pairs in some terminals.
Update or drop xterm patch and related code
Cb contains the button number, as encoded in decimal ASCII as the first parameter if the 1006 extension is supported by the terminal, or the first rawy byte minus 32 with the legacy byte-based protocol if 1006 is not supported by the terminal. Cb's value consists of the following bits: - bit 7 (128): button value bit 3 (8) - bit 6 (64): button value bit 2 (4) - bit 5 (32): drag - bit 4 (16): ctrl - bit 3 (8): alt - bit 2 (4): shift - bit 1 (2): button value bit 1 (2) - bit 0 (1): button value bit...
Horizontal mouse scrolling problems and maybe feature req
Horizontal mouse scrolling problems and maybe feature req
Aspell functions leave alternate screen
Build failure due to implicit declaration of functions
Reopening in that case.
This is not yet fixed since #include <util.h> is not imported on mac.
Kbd shortcuts commented as "gnome-terminal" are outdated
Oh, stupid me. I can finally reliably reproduce. The issue happens when I try to extend the selection too much, beyond the end of the file by pressing Shift+Down at least one too many times. Or the same thing at the top of the file, trying to extend upwards. For some reason, my definititon of these macros differs from the one in the default config, which goes something like rtarw,ltarw,begin_marking,rtarw,toggle_marking ^[ [ 1 ; 5 C Mark right Xterm That right-left (or up-down, etc.) dance at the...
See also [#299]
As I've written in email, the last major known issues in the coroutine branch were recently resolved in [758cfc] and [d05cc6].
As I've written in email, the last major known issues in the coroutine branch were recently resolved in [758cfcf] and [d05cc66].
PR #22
Taking into consideration [#346], perhaps coroutine - or really, the Windows branch - is the path forwards.
Please please pleeeease... :)
Let me bump this please. Almost exactly 9 years after reporting this bug, I suspect PuTTY still hasn't changed. The last time I checked (quite a while ago), it was in minimal maintenance mode involving ssh security updates only, nothing about terminal emulation. In the mean time, Windows Terminal has emerged, and with an ssh command also available on Windows, it's an absolutely great, modern replacement for PuTTY, offering many more modern features as well. I'm not asking to remove any feature or...
First block copy/move attempt sometimes fails with "No block"
C99 restriction
C99 formally removed this restriction. GCC hasn't enforced it in a very long time. Until a couple versions ago, MSVC required this but even they have finally updated the C frontend. Twenty-plus years on, I don't think this is much of a concern, unless we see specific build breaks as a result. Closing.
I can't reproduce this now that I've implemented a fix for [#409]. It stands to reason that the change of ifhave && !linums to ifhave could fix this, since it would block a lot of unnecessary line updates. Marking duplicate.
Screen slow to update with line numbers enabled
I can't reproduce this now that I've implemented a fix for #409. It stands to reason that the change of ifhave && !linums to ifhave could fix this, since it would block a lot of unnecessary line updates. Marking duplicate.
joe needs a regression test suite
This has been in JOE for a while now. It does not cover enough quite yet but the framework is there and proven, imo. Closing.
joe-editor.sourceforge.net woefully out of date
This needs to be updated to the new git repo, but the site is currently up-to-date so I'm closing this.
May be related to the issue addressed in patch 126 or Github PR #16
True color derived from terminfo
Fixed in git and Mercurial [6babb2]
Completion at encoding prompt crashes
Completion at encoding prompt crashes