When to submit regression in a PR
aymeric at kuri.mu
Tue Jun 25 10:19:42 UTC 2013
Shane Ambler said :
> > My question therefore is: while I will mention these problems
> > upstream, should I also make the PR? Contact the port maintainer
> > directly? I understand it is not FreeBSD specific (same issue on
> > Debian Sid) however it really make the current port unusable for
> > those working on laptops and those needing to input characters only
> > reachable with the compose key.
> I would. While the ports are handled separately from the base system
> they need to be maintained as well. If a version of a port has issues
> then an older version could stay in place.
> The pr system is used for ports as well as the base system.
Mark Felder said :
> It's probably a good idea to open a PR and let the port maintainer
> know, but we really need to have upstream to fix it. FreeBSD
> discourages doing custom "development" in the ports tree, so even if
> you could whip up a patch to fix it we would prefer that it get
> committed upstream and the port updated to pull the new version rather
> than have the port committer include a custom patch with the port.
Thanks Shane and Mark. In fact, shortly after this mail a beginning of
fix as been committed, so it will eventually surface in FreeBSD as well.
Shane Ambler said:
> Can't say I'm sure which key you refer to as compose - do you mean Alt
> or Ctrl? I have heard of the ctrl key being remapped to the caps lock
> for continuous use. You may also look into turning on sticky keys, it
> keeps a modifier key active without holding it down so that the next key
> pressed has the modifier included. see x11/xkbset
You can turn any key into a compose/multi key. Mine is mapped on the
setxkbmap -option compose:ralt
It allows you to input characters such "é" or "ø" on keyboards where
such keys are missing. It works by making key combos or chords.
As for the stickiness of the key this is partly a problem linked to
the fix just committed. By default a compose key seems to work both as
sticky and non sticky to accommodate different writing styles/needs.
This is noticeable in any X applications that accept keyboard input,
from terminals to a browser. The last commit in upstream plan9port has
brought back the functionality of the compose key only as sticky. When a
key chord is done (non-sticky) the compose functionality is not working.
Anyway this discussion is not so relevant to this list anymore :)
Thanks again for advising on the PR issue! Very useful.
More information about the freebsd-questions