Using scroll bar in emacs highlights/selects text

[ThomasN]

Binary package hint: emacs23

This is an emacs bug that has been fixed in the emacs source code.
Please provide a recompiled emacs package.
Redhat emacs23 package had the same problem.
See this report: https://bugzilla.redhat.com/show_bug.cgi?id=543046
This is a very annoying bug.
Thank you for providing a new package ASAP.

[gero (gerod)]

This bug is indeed very annoying. Any chance to get it fixed soon, please?

Moreover, when I let go of the scrollbar it frequently snaps back to it's previous position (and with it the displayed section of the file) instead of staying where it is. Is this problem related?

[elrond (elrond.)]

This has been fixed in Emacs 23.2 so I'm going to mark this as duplicate of bug #588203

[era (era)]

gero wrote in https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/588203/comments/20
> Bug #581486 is not really a duplicate of this bug but fixing this one would probably also fix the other one.
>
> It's about two very annoying bugs in the Emacs version currently shipping with Lucid (23.1.1):
> * Moving the scroll bar is marking text.
> * When letting go of the scroll bar it often snaps back to its previous position (and with it the displayed
> section of the file) instead of staying where it is.
>
> I gather that these problems stem from bugs in the interaction with GTK and X. Apparently they have
> been fixed in later versions, including Emacs 23.2.
>
> As these are rather severe usability problems, is there any chance to get Lucid upgraded to Emacs 23.2?

As a general observation of Ubuntu policy, it is unlikely that Lucid would be updated to 23.2, but if it's feasible to backport patches for individual bugs, getting those fixes into 23.1 could be requested as an SRU. A rough workaround is documented in the upstream bug for bug #581486, so I doubt it's worth trying to hunt down the relevant upstream patch just to see whether it could be backported to 23.1, but if you feel up to it, by all means feel welcome to try. I would propose to remove the duplicate status for bug #581486 and following up here, if you decide to pursue this.

[era (era)]

This shouldn't be marked as a duplicate anyhow. Instead, the new version should include a Changelog which points to the bugs closed by the upload.

[phil (fongpwf)]

The workaround given in http://debbugs.gnu.org/cgi-bin/bugreport.cgi?bug=4870 indicates that setting GDK_NATIVE_WINDOWS=1 is a workaround.
Is that a environment variable? Or an emacs variable?

[gero (gerod)]

phil, it's an environment variable. You can prepend it to calling emacs like this ('$' being the shell prompt):

$ GDK_NATIVE_WINDOWS=1 emacs

[Psychotron (redm)]

This affects emacs22 as well. The workaround works. But please fix this properly.

[Launchpad Janitor (janitor)]

This bug was fixed in the package emacs23 - 23.2+1-4ubuntu1

---------------
emacs23 (23.2+1-4ubuntu1) natty; urgency=low

  [ Michael W. Olson (GNU address) ]
  * Resync with Debian. Remaining changes:
  * debian/control.in:
    - Change Maintainer to Ubuntu Core Developers, per Ubuntu policy.
    - Conflict and Replace emacs23-common-non-dfsg, since we provide
      all of its features.
    - Do not suggest emacs23-common-non-dfsg.
    - Replace use of Source-Version with source:Version.
    - Require autotools-dev (>= 20100122.1) in Build-Depends, since
      the version in Karmic will fail due to a missing Perl module.
  * debian/control: Regenerate.
  * debian/copyright.in:
    - Remove text about removed files.
  * debian/copyright: Regenerate.
  * debian/emacsVER-common.postinst:
    - Don't install info files to info/dir. This happens
      automatically now.
  * debian/emacsVER-common.prerm:
    - Don't remove info files from info/dir. This happens
      automatically now.
  * debian/patches:
    - handle-dfsg-split.diff: Remove.
    - ubuntu-restore-nondfsg-files.diff: New patch that reintroduces
      the non-DFSG files, with the exception of .elc files and info
      files, which use special characters and thus can't be easily
      represented in patch form. These will be regenerated at build
      time.
  * debian/rules:
    - Do not install replacements for non-DFSG files.
    - Install all info files, not just efaq.
    - Avoid uselessly building info files a 2nd time.

  [ Reinhard Tartler ]
  * Reintegrate ubuntu history in debian/changelog
  * verified that debian/patches/fix-movemail-race.diff can be dropped,
    it is integrated in the new upstream version.
  * Rebuild against new debhelper to get trigger support: LP: #449729
  * New upstream version (LP: #588203) solves:
    - huge font sizes. LP: #445402
    - scroll bar in emacs highlights/selects text, LP: #581486
    - org and tbl menus are no longer missing in org-mode, LP: #640504
  * Add patch fix-ftbfs-xft-fontconfig.diff to avoid FTBFS.

emacs23 (23.2+1-4) unstable; urgency=low

  * Disable parallel builds (via DEB_BUILD_OPTIONS=parallel) until an
    upstream race condition is fixed. Thanks to Sven Joachim
    <email address hidden> for the report. (closes: #592992)

emacs23 (23.2+1-3) unstable; urgency=low

  * Don't try to "mkdir $(infodir)" in doc/*/Makefile.in. Thanks to
    Stéphane Glondu <email address hidden> for the 23.2+1-2.1 NMU.

  * Use -O1 rather than -O2 on ia64. Fixes a build failure (looks
    like a broken byte compiler) with newer versions of gcc
    (c.f. #207580). Thanks to Sven Joachim <email address hidden> for the
    report and thanks to Stéphane Glondu <email address hidden> for the
    23.2+1-2.1 NMU. (closes: #582439)

  * Remove deprecated Encoding field from emacsVER.desktop. Thanks to
    Stéphane Glondu <email address hidden> for the 23.2+1-2.1
    NMU.

  * Use "set -e" rather than "/bin/sh -e" in emacsVER-common.postinst
    and emacsVER-bin-common.postinst. Thanks to Stéphane Glondu
    <email address hidden> for the 23.2+1-2.1 NMU.

  * Add a Homepage field to debian/control.in. Thanks to Stéphane
    Glondu <email address hidden> for the ...

[phil (fongpwf)]

Is the fix going to ported to either Lucid or Maverick?

[era (era)]

@phil: as outlined above, a backport can be requested if somebody extracts the relevant patches and produces a working build. This would seem to require dedicated volunteer effort at this point; I'm not convinced the cost outweighs the benefit as we can hope for a fix in Ubuntu 11.04 anyway.