Age | Commit message (Collapse) | Author | Files | Lines |
|
See https://plan9port-review.googlesource.com/c/plan9/+/1470
for discussion of the approach, especially Michael Stapleberg's comment:
Note that chromium, firefox and others have tried this and then switched to using the Xft.dpi X resource, see e.g. https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/libgtk2ui/gtk2_ui.cc and especially http://sources.debian.net/src/gnome-settings-daemon/3.18.2-1/plugins/xsettings/gsd-xsettings-manager.c/?hl=824#L80 for some anecdata about why this approach doesn’t work out.
The Xft.dpi resource is being set accurately by desktop environments (GNOME, KDE, …) and can easily be changed by users of niche window managers by editing ~/.Xresources.
I suggest we check only Xft.dpi, without considering the DPI environment variable or the monitor width/height.
|
|
This seems to match Terminal.
Fixes #145.
|
|
|
|
Fixes #118.
|
|
|
|
9term set $PLAN9 if PLAN9 is not set. But $PATH is not set.
As a result, 9term exits with "exec devdraw: No such file or directory"
|
|
Fixes #122, #140.
As reported in #122, `file:1:1` moves to the end of the file,
and `file:1:2` fails with “address out of range”.
I’ll use file:2:3 as an example so we can tell the line and column number apart.
What’s happening is this:
plumb/basic matches `2:3` using twocolonaddr (from plumb/fileaddr),
then sets addr to `2-#1+#3`
(the 1 is constant and was introduced because column numbers are 1-based).
Acme interprets this in three steps:
1. find the range (q0, q1) that contains line 2
2. create the range (q2, q2) where q2 = q0 - 1
3. create the range (q3, q3) where q3 = q2 + 3
The second step has a branch where if q0 == 0 and 1 > 0
(remember that 1 is constant and comes form plumb/basic),
q0 is set to the end of the file.
This makes addressing things at the end of the file easier.
The problem then is that if we select line 1,
which starts at the beginning of the file,
q0 is always 0 and the branch in step 2) will always be used.
`1:1` is interpreted as `1-#1+#1` which starts at 0, wraps around to the end of the file, then moves 1 character backwards and then forwards again, ending at the end of the file.
`1:2` is interpretes as `1-#1+#2` which starts at 0, wraps around to the end od the file, then moves 1 character backwards and tries moving 2 characters forwards beyond the end of the file, resulting in the out of range error.
In #140 @rsc proposed transforming `:X:Y` into `:X-#0+#Y-#1` instead since that
avoids wrapping around by not moving backwards at first.
This change modifies `plumb/basic` to do that.
|
|
This makes 2-1 chords possible with touchpad on a mac laptop.
|
|
Change-Id: Ice1c8c9d15cc6febf32dc2b7c449d457acc319b6
|
|
|
|
This makes fontsrv use the PostScript font names on X11.
The PostScript font names contains only alphanumeric and
hyphens. This allows us to use the Font command in acme.
It also matches the font names used by fontsrv on macOS,
which has been using PostScript font names.
|
|
To reproduce, create a column with at least two windows and resize
acme to have almost zero height.
|
|
macOS Mojave version 10.14 starts to disable font smoothing.
We disable font smoothing for OSX_VERSION >= 101400 to match the
system default font rendering.
It also makes the font rendering on macOS similar to that on X11.
|
|
Opening /dev/ptyXX files fails on recent
FreeBSD versions.
Following the same fix being applied to
Linux, OpenBSD, and Darwin, we use openpty
to open a pseudoterminal in openpts.
|
|
|
|
Helps Go module download cache, Upspin, maybe others.
|
|
* Avoid allocating empty images by adding 1 to width/height. This was
crashing fontsrv. The total width of the subfont image can be zero
even if the characters are present in the font. For example, all the
characters in x0300.bit (part of "Combining Diacritical Marks" Unicode
block) have zero width.
* Make sure U+0000 is always present in the font, otherwise libdraw
complains with: "stringwidth: bad character set for rune 0x0000 in ..."
* Use the same fallback glyph (pjw face) as OS X. This also fixes a bug
where advance was set to the total width of subfont instead of the
character.
Update #125 (most likely fixes the crash if in X11)
Change-Id: Icdc2b641b8b0c08644569006e91cf613b4d5477f
|
|
According to RFC 3501 the arguments to the LOGIN command should be
quoted strings (or length prefixed string literals). Without quoting,
authentication to some IMAP servers (e.g. Dovecot) will fail.
|
|
|
|
This change fixes a segfault in grep -e when no argument
has been provided. Thanks to Sean Hinchee for reporting
this issue.
Fixes #186.
|
|
Commit 2d82ef9d98 added ptrdiff_t in regcomp.c.
However, this change broke the build of the Unix
package because ptrdiff_t is defined in stddef.h.
|
|
When plumbing an address like `3-`, Acme selects line 1,
and similarly `3+` selects line 5.
The same problem can be observed for character addresses (`#123+`)
but _not_ for ones like `+`, `.+` or `/foo/+`:
The problem only occurs when a number is followed by a direction (`-`/`+`).
Following along with the example `3-` through `address` (in addr.c):
We read `3` into `c` and match the `case` on line 239.
The `while` loop on line 242ff reads additional digits into `c`
and puts the first non-digit back by decrementing the index `q`.
Then we find the range for line 3 on line 251 and continue.
On the next iteration, we set `prevc` to the last `c`,
but since that part read ahead _into `c`_,
`c` is currently the _next_ character we will read, `-`,
and now `prevc` is too.
Then in the case block (line 210) the condition on line 211 holds
and Acme believes that it has read two `-` in sequence
and modifies the range to account for the “first” `-`.
The “second” `-` gets applied after the loop is done, on line 292.
So the general problem is:
While reading numbers, Acme reads the next character after the number into `c`.
It decrements the counter to ensure it will read it again on the next iteration,
but it still uses it to update `prevc`.
This change solves the problem by reading digits into `nc` instead.
This variable is used to similar effect in the block for directions (line 212)
and fills the role of “local `c` that we can safely use to read ahead” nicely.
|
|
For some fonts, using box-drawing characters in the representative
text for computing the line height results in it being uncomfortably
high. Replace them with accented capitals and tall lower-case letters
which lead to a more conservative increase in the line height.
Fixes #162.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Double the width returned by CTFontGetBoundingBox when drawing.
Add box drawing characters for determining the line height.
Call freememimage(1) for the character memimage.
Fixes #18.
Fixes #120.
Fixes #146.
|
|
MacPorts installs osxfuse under /opt/local.
|
|
fontsrv wasn't rendering fontawesome icons,
which uses the private use area around 0xf000.
|
|
Current versions of osxfuse ship with multiple versions of its kernel
extension (kext) for differend versions of macOS.
Running mount(1) on macOS with a current version of osxfuse fails with
`don't know how to mount (no fuse)' since it fails to find the kext.
Running 9pfuse(4) directly works fine.
This change adds a check to mount(1) that determines:
1) which version of macOS we're running on
2) if there is an osxfuse kext available for this version of macOS
|
|
|
|
To use astro(1) and scat(1) one has to create sky/here and
download various catalogue files as detailed in sky/README.
This change marks those files as ignored by git so they
don't clutter its status messages.
|
|
TERM_PROGRAM is the customary way to identify which kind of terminal
emulator program one uses on macOS.
This change sets TERM_PROGRAM to termprog since both variables are used
for the same purpose.
|
|
read(3) sometimes errors with EINTR on macOS over slow connections.
9pfuse(1) now retries read(3) instead of sysfatal(3)ing.
|
|
Fixes #81.
|
|
|
|
|
|
as the old grody way doesn't work any more on FreeBSD-10 and later.
|
|
rc on amd64 stores ulimit values as 32-bit int, but the limits on
OpenBSD amd64 can exceed 2^31, so "ulimit -a" shows some values as
negative. This is a problem when I want to increase my ulimit but
the hard ulimit values are printed as negative.
|
|
|
|
|
|
Fixes #6.
Change-Id: Id9950f59c7970575866a7c22a69bfbf3a271f2bb
|
|
|
|
|