Guenther Brunthaler

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...

joe ignores fractional part of numeric literals in some locales

I would also very interested in an "edge resistance" feature, because I consider it superior to "snapping". In order to fill in the missing information, let me explain how edge resistance works. When a window is dragged using the mouse and its edge comes near to the edge of another window or the screen, there is no magnetic attraction like with "snapping" that makes the dragged window "jump" to touch the other edge. Instead, nothing happens until the dragged edge actually touches the other edge....

I'm not sure of the solution to this yet In the meantime I had an idea about that: Why not adding an option to joe that .joe_state is located relative to $XDG_RUNTIME_DIR rather than to $HOME? If $XDG_RUNTIME_DIR is unset or does not point to a valid directory, $HOME can still be used as a fallback. As a workaround to the problem, I have currently taken the following measures in to avoid the security problem: I create a symlink with a known name (say ~/.volatile) in my $HOME directory which points...

What is this "joe_state" file good for? It stores things such as the last search expression or the current cursor position within the file edited last. And also the contents of the kill ring. If the information is only valid for the current session One problem here is how to define "session". On your local machine it might be pretty obvious. But what if you are being logged into a remote machine with two different shells at the same time? Depending on the point of view this could be interpreted as...

I guess shell history file is a similar security hole But only if one uses passwords directly in the command line, which should be avoided for a different reason: Every other user who runs "ps -af" at the time when the command is executed would see the password as well. Therefore, it is unwise to use passwords directly in the command line at all. And then they won't show up in the shell history either.

I also want to point out that deleting or overwriting the state file cannot be a...

Saving the kill ring in .joe_state is a security risk