Path of tool-bar icons

Path of tool-bar icons

[Mick Bert]

Hello
Working on a RHEL host machine, administrators  installed emacs from a
subset of official repository (i don't know have many details about it),
version:

  GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu,
  GTK+ Version 3.22.10) of 2017-09-12
  on x86-017.build.eng.bos.redhat.com

When I run it, it does not display any icon in the toolbar. Icons are at
path:

  /usr/share/emacs/24.3/etc/images

How can I know where emacs is looking for icons, or possibly change such
path?

--
Mick

Re: Path of tool-bar icons

[Emanuel Berg]

Mick Bert wrote:

> When I run it, it does not display any icon
> in the toolbar. Icons are at path:
>
>   /usr/share/emacs/24.3/etc/images
>
> How can I know where emacs is looking for
> icons, or possibly change such path?

Well, I don't use RHEL or icons or tool bars,
but if Emacs couldn't find the icons, wouldn't
that have rendered an error rather than the
icons peacefully not showing up? Perhaps they
are just disabled?

Check out `tool-bar-style' if you're on GTK+.
Or perhaps `tool-bar-images-pixel-height' is
set to 0 :)

    tool-bar-style is a variable defined in `C
    source code'. Its value is nil

    Documentation:
    Tool bar style to use.
    It can be one of
     image            - show images only
     text             - show text only
     both             - show both, text below image
     both-horiz       - show text to the right of the image
     text-image-horiz - show text to the left of the image
     any other        - use system default or image if no system default.

    This variable only affects the GTK+ toolkit
    version of Emacs.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Path of tool-bar icons

[Mick Bert]

2018-04-11 11:22 GMT+02:00 Emanuel Berg <moasen@zoho.com>:
>
> Mick Bert wrote:
>
> > When I run it, it does not display any icon
> > in the toolbar. Icons are at path:
> >
> >   /usr/share/emacs/24.3/etc/images
> >
> > How can I know where emacs is looking for
> > icons, or possibly change such path?
>
> Well, I don't use RHEL or icons or tool bars,
> but if Emacs couldn't find the icons, wouldn't
> that have rendered an error rather than the
> icons peacefully not showing up? Perhaps they
> are just disabled?

No messages at all on strerr ot stdout. Toolbar is enable as by default.
I can disable and enable it with M-x tool-bar-mode, the toolbar disappear
and appear again, but empty. I can click buttons (and they works), and I
see tool-tips rolling with mouse pointer, but all I can see is a uniform
gray strip.
>
> Check out `tool-bar-style' if you're on GTK+.
> Or perhaps `tool-bar-images-pixel-height' is
> set to 0 :)

Neither the first nor the second variable affect the toolbar at all. I set
them with:

  M-x eval-expression
than
  (setq tool-bar-images-pixel-height 40)

>     This variable only affects the GTK+ toolkit
>     version of Emacs.

The version of emacs I wrote in the first email was the resulat of

  M-x version

so I think is reliable.

--
Mick

Re: Path of tool-bar icons

[Arkadiusz Drabczyk]

On 2018-04-11, Mick Bert <micbert75@gmail.com> wrote:
> Hello
> Working on a RHEL host machine, administrators  installed emacs from a
> subset of official repository (i don't know have many details about it),
> version:
>
>   GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu,
>   GTK+ Version 3.22.10) of 2017-09-12
>   on x86-017.build.eng.bos.redhat.com
>
> When I run it, it does not display any icon in the toolbar. Icons are at
> path:
>
>   /usr/share/emacs/24.3/etc/images
>
> How can I know where emacs is looking for icons

You can use strace to check, example output:

$ strace emacs |& grep access | grep /images
faccessat(AT_FDCWD, "/usr/share/emacs/24.5/etc/images/new.xpm", R_OK) = 0
faccessat(AT_FDCWD, "/usr/share/emacs/24.5/etc/images/open.xpm", R_OK) = 0
faccessat(AT_FDCWD, "/usr/share/emacs/24.5/etc/images/diropen.xpm", R_OK) = 0
faccessat(AT_FDCWD, "/usr/share/emacs/24.5/etc/images/close.xpm", R_OK) = 0
faccessat(AT_FDCWD, "/usr/share/emacs/24.5/etc/images/save.xpm", R_OK) = 0
(...)
-- 
Arkadiusz Drabczyk <arkadiusz@drabczyk.org>

Re: Path of tool-bar icons

[Mick Bert]

2018-04-11 13:39 GMT+02:00 Arkadiusz Drabczyk <arkadiusz@drabczyk.org>:
>
> You can use strace to check, example output:
>
> $ strace emacs |& grep access | grep /images

Nice idea. After few tests, I used the command:

 trace /usr/bin/emacs-24.3|& grep '\.[bx]pm' | grep share |grep images

I report here an extract of what I get:

  stat("/usr/share/emacs/24.3/etc/images/new.xpm",
{st_mode=S_IFREG|0644, st_size=3331, ...}) = 0
  open("/usr/share/emacs/24.3/etc/images/new.xpm", O_RDONLY) = 15
  stat("/usr/share/emacs/24.3/etc/images/new.xpm",
{st_mode=S_IFREG|0644, st_size=3331, ...}) = 0
  open("/usr/share/emacs/24.3/etc/images/new.xpm", O_RDONLY) = 15
  open("/usr/share/emacs/24.3/etc/images/new.xpm", O_RDONLY) = 15
  stat("/usr/share/emacs/24.3/etc/images/open.xpm",
{st_mode=S_IFREG|0644, st_size=4068, ...}) = 0
  open("/usr/share/emacs/24.3/etc/images/open.xpm", O_RDONLY) = 15
  stat("/usr/share/emacs/24.3/etc/images/open.xpm",
{st_mode=S_IFREG|0644, st_size=4068, ...}) = 0
  open("/usr/share/emacs/24.3/etc/images/open.xpm", O_RDONLY) = 15
  open("/usr/share/emacs/24.3/etc/images/open.xpm", O_RDONLY) = 15
  ...

Therefore it looks it is reading the images, so why isn't it displaying them?
Any idea?

--
Mick

Re: Path of tool-bar icons

[Arkadiusz Drabczyk]

On 2018-04-11, Mick Bert <micbert75@gmail.com> wrote:
> 2018-04-11 13:39 GMT+02:00 Arkadiusz Drabczyk <arkadiusz@drabczyk.org>:
>>
>> You can use strace to check, example output:
>>
>> $ strace emacs |& grep access | grep /images
>
> Nice idea. After few tests, I used the command:
>
>  trace /usr/bin/emacs-24.3|& grep '\.[bx]pm' | grep share |grep images
>
> I report here an extract of what I get:
>
>   stat("/usr/share/emacs/24.3/etc/images/new.xpm",
> {st_mode=S_IFREG|0644, st_size=3331, ...}) = 0
>   open("/usr/share/emacs/24.3/etc/images/new.xpm", O_RDONLY) = 15
>   stat("/usr/share/emacs/24.3/etc/images/new.xpm",
> {st_mode=S_IFREG|0644, st_size=3331, ...}) = 0
>   open("/usr/share/emacs/24.3/etc/images/new.xpm", O_RDONLY) = 15
>   open("/usr/share/emacs/24.3/etc/images/new.xpm", O_RDONLY) = 15
>   stat("/usr/share/emacs/24.3/etc/images/open.xpm",
> {st_mode=S_IFREG|0644, st_size=4068, ...}) = 0
>   open("/usr/share/emacs/24.3/etc/images/open.xpm", O_RDONLY) = 15
>   stat("/usr/share/emacs/24.3/etc/images/open.xpm",
> {st_mode=S_IFREG|0644, st_size=4068, ...}) = 0
>   open("/usr/share/emacs/24.3/etc/images/open.xpm", O_RDONLY) = 15
>   open("/usr/share/emacs/24.3/etc/images/open.xpm", O_RDONLY) = 15
>   ...
>
> Therefore it looks it is reading the images, so why isn't it displaying them?
> Any idea?

Can you display these images with an image viewer?  You can also try
starting emacs with -Q just for the case:

-Q, --quick
        Similar to "-q --no-site-file --no-splash".  Also, avoid
	processing X resources.

-- 
Arkadiusz Drabczyk <arkadiusz@drabczyk.org>

Re: Path of tool-bar icons

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Apr 11, 2018 at 04:01:25PM +0200, Mick Bert wrote:
> 2018-04-11 13:39 GMT+02:00 Arkadiusz Drabczyk <arkadiusz@drabczyk.org>:
> >
> > You can use strace to check, example output:
> >
> > $ strace emacs |& grep access | grep /images
> 
> Nice idea. After few tests, I used the command:
> 
>  trace /usr/bin/emacs-24.3|& grep '\.[bx]pm' | grep share |grep images
> 
> I report here an extract of what I get:
> 
>   stat("/usr/share/emacs/24.3/etc/images/new.xpm",
> {st_mode=S_IFREG|0644, st_size=3331, ...}) = 0

[...]

> Therefore it looks it is reading the images, so why isn't it displaying them?
> Any idea?

Silly question, but... was your Emacs configured with XPM support?

You can check that by loading one of those images with Emacs: you
should be able to change between "display as text" and "display as
image" with C-c C-c.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrOKWIACgkQBcgs9XrR2kYtJwCePEcrwW5OMspfZFxaH9caR+vs
w+oAniq+LwbiuZk/ss3lA0gHa7Hek8R7
=9dpU
-----END PGP SIGNATURE-----

Re: Path of tool-bar icons

[Eli Zaretskii]

> From: Mick Bert <micbert75@gmail.com>
> Date: Wed, 11 Apr 2018 16:01:25 +0200
> 
> 2018-04-11 13:39 GMT+02:00 Arkadiusz Drabczyk <arkadiusz@drabczyk.org>:
> >
> > You can use strace to check, example output:
> >
> > $ strace emacs |& grep access | grep /images
> 
> Nice idea. After few tests, I used the command:
> 
>  trace /usr/bin/emacs-24.3|& grep '\.[bx]pm' | grep share |grep images
> 
> I report here an extract of what I get:
> 
>   stat("/usr/share/emacs/24.3/etc/images/new.xpm",
> {st_mode=S_IFREG|0644, st_size=3331, ...}) = 0
>   open("/usr/share/emacs/24.3/etc/images/new.xpm", O_RDONLY) = 15
>   stat("/usr/share/emacs/24.3/etc/images/new.xpm",
> {st_mode=S_IFREG|0644, st_size=3331, ...}) = 0
>   open("/usr/share/emacs/24.3/etc/images/new.xpm", O_RDONLY) = 15
>   open("/usr/share/emacs/24.3/etc/images/new.xpm", O_RDONLY) = 15
>   stat("/usr/share/emacs/24.3/etc/images/open.xpm",
> {st_mode=S_IFREG|0644, st_size=4068, ...}) = 0
>   open("/usr/share/emacs/24.3/etc/images/open.xpm", O_RDONLY) = 15
>   stat("/usr/share/emacs/24.3/etc/images/open.xpm",
> {st_mode=S_IFREG|0644, st_size=4068, ...}) = 0
>   open("/usr/share/emacs/24.3/etc/images/open.xpm", O_RDONLY) = 15
>   open("/usr/share/emacs/24.3/etc/images/open.xpm", O_RDONLY) = 15
>   ...

Jeez, crowd, whatever happened to reading the fine docs (or the
sources, for that matter)?

  image-load-path is a variable defined in ‘image.el’.
  Its value is
  ("/usr/share/emacs/26.1/etc/images/" data-directory load-path)

  Documentation:
  List of locations in which to search for image files.
  If an element is a string, it defines a directory to search.
  If an element is a variable symbol whose value is a string, that
  value defines a directory to search.
  If an element is a variable symbol whose value is a list, the
  value is used as a list of directories to search.

  Subdirectories are not automatically included in the search.

Re: Path of tool-bar icons

[Emanuel Berg]

Eli Zaretskii wrote:

> Jeez, crowd, whatever happened to reading the
> fine docs (or the sources, for that matter)?
>
>   image-load-path

I still think it should be an error if images
are enabled, and an image is asked for, but
cannot be found.

And in that error message, one can include
a reference to `image-load-path'!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Path of tool-bar icons

