The y-position of a character found by asking fontconfig for a matching
font does not take the border pixels into account, resulting in a
slightly misaligned vertical position.
Signed-off-by: Ton van den Heuvel <tonvandenheuvel@gmail.com>
Signed-off-by: Christoph Lohmann <20h@r-36.net>
This fix is needed to use dual-width fonts, which have double-width
glyphs (e.g. CJK unified ideographs).
Signed-off-by: Ryusei Yamaguchi <mandel59@gmail.com>
Signed-off-by: Christoph Lohmann <20h@r-36.net>
Scratch the preceding patch, this one is more correct
(don't forget to 'git am --scissors' ;))
-- >8 --
Also reformat the strings in a saner layout
Signed-off-by: Christoph Lohmann <20h@r-36.net>
This way we can call cresize() to set the terminal size before creating
a tty or spawning a process, which will start with the correct size.
Signed-off-by: Christoph Lohmann <20h@r-36.net>
ttywrite was assuming that if it could not write then it could
read, but this is not necessarily true, there are some situations
where you cannot read or write. The correct behaviour is to detect
if you can read or/and write.
If we want to show a custom selected cursor color, we must not set the
revert attribute to the drawn glyph.
Signed-off-by: Christoph Lohmann <20h@r-36.net>
Before the fix the cursor wouldn't obey if it's in a selection. If it is
inside it will now change to the reverse. This patch also adds that the
defaultcs will be reversed for the manually drawn cursors.
Before this patch, when pasting over BUFSIZE (8192 bytes here), st would
do the following:
\e[200~...8192 bytes...\e[201~\e[200~...remaining bytes...\e[201~
With this patch, the start marker is only sent when the offset is 0 (at
the beginning of selnotify) and the end marker is only sent when the
remaining bytes to read are 0 (at the end).
For short pastes, both conditions are true in the same iteration.
For long pastes, it removes the extra markers in the middle, keeping the
intended wrapping:
\e[200~...8192 bytes......remaining bytes...\e[201~
Signed-off-by: Christoph Lohmann <20h@r-36.net>
gcc would warn about an unused result. We know it is 0 and dup()
can't fail in these circumstances, as we closed fd0 previously.
Using dup2() to do the same saves one line and shuts gcc up, bringing
us a clean build back.
When a line has no any character linelen is 0, so last = &term.line[y][MIN(lastx, linelen-1)]
generated a pointer to the end of the previous line. The best thing we can do in this case
is to add a newline, because we don't have a glyph to print (and consult its state of
wrapping).
wcwidth() returns -1 for all the non visible characters, but it doesn't
necessarilly mean that they are incorrect. It only means that they are not
printable.
A little fix in xwrite().
>From 3727d2e3344b57128ab51c7839795204f1f839ff Mon Sep 17 00:00:00 2001
From: Quentin Rameau <quinq@fifth.space>
Date: Fri, 24 Jul 2015 11:40:46 +0200
Subject: [PATCH] Fix type for write(2) return variable.
The allocated lengh of s fits into an integer so we can safely use
ssize_t here.
This practice proved itself in sbase, ubase and a couple of other
projects.
Also remove the True and False defined in X11 and FcTrue and FcFalse
defined in Fontconfig.
Signed-off-by: Christoph Lohmann <20h@r-36.net>
Any system having different assignments than the usual 0, 1, 2 for
the standard file numbers and 0, 1 for the exit-statuses is broken
beyond repair.
Let's keep it simple and just use the numbers, no reason to fall
out of the window here and bend down for POSIX.
In one occasion, the ret-variable was not necessary. The check was
rewritten.
Signed-off-by: Christoph Lohmann <20h@r-36.net>
For a higher usefulness of the utf8strchr function, the index of the
UTF-8 character could be returned in addition with a Rune instead of a
char*. Since utf8strchr is currently only used by ISDELIM I didn't
bother to increase the complexity.
Here's a patch that fixes a bug when calling `makedrawglyphfontspecs'
in `drawregion'. Wasn't offseting the pointer into the input glyphs
array by `x1'. The bug isn't causing any problems currently, because
`drawregion' is always called with `x1' and `y1' values of 0, but if
this ever changes in the future, the bug would certainly cause some
problems.
I have another patch here for review that optimizes the performance of
glyph drawing, primarily when using non-unit kerning values, and fixes a
few other minor issues. It's dependent on the earlier patch from me that
stores unicode codepoints in a Rune type, typedef'd to uint_least32_t.
This patch is a pretty big change to xdraws so your scrutiny is
appreciated.
First, some performance numbers. I used Yu-Jie Lin termfps.sh shell
script to benchmark before and after, and you can find it in the
attachments. On my Kaveri A10 7850k machine, I get the following
results:
Before Patch
============
1) Font: "Liberation Mono:pixelsize=12:antialias=false:autohint=false"
cwscale: 1.0, chscale: 1.0
For 273x83 100 frames.
Elapsed time : 1.553
Frames/second: 64.352
Chars /second: 1,458,159
2) Font: "Inconsolata:pixelsize=14:antialias=true:autohint=true"
cwscale: 1.001, chscale: 1.001
For 239x73 100 frames.
Elapsed time : 159.286
Frames/second: 0.627
Chars /second: 10,953
After Patch
===========
3) Font: "Liberation Mono:pixelsize=12:antialias=false:autohint=false"
cwscale: 1.0, chscale: 1.0
For 273x83 100 frames.
Elapsed time : 1.544
Frames/second: 64.728
Chars /second: 1,466,690
4) Font: "Inconsolata:pixelsize=14:antialias=true:autohint=true"
cwscale: 1.001, chscale: 1.001
For 239x73 100 frames.
Elapsed time : 1.955
Frames/second: 51.146
Chars /second: 892,361
As you can see, while the improvements for fonts with unit-kerning is
marginal, there's a huge ~81x performance increase with the patch when
using kerning values other than 1.0.
So what does the patch do?
The `xdraws' function would render each glyph one at a time if non-unit
kerning values were configured, and this was the primary cause of the
slow down. Xft provides a handful of functions which allow you to render
multiple characters or glyphs at time, each with a unique <x,y> position,
so it was simply a matter of massaging the data into a format that would
allow us to use one of these functions.
I've split `xdraws' up into two functions. In the first pass with
`xmakeglyphfontspecs' it will iterate over all of the glyphs in a given
row and it will build up an array of corresponding XftGlyphFontSpec
records. Much of the old logic for resolving fonts for glyphs using Xft
and fontconfig went into this function.
The second pass is done with `xrenderglyphfontspecs' which contains the
old logic for determining colors, clearing the background, and finally
rendering the array of XftGlyphFontSpec records.
There's a couple of other things that have been improved by this patch.
For instance, the UTF-32 codepoints in the Line's were being re-encoded
back into UTF-8 strings to be passed to `xdraws' which in turn would then
decode back to UTF-32 to verify that the Font contained a matching glyph
for the code point. Next, the UTF-8 string was being passed to
`XftDrawStringUtf8' which internally mallocs a scratch buffer and decodes
back to UTF-32 and does the lookup of the glyphs all over again.
This patch gets rid of all of this redundant round-trip encoding and
decoding of characters to be rendered and only looks up the glyph index
once (per font) during the font resolution phase. So this is probably
what's responsible for the marginal improvements seen when kerning values
are kept to 1.0.
I imagine there are other performance improvements here too, not seen in
the above benchmarks, if the user has lots of non-ASCII code plane characters
on the screen, or several different fonts are being utilized during
screen redraw.
Anyway, if you see any problems, please let me know and I can fix them.
When user clicks LMB, one character is selected, but will not be copied
to selection until the user moves cursor a bit. Therefore, the character
should not be highlighted as selected yet.
Before the patch, the trick was not to mark line as dirty to avoid
highlighting it. However, if user has already selected something and
clicks in line that contains selection, selclear sets the line as dirty
and one character is highlighted when it should not.
This patch replaces dirty trick with explicit check for sel.mode inside
selected().
This patch also prevents sel.mode from increasing beyond 2. It is almost
impossible, but sel.mode may overflow if mouse is moved around for too
long while selecting.
st.c:1321:2: warning: ignoring return value of function declared with warn_unused_result attribute [-Wunused-result]
system(cmd);
^~~~~~ ~~~
Debatable whether an error here should case exit(EXIT_FAILURE). Just
preserving the existing behaviour for now.
Not always is desirable to create a pseudo terminal, and some times
we want to open a terminal emulator over a tty line. With this new
patch is possible to do someting like:
$ st -l /dev/ttyS0 115200
Without this option was needed to launch another terminal emulator
over st (for example minicom, picocom, cu, ...).
ICCCM mandates the use of real timestamps to interact with the
selection, to rule out race conditions if the clients are run at
different speeds. I have implemented the low hanging fruit, putting the
timestamps into text selection. Also, ICCCM mandates a check for whether
XSetSelectionOwner() worked. Not sure my version is correct, though.
tmoveto resets CURSOR_WRAPNEXT.
Simple testcase:
for i in $(seq 1 200); do
printf '\t.';
usleep 100000;
printf '\t@';
usleep 100000;
done
In st executing this script causes @ and . to overwrite each other in
the last column.
XFilterEvent usually filters KeyPress events according to input method.
At this point the window is not mapped. The only events that we process
are ConfigureNotify and MapNotify. They should not be filtered by input
method.
strsep() is not a POSIX function, and it means that every system
needs different defines to expose it. If the prototype of strsep
is not exposed then an ugly int/pointer is done and it might mean
a crash. The best solution?, to remove the strsep and make a custom
loop. If C programmers cannot do this kind of loops without calling
a library function, then maybe we should move all the suckless
software to Java.
Some programs can only deal with XA_STRING, and it makes impossible st
be able of copying to them. This patch makes st answer also to XA_STRING,
althought it sends utf8 strings. It is not a problem because moderm
applications must support utf8.
Thanks to Alex Pilon <alp@alexpilon.ca>!
Now there is a distinction between the primary and clipboard selection. With
Mod + Shift + c/v the clipboard is handled. The old Insert behavious does
reside.
The unicode long is added to the cache. So when fontconfig does fall back to
the default font (where there is no easy way to find this out from the
pattern) it isn't reloaded.
Use the terminfo delay syntax ($<x>) in our flash capability to avoid
hardcoding a fixed delay in redraw() when called from tsetmode() with
DECSCNM.
We need to turn on the npc capability so that delays are made with
xon/xoff instead of padding characters.
When MODE_INSERT is set we'd shift characters on the same
line forward before inserting our character in tputc().
This did not account for wide characters where width != 1.
This patch makes it so we shift the correct amount.
In tputc(), when a character wasn't large enough to fit
on the current line, we would call tnewline() to place it on
the next line. Unfortunately, we weren't resetting our glyph
pointer and this caused memory corruption when a
wide character (width == 2) was being written. This patch
resets our glyph pointer after calls to tnewline().
If blinktimeout is set to a value greater than 1000, pselect will
receive a timeout argument with tv_nsec greater than 1E9 (1 sec), and
fail, making st crash. This patch just ensures that the timespec
structure is correctly filled with a value properly decomposed between
tv_sec and tv_nsec.
Reported by JasonWoof on IRC. Thanks!
Trailing whitespaces are trimmed when copying from normal selection and
rectangular selection on lines that have their last character included
or on the left of the selection. It leads to inconsistent behaviors when
copying the exact same text from the left and right window in
applications with vertical splits.
This patch solves this issue by always trimming the selection.
- POSIX states the SHELL environment variable "... shall represent a
pathname of the user's preferred command language interpreter." As
such, st should check for its presence when deciding what shell to
use; just as HOME can be defined to override one's passwd-defined home
directory, a user should also be able to override their passwd-defined
shell using the SHELL environment variable.
The XBell() call currently used when a bell is recieved sends a message
to the X server, but if the X server doesn't know how to sound it,
it just gets ignored and I have not been able to find anywhere in x.org's
code a way to configure the action that the server does.
However, if you use XkbBell() then you can have a process listening for
the XkbBellNotifyEvent that is produced and either alert you visually or
play an audio file or whatever you want as your notification. You have
to include one more header file but the function seems to be compiled as
part of Xlib, at least on my installation.
CustaiCo
SI (0x0F or ^O) means Shift In, and it selects G1 charset definition,
and SO (0x0E or ^N) means Shift Out, and it selects G0 charset
definition, but st was doing just the inverse.
St runs an interactive shell and not a login shell, and it means
that profile is not loaded. The default terminal configuration
in some system is not the correct for st, but since profile is
not loaded there is no way of getting a script configures the
correct values.
St doesn't update the utmp files, this is the job of another
suckless tool, utmp. Utmp also opens a login shell (it is the
logical behaviour when you create a new user record) it is a
good option execute utmp and then get a correct input in
utmp, wtmp and lastlog file, and execute the content of the
profile.
When getting selected text, lines that were wrapped because of length
ought not include the wrapping newline in the selection.
This comes up, for example, when copying a bash command that is long
enough to wrap from the console and pasting it back into the console.
The extra newline breaks it.
Similiarly, changes behavior when trimming whitespace from the end of a
physical line to only do so if the line does not wrap. Otherwise we are
trimming whitespace from the middle of a logical line, which may change
its meaning.
Signed-off-by: Roberto E. Vargas Caballero <k0ga@shike2.com>
This makes any sequence of identical delimiters be considered a single
word in word-snapping mode. This seems more coherent for this mode and
is similar to what xterm does.
Signed-off-by: Roberto E. Vargas Caballero <k0ga@shike2.com>
This simplifies getbuttoninfo() and bpress(), and fixes a bug which made word
snapping behave incorrectly when a delimiter was at the beginning or end of
line.
Signed-off-by: Roberto E. Vargas Caballero <k0ga@shike2.com>
Ton van den Heuvel