Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Glenn Morris]

Paul Eggert wrote:

> revision-id: eggert@cs.ucla.edu-20131211223102-pex3hszrsaonpkti
> committer: Paul Eggert <eggert@cs.ucla.edu>
> timestamp: Wed 2013-12-11 14:31:02 -0800
> message:
>   Make 'configure' work out-of-the-box on Solaris.

I don't really care, but:

I find this a misleading description. Configure worked just fine on
Solaris, and nothing in your change is specific to Solaris. What this
change really is is "make absence of normal image libraries or their
headers a warning rather than an error".

This stuff was over 6 years old, and was pretty thoroughly debated at
the time, eg:

http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg01112.html

Solaris is many times less relevant today than it was 6 years ago;
inexperienced builders wondering "why doesn't my Emacs show images" are
likely more prevalent. The point was that such people are liable to miss
a warning flying by amongst the (lengthy) configure output.

> Another possibility would be to disable X11 if these libraries are
> missing.

I don't think that would be a very good idea...

> The point is that a plain 'configure' should not fail on platforms
> like Solaris 11 where one or more image libraries are not installed by
> default.

I'm not sure if there are any platforms where the necessary headers to
compile applications with image libraries are installed by default (but
"installed by default" is nebulous anyway; does it mean a truly minimal
install, a desktop install, server install, workstation install, etc).

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Paul Eggert]

Glenn Morris wrote:
> I'm not sure if there are any platforms where the necessary headers to
> compile applications with image libraries are installed by default (but
> "installed by default" is nebulous anyway; does it mean a truly minimal
> install, a desktop install, server install, workstation install, etc).

I have ready access to two Solaris servers, both installed by others,
and both with quite a few of the Solaris development libraries installed.
Without that patch, './configure' fails on both due to one or more
missing graphics development libraries.

It's just two data points, but it's not a good sign; it gives the impression
to naive builders that Emacs is a pain to port.

When I'm on these servers, I always run Emacs in tty mode, so it doesn't
bother me a bit that libgif etc. are missing.  I realize I could configure
with --without-x but that would lose some ability to test that X11 compiles
work on Solaris.  I also realize I could configure with --without-jpeg
--without-png --without-gif --without-tiff, or whatever, but I always
forget which flags they are and frankly I just want to type './configure'.

I wasn't aware of the earlier discussion about this.  Oh well.
I've reverted the patch, since Richard decided to do it this way.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

 > I also realize I could configure with --without-jpeg
 > --without-png --without-gif --without-tiff, or whatever, but I always
 > forget which flags they are and frankly I just want to type './configure'.

Since my Debian package manager refuses to orderly install the tiff
libraries I have to configure --without-tiff.  Obviously, I'd prefer
that Emacs would silently configure without a library if it doesn't find
it.

martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Eli Zaretskii]

> Date: Thu, 12 Dec 2013 11:18:08 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
>  > I also realize I could configure with --without-jpeg
>  > --without-png --without-gif --without-tiff, or whatever, but I always
>  > forget which flags they are and frankly I just want to type './configure'.
> 
> Since my Debian package manager refuses to orderly install the tiff
> libraries I have to configure --without-tiff.  Obviously, I'd prefer
> that Emacs would silently configure without a library if it doesn't find
> it.

You only ever need to run configure explicitly once for each new
branch.  Thereafter, just say "make".

Also, config.log shows all the options you used to invoke configure
the last time.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

 > You only ever need to run configure explicitly once for each new
 > branch.  Thereafter, just say "make".

When I want to check whether a feature works with the GTK or Lucid
build, I have to reconfigure in between.

 > Also, config.log shows all the options you used to invoke configure
 > the last time.

Still it would be great if I didn't have to care about a missing image
library  ...

martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Eli Zaretskii]

> Date: Thu, 12 Dec 2013 19:11:04 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
>  > You only ever need to run configure explicitly once for each new
>  > branch.  Thereafter, just say "make".
> 
> When I want to check whether a feature works with the GTK or Lucid
> build, I have to reconfigure in between.

My advice is to use a separate branch for that.  Branching is cheap,
and you avoid breaking or messing up your bound branch.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Stephen J. Turnbull]

martin rudalics writes:

 > When I want to check whether a feature works with the GTK or Lucid
 > build, I have to reconfigure in between.

Aside from multiple branches, which are a PITA if conceptually they're
supposed to be identical source IMO, surely Emacs uses the wonderful
support Make has for VPATH aka configure --srcdir builds?  Have a GTK
blddir, a Lucid blddir, etc for any that you regularly build.  After
doing that once, just "make" should win (or perhaps an occasional
"make bootstrap").

 > Still it would be great if I didn't have to care about a missing image
 > library  ...