[Eli Zaretskii]

> From: Emanuel Berg <moasen@zoho.com>
> Date: Wed, 11 Apr 2018 19:05:44 +0200
> 
> I still think it should be an error if images
> are enabled, and an image is asked for, but
> cannot be found.

We already do insert an error message into *Messages*, we just don't
display it, because the image is looked up during redisplay, and
displaying an error from redisplay is a bad idea: the error message
will trigger another redisplay cycle, which will again signal the
error, etc.

> And in that error message, one can include
> a reference to `image-load-path'!

I'm not sure (you are talking about a broken installation), but feel
free to file a bug report about that.

Re: Path of tool-bar icons

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Apr 11, 2018 at 07:33:43PM +0300, Eli Zaretskii wrote:

[...]

> Jeez, crowd, whatever happened to reading the fine docs (or the
> sources, for that matter)?

:-)

[image-load-path]

You are right, of course. But... I must admit that I searched for
something with "icon" and failed miserably (something with "path"
would've led me to image-load-path). I didn't try the sources yet.

This is a difficult thing in Emacs: it has its own (strong) culture
and its lexicon sometimes differs in subtle ways from people's
expectations. Now I don't have a good idea on how to tackle that :-(

Cheers & thanks
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrOVwwACgkQBcgs9XrR2kYLQQCff64p+6NCWc7z6j3s9BCrCsAN
ZlYAn0ItkU5Ut0C1+KHL9p6liwCtChzc
=M8C2
-----END PGP SIGNATURE-----

Re: Path of tool-bar icons

[Emanuel Berg]

Eli Zaretskii wrote:

> We already do insert an error message into
> *Messages*

OK, no, that's sufficient.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Path of tool-bar icons

[Emanuel Berg]

tomas wrote:

> This is a difficult thing in Emacs: it has
> its own (strong) culture and its lexicon
> sometimes differs in subtle ways from
> people's expectations.

There are a couple of such cases but it isn't
epidemic like some people like to exaggerate,
often to push the "Emacs is difficult to learn"
notion, likewise exaggerated. There was a guy on
this list who made a big hullabaloo of some
window/frame issue for example...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Path of tool-bar icons

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Apr 11, 2018 at 10:38:43PM +0200, Emanuel Berg wrote:
> tomas wrote:
> 
> > This is a difficult thing in Emacs: it has
> > its own (strong) culture and its lexicon
> > sometimes differs in subtle ways from
> > people's expectations.
> 
> There are a couple of such cases but it isn't
> epidemic like some people like to exaggerate,
> often to push the "Emacs is difficult to learn"
> notion, likewise exaggerated. There was a guy on
> this list who made a big hullabaloo of some
> window/frame issue for example...

I think it *is* a hurdle. I don't think changing Emacs'
culture is a solution to that (nor that it's desirable,
for that). But I do think it helps being aware of it.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrOdksACgkQBcgs9XrR2kYUrQCcDTGT7IKWiCk7kziltr69Bzch
UE0An2tqAiUGc1SZ3OeYpVDYN4l02FEh
=wfF6
-----END PGP SIGNATURE-----

RE: Path of tool-bar icons

[Drew Adams]

<user looks for "icon" instead of what Emacs expects: "image">

> > > This is a difficult thing in Emacs: it has
> > > its own (strong) culture and its lexicon
> > > sometimes differs in subtle ways from
> > > people's expectations.
> >
> > There are a couple of such cases but it isn't
> > epidemic like some people like to exaggerate,
> > often to push the "Emacs is difficult to learn"
> > notion, likewise exaggerated. There was a guy on
> > this list who made a big hullabaloo of some
> > window/frame issue for example...
> 
> I think it *is* a hurdle. I don't think changing Emacs'
> culture is a solution to that (nor that it's desirable,
> for that). But I do think it helps being aware of it.

1. `C-h r'

