DNS resolution errors from make-network-process are signalled
immediately, and not passed to the sentinel function. Make sure that
we pass such errors along, so DNS errors aren't buried in the
*fsm-debug* buffer.
Avoid breaking existing installations: if the global history file
already exists, use it; if the file/directory exists at the old
location, keep using it.
Requiring jabber-autoloads from .emacs or a similar location is the
only supported way to load jabber.el, and it's also the way it gets
done when installing it as a package.
If there are no connections, disable "Disconnect".
If there are no unread messages, disable "Next unread message".
This also ensures that the functions are loaded when the user might
try to activate the menu item.
If the user installed the package into `package-user-dir' (as opposed
to a system-wide installation), it should be fine to display a Jabber
menu by default (which still can be turned off).
...instead of the other way around. This should make it possible to
build an ELPA-style package straight out of Git without running
autoconf, while we'd still be able to build tarballs through automake.
Sometimes this fails because the connection is closed. Not sure
exactly why this happens, but the sentinel function should discover
the lost connection anyway, and having an error signalled in a timer
function doesn't help anyone.
When using native GnuTLS, we can now connect asynchronously, without
blocking Emacs if the remote server is slow to accept the connection
(or just times out).
Such connections are now identical to "network" (i.e. TLS-less)
connections, so I reverted jabber-starttls-connect to its previous
state: it is now used exclusively to connect using gnutls-cli external
processes.
They shouldn't be used just to have them listed in Customize; see
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14247 . Besides, they
should be loaded by the requires in jabber.el anyway.
I left jabber-account-list and jabber-display-menu in for now, as they
are involved in a complicated dance regarding whether to display the
Jabber menu by default. Need to solve this somehow and get rid of
those two autoload cookies as well.
This directory should never be added to any load path, since
jabber-muc-nick-coloring.el explicitly specifies the directory when
referencing hexrgb. We wouldn't want to override any newer,
separately installed, hexrgb.el.
Adding this file should make life easier for emacsmirror.
While jabber-sexp2xml has no problems with them, xml-print (used by
jabber-console) doesn't like them. This causes truncated stanzas in
the XML log and error messages like these:
Couldn't write XML log: Wrong type argument: char-or-string-p, nil
That makes it impossible to run Emacs if jabber-debug-log-xml has been
customized, but jabber-console.el is not in the load path for some
reason. Instead add an autoload cookie for jabber-process-console to
ensure that it gets loaded when needed. Also remove duplicate
definition of jabber-buffer-connection.
sha1.el was included in Emacs 22.1 (released in 2007) and has since
been replaced by native functions; there's no point in us including it
anymore. hex-util.el was only used by sha1.el.
Newer versions of Automake (since 1.13) treat Emacs Lisp files in
subdirectories differently, which causes problems with hexrgb.el. I
made it copy hexrgb.el into the top directory, and it seems to work
for me.
Update README. New minimum version is 23.1, which is when dns.el
started supporting SRV queries. (Still need to update TLS section.)
TESTS_ENVIRONMENT is no longer a safe place to put an Emacs
invocation. However, LOG_COMPILER was introduced in Automake 1.12 for
such things.
Tested with Automake 1.13.1.
# By Magnus Henoch (18) and others
# Via Magnus Henoch
* upstream: (31 commits)
Ensure that jabber-bookmarks is loaded in jabber-jid-bookmarkname
Fix :get function for jabber-roster-default-group-name
If all accounts are already connected in jabber-connect-all, say so
Make nick coloring work in Emacs24
Don't display "added to roster" messages for initial roster population
Don't add extra newline when using STARTTLS
Fix reporting of STARTTLS negotiation errors
Fix error handling for old-style SSL/TLS connections
Support native GnuTLS for STARTTLS
s/screen/tmux/ in jabber-tmux.el
Mention tmux alerts in the documentation
Add tmux alerts
Fix build with automake > 1.11.4
Avoid groupchat buffer on RET in roster if we're not 100% sure it's a groupchat (bug 3483380)
Version 0.8.91
* jabberd.el (jabberd-handle): Update for new namespace handling.
Use namespace prefixes declared on stream root element
jabber-core: Fix header parsing
Fix :get function for jabber-roster-default-group-name
Use xml-parse-region to parse stream header
...
Conflicts:
jabber-roster.el
jabber.texi
Apparently sending an extra newline after each stanza was necessary
with the OpenSSL client, but it seems to be messing up native STARTTLS
negotiation more often than not (I suspect it's a race condition), and
removing it seems not to hurt when using STARTTLS with gnutls-cli.
jabber-starttls-process-input now signals an error on negotiation
failure, as gnutls-negotiate already does. Catch errors in
jabber-core, and put them as disconnection reason in the state data,
to get fewer and less confusing messages in the echo area.
When connecting to a Jabber server over SSL/TLS without STARTTLS
(the legacy "port 5223" method), any connection error would
cause the state machine to be stuck in the :connecting state,
unable to go back or forward. Fix this by catching and reporting
errors in jabber-ssl-connect.
Emacs 24 supports linking to the GnuTLS library. Let's use it when
available.
Also add a customisable variable for ignoring invalid certificates.
We should now be validating certificates against the XMPP server name,
not the hostname from DNS SRV, so there should be less need for this
now, but there's always the occasional basement server with a
self-signed certificate...