This is nearly trivial to support, except that it would be bad if
other users were surprised by the absence of features they expect due
to a lack of some *-devel.rpm.  The UI aspect isn't that hard, but I
can't post code because it would be based on XEmacs code of provenance
unknown to me, and anyway it suits of mode of configuration unlike
that of GNU Emacs.  If it *can* be user-optional at configure time it
*is* optional, with --enable-FEATURE={no|auto|yes}, where "auto" means
"use it if you can find it and it's usable", and "yes" means "error if
you can't find a usable library and header".

GNU Emacs might prefer a single --enable-missing-features configure
option, with "no" meaning you get a configure error when a standard
feature is missing.  Preferably attempting to continue configuration
of all features, collecting "missing feature" errors to report at the
end of the run (which of course finishes with a fatal error), and
"yes" meaning you get a warning but configure continues and produces a
buildable tree (as far as configure knows, of course).

Either way, you could add support for it feature by feature without
disturbing current users just by defaulting --enable-missing-features
to "no", or all the --enable-FEATURE options to "yes".

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

 > Aside from multiple branches, which are a PITA if conceptually they're
 > supposed to be identical source IMO, surely Emacs uses the wonderful
 > support Make has for VPATH aka configure --srcdir builds?  Have a GTK
 > blddir, a Lucid blddir, etc for any that you regularly build.  After
 > doing that once, just "make" should win (or perhaps an occasional
 > "make bootstrap").

Sounds intriguing.  Does anyone do that here?

 > Either way, you could add support for it feature by feature without
 > disturbing current users just by defaulting --enable-missing-features
 > to "no", or all the --enable-FEATURE options to "yes".

The last time I checked this, building stops when it doesn't find a
missing image library but continues when it doesn't find the Motif
libraries.

martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Eli Zaretskii]

> Date: Fri, 13 Dec 2013 11:13:54 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu, 
>  emacs-devel@gnu.org
> 
>  > Aside from multiple branches, which are a PITA if conceptually they're
>  > supposed to be identical source IMO, surely Emacs uses the wonderful
>  > support Make has for VPATH aka configure --srcdir builds?  Have a GTK
>  > blddir, a Lucid blddir, etc for any that you regularly build.  After
>  > doing that once, just "make" should win (or perhaps an occasional
>  > "make bootstrap").
> 
> Sounds intriguing.  Does anyone do that here?

I do, sometimes.

But I disagree with Stephen about the PITA part: normally, when I make
a different build, I do that because I need to debug it or test some
changes specific to that build.  Having a separate branch for that
from the get-go makes it very easy to make changes without thinking
twice, and also to merge those changes later onto the trunk.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > But I disagree with Stephen about the PITA part: normally, when I make
 > a different build, I do that because I need to debug it or test some
 > changes specific to that build.  Having a separate branch for that
 > from the get-go makes it very easy to make changes without thinking
 > twice, and also to merge those changes later onto the trunk.

As I understood Martin, he is often in the situation where he just
wants to confirm that all of several non-conflicting builds (eg, in C
they'd be separated by #ifdefs for Win32, Xt, and GTK+) work with the
same patch.  If a problem occurs in common code, I would not want to
commit it all until it works on all of those builds, and the source
trees for the various builds should be kept in synch.  That's easiest
if the sources trees are actually all the same tree.  On the other
hand, if the problem occurs in only one of several #ifdefs, I don't
want to commit that patch at all until all of the builds work.  Again,
it makes sense to do the tests in separate builddirs from the same
source tree.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

 > As I understood Martin, he is often in the situation where he just
 > wants to confirm that all of several non-conflicting builds (eg, in C
 > they'd be separated by #ifdefs for Win32, Xt, and GTK+) work with the
 > same patch.  If a problem occurs in common code, I would not want to
 > commit it all until it works on all of those builds, and the source
 > trees for the various builds should be kept in synch.

And keeping them in synch is a pain with different branches.

martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Jan Djärv]

Hello.

14 dec 2013 kl. 12:23 skrev martin rudalics <rudalics@gmx.at>:

> > As I understood Martin, he is often in the situation where he just
> > wants to confirm that all of several non-conflicting builds (eg, in C
> > they'd be separated by #ifdefs for Win32, Xt, and GTK+) work with the
> > same patch.  If a problem occurs in common code, I would not want to
> > commit it all until it works on all of those builds, and the source
> > trees for the various builds should be kept in synch.
> 
> And keeping them in synch is a pain with different branches.

I have not read the whole thread, but isn't this what separate build directories are for?  Use them all the time.

	Jan D.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

> I have not read the whole thread, but isn't this what separate build directories are for?  Use them all the time.

I understand that meanwhile.  But what do I have to do to use them?

martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Eli Zaretskii]

> Date: Sat, 14 Dec 2013 14:45:23 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,
> 	Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii <eliz@gnu.org>,
> 	emacs-devel <emacs-devel@gnu.org>
> 
> > I have not read the whole thread, but isn't this what separate build directories are for?  Use them all the time.
> 
> I understand that meanwhile.  But what do I have to do to use them?

Nothing.  Juts create a directory, chdir there, and invoke the
configure script from the source directory, as in
"/d/foo/bar/configure" or "../../foo/bar/configure".  The script will
do the rest.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Jan Djärv]

Hi. 

14 dec 2013 kl. 14:45 skrev martin rudalics <rudalics@gmx.at>:

>> I have not read the whole thread, but isn't this what separate build directories are for?  Use them all the time.
> 
> I understand that meanwhile.  But what do I have to do to use them?

Use a make that supports Vpath (I think that is all makes nowdays).

% mkdir obj-gtk
% cd obj-gtk
% /path/to/src/configure 
% make 
% mkdir ../obj-lucid
% cd ../obj-lucid
% /path/to/src/configure --with-x-toolkit lucid
% make 

And so on. 

    Jan D. 

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Stephen J. Turnbull]

Jan Djärv writes:

 > Use a make that supports Vpath (I think that is all makes nowdays).

I think it's probably safest to use GNU Make, as historically many
Makes had variant ideas of what VPATH should do.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

> % mkdir obj-gtk
> % cd obj-gtk
> % /path/to/src/configure 

When I do that I'm told

source directory already configured; run "make distclean" there first

martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Eli Zaretskii]

> Date: Sat, 14 Dec 2013 18:52:59 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,
> 	Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii <eliz@gnu.org>,
> 	emacs-devel <emacs-devel@gnu.org>
> 
> > % mkdir obj-gtk
> > % cd obj-gtk
> > % /path/to/src/configure 
> 
> When I do that I'm told
> 
> source directory already configured; run "make distclean" there first

Good advice; do as it says.

When you build in separate build directories, you aren't supposed to
build in the tree as well.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

>> source directory already configured; run "make distclean" there first
> 
> Good advice; do as it says.
> 
> When you build in separate build directories, you aren't supposed to
> build in the tree as well.

Works like a charm now.  Thanks to everyone for the advices.

martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

> Good advice; do as it says.

Just in case you're back from skiing: How do I now get my globals.h back
into the src directory?  Emacs doesn't find my variables any more :-(

Thanks in advance, martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Eli Zaretskii]

> Date: Sun, 15 Dec 2013 20:45:18 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, stephen@xemacs.org, eggert@cs.ucla.edu, 
>  emacs-devel@gnu.org
> 
> > Good advice; do as it says.
> 
> Just in case you're back from skiing: How do I now get my globals.h back
> into the src directory?  Emacs doesn't find my variables any more :-(

Run "make TAGS" in the build directory would be my guess.

Or maybe it's a bug.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

 >> How do I now get my globals.h back
 >> into the src directory?  Emacs doesn't find my variables any more :-(
 >
 > Run "make TAGS" in the build directory would be my guess.
 >
 > Or maybe it's a bug.

I now have set `source-directory' to the build directory which obviously
breaks `find-function-C-source'.

martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Eli Zaretskii]

> Date: Mon, 16 Dec 2013 11:29:21 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, stephen@xemacs.org, eggert@cs.ucla.edu, 
>  emacs-devel@gnu.org
> 
>  >> How do I now get my globals.h back
>  >> into the src directory?  Emacs doesn't find my variables any more :-(
>  >
>  > Run "make TAGS" in the build directory would be my guess.
>  >
>  > Or maybe it's a bug.
> 
> I now have set `source-directory' to the build directory which obviously
> breaks `find-function-C-source'.

Sorry, I'm probably missing something: why did you need to make such a
strange assignment?  What command(s) were not working before that?

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

 > Sorry, I'm probably missing something: why did you need to make such a
 > strange assignment?

Alzheimer's disease, presumably.

 >  What command(s) were not working before that?

