* Path of tool-bar icons
@ 2018-04-11 8:13 Mick Bert
2018-04-11 11:39 ` Arkadiusz Drabczyk
2018-04-12 12:39 ` Mick Bert
0 siblings, 2 replies; 25+ messages in thread
From: Mick Bert @ 2018-04-11 8:13 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
[not found] <mailman.12009.1523434449.27995.help-gnu-emacs@gnu.org>
@ 2018-04-11 9:22 ` Emanuel Berg
2018-04-11 11:20 ` Mick Bert
0 siblings, 1 reply; 25+ messages in thread
From: Emanuel Berg @ 2018-04-11 9:22 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 9:22 ` Path of tool-bar icons Emanuel Berg
@ 2018-04-11 11:20 ` Mick Bert
0 siblings, 0 replies; 25+ messages in thread
From: Mick Bert @ 2018-04-11 11:20 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 8:13 Mick Bert
@ 2018-04-11 11:39 ` Arkadiusz Drabczyk
2018-04-11 14:01 ` Mick Bert
2018-04-12 12:39 ` Mick Bert
1 sibling, 1 reply; 25+ messages in thread
From: Arkadiusz Drabczyk @ 2018-04-11 11:39 UTC (permalink / raw
To: help-gnu-emacs
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>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 11:39 ` Arkadiusz Drabczyk
@ 2018-04-11 14:01 ` Mick Bert
2018-04-11 14:36 ` Arkadiusz Drabczyk
` (3 more replies)
0 siblings, 4 replies; 25+ messages in thread
From: Mick Bert @ 2018-04-11 14:01 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 14:01 ` Mick Bert
@ 2018-04-11 14:36 ` Arkadiusz Drabczyk
2018-04-11 15:27 ` tomas
` (2 subsequent siblings)
3 siblings, 0 replies; 25+ messages in thread
From: Arkadiusz Drabczyk @ 2018-04-11 14:36 UTC (permalink / raw
To: help-gnu-emacs
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>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 14:01 ` Mick Bert
2018-04-11 14:36 ` Arkadiusz Drabczyk
@ 2018-04-11 15:27 ` tomas
2018-04-11 16:33 ` Eli Zaretskii
[not found] ` <mailman.12043.1523464419.27995.help-gnu-emacs@gnu.org>
3 siblings, 0 replies; 25+ messages in thread
From: tomas @ 2018-04-11 15:27 UTC (permalink / raw
To: help-gnu-emacs
-----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-----
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 14:01 ` Mick Bert
2018-04-11 14:36 ` Arkadiusz Drabczyk
2018-04-11 15:27 ` tomas
@ 2018-04-11 16:33 ` Eli Zaretskii
2018-04-11 18:42 ` tomas
` (2 more replies)
[not found] ` <mailman.12043.1523464419.27995.help-gnu-emacs@gnu.org>
3 siblings, 3 replies; 25+ messages in thread
From: Eli Zaretskii @ 2018-04-11 16:33 UTC (permalink / raw
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
[not found] ` <mailman.12043.1523464419.27995.help-gnu-emacs@gnu.org>
@ 2018-04-11 17:05 ` Emanuel Berg
2018-04-11 17:29 ` Eli Zaretskii
[not found] ` <mailman.12050.1523467772.27995.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 25+ messages in thread
From: Emanuel Berg @ 2018-04-11 17:05 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 17:05 ` Emanuel Berg
@ 2018-04-11 17:29 ` Eli Zaretskii
[not found] ` <mailman.12050.1523467772.27995.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2018-04-11 17:29 UTC (permalink / raw
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 16:33 ` Eli Zaretskii
@ 2018-04-11 18:42 ` tomas
2018-04-12 12:44 ` Eli Zaretskii
[not found] ` <mailman.12056.1523472150.27995.help-gnu-emacs@gnu.org>
2018-04-12 12:18 ` Mick Bert
2 siblings, 1 reply; 25+ messages in thread
From: tomas @ 2018-04-11 18:42 UTC (permalink / raw
To: help-gnu-emacs
-----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-----
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
[not found] ` <mailman.12050.1523467772.27995.help-gnu-emacs@gnu.org>
@ 2018-04-11 20:33 ` Emanuel Berg
0 siblings, 0 replies; 25+ messages in thread
From: Emanuel Berg @ 2018-04-11 20:33 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
[not found] ` <mailman.12056.1523472150.27995.help-gnu-emacs@gnu.org>
@ 2018-04-11 20:38 ` Emanuel Berg
2018-04-11 20:55 ` tomas
0 siblings, 1 reply; 25+ messages in thread
From: Emanuel Berg @ 2018-04-11 20:38 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 20:38 ` Emanuel Berg
@ 2018-04-11 20:55 ` tomas
2018-04-11 21:47 ` Drew Adams
[not found] ` <mailman.12074.1523483281.27995.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 25+ messages in thread
From: tomas @ 2018-04-11 20:55 UTC (permalink / raw
To: help-gnu-emacs
-----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-----
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: Path of tool-bar icons
2018-04-11 20:55 ` tomas
@ 2018-04-11 21:47 ` Drew Adams
2018-04-12 7:11 ` tomas
2018-04-12 11:26 ` Eli Zaretskii
[not found] ` <mailman.12074.1523483281.27995.help-gnu-emacs@gnu.org>
1 sibling, 2 replies; 25+ messages in thread
From: Drew Adams @ 2018-04-11 21:47 UTC (permalink / raw
To: tomas, help-gnu-emacs
<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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
[not found] ` <mailman.12074.1523483281.27995.help-gnu-emacs@gnu.org>
@ 2018-04-11 21:59 ` Emanuel Berg
2018-04-11 22:23 ` Drew Adams
0 siblings, 1 reply; 25+ messages in thread
From: Emanuel Berg @ 2018-04-11 21:59 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: Path of tool-bar icons
2018-04-11 21:59 ` Emanuel Berg
@ 2018-04-11 22:23 ` Drew Adams
0 siblings, 0 replies; 25+ messages in thread
From: Drew Adams @ 2018-04-11 22:23 UTC (permalink / raw
To: Emanuel Berg, help-gnu-emacs
> > <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".
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 21:47 ` Drew Adams
@ 2018-04-12 7:11 ` tomas
2018-04-12 11:26 ` Eli Zaretskii
1 sibling, 0 replies; 25+ messages in thread
From: tomas @ 2018-04-12 7:11 UTC (permalink / raw
To: Drew Adams; +Cc: help-gnu-emacs
-----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-----
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 21:47 ` Drew Adams
2018-04-12 7:11 ` tomas
@ 2018-04-12 11:26 ` Eli Zaretskii
2018-04-12 16:55 ` Drew Adams
1 sibling, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2018-04-12 11:26 UTC (permalink / raw
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 16:33 ` Eli Zaretskii
2018-04-11 18:42 ` tomas
[not found] ` <mailman.12056.1523472150.27995.help-gnu-emacs@gnu.org>
@ 2018-04-12 12:18 ` Mick Bert
2018-04-12 12:39 ` Eli Zaretskii
2 siblings, 1 reply; 25+ messages in thread
From: Mick Bert @ 2018-04-12 12:18 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-12 12:18 ` Mick Bert
@ 2018-04-12 12:39 ` Eli Zaretskii
0 siblings, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2018-04-12 12:39 UTC (permalink / raw
To: help-gnu-emacs
> 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?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 8:13 Mick Bert
2018-04-11 11:39 ` Arkadiusz Drabczyk
@ 2018-04-12 12:39 ` Mick Bert
1 sibling, 0 replies; 25+ messages in thread
From: Mick Bert @ 2018-04-12 12:39 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-11 18:42 ` tomas
@ 2018-04-12 12:44 ` Eli Zaretskii
2018-04-12 12:49 ` tomas
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2018-04-12 12:44 UTC (permalink / raw
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Path of tool-bar icons
2018-04-12 12:44 ` Eli Zaretskii
@ 2018-04-12 12:49 ` tomas
0 siblings, 0 replies; 25+ messages in thread
From: tomas @ 2018-04-12 12:49 UTC (permalink / raw
To: Eli Zaretskii; +Cc: help-gnu-emacs
-----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-----
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: Path of tool-bar icons
2018-04-12 11:26 ` Eli Zaretskii
@ 2018-04-12 16:55 ` Drew Adams
0 siblings, 0 replies; 25+ messages in thread
From: Drew Adams @ 2018-04-12 16:55 UTC (permalink / raw
To: Eli Zaretskii, help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2018-04-12 16:55 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.12009.1523434449.27995.help-gnu-emacs@gnu.org>
2018-04-11 9:22 ` Path of tool-bar icons Emanuel Berg
2018-04-11 11:20 ` Mick Bert
2018-04-11 8:13 Mick Bert
2018-04-11 11:39 ` Arkadiusz Drabczyk
2018-04-11 14:01 ` Mick Bert
2018-04-11 14:36 ` Arkadiusz Drabczyk
2018-04-11 15:27 ` tomas
2018-04-11 16:33 ` Eli Zaretskii
2018-04-11 18:42 ` tomas
2018-04-12 12:44 ` Eli Zaretskii
2018-04-12 12:49 ` tomas
[not found] ` <mailman.12056.1523472150.27995.help-gnu-emacs@gnu.org>
2018-04-11 20:38 ` Emanuel Berg
2018-04-11 20:55 ` tomas
2018-04-11 21:47 ` Drew Adams
2018-04-12 7:11 ` tomas
2018-04-12 11:26 ` Eli Zaretskii
2018-04-12 16:55 ` Drew Adams
[not found] ` <mailman.12074.1523483281.27995.help-gnu-emacs@gnu.org>
2018-04-11 21:59 ` Emanuel Berg
2018-04-11 22:23 ` Drew Adams
2018-04-12 12:18 ` Mick Bert
2018-04-12 12:39 ` Eli Zaretskii
[not found] ` <mailman.12043.1523464419.27995.help-gnu-emacs@gnu.org>
2018-04-11 17:05 ` Emanuel Berg
2018-04-11 17:29 ` Eli Zaretskii
[not found] ` <mailman.12050.1523467772.27995.help-gnu-emacs@gnu.org>
2018-04-11 20:33 ` Emanuel Berg
2018-04-12 12:39 ` Mick Bert
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.