`i glossary'
(or `g glossary', if you know there is a node named Glossary)

If you want to suggest a common term to add to the glossary,
to xref a more traditional Emacs term, even if the two are
not exactly synonymous, you can do that: `M-x report-emacs-bug'.

For example, search the glossary for "paste" and you'll
find this entry:

  Cut and Paste
      see Glossary--Killing, and see Glossary--Yanking

Those are links, after "see".  They should take you to the
glossary entries "killing" and "yanking", respectively.

Unfortunately, a regression was apparently introduced in
Emacs 24.5 - those links now take you elsewhere.  I just
filed bug #31130 for this.

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

(The fact that this regression has apparently gone
unnoticed since Emacs 24.5 maybe indicates how little use
people make of at least some glossary entries, if not the
glossary itself.)


2. There is also this page on Emacs Wiki:
https://www.emacswiki.org/emacs/EmacsJargon


3. However, I'm not sure that this problem of
looking-for-"icon"-instead-of-"image" is really a
problem of Emacs using uncommon jargon.  I'd think
that it's kinda natural to look for "image" if "icon"
finds no hits wrt the tool bar.

Re: Path of tool-bar icons

[Emanuel Berg]

Drew Adams wrote:

> <user looks for "icon" instead of what Emacs
> expects: "image">
> [...]
> 1. `C-h r'
>
> `i glossary'
> (or `g glossary', if you know there is a node
> named Glossary)

    Tool Bar
         The tool bar is a line (sometimes multiple
         lines) of icons at the top of an Emacs
         frame. Clicking on one of these icons
         executes a command. You can think of this
         as a graphical relative of the menu bar
         (q.v.). *Note Tool Bars::.

So ?

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: Path of tool-bar icons

[Drew Adams]

> > <user looks for "icon" instead of what Emacs
> > expects: "image">
> > [...]
> > 1. `C-h r'
> >
> > `i glossary'
> > (or `g glossary', if you know there is a node
> > named Glossary)
> 
> So ?

1. My point was that if someone really thinks that some
Emacs users will think only "icon" and never "image"
in this context, and it is a sufficiently important
problem, they can ask that the two terms be added to
the glossary and linked there.  Emacs jargon uses
"yank", but newbies can find it under "paste" in the
glossary.

(Personally, I can't imagine not thinking of looking
for "image" if I didn't find what I was looking for
under "icon".  But users look for things differently,
and users have different vocabularies and mental
models.)

Even without bringing the glossary into it (and this
is a case where the glossary is not really relevant,
I think - "image" is not really Emacs jargon), you
could request an _index_ entry for "icon" that links
to where `image-load-path' is discussed.

2. But that variable is covered only in the Elisp
manual, not the Emacs manual.  There is an index entry
for it, but index entries that contain substring "icon"
don't lead there.  So if someone thought this was a real
discovery problem s?he could request an index entry in
the Elisp manual for "icon file locations" or some such,
which would take you to the same node (`Defining Images').

3. But it is true that if something is not in one
of the manuals then there is no equivalent of indexing
or a glossary.  (But you can google or search Emacs Wiki.)

You can search doc strings or use apropos commands,
including `apropos-documentation', but that just
searches doc strings literally.  It doesn't take advantage
of someone having created an explicit link (xref) between
"icon" and "image".

Re: Path of tool-bar icons

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Apr 11, 2018 at 02:47:39PM -0700, Drew Adams wrote:
> <user looks for "icon" instead of what Emacs expects: "image">
> 
> > > > This is a difficult thing in Emacs: it has
> > > > its own (strong) culture [...]

> 1. `C-h r'
> 
> `i glossary'
> (or `g glossary', if you know there is a node named Glossary)
> 
> If you want to suggest a common term to add to the glossary,
> to xref a more traditional Emacs term, even if the two are
> not exactly synonymous, you can do that: `M-x report-emacs-bug'.

Thanks! I didnn't know about "glossary". This is actually a
compelling approach. I'll spend some time with that.

[...]

> 3. However, I'm not sure that this problem of
> looking-for-"icon"-instead-of-"image" is really a
> problem of Emacs using uncommon jargon.  I'd think
> that it's kinda natural to look for "image" if "icon"
> finds no hits wrt the tool bar.

Remember that not all of us are native English speakers,
thus composing the subtle lexical problem.

Of course, after the fact it's even clear to me that I
should have tried "image" after having failed with "icon",
but that's too late :)

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrPBo4ACgkQBcgs9XrR2kbAwQCcDKtCpajU6voJz4Xa+FmH8PZc
qW8An1xldenW6lOxhP9KoQpo19dzk2zm
=kT0O
-----END PGP SIGNATURE-----

Re: Path of tool-bar icons

[Eli Zaretskii]

> Date: Wed, 11 Apr 2018 14:47:39 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> For example, search the glossary for "paste" and you'll
> find this entry:
> 
>   Cut and Paste
>       see Glossary--Killing, and see Glossary--Yanking
> 
> Those are links, after "see".  They should take you to the
> glossary entries "killing" and "yanking", respectively.
> 
> Unfortunately, a regression was apparently introduced in
> Emacs 24.5 - those links now take you elsewhere.  I just
> filed bug #31130 for this.
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31130

Actually, as I reported on the bug tracker, there's no regression, and
the problem is most probably local to Drew's system.

> (The fact that this regression has apparently gone
> unnoticed since Emacs 24.5 maybe indicates how little use
> people make of at least some glossary entries, if not the
> glossary itself.)

Actually, I've reviewed all the Glossary entries a couple of months
ago (in preparation for Emacs 26.1 release), so I think you are too
quick to draw conclusions from unconfirmed problem reports.

Re: Path of tool-bar icons

[Mick Bert]

2018-04-11 18:33 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:
>
> Jeez, crowd, whatever happened to reading the fine docs (or the
> sources, for that matter)?
>
>   image-load-path is a variable defined in ‘image.el’.
>   Its value is
>   ("/usr/share/emacs/26.1/etc/images/" data-directory load-path)
>
>   Documentation:
>   List of locations in which to search for image files.
>   If an element is a string, it defines a directory to search.
>   If an element is a variable symbol whose value is a string, that
>   value defines a directory to search.
>   If an element is a variable symbol whose value is a list, the
>   value is used as a list of directories to search.
>
>   Subdirectories are not automatically included in the search.
>

As I expected, image-load-path has the correct value, and if I try
to open the file in an emacs buffer, copying the path from the *Help*
buffer (in order to be sure it matches), imeges are correctly loaded
(as you can see in the picture linked [1]).

Are there anything I can check in the X resources? That's the
emacs entries:

~ $xrdb -query|grep -i emacs
emacs*cursorBlibk:    true
emacs*cursorColor:    #404040
emacs*font:    -*-fixed-*-r-*-*-10-*-*-*-*-*-*-*
emacs*foreground:    #404040
emacs*fullscreen:    false
emacs*geometry:    140x80
emacs*reverseVideo:    true
emacs*toolBar:    true


[1] http://hilbert.users.micso.net/images/emacs-tool-bar.png

--
Mick

Re: Path of tool-bar icons

[Eli Zaretskii]

> From: Mick Bert <micbert75@gmail.com>
> Date: Thu, 12 Apr 2018 14:18:29 +0200
> 
> As I expected, image-load-path has the correct value, and if I try
> to open the file in an emacs buffer, copying the path from the *Help*
> buffer (in order to be sure it matches), imeges are correctly loaded
> (as you can see in the picture linked [1]).
> 
> Are there anything I can check in the X resources? That's the
> emacs entries:
> 
> ~ $xrdb -query|grep -i emacs
> emacs*cursorBlibk:    true
> emacs*cursorColor:    #404040
> emacs*font:    -*-fixed-*-r-*-*-10-*-*-*-*-*-*-*
> emacs*foreground:    #404040
> emacs*fullscreen:    false
> emacs*geometry:    140x80
> emacs*reverseVideo:    true
> emacs*toolBar:    true

Report this as a bug, using "M-x report-emacs-bug RET".  This ceased
to be a help-gnu-emacs issue long ago.

In the original bu report, you said:

> Working on a RHEL host machine, administrators  installed emacs from a
> subset of official repository (i don't know have many details about it),
> version:
> 
>   GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu,
>   GTK+ Version 3.22.10) of 2017-09-12
>   on x86-017.build.eng.bos.redhat.com

What does "subset of official repository" mean in this context?  IOW,
what is unusual in this Emacs installation, as far as you know?

Re: Path of tool-bar icons

[Mick Bert]

2018-04-11 10:13 GMT+02:00 Mick Bert <micbert75@gmail.com>:
>
> When I run it, it does not display any icon in the toolbar. Icons are at
> path:
>

Stop tormentig youself (I do)!
Eventually I found that [1] RHEL bug (I suppose related more to gtk,
rather than emacs itself)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1477745


--
Mick

Re: Path of tool-bar icons

[Eli Zaretskii]

> Date: Wed, 11 Apr 2018 20:42:20 +0200
> From: <tomas@tuxteam.de>
> 
> [image-load-path]
> 
> You are right, of course. But... I must admit that I searched for
> something with "icon" and failed miserably (something with "path"
> would've led me to image-load-path). I didn't try the sources yet.

Fixed.

Re: Path of tool-bar icons

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 12, 2018 at 03:44:59PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 11 Apr 2018 20:42:20 +0200
> > From: <tomas@tuxteam.de>
> > 
> > [image-load-path]
> > 
> > You are right, of course. But... I must admit that I searched for
> > something with "icon" and failed miserably (something with "path"
> > would've led me to image-load-path). I didn't try the sources yet.
> 
> Fixed.

Awesome. You rock!

thanks
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrPVb0ACgkQBcgs9XrR2kaeUwCfc5mRDqHu5jJd5wLnc7crpNY5
DFsAnR5orxQMBcyw8H/m1nqbaBYF0eHj
=x40R
-----END PGP SIGNATURE-----

RE: Path of tool-bar icons

[Drew Adams]

> Actually, as I reported on the bug tracker, there's no regression, and
> the problem is most probably local to Drew's system.

There was a regression in Emacs 24.5 (it is still present
in 24.5).

I tested using emacs -Q in Emacs 26, 25.3.1, 24.5, 24.4,
and even 23.4, 22.3, and 20.

But I had multiple sessions for different releases open
at the same time, and it seems that somehow that affected
even the emacs -Q tests (?).  I can't repro the problem
now with releases after 24.5.