I've been fiddling around a little with xpm-mode, but I don't understand
something.
Does anyone know why it's implemented as a minor mode with a mandated major
mode? I would have thought it would have been a major mode derived from
picture mode.
Is there something I'm missing?
Sincerely,
Byrel
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Ar an triú lá de mí Iúil, scríobh Stephen J. Turnbull:
> > And Mule is plenty fast enough these days,
>
> No, it's not. VM can tie up XEmacs for minutes when saving a 50MB
> folder. This includes autosaves, which means that XEmacs can drop
> dead without warning any time I'm reading mail.
What evidence do you have that this is Mule-specific? Do you ever run VM
under non-Mule?
--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Ar an triú lá de mí Iúil, scríobh Stephen J. Turnbull:
> Aidan Kehoe writes:
>
> > "Unibyte coding system" has no meaning in XEmacs.
>
> Of course it does.
No. “Unibyte” is an FSF term. I can guess what you meant by it, but not
everyone puts the amount of time you do into reading the FSF lists, it’s not
immediately clear in the absence of that time.
> > If a user is editing KOI8-R under non-Mule and has set a buffer’s font
> > to use a KOI8-R font, XEmacs corrupts data when Cyrillic is pasted in
> > from another app,
>
> I assume the other app is not using KOI8 then.
What? If the other app is using KOI8, it’ll transfer the selection using
either the UTF8_STRING or the COMPOUND_TEXT selection type, which will give
mojibake in XEmacs.
> That's a PEBKAC. If users want to work in a multi-encoding environment
> (which these days means "pretty much any interprocess communication"),
> they need to use Mule.
If the user wants non-Latin-1 data not to be trashed, they need to be using
Mule.
> > XEmacs will not assign Cyrillic text read from UTF-8 files on
> > disk to code points between #x80 and #x100, upcasing will leave
>
> And your point might be? In no-Mule XEmacs, Latin-1 is text and text
> modes will DTRT, other encodings are binary and require the same care
> as when editing a tar file or DOS .exe by hand.
That’s the first time I’ve seen that opinion.
> My point is simply that "C-u C-x C-f binary.file RET utf-8 RET C-x C-w
> copy.file RET" should either error or produce a byte-for-byte
> identical copy in any version of XEmacs. You can classify the current
> behavior as "wont fix", I'm not asking you to fix it. It is, however,
> a bug, and a bad one.
Well, I’ve modified the issue tracker entry to reflect what I think of the
issue. You’re free to change that.
> > character appears. This is unusable for inputting those characters.
>
> Sure, and there's no keyboard interface for producing tar file
> metadata if you edit a tar file. That doesn't mean XEmacs should
> corrupt the file just by reading it into a buffer and writing it back
> out again!
>
> > Trashing the user’s non-Latin-1 data is the fundamental design
> > decision of no-Mule.
>
> No. The fundamental design decision of no-Mule is that data is binary,
> and mixing data of different types is the user's responsibility.
No. Were that the case, different line-endings wouldn’t be transformed to
Unix, and the various packages that allow transparent access to compressed
and encrypted data would give up.
--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I installed the latest beta XEmacs 21.5.31 and was testing toolbars and
found a bug.
I put on a bottom toolbar with only text glyphs in it, though otherwise
identical to the default toolbar.
When I clicked open button, find-file dialog comes up, then 3-4 seconds
later XEmacs crashes and goes away.
If I use the open button on the default toolbar, it works fine.
I also noticed the bottom toolbar shows up on the find-file dialog
before it crashes.
Below is the lisp backtrace for XEmacs -vanilla, and attached are a C
backtrace, and the code I ran to put the toolbar up.
This works repeatedly, and was the same when running xemacs -vanilla.
It is similar to issue 697, but triggered differently. Should I start
another issue? Or put this in as a message under that issue?
exact error message:
Fatal error: assertion failed, file redisplay.c, line 9179, pos >= 0 &&
pos < dy->largest_
Fatal error (6).
--------------------------------------------------------------------------------------------
Lisp backtrace follows:
# (unwind-protect ...)
event-window(#<motion-event 28, 701 0x10b5>)
# bind (frame event)
default-mouse-motion-handler(#<motion-event 28, 701 0x10b5>)
("execute_internal_event()" "[internal]")
(dispatch-event "[internal]")
# (condition-case ... . error)
# (unwind-protect ...)
read-minibuffer-internal("Find file: ")
byte-code("..." [standard-output standard-input prompt
recursion-depth minibuffer-depth t read-minibuffer-internal] 2)
# (catch exit ...)
# bind (mouse-grabbed-buffer current-prefix-arg
minibuffer-history-variable minibuffer-history-position
minibuffer-scroll-window)
# (unwind-protect ...)
# bind (minibuffer-default oconfig mconfig frame buffer window oframe
owindow dir default abbrev-table history readp keymap initial-contents
prompt)
read-from-minibuffer("Find file: " "~/" #<keymap read-file-name-map
size 2 0x3c> nil file-name-history nil "~/toolbar-text-menu.el")
# bind (minibuffer-completion-table minibuffer-completion-predicate
minibuffer-completion-confirm last-exact-completion insert completer
initial-contents must-match default dir prompt history)
read-file-name-2(file-name-history "Find file: " nil
"~/toolbar-text-menu.el" nil nil read-file-name-internal)
# (unwind-protect ...)
# bind (window-min-height user-data dirwin filewin frame butbuf
dirbuf filebuf file-p completer initial-contents must-match default dir
prompt history)
mouse-read-file-name-1(file-name-history "Find file: " nil
"~/toolbar-text-menu.el" nil nil read-file-name-internal)
byte-code("..." [initial-contents must-match default dir prompt
history mouse-read-file-name-1 completer] 8)
# bind (completer initial-contents must-match default dir prompt
history type)
read-file-name-1(file file-name-history "Find file: " nil
"~/toolbar-text-menu.el" nil nil read-file-name-internal)
# bind (history initial-contents must-match default dir prompt)
read-file-name("Find file: ")
(list (read-file-name "Find file: ") (and current-prefix-arg
(read-coding-system "Coding system: ")) t)
call-interactively(find-file)
#<compiled-function (from toolbar-open) nil "...(4)"
[toolbar-open-function call-interactively] 2 1466147 nil 0xa40>()
call-interactively(toolbar-open)
# bind (callback button event)
release-and-activate-toolbar-button(#<buttonup-event button1up 0xf55>)
# bind (command-debug-status)
call-interactively(release-and-activate-toolbar-button)
(dispatch-event "[internal]")
# (condition-case ... . error)
# (catch top-level ...)
-----------------------------------------------------------------------------------------
Steve Mitchell
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Oops, copied from wrong buffer for 1st message:
Below are the commands I was using to create the toolbar:
;--- first make a blank toolbar structure
(setq text-icons-toolbar (make-toolbar-specifier nil))
;--- define buttons to go on the toolbar
(setq text-icon-open (toolbar-make-button-list "Open"))
(setq text-icon-dired (toolbar-make-button-list "Dired"))
(setq text-icon-save (toolbar-make-button-list "Save"))
;---add buttons to the new toolbar
(set-specifier text-icons-toolbar (cons (current-buffer)
(toolbar-add-item (specifier-instance text-icons-toolbar)[text-icon-open
toolbar-open t "Open a file"])))
(set-specifier text-icons-toolbar (cons 'global (toolbar-add-item
(specifier-instance text-icons-toolbar)[text-icon-dired
toolbar-dired t "Edit a directory"])))
(set-specifier text-icons-toolbar (cons 'global (toolbar-add-item
(specifier-instance text-icons-toolbar)[text-icon-save
toolbar-save t "Save buffer"] )))
;--- copy text-icons-toolbar to bottom-toolbar
(copy-specifier text-icons-toolbar bottom-toolbar)
;--- next 2 lines have to both be run to make the toolbar visible
(set-specifier bottom-toolbar-visible-p t) ; make the toolbar visible
(set-specifier bottom-toolbar-width 28 ) ; set the height of the
toolbar to (non zero) pixels
;--- set the border width,
;---- i.e. the border around the outside of all the icons as a group,
but not between them
(set-specifier bottom-toolbar-border-width 4) ; set the border width in
pixels
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I created a bottom toolbar, put any amount of icons in it, and when I
use the open icon on the built-in standard toolbar, the find-file dialog
box now has a bottom toolbar as well.
And if you make a left or right toolbar or _even a top toolbar,_ the
find-file dialog comes up with the same toolbars that you have defined.
It is inheriting them, I guess.
The standard built-in toolbar at the top is the default toolbar, and it
does not show up in a find-file dialog.
I'm asking if this is by design or just something wasn't looked at closely?
By happenstance, I duplicated the default menu with different icons as a
new bottom toolbar for experimenting making icons.
The problem then is that from within the find-file dialog on the new
bottom-toolbar you can press the open button, and open another copy of
the find-file dialog, then, since it has an open button on it's bottom
toolbar, you can open a third copy of the find-file dialog within that,
and I suppose you can keep doing that...
If this was an intentional part of the design, under what circumstances
would it be desirable to have toolbars inside a find-file dialog?
And if it is intentional, I would like to report a bug, that when
closing the third find-file dialog, the second find-file dialog no
longer displays your list of files on disk, it displays the contents of
one of your buffers, and then when closing the second find-file dialog
box, the original find-file dialog box displays the contents of a
different buffer. Like it is blindly executing a last-buffer command or
when closing the buffer that has the list of files, it has to select a
different buffer for the previous find-file dialog?
A sense of impending doom and specters of imminent crashes crept over
me, and I closed all find-file dialog boxes and started a new copy of
XEmacs.
How can I specify where a toolbar should show up?
a specifier, if this is a dialog box, don't display?
a tag predicate or a locale in a specifier?
Can a locale be anywhere-but-dialog-boxes?
On the main (default) toolbar, I can click [open] to start a find-file
dialog box, and then
click the [open] button again and open a second find-file dialog box.
Do we ever need more than one find-file dialog open at a time? If not,
then a test in find-file dialog to see if it is already open would be a
better place to prevent 2 open at once? Or simply gray-out the open
button when it is in use?
Steve Mitchell
Below are the commands I was using to create the toolbar:
;--- first make a blank toolbar structure
(setq text-icons-toolbar (make-toolbar-specifier nil))
;--- define buttons to go on the toolbar
(setq text-icon-open (toolbar-make-button-list "Open"))
(setq text-icon-dired (toolbar-make-button-list "Dired"))
(setq text-icon-save (toolbar-make-button-list "Save"))
;---add buttons to the new toolbar
(set-specifier text-icons-toolbar (cons (current-buffer)
(toolbar-add-item (specifier-instance text-icons-toolbar)[text-icon-open
toolbar-open t "Open a file"])))
(set-specifier text-icons-toolbar (cons 'global (toolbar-add-item
(specifier-instance text-icons-toolbar)[text-icon-dired
toolbar-dired t "Edit a directory"])))
(set-specifier text-icons-toolbar (cons 'global (toolbar-add-item
(specifier-instance text-icons-toolbar)[text-icon-save
toolbar-save t "Save buffer"] )))
;--- copy text-icons-toolbar to bottom-toolbar
(copy-specifier text-icons-toolbar top-toolbar)
;--- next 2 lines have to both be run to make the toolbar visible
(set-specifier top-toolbar-visible-p t) ; make the toolbar visible
(set-specifier top-toolbar-width 28 ) ; set the height of the
toolbar to (non zero) pixels
;--- set the border width,
;---- i.e. the border around the outside of all the icons as a group,
but not between them
(set-specifier top-toolbar-border-width 4) ; set the border width in pixels
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Mats, Marcus,
Both of you refer to "themed icons" and I am not understanding how you
mean that term. There are thousand's of icons already made on the
internet and thousands of themes that people put together with those
icons--exactly what themed icons are you talking about? It sounds like
you have something definite in mind with that term.
The problem I have using the tango icon set on my desktop is they do not
have (and do not intend to have) the size of icons that I use on my
desktop, I use the 128 x 128 size, which gives an icon of about 3/4" or
20mm square on a 30" monitor. I think Enlightenment might be scaling
them down some, and cannot tell for sure at the moment, but those sizes
I measured with a scale are actual.
Tango has a new optional size of 256 x 256 but I didn't see any themes
that include that optional size (which could be scaled down to 128 x 128
individually in gimp). Could be because it is optional and maybe
because it is new. Or maybe I didn't search hard enough.
I agree the icons that come with XEmacs could use improving, and for me
the biggest improvement would be the size. I measured the icons that
are default in XEmacs and they measure 3/8" or 10mm square and the text
is not readily readable.
Just to be clear, I don't want icons 3/4" x 3/4" in an application, that
is just what size I use on my desktop, my thought was maybe "themed
icons" referred to the same theme as the user was using on their desktop.
I spent some time last week learning how XEmacs does icons and feel
confident that I could write a Icon Theme menu that would let you with
one click change between sets of icons or their size. A list could be
stored in a file for each theme--you just edit a template file to point
to the location of the icons you want to use. Is that the kind of
improvement people want to see? Ease of switching between icons or icon
sets?
It is not hard to create icons, just time consuming. Is that what
people who what better icons in XEmacs want? Being able to use New
Icons without the drudgery involved in creating them? A lot of good
icons exist...
I asked which icons people wanted in a complete "set" of XEmacs icons
before, trying to get an idea which icons that tango, for example, would
not have in their themes (thinking news, for example), that would have
to be created to have a full set for an XEmacs icon theme.
I would also like to ask: what sizes should the XEmacs icons come in?
Currently they are only in one size:
28 x 28 icon only and 33 x 33 icon with label.
Steve Mitchell
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2011-06-28 - 2011-07-05)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
531 open ( +5) / 249 closed ( +0) / 780 total ( +5)
Open issues with patches: 12
Average duration of open issues: 885 days.
Median duration of open issues: 948 days.
Open Issues Breakdown
new 193 ( +4)
deferred 6 ( +0)
napping 4 ( +0)
verified 54 ( +0)
assigned 152 ( +1)
committed 29 ( +0)
documented 3 ( +0)
done/needs work 24 ( +0)
Issues Created Or Reopened (5)
______________________________
21.5b31: gnus v5.10.8 attempts to render faces in text mode, g 2011-06-29
http://tracker.xemacs.org/XEmacs/its/issue778 created tkil
xemacs 21.5.31 fails compilation with +motif -xft 2011-06-30
http://tracker.xemacs.org/XEmacs/its/issue779 created graaff
No-mule XEmacs can corrupt UTF-8 files. 2011-07-02
http://tracker.xemacs.org/XEmacs/its/issue780 created stephen
"Make me a developer"/"Assign to me" UI inconvenient at best, 2011-07-02
http://tracker.xemacs.org/XEmacs/its/issue781 created stephen
add #'test-completion for Emacs compatibility 2011-07-05
http://tracker.xemacs.org/XEmacs/its/issue782 created mike.kupfer
Top Issues Most Discussed (1)
_____________________________
4 21.5b31: gnus v5.10.8 attempts to render faces in text mode, ge 6 days
assigned http://tracker.xemacs.org/XEmacs/its/issue778
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I'm in favor of new icons, and am willing to help.
and have been working on some icons for myself
for a while now, though understanding glyphs is taking me a while to
accomplish, and the time it takes to make icons
all from scratch. From scratch, because I see millions of icons in the
internet with unknown licenses, and am cautious of stepping on
somebody's toes by giving them out with XEmacs.
I find I have never used some of the icons that are on the iconbar now,
and wish there were icons for additional (different) tasks from the
current set.
2 questions, 2 comments:
1. What do people want to do with icons?
personally I use the one-button-click save as I save
pretty frequently. What do other people actually
want to use their iconbar for?
2. what icons should be included in a "complete set"
of icons that we are talking about making here?
3. Also, I wonder if we did do some new icons if that would be
enough. Wouldn't we also want to do some other components
on the screen, like the iconbar background, and then make
the menubar background to match it, then there are the gutters with the
scroll bars, surely they should match the menubar too. Where do you
stop? Do you implement full
theming? All the sudden this looks like it would grow into a full
facelift and take a large amount of all of our time.
4. If we do make a set (or several) of icons and update the screen's
looks, it would be nice to make a lisp file to automatically change all
the icons to a new set, and a lisp file to change all the icons back to
the defaults, in case they get messed up by user modifications along the
way.
Steve Mitchell
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I cannot cvs ci to the packages today. Here's what I get:
Can't do setuid (cannot exec sperl)
cvs commit: Pre-commit check failed
cvs [commit aborted]: correct above errors first!
Here's my setup:
CVS/Repository: XEmacs/packages
CVS/Root: :ext:didier-guest@cvs.debian.org:/cvs/xemacs
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta