GNU bug report logs - #71487
[Feature Request] Allow `tool-bar-position' 'left and 'right in more systems

Previous Next

To reply to this bug, email your comments to 71487 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Elijah G." <eg642616 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [Feature Request] Allow `tool-bar-position' 'left and 'right in
 more systems
Date: Mon, 10 Jun 2024 20:50:42 -0600

Hello, the current emacs-30 allows move the tool-bar to bottom, i would
like to know if there are plans for allow move it to left and right.

Also I would like to help on this (only for windows-nt port), but i
would need to get more information such as which files, variables or
functions are needed to modify.

Thanks.

-- 
E.G. from Gnus The Newsreader and E-mail client

Message #8 received at 71487 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Elijah G." <eg642616 <at> gmail.com>
Cc: 71487 <at> debbugs.gnu.org
Subject: Re: bug#71487: [Feature Request] Allow `tool-bar-position' 'left and
 'right in more systems
Date: Wed, 12 Jun 2024 09:30:30 +0300

> From: "Elijah G." <eg642616 <at> gmail.com>
> Date: Mon, 10 Jun 2024 20:50:42 -0600
> 
> Hello, the current emacs-30 allows move the tool-bar to bottom, i would
> like to know if there are plans for allow move it to left and right.

It should be a good feature, I think, but if you are asking whether
somebody is working on that, I don't think so.

> Also I would like to help on this (only for windows-nt port), but i
> would need to get more information such as which files, variables or
> functions are needed to modify.

The usual suspects: xdisp.c, dispnew.c, frame.c, window.c, *term.[cm],
*fns.[cm], gtkutil.c, xsettings.c.  Search all those for "tool_bar" to
find the relevant code.

Thanks.

Message #13 received at 71487-close <at> debbugs.gnu.org (full text, mbox):

From: Dave Hart <davehart <at> gmail.com>
To: Nick Bowler <nbowler <at> draconx.ca>,
 GNU Automake mailing list <automake <at> gnu.org>
Cc: 71487-close <at> debbugs.gnu.org
Subject: Re: automake-1.16.92 released
Date: Sun, 30 Jun 2024 17:34:37 +0000

[Message part 1 (text/plain, inline)]

On Sun, 30 Jun 2024 at 05:03, Nick Bowler <nbowler <at> draconx.ca> wrote:

> [...]
>
> autoreconf decides to run libtoolize based on an m4 trace right after
> it runs aclocal, looking for expansion of LT_INIT (or the older
> AC_PROG_LIBTOOL).
>
> This means that for this to work at all:
>
>  (1) a macro definition of LT_INIT must be available at this time, and
>  (2) the LT_INIT macro must actually be expanded directly, and
>  (3) tracing must not be disabled.
>
> Normally aclocal will take care of (1).  Since this tool is part of
> Automake, this is something you have changed in your setup so it's
> plausible this is the underlying cause of your problem.
>
> aclocal works basically by grepping your configure.ac and all the files
> it knows about looking for things that look like macro definitions and
> things that look like macro expansions, and copying in any missing
> definitions.  So for this to work:
>
>   (1.1) aclocal must know where to find the definition of LT_INIT.
>   (1.2) aclocal must see the place where LT_INIT is expanded.
>
> Normally, aclocal and libtool are installed to the same prefix, libtool
> will install its macros into the default aclocal search path, and
> aclocal will find the macro definitions.  If they are installed into
> different prefixes, aclocal will need help, you can use the dirlist
> mechanism (recommended for a permanent installation) or for a quick fix,
> set the ACLOCAL_PATH environment variable to the installed location of
> the libtool macros.
>

Thanks for explaining this, Nick, and in fact the problem was
self-inflicted as I was installing the prerelease Automake versions to a
different prefix than libtool (and the base automake) without taking steps
to help aclocal find the libtool macro definitions.

After installing Libtool to the same prefix as the prerelease Automake, the
problem disappeared.

Cheers,
Dave Hart

[Message part 2 (text/html, inline)]

Message #16 received at 71487 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Dave Hart <davehart <at> gmail.com>, Nick Bowler <nbowler <at> draconx.ca>, 
 GNU Automake mailing list <automake <at> gnu.org>
Cc: 71487 <at> debbugs.gnu.org
Subject: Re: bug#71487: automake-1.16.92 released
Date: Sun, 30 Jun 2024 11:39:09 -0700

reopen 71487
thanks

Dave Hart <davehart <at> gmail.com> writes:

> After installing Libtool to the same prefix as the prerelease Automake, the
> problem disappeared.

I think you might have sent this to the wrong bug report.

Bug#71487 is an Emacs bug, see:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71487

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.