A tags based command and `find-variable'.  I was completely confused by
the fact that etags can't locate defvars anyway (or any more IIUC) and
that globals.h moved to another directory.  All I had to do was re-run
etags in the src directory.

Thanks for asking the right questions, martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Jan Djärv]

Hello. 

14 dec 2013 kl. 18:52 skrev martin rudalics <rudalics@gmx.at>:

>> % mkdir obj-gtk
>> % cd obj-gtk
>> % /path/to/src/configure 
> 
> When I do that I'm told
> 
> source directory already configured; run "make distclean" there first
> 

You can't build in src dir and separate dirs at the same time.  Src dir. must be prestine. 

    Jan D. 

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Andreas Schwab]

martin rudalics <rudalics@gmx.at> writes:

> But what do I have to do to use them?

Read INSTALL.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

 > But I disagree with Stephen about the PITA part: normally, when I make
 > a different build, I do that because I need to debug it or test some
 > changes specific to that build.  Having a separate branch for that
 > from the get-go makes it very easy to make changes without thinking
 > twice, and also to merge those changes later onto the trunk.

The problem with a separate branch is that I continuously have to
resolve conflicts, sometimes over a longer period.  I currently do that
for four branches already and it's getting tedious.

martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Eli Zaretskii]

> Date: Sat, 14 Dec 2013 12:23:05 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: stephen@xemacs.org, eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
>  > But I disagree with Stephen about the PITA part: normally, when I make
>  > a different build, I do that because I need to debug it or test some
>  > changes specific to that build.  Having a separate branch for that
>  > from the get-go makes it very easy to make changes without thinking
>  > twice, and also to merge those changes later onto the trunk.
> 
> The problem with a separate branch is that I continuously have to
> resolve conflicts, sometimes over a longer period.  I currently do that
> for four branches already and it's getting tedious.

If you have the same changes in each of the branches, then indeed
separate build directories is what you want.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Glenn Morris]

martin rudalics wrote:

> Since my Debian package manager refuses to orderly install the tiff
> libraries

If we could go back to the actual issue.
I don't understand your statement here.

apt-get install libtiff5-dev 

works fine for me. (It may be libtiff4-dev depending on which version of
Debian you are using, or even libtiff-dev perhaps.) This is one of the
things that `apt-get build-dep emacs24', as suggested in INSTALL, will
do for you.

And if you don't have root, just grab libtiff and install it yourself
somewhere.

(Having said all that, personally I would not class libtiff as
"essential" for Emacs, but that point was made 6 years ago too.)

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Stefan Monnier]

> apt-get install libtiff5-dev
> works fine for me. (It may be libtiff4-dev depending on which version of
> Debian you are using, or even libtiff-dev perhaps.) This is one of the
> things that `apt-get build-dep emacs24', as suggested in INSTALL, will
> do for you.

I do remember having some trouble with this.  Nothing that prevented
installation, but I sometimes had to do some apt gymnastics to satisfy
all the dependencies and conflicts while keeping all the other
packages installed.

> (Having said all that, personally I would not class libtiff as
> "essential" for Emacs, but that point was made 6 years ago too.)

I'm in favor or making libtiff non-essential (i.e. just emit a warning
if it's missing, rather than stopping the installation).


        Stefan

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Paul Eggert]

Stefan Monnier wrote:
> I'm in favor or making libtiff non-essential (i.e. just emit a warning
> if it's missing, rather than stopping the installation).

That'd be easy to arrange.  How about libgif, libpng, libjpeg, and
libxpm?  If they're all non-essential we can reinstall the patch
in trunk bzr 115472.  If just some are essential, we can
change 'configure' to exit only if an essential one is missing.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Eli Zaretskii]

> Date: Sun, 15 Dec 2013 09:12:11 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> How about libgif, libpng, libjpeg, and libxpm?

I thunk libxpm should be essential, as it is needed for color icons
(toolbar etc.).  And if you build with GTK, I'm quite sure you will
get libpng whether you want it or not.  Same for librsvg (which you
didn't mention) -- it pulls in at least libpng, and can also require
others, depending on how it was configured when built.

So my suggestion would be to make at least libxpm and libpng
essential.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Stefan Monnier]

>> How about libgif, libpng, libjpeg, and libxpm?

I think libtiff is the only one I'm willing to "demote" for now.


        Stefan

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

> I think libtiff is the only one I'm willing to "demote" for now.

In this case I rather wouldn't demote any of them.
But please make the text in INSTALL less ambiguous
in this regard.

Thanks, martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[Paul Eggert]

martin rudalics wrote:
> In this case I rather wouldn't demote any of them.
> But please make the text in INSTALL less ambiguous
> in this regard.

I gave that a shot in trunk bzr 115548.

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

> I gave that a shot in trunk bzr 115548.

Very good.  Thanks, Paul.

martin

Re: trunk r115472: Make 'configure' work out-of-the-box on Solaris.

[martin rudalics]

 >> Since my Debian package manager refuses to orderly install the tiff
 >> libraries
 >
 > If we could go back to the actual issue.

Sorry for usurping this thread.

 > I don't understand your statement here.
 >
 > apt-get install libtiff5-dev
 >
 > works fine for me. (It may be libtiff4-dev depending on which version of
 > Debian you are using, or even libtiff-dev perhaps.) This is one of the
 > things that `apt-get build-dep emacs24', as suggested in INSTALL, will
 > do for you.

It works for me now as well.  But it did not work a couple of months ago
when I tried for the first time with Synaptic (IIRC it didn't offer me
libtiff5-dev back then but my memory may fail).  I also tried `apt-get
build-dep emacs24' then but it didn't enlighten me much.  So I retrieved
most information about which libraries to install from information I
found on the Web.

Probably the fact that on most installations the necessary libraries are
already present means that people usually don't have to bother about
installing them.  Resolving library dependencies manually might be a
demanding experiment for an inexperienced user like me.  My primary aim
was to simply not break my installation (something which caused me to
abandon working on GNU/Linux in younger days).

Also the note in INSTALL saying that

   Emacs will configure itself to build with these libraries if the
   `configure' script finds them on your system, unless you supply the
   appropriate --without-LIB option.

is misleading IMHO since it implies that Emacs will not stop with an
error if it does not find one of these libraries.

 > And if you don't have root, just grab libtiff and install it yourself
 > somewhere.
 >
 > (Having said all that, personally I would not class libtiff as
 > "essential" for Emacs, but that point was made 6 years ago too.)

Personally, I don't know and never used TIFF.  So why should I bother?
Though maybe that building with TIFF works now also allows me to build
with Open Motif support which did not work so far ...

martin

Longlines mode and visual-line mode... again

[Danil Orlov]

Hello.

  The main feature  for me(and I hop  for many others too) in  longlines mode is
soft line wrap  on given column.  Occasionally, ll-mode is  obsolete, and we have
visual-line instead of it. That's ok. But that new mode doesn't have this useful
feature from the box. That's not ok.

  So, what is typical action for a typical emacs user who wants to get soft line
break,  avoiding to  see  message about  ll-mode  could be  dropped  in any  next
release? Right! He goes to:

http://www.emacswiki.org/emacs/VisualLineMode

And copy this fragment into his .emacs or what-else-he-use:

================================================================================
(defvar visual-wrap-column nil)

(defun set-visual-wrap-column (new-wrap-column &optional buffer)
  "Force visual line wrap at NEW-WRAP-COLUMN in BUFFER (defaults
to current buffer) by setting the right-hand margin on every
window that displays BUFFER.  A value of NIL or 0 for
NEW-WRAP-COLUMN disables this behavior."
  (interactive (list (read-number "New visual wrap column, 0 to disable: " (or visual-wrap-column fill-column 0))))
  (if (and (numberp new-wrap-column)
           (zerop new-wrap-column))
    (setq new-wrap-column nil))
  (with-current-buffer (or buffer (current-buffer))
    (visual-line-mode t)
    (set (make-local-variable 'visual-wrap-column) new-wrap-column)
    (add-hook 'window-configuration-change-hook 'update-visual-wrap-column nil t)
    (let ((windows (get-buffer-window-list)))
      (while windows
        (when (window-live-p (car windows))
          (with-selected-window (car windows)
            (update-visual-wrap-column)))
        (setq windows (cdr windows))))))

(defun update-visual-wrap-column ()
  (if (not visual-wrap-column)
    (set-window-margins nil nil)
    (let* ((current-margins (window-margins))
           (right-margin (or (cdr current-margins) 0))
           (current-width (window-width))
           (current-available (+ current-width right-margin)))
      (if (<= current-available visual-wrap-column)
        (set-window-margins nil (car current-margins))
        (set-window-margins nil (car current-margins)
                            (- current-available visual-wrap-column))))))
================================================================================


  And  why  this  little  piece   of  functionality  cannot  be  integrated  into
visual-line mode?  Especially if visual-line-mode is  recommended as replacement
for ll-mode.

Re: Longlines mode and visual-line mode... again

[Stefan Monnier]

>   And  why  this  little  piece   of  functionality  cannot  be
> integrated  into visual-line mode?

Because nobody has done the work to actually integrate this feature into
visual-line-mode.
The code you quote seems mostly OK, but I don't know who wrote it, so
I can't just install it, for copyright reasons.

If someone can rewrite it and submit a patch, or if the original author
can submit the patch, I'd be happy to install the feature.


        Stefan