Merge remote-tracking branch 'origin/master' into feature/android
This commit is contained in:
Po Lu
commit
64206ee3af
41 changed files with 720 additions and 468 deletions
|
|
@ -2762,8 +2762,8 @@ if test "${with_ns}" != no; then
|
|||
GNUSTEP_LOCAL_HEADERS="-I${GNUSTEP_LOCAL_HEADERS}"
|
||||
test "x${GNUSTEP_LOCAL_LIBRARIES}" != "x" && \
|
||||
GNUSTEP_LOCAL_LIBRARIES="-L${GNUSTEP_LOCAL_LIBRARIES}"
|
||||
CPPFLAGS="$CPPFLAGS -I${GNUSTEP_SYSTEM_HEADERS} ${GNUSTEP_LOCAL_HEADERS}"
|
||||
CFLAGS="$CFLAGS -I${GNUSTEP_SYSTEM_HEADERS} ${GNUSTEP_LOCAL_HEADERS}"
|
||||
CPPFLAGS="$CPPFLAGS -isystem ${GNUSTEP_SYSTEM_HEADERS} ${GNUSTEP_LOCAL_HEADERS}"
|
||||
CFLAGS="$CFLAGS -isystem ${GNUSTEP_SYSTEM_HEADERS} ${GNUSTEP_LOCAL_HEADERS}"
|
||||
LDFLAGS="$LDFLAGS -L${GNUSTEP_SYSTEM_LIBRARIES} ${GNUSTEP_LOCAL_LIBRARIES}"
|
||||
LIBS_GNUSTEP="-lgnustep-gui -lgnustep-base -lobjc -lpthread"
|
||||
dnl GNUstep defines BASE_NATIVE_OBJC_EXCEPTIONS to 0 or 1.
|
||||
|
|
|
|||
|
|
@ -496,8 +496,43 @@ Customization}.
|
|||
If you think you have found a bug in Emacs, please report it. We
|
||||
cannot promise to fix it, or always to agree that it is a bug, but we
|
||||
certainly want to hear about it. The same applies for new features
|
||||
you would like to see added. The following sections will help you to
|
||||
construct an effective bug report.
|
||||
you would like to see added. This section will help you to determine
|
||||
whether you found a bug, and if so, construct an effective bug report.
|
||||
|
||||
The general procedure when you find something that could be a bug is
|
||||
as follows:
|
||||
|
||||
@itemize @bullet
|
||||
@item
|
||||
See if what you found is a known problem or a bug that was already
|
||||
reported and/or fixed. @xref{Known Problems}, where you will find how
|
||||
to look for known problems and bugs.
|
||||
|
||||
@item
|
||||
If you are unsure whether the behavior you see is a bug, see @ref{Bug
|
||||
Criteria}, which tells what we consider as clear bugs in Emacs.
|
||||
|
||||
@item
|
||||
Once you decide you found a bug, see @ref{Understanding Bug
|
||||
Reporting}, which helps you in describing what you see in the most
|
||||
efficient manner, making our job of reproducing the issue and
|
||||
investigating it easier.
|
||||
|
||||
@item
|
||||
Next, see @ref{Checklist, Checklist for Bug Reports}, where we
|
||||
describe in detail how to submit a bug report and what information to
|
||||
include in it. In a nutshell, you submit a bug report via electronic
|
||||
mail using the Emacs command @code{report-emacs-bug}, which assists
|
||||
you in doing so. Submitting a bug report starts the process of
|
||||
investigating and fixing the bug, where you will receive copies of
|
||||
email messages discussing the bug, in which we might ask you to
|
||||
provide more information, test possible fixes, etc.
|
||||
|
||||
@item
|
||||
Finally, if you want to propose specific changes to Emacs, whether to
|
||||
fix a bug, add a new feature, or improve our documentation, please see
|
||||
@ref{Sending Patches}, for details about submitting such changes.
|
||||
@end itemize
|
||||
|
||||
@menu
|
||||
* Known Problems:: How to read about known problems and bugs.
|
||||
|
|
@ -509,9 +544,10 @@ construct an effective bug report.
|
|||
|
||||
@node Known Problems
|
||||
@subsection Reading Existing Bug Reports and Known Problems
|
||||
@cindex known bugs and problems
|
||||
|
||||
Before reporting a bug, if at all possible please check to see if it
|
||||
is already known about. Indeed, it may already have been fixed in a
|
||||
Before reporting a bug, if at all possible, please check to see if
|
||||
we already know about it. Indeed, it may already have been fixed in a
|
||||
later release of Emacs, or in the development version. Here is a list
|
||||
of the main places you can read about known issues:
|
||||
|
||||
|
|
@ -519,20 +555,26 @@ of the main places you can read about known issues:
|
|||
@item
|
||||
The @file{etc/PROBLEMS} file; type @kbd{C-h C-p} to read it. This
|
||||
file contains a list of particularly well-known issues that have been
|
||||
encountered in compiling, installing and running Emacs. Often, there
|
||||
are suggestions for workarounds and solutions.
|
||||
encountered in compiling, installing and running Emacs, with special
|
||||
emphasis on issues caused by other software that cannot be easily
|
||||
solved in Emacs. Often, you will find there suggestions for
|
||||
workarounds and solutions.
|
||||
|
||||
@cindex bug tracker
|
||||
@cindex issue tracker
|
||||
@cindex search known bugs
|
||||
@item
|
||||
The GNU Bug Tracker at @url{https://debbugs.gnu.org}. Emacs bugs are
|
||||
filed in the tracker under the @samp{emacs} package. The tracker
|
||||
records information about the status of each bug, the initial bug
|
||||
report, and the follow-up messages by the bug reporter and Emacs
|
||||
developers. You can search for bugs by subject, severity, and other
|
||||
criteria.
|
||||
The GNU Bug Tracker at @url{https://debbugs.gnu.org}. Emacs bugs and
|
||||
issues are filed in the tracker under the @samp{emacs} package. The
|
||||
tracker records information about the status of each bug, the initial
|
||||
bug report, and the follow-up messages by the bug reporter and Emacs
|
||||
developers who participate in discussing and fixing the bug. You can
|
||||
search for bugs by subject, severity, and other criteria. For more
|
||||
complex search criteria, use
|
||||
@url{https://debbugs.gnu.org/cgi/search.cgi}.
|
||||
|
||||
@cindex debbugs package
|
||||
Instead of browsing the bug tracker as a webpage, you can browse it
|
||||
Instead of browsing the bug tracker as a web page, you can browse it
|
||||
from Emacs using the @code{debbugs} package, which can be downloaded
|
||||
via the Package Menu (@pxref{Packages}). This package provides the
|
||||
command @kbd{M-x debbugs-gnu} to list bugs, and @kbd{M-x
|
||||
|
|
@ -558,14 +600,14 @@ used, and is mainly of historical interest. At one time, it was used
|
|||
for bug reports in development (i.e., not yet released) versions of
|
||||
Emacs. You can read the archives for 2003 to mid 2007 at
|
||||
@url{https://lists.gnu.org/r/emacs-pretest-bug/}. Nowadays,
|
||||
it is an alias for @samp{bug-gnu-emacs}.
|
||||
email messages sent to this list are redirected to
|
||||
@samp{bug-gnu-emacs}.
|
||||
|
||||
@item
|
||||
The @samp{emacs-devel} mailing list. Sometimes people report bugs to
|
||||
this mailing list. This is not the main purpose of the list, however,
|
||||
and it is much better to send bug reports to the bug list. You should
|
||||
not feel obliged to read this list before reporting a bug.
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
|
|
@ -628,20 +670,21 @@ to begin by reporting them to the package developers.
|
|||
|
||||
@node Understanding Bug Reporting
|
||||
@subsection Understanding Bug Reporting
|
||||
@cindex bug reporting
|
||||
@cindex bug reporting, principles
|
||||
@cindex report an Emacs bug, how to
|
||||
|
||||
When you decide that there is a bug, it is important to report it
|
||||
When you decide that there is a bug, it is important to report it,
|
||||
and to report it in a way which is useful. What is most useful is an
|
||||
exact description of what commands you type, starting with the shell
|
||||
command to run Emacs, until the problem happens.
|
||||
command to run Emacs, until the problem happens, and the effects
|
||||
produced by typing those commands.
|
||||
|
||||
The most important principle in reporting a bug is to report
|
||||
@emph{facts}. Hypotheses and verbal descriptions are no substitute
|
||||
for the detailed raw data. Reporting the facts is straightforward,
|
||||
but many people strain to posit explanations and report them instead
|
||||
of the facts. If the explanations are based on guesses about how
|
||||
Emacs is implemented, they will be useless; meanwhile, lacking the
|
||||
Emacs is implemented, they night not be useful; meanwhile, lacking the
|
||||
facts, we will have no real information about the bug. If you want to
|
||||
actually @emph{debug} the problem, and report explanations that are
|
||||
more than guesses, that is useful---but please include the raw facts
|
||||
|
|
@ -661,19 +704,23 @@ problem. There is no way we could guess that we should try visiting a
|
|||
file with a @samp{z} in its name.
|
||||
|
||||
You should not even say ``visit a file'' instead of @kbd{C-x C-f}.
|
||||
Similarly, rather than saying ``if I have three characters on the
|
||||
line'', say ``after I type @kbd{@key{RET} A B C @key{RET} C-p}'', if
|
||||
that is the way you entered the text.
|
||||
That's because a file can be visited in more than one way, and there's
|
||||
no certainty that all of them reproduce the problem. Similarly,
|
||||
rather than saying ``if I have three characters on the line'', say
|
||||
``after I type @kbd{@key{RET} A B C @key{RET} C-p}'', if that is the
|
||||
way you entered the text---that is, tell us about the text which in
|
||||
your case produced the problem.
|
||||
|
||||
If possible, try quickly to reproduce the bug by invoking Emacs with
|
||||
@command{emacs -Q} (so that Emacs starts with no initial
|
||||
customizations; @pxref{Initial Options}), and repeating the steps that
|
||||
you took to trigger the bug. If you can reproduce the bug this way,
|
||||
that rules out bugs in your personal customizations. Then your bug
|
||||
report should begin by stating that you started Emacs with
|
||||
@command{emacs -Q}, followed by the exact sequence of steps for
|
||||
reproducing the bug. If possible, inform us of the exact contents of
|
||||
any file that is needed to reproduce the bug.
|
||||
that rules out bugs in your personal customizations and makes the bug
|
||||
much easier to reproduce. Then your bug report should begin by
|
||||
stating that you started Emacs with @command{emacs -Q}, followed by
|
||||
the exact sequence of steps for reproducing the bug. If possible,
|
||||
inform us of the exact contents of any file that is needed to
|
||||
reproduce the bug.
|
||||
|
||||
Some bugs are not reproducible from @command{emacs -Q}; some are not
|
||||
easily reproducible at all. In that case, you should report what you
|
||||
|
|
@ -687,6 +734,7 @@ separate bug report for each.
|
|||
@subsection Checklist for Bug Reports
|
||||
@cindex checklist before reporting a bug
|
||||
@cindex bug reporting, checklist
|
||||
@cindex report bugs in Emacs
|
||||
|
||||
Before reporting a bug, first try to see if the problem has already
|
||||
been reported (@pxref{Known Problems}).
|
||||
|
|
@ -706,7 +754,7 @@ information; you should still read and follow the guidelines below, so
|
|||
you can enter the other crucial information by hand before you send
|
||||
the message. You may feel that some of the information inserted by
|
||||
@kbd{M-x report-emacs-bug} is not relevant, but unless you are
|
||||
absolutely sure it is best to leave it, so that the developers can
|
||||
absolutely sure, it is best to leave it, so that the developers can
|
||||
decide for themselves.
|
||||
|
||||
When you have finished writing your report, type @kbd{C-c C-c} and it
|
||||
|
|
@ -721,24 +769,26 @@ If you cannot send mail from inside Emacs, you can copy the
|
|||
text of your report to your normal mail client (if your system
|
||||
supports it, you can type @kbd{C-c M-i} to have Emacs do this for you)
|
||||
and send it to that address. Or you can simply send an email to that
|
||||
address describing the problem.
|
||||
address describing the problem, including the necessary information
|
||||
mentioned below.
|
||||
|
||||
If you want to submit code to Emacs (to fix a problem or implement a
|
||||
new feature), the easiest way to do this is to send a patch to the
|
||||
Emacs issue tracker. This is done with the @kbd{M-x
|
||||
submit-emacs-patch} command, and works much the same as when reporting
|
||||
bugs.
|
||||
Emacs issue tracker. Use the @kbd{M-x submit-emacs-patch} command for
|
||||
that, which works much the same as when reporting bugs; @pxref{Sending
|
||||
Patches}.
|
||||
|
||||
In any case, your report will be sent to the @samp{bug-gnu-emacs}
|
||||
mailing list, and stored in the GNU Bug Tracker at
|
||||
@url{https://debbugs.gnu.org}. Please include a valid reply email
|
||||
address, in case we need to ask you for more information about your
|
||||
report. Submissions are moderated, so there may be a delay before
|
||||
your report appears.
|
||||
your report actually appears on the tracker.
|
||||
|
||||
You do not need to know how the GNU Bug Tracker works in order to
|
||||
report a bug, but if you want to, you can read the tracker's online
|
||||
documentation to see the various features you can use.
|
||||
report a bug, but if you want to, you can read the tracker's
|
||||
@uref{https://debbugs.gnu.org/Advanced.html, online documentation} to
|
||||
see the various features you can use.
|
||||
|
||||
All mail sent to the @samp{bug-gnu-emacs} mailing list is also
|
||||
gatewayed to the @samp{gnu.emacs.bug} newsgroup. The reverse is also
|
||||
|
|
@ -749,55 +799,43 @@ tracker.
|
|||
|
||||
If your data is more than 500,000 bytes, please don't include it
|
||||
directly in the bug report; instead, offer to send it on request, or
|
||||
make it available online and say where.
|
||||
make it available online and say where. Large attachments are best
|
||||
sent compressed.
|
||||
|
||||
The GNU Bug Tracker will assign a bug number to your report; please
|
||||
use it in the following discussions.
|
||||
use it in the following discussions, keeping the bug address in the
|
||||
list of recipients, so that the bug discussion is recorded by the
|
||||
tracker. The bug address will look like
|
||||
@samp{@var{nnnnn}@@debbugs.gnu.org}, where @var{nnnnn} is the bug
|
||||
number.
|
||||
|
||||
To enable maintainers to investigate a bug, your report
|
||||
should include all these things:
|
||||
|
||||
@itemize @bullet
|
||||
@item
|
||||
The version number of Emacs. Without this, we won't know whether there is any
|
||||
point in looking for the bug in the current version of GNU Emacs.
|
||||
A description of what behavior you observe that you believe is
|
||||
incorrect. For example, ``The Emacs process gets a fatal signal'', or,
|
||||
``The resulting text is as follows, which I think is wrong.''
|
||||
|
||||
@findex emacs-version
|
||||
@kbd{M-x report-emacs-bug} includes this information automatically,
|
||||
but if you are not using that command for your report you can get the
|
||||
version number by typing @kbd{M-x emacs-version @key{RET}}. If that
|
||||
command does not work, you probably have something other than GNU
|
||||
Emacs, so you will have to report the bug somewhere else.
|
||||
Of course, if the bug is that Emacs gets a fatal signal, then one can't
|
||||
miss it. But if the bug is incorrect text, the maintainer might fail to
|
||||
notice what is wrong. Why leave it to chance?
|
||||
|
||||
@item
|
||||
The type of machine you are using, and the operating system name and
|
||||
version number (again, automatically included by @w{@kbd{M-x
|
||||
report-emacs-bug}}). @w{@kbd{M-x emacs-version @key{RET}}} provides
|
||||
this information too. Copy its output from the @file{*Messages*}
|
||||
buffer, so that you get it all and get it accurately, or use
|
||||
@w{@kbd{C-u M-x emacs-version @key{RET}}} to insert the version
|
||||
information into the current buffer.
|
||||
Even if the problem you experience is a fatal signal, you should still
|
||||
say so explicitly. Suppose something strange is going on, such as, your
|
||||
copy of the source is out of sync, or you have encountered a bug in the
|
||||
C library on your system. (This has happened!) Your copy might crash
|
||||
and the copy here might not. If you @emph{said} to expect a crash, then
|
||||
when Emacs here fails to crash, we would know that the bug was not
|
||||
happening. If you don't say to expect a crash, then we would not know
|
||||
whether the bug was happening---we would not be able to draw any
|
||||
conclusion from our observations.
|
||||
|
||||
@item
|
||||
The operands given to the @code{configure} command when Emacs was
|
||||
installed (automatically included by @kbd{M-x report-emacs-bug}).
|
||||
|
||||
@item
|
||||
A complete list of any modifications you have made to the Emacs source.
|
||||
(We may not have time to investigate the bug unless it happens in an
|
||||
unmodified Emacs. But if you've made modifications and you don't tell
|
||||
us, you are sending us on a wild goose chase.)
|
||||
|
||||
Be precise about these changes. A description in English is not
|
||||
enough---send a unified context diff for them.
|
||||
|
||||
Adding files of your own, or porting to another machine, is a
|
||||
modification of the source.
|
||||
|
||||
@item
|
||||
Details of any other deviations from the standard procedure for installing
|
||||
GNU Emacs.
|
||||
Usually, description of the behavior and of the way to reproduce the
|
||||
problem needs to specify one or more of the following aspects:
|
||||
|
||||
@itemize @minus
|
||||
@item
|
||||
The complete text of any files needed to reproduce the bug.
|
||||
|
||||
|
|
@ -824,73 +862,6 @@ file until the Emacs process is killed. Be aware that sensitive
|
|||
information (such as passwords) may end up recorded in the dribble
|
||||
file.
|
||||
|
||||
@item
|
||||
@findex open-termscript
|
||||
@cindex termscript file
|
||||
@vindex TERM@r{, environment variable, and display bugs}
|
||||
For possible display bugs on text-mode terminals, the terminal type
|
||||
(the value of environment variable @env{TERM}), the complete termcap
|
||||
entry for the terminal from @file{/etc/termcap} (since that file is
|
||||
not identical on all machines), and the output that Emacs actually
|
||||
sent to the terminal.
|
||||
|
||||
The way to collect the terminal output is to execute the Lisp expression
|
||||
|
||||
@example
|
||||
(open-termscript "~/termscript")
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
using @kbd{M-:} or from the @file{*scratch*} buffer just after
|
||||
starting Emacs. From then on, Emacs copies all terminal output to the
|
||||
specified termscript file as well, until the Emacs process is killed.
|
||||
If the problem happens when Emacs starts up, put this expression into
|
||||
your Emacs initialization file so that the termscript file will be
|
||||
open when Emacs displays the screen for the first time.
|
||||
|
||||
Be warned: it is often difficult, and sometimes impossible, to fix a
|
||||
terminal-dependent bug without access to a terminal of the type that
|
||||
stimulates the bug.
|
||||
|
||||
@item
|
||||
If non-@acronym{ASCII} text or internationalization is relevant, the locale that
|
||||
was current when you started Emacs. On GNU/Linux and Unix systems, or
|
||||
if you use a POSIX-style shell such as Bash, you can use this shell
|
||||
command to view the relevant values:
|
||||
|
||||
@smallexample
|
||||
echo LC_ALL=$LC_ALL LC_COLLATE=$LC_COLLATE LC_CTYPE=$LC_CTYPE \
|
||||
LC_MESSAGES=$LC_MESSAGES LC_TIME=$LC_TIME LANG=$LANG
|
||||
@end smallexample
|
||||
|
||||
Alternatively, use the @command{locale} command, if your system has it,
|
||||
to display your locale settings.
|
||||
|
||||
You can use the @kbd{M-!} command to execute these commands from
|
||||
Emacs, and then copy the output from the @file{*Messages*} buffer into
|
||||
the bug report. Alternatively, @kbd{M-x getenv @key{RET} LC_ALL
|
||||
@key{RET}} will display the value of @code{LC_ALL} in the echo area, and
|
||||
you can copy its output from the @file{*Messages*} buffer.
|
||||
|
||||
@item
|
||||
A description of what behavior you observe that you believe is
|
||||
incorrect. For example, ``The Emacs process gets a fatal signal'', or,
|
||||
``The resulting text is as follows, which I think is wrong.''
|
||||
|
||||
Of course, if the bug is that Emacs gets a fatal signal, then one can't
|
||||
miss it. But if the bug is incorrect text, the maintainer might fail to
|
||||
notice what is wrong. Why leave it to chance?
|
||||
|
||||
Even if the problem you experience is a fatal signal, you should still
|
||||
say so explicitly. Suppose something strange is going on, such as, your
|
||||
copy of the source is out of sync, or you have encountered a bug in the
|
||||
C library on your system. (This has happened!) Your copy might crash
|
||||
and the copy here might not. If you @emph{said} to expect a crash, then
|
||||
when Emacs here fails to crash, we would know that the bug was not
|
||||
happening. If you don't say to expect a crash, then we would not know
|
||||
whether the bug was happening---we would not be able to draw any
|
||||
conclusion from our observations.
|
||||
|
||||
@item
|
||||
If the bug is that the Emacs Manual or the Emacs Lisp Reference Manual
|
||||
fails to describe the actual behavior of Emacs, or that the text is
|
||||
|
|
@ -906,33 +877,6 @@ To get the error message text accurately, copy it from the
|
|||
@file{*Messages*} buffer into the bug report. Copy all of it, not just
|
||||
part.
|
||||
|
||||
@findex toggle-debug-on-error
|
||||
@pindex Edebug
|
||||
To make a backtrace for the error, use @kbd{M-x toggle-debug-on-error}
|
||||
before the error happens (that is to say, you must give that command
|
||||
and then make the bug happen). This causes the error to start the Lisp
|
||||
debugger, which shows you a backtrace. Copy the text of the
|
||||
debugger's backtrace into the bug report. @xref{Edebug,, Edebug,
|
||||
elisp, the Emacs Lisp Reference Manual}, for information on debugging
|
||||
Emacs Lisp programs with the Edebug package.
|
||||
|
||||
This use of the debugger is possible only if you know how to make the
|
||||
bug happen again. If you can't make it happen again, at least copy
|
||||
the whole error message.
|
||||
|
||||
@vindex debug-on-quit
|
||||
If Emacs appears to be stuck in an infinite loop or in a very long
|
||||
operation, typing @kbd{C-g} with the variable @code{debug-on-quit}
|
||||
non-@code{nil} will start the Lisp debugger and show a backtrace.
|
||||
This backtrace is useful for debugging such long loops, so if you can
|
||||
produce it, copy it into the bug report.
|
||||
|
||||
@vindex debug-on-event
|
||||
If you cannot get Emacs to respond to @kbd{C-g} (e.g., because
|
||||
@code{inhibit-quit} is set), then you can try sending the signal
|
||||
specified by @code{debug-on-event} (default SIGUSR2) from outside
|
||||
Emacs to cause it to enter the debugger.
|
||||
|
||||
@item
|
||||
Check whether any programs you have loaded into the Lisp world,
|
||||
including your initialization file, set any variables that may affect
|
||||
|
|
@ -960,65 +904,89 @@ code is in your version at a given line number, and we could not be
|
|||
certain.
|
||||
|
||||
@item
|
||||
Additional information from a C debugger such as GDB might enable
|
||||
someone to find a problem on a machine which he does not have available.
|
||||
If you don't know how to use GDB, please read the GDB manual---it is not
|
||||
very long, and using GDB is easy. You can find the GDB distribution,
|
||||
including the GDB manual in online form, in most of the same places you
|
||||
can find the Emacs distribution. To run Emacs under GDB, you should
|
||||
switch to the @file{src} subdirectory in which Emacs was compiled, then
|
||||
do @samp{gdb emacs}. It is important for the directory @file{src} to be
|
||||
current so that GDB will read the @file{.gdbinit} file in this
|
||||
directory.
|
||||
@findex open-termscript
|
||||
@cindex termscript file
|
||||
@vindex TERM@r{, environment variable, and display bugs}
|
||||
For possible display bugs on text-mode terminals, the terminal type
|
||||
(the value of environment variable @env{TERM}), the complete termcap
|
||||
entry for the terminal from @file{/etc/termcap} (since that file is
|
||||
not identical on all machines), and the output that Emacs actually
|
||||
sent to the terminal.
|
||||
|
||||
However, you need to think when you collect the additional information
|
||||
if you want it to show what causes the bug.
|
||||
The way to collect the terminal output is to invoke the command
|
||||
@kbd{M-x open-termscript} just after starting Emacs; it will prompt
|
||||
you for the name of the file where to record all terminal output until
|
||||
the Emacs process is killed. If the problem happens when Emacs starts
|
||||
up, put the Lisp expression
|
||||
|
||||
@cindex backtrace for bug reports
|
||||
For example, many people send just a C-level backtrace, but that is
|
||||
not very useful by itself. A simple backtrace with arguments often
|
||||
conveys little about what is happening inside GNU Emacs, because most
|
||||
of the arguments listed in the backtrace are pointers to Lisp objects.
|
||||
The numeric values of these pointers have no significance whatever;
|
||||
all that matters is the contents of the objects they point to (and
|
||||
most of the contents are themselves pointers).
|
||||
@example
|
||||
(open-termscript "~/termscript")
|
||||
@end example
|
||||
|
||||
@findex debug_print
|
||||
To provide useful information, you need to show the values of Lisp
|
||||
objects in Lisp notation. Do this for each variable which is a Lisp
|
||||
object, in several stack frames near the bottom of the stack. Look at
|
||||
the source to see which variables are Lisp objects, because the debugger
|
||||
thinks of them as integers.
|
||||
@noindent
|
||||
into your Emacs initialization file so that the termscript file will
|
||||
be open when Emacs displays the screen for the first time.
|
||||
|
||||
To show a variable's value in Lisp syntax, first print its value, then
|
||||
use the user-defined GDB command @code{pr} to print the Lisp object in
|
||||
Lisp syntax. (If you must use another debugger, call the function
|
||||
@code{debug_print} with the object as an argument.) The @code{pr}
|
||||
command is defined by the file @file{.gdbinit}, and it works only if you
|
||||
are debugging a running process (not with a core dump).
|
||||
Be warned: it is often difficult, and sometimes impossible, to fix a
|
||||
terminal-dependent bug without access to a terminal of the type that
|
||||
stimulates the bug.
|
||||
@end itemize
|
||||
|
||||
To make Lisp errors stop Emacs and return to GDB, put a breakpoint at
|
||||
@code{Fsignal}.
|
||||
@item
|
||||
The version number of Emacs. Without this, we won't know whether there is any
|
||||
point in looking for the bug in the current version of GNU Emacs.
|
||||
|
||||
For a short listing of Lisp functions running, type the GDB
|
||||
command @code{xbacktrace}.
|
||||
@findex emacs-version
|
||||
@kbd{M-x report-emacs-bug} includes this information automatically,
|
||||
but if you are not using that command for your report you can get the
|
||||
version number by typing @kbd{M-x emacs-version @key{RET}}. If that
|
||||
command does not work, you probably have something other than GNU
|
||||
Emacs, so you will have to report the bug somewhere else.
|
||||
|
||||
The file @file{.gdbinit} defines several other commands that are useful
|
||||
for examining the data types and contents of Lisp objects. Their names
|
||||
begin with @samp{x}. These commands work at a lower level than
|
||||
@code{pr}, and are less convenient, but they may work even when
|
||||
@code{pr} does not, such as when debugging a core dump or when Emacs has
|
||||
had a fatal signal.
|
||||
@item
|
||||
The type of machine you are using, and the operating system name and
|
||||
version number (again, automatically included by @w{@kbd{M-x
|
||||
report-emacs-bug}}). @w{@kbd{M-x emacs-version @key{RET}}} provides
|
||||
this information too. Copy its output from the @file{*Messages*}
|
||||
buffer, so that you get it all and get it accurately, or use
|
||||
@w{@kbd{C-u M-x emacs-version @key{RET}}} to insert the version
|
||||
information into the current buffer.
|
||||
|
||||
@cindex debugging Emacs, tricks and techniques
|
||||
More detailed advice and other useful techniques for debugging Emacs
|
||||
are available in the file @file{etc/DEBUG} in the Emacs distribution.
|
||||
That file also includes instructions for investigating problems
|
||||
whereby Emacs stops responding (many people assume that Emacs is
|
||||
``hung'', whereas in fact it might be in an infinite loop).
|
||||
@item
|
||||
The command-line arguments given to the @code{configure} command when
|
||||
Emacs was built (automatically included by @kbd{M-x
|
||||
report-emacs-bug}).
|
||||
|
||||
To find the file @file{etc/DEBUG} in your Emacs installation, use the
|
||||
directory name stored in the variable @code{data-directory}.
|
||||
@item
|
||||
A complete list of any modifications you have made to the Emacs source.
|
||||
(We may not have time to investigate the bug unless it happens in an
|
||||
unmodified Emacs. But if you've made modifications and you don't tell
|
||||
us, you are sending us on a wild goose chase.)
|
||||
|
||||
Be precise about these changes. A description in English is not
|
||||
enough---send a unified context diff for them.
|
||||
|
||||
Adding files of your own, or porting to another machine, is a
|
||||
modification of the source.
|
||||
|
||||
@item
|
||||
Details of any other deviations from the standard procedure for installing
|
||||
GNU Emacs.
|
||||
|
||||
@item
|
||||
If non-@acronym{ASCII} text or internationalization is relevant, the locale that
|
||||
was current when you started Emacs. This is automatically included by @kbd{M-x
|
||||
report-emacs-bug}; alternatively, on GNU/Linux and Unix systems, or
|
||||
if you use a POSIX-style shell such as Bash, you can use this shell
|
||||
command to view the relevant values:
|
||||
|
||||
@smallexample
|
||||
echo LC_ALL=$LC_ALL LC_COLLATE=$LC_COLLATE LC_CTYPE=$LC_CTYPE \
|
||||
LC_MESSAGES=$LC_MESSAGES LC_TIME=$LC_TIME LANG=$LANG
|
||||
@end smallexample
|
||||
|
||||
You can also use the @command{locale} command, if your system has it,
|
||||
to display your locale settings.
|
||||
@end itemize
|
||||
|
||||
Here are some things that are not necessary in a bug report:
|
||||
|
|
@ -1075,17 +1043,13 @@ objects with @code{pr} (see above).
|
|||
A patch for the bug.
|
||||
|
||||
A patch for the bug is useful if it is a good one. But don't omit the
|
||||
other information that a bug report needs, such as the test case, on the
|
||||
assumption that a patch is sufficient. We might see problems with your
|
||||
patch and decide to fix the problem another way, or we might not
|
||||
other information that a bug report needs, such as the test case, on
|
||||
the assumption that a patch is sufficient. We might see problems with
|
||||
your patch and decide to fix the problem another way, or we might not
|
||||
understand it at all. And if we can't understand what bug you are
|
||||
trying to fix, or why your patch should be an improvement, we mustn't
|
||||
install it.
|
||||
|
||||
@ifnottex
|
||||
@xref{Sending Patches}, for guidelines on how to make it easy for us to
|
||||
understand and install your patches.
|
||||
@end ifnottex
|
||||
install it. @xref{Sending Patches}, for guidelines on how to make it
|
||||
easy for us to understand and install your patches.
|
||||
|
||||
@item
|
||||
A guess about what the bug is or what it depends on.
|
||||
|
|
@ -1094,6 +1058,104 @@ Such guesses are usually wrong. Even experts can't guess right about
|
|||
such things without first using the debugger to find the facts.
|
||||
@end itemize
|
||||
|
||||
If you are willing to debug Emacs and provide additional information
|
||||
about the bug, here is some useful advice:
|
||||
|
||||
@findex toggle-debug-on-error
|
||||
@pindex Edebug
|
||||
@itemize
|
||||
@item
|
||||
If the bug manifests itself as an error message, try providing a Lisp
|
||||
backtrace for the error. To make a backtrace for the error, use
|
||||
@kbd{M-x toggle-debug-on-error} before the error happens (that is to
|
||||
say, you must give that command and then make the bug happen). This
|
||||
causes the error to start the Lisp debugger, which shows you a
|
||||
backtrace. Copy the text of the debugger's backtrace into the bug
|
||||
report. @xref{Edebug,, Edebug, elisp, the Emacs Lisp Reference
|
||||
Manual}, for information on debugging Emacs Lisp programs with the
|
||||
Edebug package.
|
||||
|
||||
This use of the debugger is possible only if you know how to make the
|
||||
bug happen again. If you can't make it happen again, at least copy
|
||||
the whole error message.
|
||||
|
||||
@vindex debug-on-quit
|
||||
@item
|
||||
If Emacs appears to be stuck in an infinite loop or in a very long
|
||||
operation, typing @kbd{C-g} with the variable @code{debug-on-quit}
|
||||
non-@code{nil} will start the Lisp debugger and show a backtrace.
|
||||
This backtrace is useful for debugging such long loops, so if you can
|
||||
produce it, copy it into the bug report.
|
||||
|
||||
@vindex debug-on-event
|
||||
If you cannot get Emacs to respond to @kbd{C-g} (e.g., because
|
||||
@code{inhibit-quit} is set), then you can try sending the signal
|
||||
specified by @code{debug-on-event} (default SIGUSR2) from outside
|
||||
Emacs to cause it to enter the debugger.
|
||||
|
||||
@item
|
||||
Additional information from a C debugger such as GDB might enable
|
||||
someone to find a problem on a machine which he does not have available.
|
||||
If you don't know how to use GDB, please read the GDB manual---it is not
|
||||
very long, and using GDB is easy. You can find the GDB distribution,
|
||||
including the GDB manual in online form, in most of the same places you
|
||||
can find the Emacs distribution. To run Emacs under GDB, you should
|
||||
switch to the @file{src} subdirectory in which Emacs was compiled, then
|
||||
type @kbd{gdb ./emacs}. It is important for the directory @file{src} to be
|
||||
current so that GDB will read the @file{.gdbinit} file in this
|
||||
directory. (You can also tell GDB to read that file from inside GDB,
|
||||
by typing @kbd{source ./.gdbinit}.)
|
||||
|
||||
However, you need to think when you collect the additional information
|
||||
if you want it to show what causes the bug.
|
||||
|
||||
@cindex backtrace for bug reports
|
||||
For example, many people send just a C-level backtrace, but that is
|
||||
not very useful by itself. A simple backtrace with arguments often
|
||||
conveys little about what is happening inside GNU Emacs, because most
|
||||
of the arguments listed in the backtrace are pointers to Lisp objects.
|
||||
The numeric values of these pointers have no significance whatever;
|
||||
all that matters is the contents of the objects they point to (and
|
||||
most of the contents are themselves pointers).
|
||||
|
||||
@findex debug_print
|
||||
To provide useful information, you need to show the values of Lisp
|
||||
objects in Lisp notation. Do this for each variable which is a Lisp
|
||||
object, in several stack frames near the bottom of the stack. Look at
|
||||
the source to see which variables are Lisp objects, because the debugger
|
||||
thinks of them as integers.
|
||||
|
||||
To show a variable's value in Lisp syntax, first print its value, then
|
||||
use the user-defined GDB command @code{pr} to print the Lisp object in
|
||||
Lisp syntax. (If you must use another debugger, call the function
|
||||
@code{debug_print} with the object as an argument.) The @code{pr}
|
||||
command is defined by the file @file{.gdbinit}, and it works only if you
|
||||
are debugging a running process (not with a core dump).
|
||||
|
||||
To make Lisp errors stop Emacs and return to GDB, put a breakpoint at
|
||||
@code{Fsignal}.
|
||||
|
||||
For a backtrace of Lisp functions running, type the GDB command
|
||||
@code{xbacktrace}.
|
||||
|
||||
The file @file{.gdbinit} defines several other commands that are useful
|
||||
for examining the data types and contents of Lisp objects. Their names
|
||||
begin with @samp{x}. These commands work at a lower level than
|
||||
@code{pr}, and are less convenient, but they may work even when
|
||||
@code{pr} does not, such as when debugging a core dump or when Emacs has
|
||||
had a fatal signal.
|
||||
|
||||
@cindex debugging Emacs, tricks and techniques
|
||||
More detailed advice and other useful techniques for debugging Emacs
|
||||
are available in the file @file{etc/DEBUG} in the Emacs distribution.
|
||||
That file also includes instructions for investigating problems
|
||||
whereby Emacs stops responding (many people assume that Emacs is
|
||||
``hung'', whereas in fact it might be in an infinite loop).
|
||||
|
||||
To find the file @file{etc/DEBUG} in your Emacs installation, use the
|
||||
directory name stored in the variable @code{data-directory}.
|
||||
@end itemize
|
||||
|
||||
@node Sending Patches
|
||||
@subsection Sending Patches for GNU Emacs
|
||||
|
||||
|
|
@ -1108,26 +1170,29 @@ work in the best of circumstances, and we can't keep up unless you do
|
|||
your best to help.
|
||||
|
||||
Every patch must have several pieces of information before we
|
||||
can properly evaluate it.
|
||||
can properly evaluate it. They are described below.
|
||||
|
||||
When you have all these pieces, bundle them up in a mail message and
|
||||
send it to the developers. Sending it to
|
||||
@email{bug-gnu-emacs@@gnu.org} (which is the bug/feature list) is
|
||||
recommended, because that list is coupled to a tracking system that
|
||||
makes it easier to locate patches. If your patch is not complete and
|
||||
you think it needs more discussion, you might want to send it to
|
||||
@email{emacs-devel@@gnu.org} instead. If you revise your patch,
|
||||
send it as a followup to the initial topic.
|
||||
When you have all these pieces, use the @kbd{M-x submit-emacs-patch}
|
||||
command to send the patch. The command will prompt you for the
|
||||
Subject of the patch and a patch file. It will then create and
|
||||
display a Message mode buffer with the patch file as an attachment,
|
||||
display the buffer, and let you explain more about the patch and add
|
||||
any other information as requested below. When you are done, type
|
||||
@kbd{C-c C-c} to send the patch via email to the developers. It will
|
||||
be sent to the GNU Bug Tracker at @url{https://debbugs.gnu.org}. The
|
||||
tracker will assign a number to your submission, just like it does
|
||||
with bug reports. The developers will usually respond, perhaps asking
|
||||
you for more details or any additional information, so be sure to
|
||||
include a valid reply email address.
|
||||
|
||||
We prefer to get the patches as plain text, either inline (be careful
|
||||
your mail client does not change line breaks) or as MIME attachments.
|
||||
Here's what we ask you to provide as part of your patch submissions:
|
||||
|
||||
@itemize @bullet
|
||||
@item
|
||||
Include an explanation with your changes of what problem they fix or what
|
||||
improvement they bring about.
|
||||
An explanation of what problem you are fixing or what improvement will
|
||||
the patches bring about:
|
||||
|
||||
@itemize
|
||||
@itemize @minus
|
||||
@item
|
||||
For a fix for an existing bug, it is
|
||||
best to reply to the relevant discussion on the @samp{bug-gnu-emacs}
|
||||
|
|
@ -1140,26 +1205,28 @@ implementation.
|
|||
|
||||
@item
|
||||
For a new bug, include a proper bug report for the problem you think
|
||||
you have fixed. We need to convince ourselves that the change is
|
||||
right before installing it. Even if it is correct, we might have
|
||||
trouble understanding it if we don't have a way to reproduce the
|
||||
problem.
|
||||
you have fixed; @pxref{Checklist, Checklist for Bug Reports}. We need
|
||||
to convince ourselves that the change is right before installing it.
|
||||
Even if it is correct, we might have trouble understanding it if we
|
||||
don't have a way to reproduce the problem it tries to fix.
|
||||
@end itemize
|
||||
|
||||
@item
|
||||
Include all the comments that are appropriate to help people reading the
|
||||
source in the future understand why this change was needed.
|
||||
Include in your code changes all the comments that are appropriate to
|
||||
help people reading the source in the future understand why this
|
||||
change was needed.
|
||||
|
||||
@item
|
||||
Don't mix together changes made for different reasons.
|
||||
Send them @emph{individually}.
|
||||
|
||||
If you make two changes for separate reasons, then we might not want to
|
||||
install them both. We might want to install just one. If you send them
|
||||
all jumbled together in a single set of diffs, we have to do extra work
|
||||
to disentangle them---to figure out which parts of the change serve
|
||||
which purpose. If we don't have time for this, we might have to ignore
|
||||
your changes entirely.
|
||||
If you make two changes for separate reasons, then we might not want
|
||||
to install them both. We might want to install just one, or install
|
||||
each one in a different versions of Emacs. If you send them all
|
||||
jumbled together in a single set of diffs, we have to do extra work to
|
||||
disentangle them---to figure out which parts of the change serve which
|
||||
purpose. If we don't have time for this, we might have to postpone
|
||||
inclusion of your patches for a long time.
|
||||
|
||||
If you send each change as soon as you have written it, with its own
|
||||
explanation, then two changes never get tangled up, and we can consider
|
||||
|
|
@ -1176,52 +1243,46 @@ right away. That gives us the option of installing it immediately if it
|
|||
is important.
|
||||
|
||||
@item
|
||||
The patch itself.
|
||||
|
||||
Use @samp{diff -u} to make your diffs. Diffs without context are hard
|
||||
to install reliably. More than that, they are hard to study; we must
|
||||
always study a patch to decide whether we want to install it. Context
|
||||
format is better than contextless diffs, but we prefer the unified
|
||||
format.
|
||||
|
||||
If you have GNU diff, use @samp{diff -u -F'^[_a-zA-Z0-9$]\+ *('} when
|
||||
making diffs of C code. This shows the name of the function that each
|
||||
change occurs in.
|
||||
The patch itself. This can be produced in one of the following ways:
|
||||
|
||||
@itemize @minus
|
||||
@item
|
||||
If you are using the Emacs repository, make sure your copy is
|
||||
up-to-date (e.g., with @code{git pull}). You can commit your changes
|
||||
to a private branch and generate a patch from the master version by
|
||||
using @code{git format-patch master}. Or you can leave your changes
|
||||
uncommitted and use @code{git diff}.
|
||||
using @code{git format-patch master}. (This is the preferred method,
|
||||
as it makes our job of applying the patch easier.) Or you can leave
|
||||
your changes uncommitted and use @code{git diff}, as described below.
|
||||
|
||||
@item
|
||||
Avoid any ambiguity as to which is the old version and which is the new.
|
||||
Please make the old version the first argument to diff, and the new
|
||||
version the second argument. And please give one version or the other a
|
||||
name that indicates whether it is the old version or your new changed
|
||||
one.
|
||||
Use @kbd{diff -u} to make your diffs. If you have GNU diff, use
|
||||
@w{@kbd{diff -u -F'^[_a-zA-Z0-9$]\+ *('}} when making diffs of C code.
|
||||
This shows the name of the function that each change occurs in.
|
||||
|
||||
When producing the diffs, avoid any ambiguity as to which is the old
|
||||
version and which is the new. Please make the old version the first
|
||||
argument to diff, and the new version the second argument. And please
|
||||
give one version or the other a name that indicates whether it is the
|
||||
old version or your new changed one.
|
||||
@end itemize
|
||||
|
||||
@item
|
||||
Write the commit log entries for your changes. This is both to save us
|
||||
the extra work of writing them, and to help explain your changes so we
|
||||
can understand them.
|
||||
|
||||
The purpose of the commit log is to show people where to find what was
|
||||
changed. So you need to be specific about what functions you changed;
|
||||
in large functions, it's often helpful to indicate where within the
|
||||
function the change was.
|
||||
The purpose of the commit log is to explain the rationale of the
|
||||
changes, the way the modified code solves whatever problems your patch
|
||||
is trying to fix, and also show people where to find what was changed.
|
||||
So you need to be specific about what functions you changed and why.
|
||||
For the details about our style and requirements for good commit log
|
||||
messages, please see the ``Commit messages'' section of the file
|
||||
@file{CONTRIBUTE} in the Emacs source tree.
|
||||
|
||||
On the other hand, once you have shown people where to find the change,
|
||||
you need not explain its purpose in the change log. Thus, if you add a
|
||||
new function, all you need to say about it is that it is new. If you
|
||||
feel that the purpose needs explaining, it probably does---but put the
|
||||
explanation in comments in the code. It will be more useful there.
|
||||
|
||||
Please look at the commit log entries of recent commits to see what
|
||||
sorts of information to put in, and to learn the style that we use.
|
||||
Note that, unlike some other projects, we do require commit logs for
|
||||
documentation, i.e., Texinfo files.
|
||||
@xref{Change Log},
|
||||
Please also look at the commit log entries of recent commits to see
|
||||
what sorts of information to put in, and to learn the style that we
|
||||
use. Note that, unlike some other projects, we do require commit logs
|
||||
for documentation, i.e., Texinfo files. @xref{Change Log},
|
||||
@ifset WWW_GNU_ORG
|
||||
see
|
||||
@url{https://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html},
|
||||
|
|
@ -1232,7 +1293,7 @@ Change Log Concepts, standards, GNU Coding Standards}.
|
|||
@item
|
||||
When you write the fix, keep in mind that we can't install a change that
|
||||
would break other systems. Please think about what effect your change
|
||||
will have if compiled on another type of system.
|
||||
will have if compiled and/or used on another type of system.
|
||||
|
||||
Sometimes people send fixes that @emph{might} be an improvement in
|
||||
general---but it is hard to be sure of this. It's hard to install
|
||||
|
|
@ -1240,9 +1301,10 @@ such changes because we have to study them very carefully. Of course,
|
|||
a good explanation of the reasoning by which you concluded the change
|
||||
was correct can help convince us.
|
||||
|
||||
The safest changes are changes to the configuration files for a
|
||||
particular machine. These are safe because they can't create new bugs
|
||||
on other machines.
|
||||
The safest changes are changes to the files or portions of files that
|
||||
are only used for a particular machine or a particular system. These
|
||||
are safe because they can't create new bugs on other machines or
|
||||
systems.
|
||||
|
||||
Please help us keep up with the workload by designing the patch in a
|
||||
form that is clearly safe to install.
|
||||
|
|
@ -1259,7 +1321,7 @@ There are many ways to contribute to Emacs:
|
|||
|
||||
@itemize
|
||||
@item
|
||||
find and report bugs; @xref{Bugs}.
|
||||
find and report bugs; @pxref{Bugs}.
|
||||
|
||||
@item
|
||||
answer questions on the Emacs user mailing list
|
||||
|
|
@ -1326,15 +1388,15 @@ before you start; it might be possible to suggest ways to make your
|
|||
extension fit in better with the rest of Emacs.
|
||||
|
||||
When implementing a feature, please follow the Emacs coding standards;
|
||||
@xref{Coding Standards}. In addition, non-trivial contributions
|
||||
require a copyright assignment to the FSF; @xref{Copyright Assignment}.
|
||||
@pxref{Coding Standards}. In addition, substantial contributions
|
||||
require a copyright assignment to the FSF; @pxref{Copyright Assignment}.
|
||||
|
||||
The development version of Emacs can be downloaded from the
|
||||
repository where it is actively maintained by a group of developers.
|
||||
See the Emacs project page
|
||||
@url{https://savannah.gnu.org/projects/emacs/} for access details.
|
||||
|
||||
It is important to write your patch based on the current working
|
||||
It is important to write your patches based on the current working
|
||||
version. If you start from an older version, your patch may be
|
||||
outdated (so that maintainers will have a hard time applying it), or
|
||||
changes in Emacs may have made your patch unnecessary. After you have
|
||||
|
|
@ -1397,7 +1459,7 @@ the Emacs Lisp Reference Manual
|
|||
|
||||
@node Coding Standards
|
||||
@subsection Coding Standards
|
||||
@cindex coding standards
|
||||
@cindex coding standards for Emacs submissions
|
||||
|
||||
Contributed code should follow the GNU Coding Standards
|
||||
@url{https://www.gnu.org/prep/standards/}. This may also be available
|
||||
|
|
@ -1432,10 +1494,6 @@ to be included in Emacs.
|
|||
@item
|
||||
Remove all trailing whitespace in all source and text files.
|
||||
|
||||
@item
|
||||
Emacs has no convention on whether to use tabs in source code; please
|
||||
don't change whitespace in the files you edit.
|
||||
|
||||
@item
|
||||
Use @code{?\s} instead of @code{? } in Lisp code for a space character.
|
||||
|
||||
|
|
@ -1455,7 +1513,7 @@ packages stored in GNU ELPA, we require that the copyright be assigned
|
|||
to the FSF@. For the reasons behind this, see
|
||||
@url{https://www.gnu.org/licenses/why-assign.html}.
|
||||
|
||||
Copyright assignment is a simple process. Residents of some countries
|
||||
Copyright assignment is a simple process. Residents of many countries
|
||||
can do it entirely electronically. We can help you get started,
|
||||
including sending you the forms you should fill, and answer any
|
||||
questions you may have (or point you to the people with the answers),
|
||||
|
|
|
|||
|
|
@ -1775,6 +1775,8 @@ it's used to say which major modes this minor mode is useful in.
|
|||
|
||||
Any other keyword arguments are passed directly to the
|
||||
@code{defcustom} generated for the variable @var{mode}.
|
||||
@xref{Variable Definitions}, for the description of those keywords and
|
||||
their values.
|
||||
|
||||
The command named @var{mode} first performs the standard actions such as
|
||||
setting the variable named @var{mode} and then executes the @var{body}
|
||||
|
|
@ -1860,9 +1862,10 @@ by visiting files, and buffers that use a major mode other than
|
|||
Fundamental mode; but it does not detect the creation of a new buffer
|
||||
in Fundamental mode.
|
||||
|
||||
This defines the customization option @var{global-mode} (@pxref{Customization}),
|
||||
which can be toggled in the Customize interface to turn the minor mode on
|
||||
and off. As with @code{define-minor-mode}, you should ensure that the
|
||||
This macro defines the customization option @var{global-mode}
|
||||
(@pxref{Customization}), which can be toggled via the Customize
|
||||
interface to turn the minor mode on and off. As with
|
||||
@code{define-minor-mode}, you should ensure that the
|
||||
@code{define-globalized-minor-mode} form is evaluated each time Emacs
|
||||
starts, for example by providing a @code{:require} keyword.
|
||||
|
||||
|
|
@ -1875,24 +1878,27 @@ Use @code{:variable @var{variable}} if that's not the case--some minor
|
|||
modes use a different variable to store this state information.
|
||||
|
||||
Generally speaking, when you define a globalized minor mode, you should
|
||||
also define a non-globalized version, so that people can use (or
|
||||
disable) it in individual buffers. This also allows them to disable a
|
||||
also define a non-globalized version, so that people could use it (or
|
||||
disable it) in individual buffers. This also allows them to disable a
|
||||
globally enabled minor mode in a specific major mode, by using that
|
||||
mode's hook.
|
||||
|
||||
If given a @code{:predicate} keyword, a user option called the same as
|
||||
the global mode variable, but with @code{-modes} instead of
|
||||
@code{-mode} at the end will be created. The variable is used as a
|
||||
predicate that specifies which major modes the minor mode should be
|
||||
activated in. Valid values include @code{t} (use in all major modes,
|
||||
@code{nil} (use in no major modes), or a list of mode names (or
|
||||
@code{(not mode-name ...)}) elements (as well as @code{t} and
|
||||
@code{nil}).
|
||||
If the macro is given a @code{:predicate} keyword, it will create a
|
||||
user option called the same as the global mode variable, but with
|
||||
@code{-modes} instead of @code{-mode} at the end, i.e.@:
|
||||
@code{@var{global-mode}s}. This variable will be used in a predicate
|
||||
function that determines whether the minor mode should be activated in
|
||||
a particular major mode. Valid values of @code{:predicate} include
|
||||
@code{t} (use in all major modes), @code{nil} (don't use in any major
|
||||
modes), or a list of mode names, optionally preceded with @code{not}
|
||||
(as in @w{@code{(not @var{mode-name} @dots{})}}). These elements can
|
||||
be mixed, as shown in the following examples.
|
||||
|
||||
@example
|
||||
(c-mode (not mail-mode message-mode) text-mode)
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
This means ``use in modes derived from @code{c-mode}, and not in
|
||||
modes derived from @code{message-mode} or @code{mail-mode}, but do use
|
||||
in modes derived from @code{text-mode}, and otherwise no other
|
||||
|
|
@ -1902,13 +1908,15 @@ modes''.
|
|||
((not c-mode) t)
|
||||
@end example
|
||||
|
||||
This means ``don't use modes derived from @code{c-mode}, but use
|
||||
@noindent
|
||||
This means ``don't use in modes derived from @code{c-mode}, but do use
|
||||
everywhere else''.
|
||||
|
||||
@example
|
||||
(text-mode)
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
This means ``use in modes derived from @code{text-mode}, but nowhere
|
||||
else''. (There's an implicit @code{nil} element at the end.)
|
||||
@end defmac
|
||||
|
|
|
|||
|
|
@ -1298,9 +1298,9 @@ user.
|
|||
|
||||
To report an Eglot bug, send e-mail to @email{bug-gnu-emacs@@gnu.org}.
|
||||
|
||||
Get acquainted with Emacs's bug reporting guidelines (@pxref{Bugs,,,
|
||||
emacs, GNU Emacs Manual}). Then, follow this checklist specific to
|
||||
Eglot bug rerpots.
|
||||
To understand how to write this email, get acquainted with Emacs's bug
|
||||
reporting guidelines (@pxref{Bugs,,, emacs, GNU Emacs Manual}). Then,
|
||||
follow this Eglot-specific checklist:
|
||||
|
||||
@enumerate
|
||||
@item
|
||||
|
|
@ -1341,18 +1341,18 @@ since they are usually implicitly loaded when visiting a file in that
|
|||
language.
|
||||
|
||||
ELPA packages usually live in @code{~/.emacs.d/elpa} (or what is in
|
||||
@code{package-user-dir}). Please show the listing of files in that
|
||||
directory as well.
|
||||
@code{package-user-dir}). Including a listing of files in that
|
||||
directory is a way to tell the maintainers about ELPA package
|
||||
versions.
|
||||
|
||||
@item
|
||||
Include a recipe to replicate the problem with @emph{a clean Emacs
|
||||
run}. This means @kbd{emacs -Q -f package-initialize} invocation
|
||||
which starts Emacs with no configuration and initializes the ELPA
|
||||
packages. A very minimal (no more that 10 lines) @file{.emacs}
|
||||
initialization file is also acceptable and good means to describe
|
||||
changes to variables.
|
||||
run}. The invocation @code{emacs -Q -f package-initialize} starts
|
||||
Emacs with no configuration and initializes the ELPA packages. A very
|
||||
minimal @file{.emacs} initialization file (10 lines or less) is also
|
||||
acceptable and good means to describe changes to variables.
|
||||
|
||||
There is usually no need to include @kbd{require} statements in the
|
||||
There is usually no need to include @code{require} statements in the
|
||||
recipe, as Eglot's functionality uses autoloads.
|
||||
|
||||
Likewise, there is rarely the need to use things like
|
||||
|
|
@ -1364,9 +1364,9 @@ adding to hooks with @code{add-hook}. Prefer starting Eglot with
|
|||
@item
|
||||
Make sure to double check all the above elements and re-run the recipe
|
||||
to see that the problem is reproducible. Following the recipe should
|
||||
produce event transcript and error backtraces that are exactly the
|
||||
same or very similar to the ones you included. If the problem only
|
||||
happens sometimes, include this information in your bug report.
|
||||
produce event transcript and error backtraces that are very similar to
|
||||
the ones you included. If the problem only happens sometimes, mention
|
||||
this in your report.
|
||||
@end enumerate
|
||||
|
||||
Please keep in mind that some problems reported against Eglot may
|
||||
|
|
|
|||
|
|
@ -1504,8 +1504,10 @@ access and it has the most reasonable security protocols, use
|
|||
@end example
|
||||
|
||||
If @option{ssh} is unavailable for whatever reason, look for other
|
||||
obvious options. For MS Windows, try the @option{plink} method. For
|
||||
Kerberos, try @option{krlogin}.
|
||||
obvious options. For MS Windows, try the @option{plink}
|
||||
method@footnote{This shouldn't be needed with recent @code{OpenSSH}
|
||||
versions for MS Windows. Use method @option{sshx}.}. For Kerberos,
|
||||
try @option{krlogin}.
|
||||
|
||||
For editing local files as @option{su} or @option{sudo} methods, try
|
||||
the shortened syntax of @samp{root}:
|
||||
|
|
@ -2866,11 +2868,19 @@ When @value{tramp} uses direct remote copying, password caches are not
|
|||
consulted.
|
||||
|
||||
|
||||
@subsection Issues with Cygwin ssh
|
||||
@subsection Issues with Cygwin and MS Windows ssh
|
||||
@cindex cygwin, issues
|
||||
@cindex ms Windows, issues
|
||||
|
||||
This section is incomplete. Please share your solutions.
|
||||
|
||||
@cindex ms windows and @command{ssh}
|
||||
@cindex ms windows and @command{ssh-agent}
|
||||
|
||||
MS Windows' @command{ssh} does not open a remote TTY@. Use the method
|
||||
@option{sshx} or @option{scpx} instead. Furthermore, it cannot read a
|
||||
passphrase for ssh private keys. Use the MS @code{ssh-agent}.
|
||||
|
||||
@cindex method @option{sshx} with cygwin
|
||||
@cindex @option{sshx} method with cygwin
|
||||
|
||||
|
|
@ -2910,13 +2920,15 @@ Windows file names to Cygwin file names.
|
|||
@cindex @env{SSH_AUTH_SOCK} and emacs on ms windows
|
||||
@vindex SSH_AUTH_SOCK@r{, environment variable}
|
||||
|
||||
When using the @command{ssh-agent} on MS Windows for password-less
|
||||
interaction, @option{ssh} methods depend on the environment variable
|
||||
@env{SSH_AUTH_SOCK}. But this variable is not set when Emacs is
|
||||
started from a Desktop shortcut and authentication fails.
|
||||
When using the cygwin @command{ssh-agent} on MS Windows for
|
||||
password-less interaction, @option{ssh} methods depend on the
|
||||
environment variable @env{SSH_AUTH_SOCK}. But this variable is not
|
||||
set when Emacs is started from a Desktop shortcut and authentication
|
||||
fails.
|
||||
|
||||
One workaround is to use an MS Windows based SSH Agent, such as
|
||||
@command{Pageant}. It is part of the PuTTY Suite of tools.
|
||||
One workaround is to use an MS Windows based SSH Agent, such as the
|
||||
native MS @command{ssh-agent} or @command{Pageant}. The latter is
|
||||
part of the PuTTY Suite of tools.
|
||||
|
||||
The fallback is to start Emacs from a shell.
|
||||
|
||||
|
|
|
|||
|
|
@ -2566,6 +2566,20 @@ currently exist.
|
|||
|
||||
Yes, see @code{transient-display-buffer-action} in @ref{Configuration}.
|
||||
|
||||
@anchor{How can I copy text from the popup buffer?}
|
||||
@appendixsec How can I copy text from the popup buffer?
|
||||
|
||||
To be able to mark text in any transient popup buffer using the mouse,
|
||||
you have to add the following binding. Note that the region won't be
|
||||
visualized, while doing so. After you have quit the transient popup,
|
||||
you will be able to yank it another buffer.
|
||||
|
||||
@lisp
|
||||
(keymap-set transient-predicate-map
|
||||
"<mouse-set-region>"
|
||||
#'transient--do-stay)
|
||||
@end lisp
|
||||
|
||||
@anchor{Why did some of the key bindings change?}
|
||||
@appendixsec Why did some of the key bindings change?
|
||||
|
||||
|
|
|
|||
|
|
@ -3565,11 +3565,13 @@ font spec. In these cases, replacing ":weight 'normal" with ":weight
|
|||
'medium" should fix the issue.
|
||||
|
||||
---
|
||||
** Keymap descriptions have changed.
|
||||
** Keymap descriptions by Help commands have changed.
|
||||
'help--describe-command', 'C-h b' and associated functions that output
|
||||
keymap descriptions have changed. In particular, prefix commands are
|
||||
not output at all, and instead of "??" for closures/functions,
|
||||
"[closure]"/"[lambda]" is output.
|
||||
not output at all, and instead of "??" for closures/functions, these
|
||||
functions output "[closure]"/"[lambda]". You can get back the old
|
||||
behavior of including prefix commands by customizing the new option
|
||||
'describe-bindings-show-prefix-commands' to a non-nil value.
|
||||
|
||||
---
|
||||
** 'downcase' details have changed slightly.
|
||||
|
|
|
|||
27
etc/PROBLEMS
27
etc/PROBLEMS
|
|
@ -2313,6 +2313,33 @@ recommended way of turning on Font-lock is by typing "M-x
|
|||
global-font-lock-mode RET" or by customizing the variable
|
||||
'global-font-lock-mode'.
|
||||
|
||||
** Colors are not available or messed up on TTY frames inside 'screen'.
|
||||
|
||||
This can happen if you have COLORTERM=truecolor defined in the
|
||||
environment when Emacs starts, but your version of 'screen' doesn't
|
||||
actually support 24-bit true colors.
|
||||
|
||||
The COLORTERM environment variable is supposed to be set to the value
|
||||
"truecolor" only if the terminal used by Emacs actually supports true
|
||||
color. Emacs does not have any means of verifying that this support
|
||||
is available, it takes the fact that the variable is defined to this
|
||||
value as an indication that true color support is, in fact, available,
|
||||
and uses color setting commands that COLORTERM=truecolor presumes,
|
||||
bypassing the usual Terminfo capabilities related to colors.
|
||||
|
||||
Some text-mode terminals, such as GNOME Terminal, are known to set
|
||||
this environment variable, supposedly to announce their own support
|
||||
for true color; however the setting is then inherited by any other
|
||||
terminal emulators started from such a terminal, even though those
|
||||
other terminal emulators might not themselves support true color using
|
||||
the same commands as Emacs uses when it sees COLORTERM=truecolor.
|
||||
|
||||
The solution is to either upgrade to a newer version of 'screen'
|
||||
(version 5.x or later reportedly supports true color), or to unset the
|
||||
COLORTERM variable before starting 'screen', and let Emacs use the
|
||||
color support provided by the terminal emulator as defined in the
|
||||
Terminfo database.
|
||||
|
||||
** Unexpected characters inserted into the buffer when you start Emacs.
|
||||
See e.g. <URL:https://debbugs.gnu.org/11129>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
% Reference Card for Org Mode
|
||||
\def\orgversionnumber{9.6.1}
|
||||
\def\orgversionnumber{9.6.2}
|
||||
\def\versionyear{2023} % latest update
|
||||
\input emacsver.tex
|
||||
|
||||
|
|
|
|||
|
|
@ -186,8 +186,9 @@ and above."
|
|||
:type '(repeat string)
|
||||
:version "28.1")
|
||||
|
||||
(defcustom native-comp-driver-options (when (eq system-type 'darwin)
|
||||
'("-Wl,-w"))
|
||||
(defcustom native-comp-driver-options
|
||||
(cond ((eq system-type 'darwin) '("-Wl,-w"))
|
||||
((eq system-type 'cygwin) '("-Wl,-dynamicbase")))
|
||||
"Options passed verbatim to the native compiler's back-end driver.
|
||||
Note that not all options are meaningful; typically only the options
|
||||
affecting the assembler and linker are likely to be useful.
|
||||
|
|
|
|||
|
|
@ -452,15 +452,23 @@ No problems result if this variable is not bound.
|
|||
TURN-ON is a function that will be called with no args in every buffer
|
||||
and that should try to turn MODE on if applicable for that buffer.
|
||||
|
||||
Each of KEY VALUE is a pair of CL-style keyword arguments. :predicate
|
||||
specifies which major modes the globalized minor mode should be switched on
|
||||
in. As the minor mode defined by this function is always global, any
|
||||
:global keyword is ignored. Other keywords have the same meaning as in
|
||||
`define-minor-mode', which see. In particular, :group specifies the custom
|
||||
group. The most useful keywords are those that are passed on to the
|
||||
`defcustom'. It normally makes no sense to pass the :lighter or :keymap
|
||||
keywords to `define-globalized-minor-mode', since these are usually passed
|
||||
to the buffer-local version of the minor mode.
|
||||
Each of KEY VALUE is a pair of CL-style keyword arguments.
|
||||
The :predicate argument specifies in which major modes should the
|
||||
globalized minor mode be switched on. The value should be t (meaning
|
||||
switch on the minor mode in all major modes), nil (meaning don't
|
||||
switch on in any major mode), a list of modes (meaning switch on only
|
||||
in those modes and their descendants), or a list (not MODES...),
|
||||
meaning switch on in any major mode except MODES. The value can also
|
||||
mix all of these forms, see the info node `Defining Minor Modes' for
|
||||
details.
|
||||
As the minor mode defined by this function is always global, any
|
||||
:global keyword is ignored.
|
||||
Other keywords have the same meaning as in `define-minor-mode',
|
||||
which see. In particular, :group specifies the custom group.
|
||||
The most useful keywords are those that are passed on to the `defcustom'.
|
||||
It normally makes no sense to pass the :lighter or :keymap keywords
|
||||
to `define-globalized-minor-mode', since these are usually passed to
|
||||
the buffer-local version of the minor mode.
|
||||
|
||||
BODY contains code to execute each time the mode is enabled or disabled.
|
||||
It is executed after toggling the mode, and before running
|
||||
|
|
@ -512,7 +520,7 @@ on if the hook has explicitly disabled it.
|
|||
(setq turn-on-function
|
||||
`(lambda ()
|
||||
(require 'easy-mmode)
|
||||
(when (easy-mmode--globalized-predicate-p ,(car predicate))
|
||||
(when (easy-mmode--globalized-predicate-p ,MODE-predicate)
|
||||
(funcall ,turn-on-function)))))
|
||||
(_ (push keyw extra-keywords) (push (pop body) extra-keywords))))
|
||||
|
||||
|
|
|
|||
|
|
@ -271,7 +271,7 @@ instead the assignment is turned into something equivalent to
|
|||
(SETTER ARGS... temp)
|
||||
temp)
|
||||
so as to preserve the semantics of `setf'."
|
||||
(declare (debug (sexp (&or symbolp lambda-expr) &optional sexp)))
|
||||
(declare (debug (sexp [&or symbolp lambda-expr] &optional sexp)))
|
||||
(when (eq 'lambda (car-safe setter))
|
||||
(message "Use `gv-define-setter' or name %s's setter function" name))
|
||||
`(gv-define-setter ,name (val &rest args)
|
||||
|
|
|
|||
|
|
@ -437,7 +437,7 @@ the C sources, too."
|
|||
(setq file-name
|
||||
(locate-file file-name load-path '(".el" ".elc") 'readable)))
|
||||
((and (stringp file-name)
|
||||
(string-match "[.]*loaddefs.el\\'" file-name))
|
||||
(string-match "[.]*loaddefs.elc?\\'" file-name))
|
||||
;; An autoloaded variable or face. Visit loaddefs.el in a buffer
|
||||
;; and try to extract the defining file. The following form is
|
||||
;; from `describe-function-1' and `describe-variable'.
|
||||
|
|
|
|||
|
|
@ -717,6 +717,12 @@ Return nil if KEYS is nil."
|
|||
:group 'help
|
||||
:version "29.1")
|
||||
|
||||
(defcustom describe-bindings-show-prefix-commands nil
|
||||
"Non-nil means show prefix commands in the output of `describe-bindings'."
|
||||
:type 'boolean
|
||||
:group 'help
|
||||
:version "29.1")
|
||||
|
||||
(declare-function outline-hide-subtree "outline")
|
||||
|
||||
(defun describe-bindings (&optional prefix buffer)
|
||||
|
|
@ -1699,6 +1705,7 @@ in `describe-map-tree'."
|
|||
(setq vect (cdr vect))
|
||||
(setq end (caar vect))))
|
||||
(when (or (not (eq start end))
|
||||
describe-bindings-show-prefix-commands
|
||||
;; Don't output keymap prefixes.
|
||||
(not (keymapp definition)))
|
||||
(when first
|
||||
|
|
|
|||
|
|
@ -64,16 +64,22 @@ The action to be taken can be further customized via
|
|||
:version "28.1"
|
||||
:type 'regexp)
|
||||
|
||||
(defcustom eww-download-directory "~/Downloads/"
|
||||
"Default directory where `eww' saves downloaded files."
|
||||
:version "29.1"
|
||||
:group 'eww
|
||||
:type 'directory)
|
||||
|
||||
(defun eww--download-directory ()
|
||||
"Return the name of the download directory.
|
||||
If ~/Downloads/ exists, that will be used, and if not, the
|
||||
DOWNLOAD XDG user directory will be returned. If that's
|
||||
undefined, ~/Downloads/ is returned anyway."
|
||||
(or (and (file-exists-p "~/Downloads/")
|
||||
"~/Downloads/")
|
||||
"Return the name of the EWW download directory.
|
||||
The default is specified by `eww-download-directory'; however,
|
||||
if that directory doesn't exist and the DOWNLOAD XDG user directory
|
||||
is defined, use the latter instead."
|
||||
(or (and (file-exists-p eww-download-directory)
|
||||
eww-download-directory)
|
||||
(when-let ((dir (xdg-user-dir "DOWNLOAD")))
|
||||
(file-name-as-directory dir))
|
||||
"~/Downloads/"))
|
||||
eww-download-directory))
|
||||
|
||||
(defcustom eww-download-directory 'eww--download-directory
|
||||
"Directory where files will downloaded.
|
||||
|
|
|
|||
|
|
@ -319,7 +319,7 @@ The remote connection identified by SOURCE is flushed by
|
|||
(read-file-name-function #'read-file-name-default)
|
||||
source target)
|
||||
(if (null connections)
|
||||
(tramp-user-error nil "There are no remote connections.")
|
||||
(tramp-user-error nil "There are no remote connections")
|
||||
(setq source
|
||||
;; Likely, the source remote connection is broken. So we
|
||||
;; shall avoid any action on it.
|
||||
|
|
@ -367,15 +367,15 @@ The remote connection identified by SOURCE is flushed by
|
|||
(list source target)))
|
||||
|
||||
(unless (tramp-tramp-file-p source)
|
||||
(tramp-user-error nil "Source %s must be remote." source))
|
||||
(tramp-user-error nil "Source %s must be remote" source))
|
||||
(when (null target)
|
||||
(or (setq target (tramp-default-rename-file source))
|
||||
(tramp-user-error
|
||||
nil
|
||||
(concat "There is no target specified. "
|
||||
"Check `tramp-default-rename-alist' for a proper entry."))))
|
||||
"Check `tramp-default-rename-alist' for a proper entry"))))
|
||||
(when (tramp-equal-remote source target)
|
||||
(tramp-user-error nil "Source and target must have different remote."))
|
||||
(tramp-user-error nil "Source and target must have different remote"))
|
||||
|
||||
;; Append local file name if none is specified.
|
||||
(when (string-equal (file-remote-p target) target)
|
||||
|
|
@ -461,7 +461,7 @@ For details, see `tramp-rename-files'."
|
|||
nil
|
||||
(substitute-command-keys
|
||||
(concat "Current buffer is not remote. "
|
||||
"Consider `\\[tramp-rename-files]' instead.")))
|
||||
"Consider `\\[tramp-rename-files]' instead")))
|
||||
(setq target
|
||||
(when (null current-prefix-arg)
|
||||
;; The source remote connection shall not trigger any action.
|
||||
|
|
|
|||
|
|
@ -436,7 +436,7 @@ Otherwise, return NAME."
|
|||
crypt-vec (if (eq op 'encrypt) "encode" "decode")
|
||||
tramp-compat-temporary-file-directory localname)
|
||||
(tramp-error
|
||||
crypt-vec 'file-error "%s of file name %s failed."
|
||||
crypt-vec 'file-error "%s of file name %s failed"
|
||||
(if (eq op 'encrypt) "Encoding" "Decoding") name))
|
||||
(with-current-buffer (tramp-get-connection-buffer crypt-vec)
|
||||
(goto-char (point-min))
|
||||
|
|
@ -471,7 +471,7 @@ Raise an error if this fails."
|
|||
(file-name-directory infile)
|
||||
(concat "/" (file-name-nondirectory infile)))
|
||||
(tramp-error
|
||||
crypt-vec 'file-error "%s of file %s failed."
|
||||
crypt-vec 'file-error "%s of file %s failed"
|
||||
(if (eq op 'encrypt) "Encrypting" "Decrypting") infile))
|
||||
(with-current-buffer (tramp-get-connection-buffer crypt-vec)
|
||||
(write-region nil nil outfile)))))
|
||||
|
|
@ -495,11 +495,11 @@ directory. File names will be also encrypted."
|
|||
;; (declare (completion tramp-crypt-command-completion-p))
|
||||
(interactive "DRemote directory name: ")
|
||||
(unless tramp-crypt-enabled
|
||||
(tramp-user-error nil "Feature is not enabled."))
|
||||
(tramp-user-error nil "Feature is not enabled"))
|
||||
(unless (and (tramp-tramp-file-p name) (file-directory-p name))
|
||||
(tramp-user-error nil "%s must be an existing remote directory." name))
|
||||
(tramp-user-error nil "%s must be an existing remote directory" name))
|
||||
(when (file-name-quoted-p name)
|
||||
(tramp-user-error nil "%s must not be quoted." name))
|
||||
(tramp-user-error nil "%s must not be quoted" name))
|
||||
(setq name (file-name-as-directory (expand-file-name name)))
|
||||
(unless (member name tramp-crypt-directories)
|
||||
(setq tramp-crypt-directories (cons name tramp-crypt-directories)))
|
||||
|
|
@ -518,7 +518,7 @@ kept in their encrypted form."
|
|||
;; (declare (completion tramp-crypt-command-completion-p))
|
||||
(interactive "DRemote directory name: ")
|
||||
(unless tramp-crypt-enabled
|
||||
(tramp-user-error nil "Feature is not enabled."))
|
||||
(tramp-user-error nil "Feature is not enabled"))
|
||||
(setq name (file-name-as-directory (expand-file-name name)))
|
||||
(when (and (member name tramp-crypt-directories)
|
||||
(delete
|
||||
|
|
|
|||
|
|
@ -1115,7 +1115,7 @@ file names."
|
|||
(goto-char (point-min))
|
||||
(tramp-error-with-buffer
|
||||
nil v 'file-error
|
||||
"%s failed, see buffer `%s' for details."
|
||||
"%s failed, see buffer `%s' for details"
|
||||
msg-operation (buffer-name)))
|
||||
|
||||
;; Some WebDAV server, like the one from QNAP, do
|
||||
|
|
|
|||
|
|
@ -1147,8 +1147,8 @@ Operations not mentioned here will be handled by the normal Emacs functions.")
|
|||
(unless (tramp-get-remote-ln v)
|
||||
(tramp-error
|
||||
v 'file-error
|
||||
(concat "Making a symbolic link. "
|
||||
"ln(1) does not exist on the remote host."))))
|
||||
(concat "Making a symbolic link: "
|
||||
"ln(1) does not exist on the remote host"))))
|
||||
|
||||
(tramp-skeleton-handle-make-symbolic-link target linkname ok-if-already-exists
|
||||
(and (tramp-send-command-and-check
|
||||
|
|
@ -2150,7 +2150,7 @@ the uid and gid from FILENAME."
|
|||
cmd-result)
|
||||
(tramp-error-with-buffer
|
||||
nil v 'file-error
|
||||
"Copying directly failed, see buffer `%s' for details."
|
||||
"Copying directly failed, see buffer `%s' for details"
|
||||
(buffer-name)))))
|
||||
|
||||
;; We are on the local host.
|
||||
|
|
@ -2205,7 +2205,7 @@ the uid and gid from FILENAME."
|
|||
"%s %s %s" cmd
|
||||
(tramp-shell-quote-argument localname1)
|
||||
(tramp-shell-quote-argument tmpfile))
|
||||
"Copying directly failed, see buffer `%s' for details."
|
||||
"Copying directly failed, see buffer `%s' for details"
|
||||
(tramp-get-buffer v))
|
||||
;; We must change the ownership as remote user.
|
||||
;; Since this does not work reliable, we also
|
||||
|
|
@ -2238,7 +2238,7 @@ the uid and gid from FILENAME."
|
|||
"cp -f -p %s %s"
|
||||
(tramp-shell-quote-argument tmpfile)
|
||||
(tramp-shell-quote-argument localname2))
|
||||
"Copying directly failed, see buffer `%s' for details."
|
||||
"Copying directly failed, see buffer `%s' for details"
|
||||
(tramp-get-buffer v)))
|
||||
(t1
|
||||
(tramp-run-real-handler
|
||||
|
|
|
|||
|
|
@ -692,7 +692,7 @@ PRESERVE-UID-GID and PRESERVE-EXTENDED-ATTRIBUTES are completely ignored."
|
|||
|
||||
;; "rmdir" does not report an error. So we check ourselves.
|
||||
(when (file-exists-p directory)
|
||||
(tramp-error v 'file-error "`%s' not removed." directory)))))
|
||||
(tramp-error v 'file-error "`%s' not removed" directory)))))
|
||||
|
||||
(defun tramp-smb-handle-delete-file (filename &optional trash)
|
||||
"Like `delete-file' for Tramp files."
|
||||
|
|
|
|||
|
|
@ -1722,11 +1722,11 @@ default values are used."
|
|||
(unless (or nodefault non-essential
|
||||
(assoc method tramp-methods))
|
||||
(tramp-user-error
|
||||
v "Method `%s' is not known." method))
|
||||
v "Method `%s' is not known" method))
|
||||
;; Only some methods from tramp-sh.el do support multi-hops.
|
||||
(unless (or (null hop) nodefault non-essential (tramp-multi-hop-p v))
|
||||
(tramp-user-error
|
||||
v "Method `%s' is not supported for multi-hops." method)))))))
|
||||
v "Method `%s' is not supported for multi-hops" method)))))))
|
||||
|
||||
(put #'tramp-dissect-file-name 'tramp-suppress-trace t)
|
||||
|
||||
|
|
@ -1755,7 +1755,7 @@ See `tramp-dissect-file-name' for details."
|
|||
;; Only some methods from tramp-sh.el do support multi-hops.
|
||||
(unless (or nodefault non-essential (tramp-multi-hop-p v))
|
||||
(tramp-user-error
|
||||
v "Method `%s' is not supported for multi-hops."
|
||||
v "Method `%s' is not supported for multi-hops"
|
||||
(tramp-file-name-method v)))
|
||||
;; Return result.
|
||||
v))
|
||||
|
|
@ -3936,7 +3936,7 @@ Let-bind it when necessary.")
|
|||
;; Some handlers for `tramp-get-remote-uid' return nil if they
|
||||
;; can't get the UID; always return -1 in this case for
|
||||
;; consistency.
|
||||
-1)))
|
||||
tramp-unknown-id-integer)))
|
||||
|
||||
(defun tramp-handle-access-file (filename string)
|
||||
"Like `access-file' for Tramp files."
|
||||
|
|
@ -4896,7 +4896,7 @@ Do not set it manually, it is used buffer-local in `tramp-get-lock-pid'.")
|
|||
(unless (tramp-multi-hop-p item)
|
||||
(setq tramp-default-proxies-alist saved-tdpa)
|
||||
(tramp-user-error
|
||||
vec "Method `%s' is not supported for multi-hops."
|
||||
vec "Method `%s' is not supported for multi-hops"
|
||||
(tramp-file-name-method item)))))
|
||||
|
||||
;; Some methods ("su", "sg", "sudo", "doas", "ksu") do not use the
|
||||
|
|
|
|||
|
|
@ -5,13 +5,13 @@
|
|||
(defun org-release ()
|
||||
"The release version of Org.
|
||||
Inserted by installing Org mode or when a release is made."
|
||||
(let ((org-release "9.6.1"))
|
||||
(let ((org-release "9.6.2"))
|
||||
org-release))
|
||||
;;;###autoload
|
||||
(defun org-git-version ()
|
||||
"The Git version of Org mode.
|
||||
Inserted by installing Org or when a release is made."
|
||||
(let ((org-git-version "release_9.6.1-48-g92471e"))
|
||||
(let ((org-git-version "release_9.6.2"))
|
||||
org-git-version))
|
||||
|
||||
(provide 'org-version)
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
;; URL: https://orgmode.org
|
||||
;; Package-Requires: ((emacs "26.1"))
|
||||
|
||||
;; Version: 9.6.1
|
||||
;; Version: 9.6.2
|
||||
|
||||
;; This file is part of GNU Emacs.
|
||||
;;
|
||||
|
|
|
|||
|
|
@ -2037,10 +2037,13 @@ Once computed, the results remain cached."
|
|||
"\n")))
|
||||
(with-temp-file input-file
|
||||
(insert input-content))
|
||||
(let* ((output-file (org-texinfo-compile input-file))
|
||||
(output-content (with-temp-buffer
|
||||
(insert-file-contents output-file)
|
||||
(buffer-string))))
|
||||
(when-let* ((output-file
|
||||
;; If compilation fails, consider math to
|
||||
;; be not supported.
|
||||
(ignore-errors (org-texinfo-compile input-file)))
|
||||
(output-content (with-temp-buffer
|
||||
(insert-file-contents output-file)
|
||||
(buffer-string))))
|
||||
(let ((result (string-match-p (regexp-quote math-example)
|
||||
output-content)))
|
||||
(delete-file input-file)
|
||||
|
|
|
|||
|
|
@ -5854,7 +5854,14 @@ statement."
|
|||
(save-excursion
|
||||
(python-nav-beginning-of-statement)
|
||||
(when (and (not (python-syntax-context-type))
|
||||
(looking-at (python-rx dedenter)))
|
||||
(looking-at (python-rx dedenter))
|
||||
;; Exclude the first "case" in the block.
|
||||
(not (and (string= (match-string-no-properties 0)
|
||||
"case")
|
||||
(save-excursion
|
||||
(back-to-indentation)
|
||||
(python-util-forward-comment -1)
|
||||
(equal (char-before) ?:)))))
|
||||
(point))))
|
||||
|
||||
(defun python-info-line-ends-backslash-p (&optional line-number)
|
||||
|
|
|
|||
|
|
@ -469,7 +469,7 @@ non-nil."
|
|||
(let* (first-call )
|
||||
(while (and parent
|
||||
(setq first-call (treesit-node-parent parent))
|
||||
(string-search "call" (treesit-node-type first-call)))
|
||||
(equal "call" (treesit-node-type first-call)))
|
||||
(setq parent first-call))
|
||||
(treesit-node-start (treesit-search-subtree parent "\\." nil t))))
|
||||
|
||||
|
|
@ -883,32 +883,24 @@ a statement container is a node that matches
|
|||
"Return the fully qualified name of NODE."
|
||||
(let* ((name (ruby-ts--get-name node))
|
||||
(delimiter "#"))
|
||||
(when (equal (treesit-node-type node) "singleton_method")
|
||||
(setq delimiter "."
|
||||
name (treesit-node-text (treesit-node-child-by-field-name node "name"))))
|
||||
(while (setq node (treesit-parent-until node #'ruby-ts--class-or-module-p))
|
||||
(setq name (concat (ruby-ts--get-name node) delimiter name))
|
||||
(if name
|
||||
(setq name (concat (ruby-ts--get-name node) delimiter name))
|
||||
(setq name (ruby-ts--get-name node)))
|
||||
(setq delimiter "::"))
|
||||
name))
|
||||
|
||||
(defun ruby-ts--imenu-helper (node)
|
||||
"Convert a treesit sparse tree NODE in an imenu list.
|
||||
Helper for `ruby-ts--imenu' which converts a treesit sparse
|
||||
NODE into a list of imenu ( name . pos ) nodes"
|
||||
(let* ((ts-node (car node))
|
||||
(subtrees (mapcan #'ruby-ts--imenu-helper (cdr node)))
|
||||
(name (when ts-node
|
||||
(ruby-ts--full-name ts-node)))
|
||||
(marker (when ts-node
|
||||
(set-marker (make-marker)
|
||||
(treesit-node-start ts-node)))))
|
||||
(cond
|
||||
((or (null ts-node) (null name)) subtrees)
|
||||
;; Don't include the anonymous "class" and "module" nodes
|
||||
((string-match-p "(\"\\(class\\|module\\)\")"
|
||||
(treesit-node-string ts-node))
|
||||
nil)
|
||||
(subtrees
|
||||
`((,name ,(cons name marker) ,@subtrees)))
|
||||
(t
|
||||
`((,name . ,marker))))))
|
||||
(defun ruby-ts--imenu-helper (tree)
|
||||
"Convert a treesit sparse tree NODE in a flat imenu list."
|
||||
(if (cdr tree)
|
||||
;; We only use the "leaf" values in the tree. It does include a
|
||||
;; leaf node for every class or module body.
|
||||
(cl-mapcan #'ruby-ts--imenu-helper (cdr tree))
|
||||
(list (cons (ruby-ts--full-name (car tree))
|
||||
(treesit-node-start (car tree))))))
|
||||
|
||||
;; For now, this is going to work like ruby-mode and return a list of
|
||||
;; class, modules, def (methods), and alias. It is likely that this
|
||||
|
|
@ -916,8 +908,14 @@ NODE into a list of imenu ( name . pos ) nodes"
|
|||
(defun ruby-ts--imenu ()
|
||||
"Return Imenu alist for the current buffer."
|
||||
(let* ((root (treesit-buffer-root-node))
|
||||
(nodes (treesit-induce-sparse-tree root "^\\(method\\|alias\\|class\\|module\\)$")))
|
||||
(ruby-ts--imenu-helper nodes)))
|
||||
(tree (treesit-induce-sparse-tree root
|
||||
(rx bol (or "singleton_method"
|
||||
"method"
|
||||
"alias"
|
||||
"class"
|
||||
"module")
|
||||
eol))))
|
||||
(ruby-ts--imenu-helper tree)))
|
||||
|
||||
(defun ruby-ts--arrow-up-start (arg)
|
||||
"Move to the start ARG levels up or out."
|
||||
|
|
|
|||
|
|
@ -232,8 +232,9 @@ If AUTO-SAVE is non-nil, compare the saved contents to the one last saved,
|
|||
savehist-coding-system))
|
||||
(run-hooks 'savehist-save-hook)
|
||||
(let ((print-length nil)
|
||||
(print-level nil)
|
||||
(print-quoted t))
|
||||
(print-level nil)
|
||||
(print-quoted t)
|
||||
(print-circle t))
|
||||
;; Save the minibuffer histories, along with the value of
|
||||
;; savehist-minibuffer-history-variables itself.
|
||||
(when savehist-save-minibuffer-history
|
||||
|
|
|
|||
|
|
@ -7151,7 +7151,7 @@ CONDITION is either:
|
|||
- the symbol t, to always match,
|
||||
- the symbol nil, which never matches,
|
||||
- a regular expression, to match a buffer name,
|
||||
- a predicate function that takes a buffer object and ARG as
|
||||
- a predicate function that takes BUFFER-OR-NAME and ARG as
|
||||
arguments, and returns non-nil if the buffer matches,
|
||||
- a cons-cell, where the car describes how to interpret the cdr.
|
||||
The car can be one of the following:
|
||||
|
|
@ -7177,8 +7177,8 @@ CONDITION is either:
|
|||
(string-match-p condition (buffer-name buffer)))
|
||||
((pred functionp)
|
||||
(if (eq 1 (cdr (func-arity condition)))
|
||||
(funcall condition buffer)
|
||||
(funcall condition buffer arg)))
|
||||
(funcall condition buffer-or-name)
|
||||
(funcall condition buffer-or-name arg)))
|
||||
(`(major-mode . ,mode)
|
||||
(eq
|
||||
(buffer-local-value 'major-mode buffer)
|
||||
|
|
|
|||
|
|
@ -2516,17 +2516,22 @@ prefix argument and pivot to `transient-update'."
|
|||
|
||||
(defun transient--invalid (msg)
|
||||
(ding)
|
||||
(message "%s: `%s' (Use `%s' to abort, `%s' for help) [%s]"
|
||||
(message "%s: `%s' (Use `%s' to abort, `%s' for help)%s"
|
||||
msg
|
||||
(propertize (key-description (this-single-command-keys))
|
||||
'face 'font-lock-warning-face)
|
||||
(propertize "C-g" 'face 'transient-key)
|
||||
(propertize "?" 'face 'transient-key)
|
||||
;; `this-command' is `transient--undefined' or similar at this
|
||||
;; point. Show the command the user actually tried to invoke.
|
||||
(propertize (symbol-name (transient--suffix-symbol
|
||||
this-original-command))
|
||||
'face 'font-lock-warning-face))
|
||||
;; `this-command' is `transient-undefined' or `transient-inapt'.
|
||||
;; Show the command (`this-original-command') the user actually
|
||||
;; tried to invoke. For an anonymous inapt command that is a
|
||||
;; lambda expression, which cannot be mapped to a symbol, so
|
||||
;; forgo displaying the command.
|
||||
(if-let ((cmd (ignore-errors
|
||||
(symbol-name (transient--suffix-symbol
|
||||
this-original-command)))))
|
||||
(format " [%s]" (propertize cmd 'face 'font-lock-warning-face))
|
||||
""))
|
||||
(unless (and transient--transient-map
|
||||
(memq transient--transient-map overriding-terminal-local-map))
|
||||
(let ((transient--prefix (or transient--prefix 'sic)))
|
||||
|
|
|
|||
|
|
@ -3056,11 +3056,17 @@ function signals an error."
|
|||
(apply #'treesit--call-process-signal
|
||||
(if (file-exists-p "scanner.cc") c++ cc)
|
||||
nil t nil
|
||||
`("-fPIC" "-shared"
|
||||
,@(directory-files
|
||||
default-directory nil
|
||||
(rx bos (+ anychar) ".o" eos))
|
||||
"-o" ,lib-name))
|
||||
(if (eq system-type 'cygwin)
|
||||
`("-shared" "-Wl,-dynamicbase"
|
||||
,@(directory-files
|
||||
default-directory nil
|
||||
(rx bos (+ anychar) ".o" eos))
|
||||
"-o" ,lib-name)
|
||||
`("-fPIC" "-shared"
|
||||
,@(directory-files
|
||||
default-directory nil
|
||||
(rx bos (+ anychar) ".o" eos))
|
||||
"-o" ,lib-name)))
|
||||
;; Copy out.
|
||||
(unless (file-exists-p out-dir)
|
||||
(make-directory out-dir t))
|
||||
|
|
|
|||
|
|
@ -7510,8 +7510,8 @@ Its value takes effect before processing the ACTION argument of
|
|||
If non-nil, this is an alist of elements (CONDITION . ACTION),
|
||||
where:
|
||||
|
||||
CONDITION is passed to `buffer-match-p', along with the buffer
|
||||
that is to be displayed and the ACTION argument of
|
||||
CONDITION is passed to `buffer-match-p', along with the name of
|
||||
the buffer that is to be displayed and the ACTION argument of
|
||||
`display-buffer', to check if ACTION should be used.
|
||||
|
||||
ACTION is a cons cell (FUNCTIONS . ALIST), where FUNCTIONS is an
|
||||
|
|
@ -7568,12 +7568,16 @@ all fail. It should never be set by programs or users. See
|
|||
(defun display-buffer-assq-regexp (buffer-or-name alist action)
|
||||
"Retrieve ALIST entry corresponding to buffer specified by BUFFER-OR-NAME.
|
||||
This returns the cdr of the alist entry ALIST if the entry's
|
||||
key (its car) and BUFFER-OR-NAME satisfy `buffer-match-p', using
|
||||
the key as CONDITION argument of `buffer-match-p'. ACTION should
|
||||
have the form of the action argument passed to `display-buffer'."
|
||||
key (its car) and the name of the buffer designated by
|
||||
BUFFER-OR-NAME satisfy `buffer-match-p', using the key as
|
||||
CONDITION argument of `buffer-match-p'. ACTION should have the
|
||||
form of the action argument passed to `display-buffer'."
|
||||
(catch 'match
|
||||
(dolist (entry alist)
|
||||
(when (buffer-match-p (car entry) buffer-or-name action)
|
||||
(when (buffer-match-p (car entry) (if (stringp buffer-or-name)
|
||||
buffer-or-name
|
||||
(buffer-name buffer-or-name))
|
||||
action)
|
||||
(throw 'match (cdr entry))))))
|
||||
|
||||
(defvar display-buffer--same-window-action
|
||||
|
|
|
|||
|
|
@ -8573,6 +8573,10 @@ - (instancetype)toolbarClicked: (id)item
|
|||
return self;
|
||||
}
|
||||
|
||||
- (BOOL) validateToolbarItem: (NSToolbarItem *) toolbarItem
|
||||
{
|
||||
return [toolbarItem isEnabled];
|
||||
}
|
||||
|
||||
- (instancetype)toggleToolbar: (id)sender
|
||||
{
|
||||
|
|
|
|||
|
|
@ -180,6 +180,15 @@ static timezone_t const utc_tz = 0;
|
|||
static struct tm *
|
||||
emacs_localtime_rz (timezone_t tz, time_t const *t, struct tm *tm)
|
||||
{
|
||||
#ifdef WINDOWSNT
|
||||
/* The Windows CRT functions are "optimized for speed", so they don't
|
||||
check for timezone and DST changes if they were last called less
|
||||
than 1 minute ago (see http://support.microsoft.com/kb/821231).
|
||||
So all Emacs features that repeatedly call time functions (e.g.,
|
||||
display-time) are in real danger of missing timezone and DST
|
||||
changes. Calling tzset before each localtime call fixes that. */
|
||||
tzset ();
|
||||
#endif
|
||||
tm = localtime_rz (tz, t, tm);
|
||||
if (!tm && errno == ENOMEM)
|
||||
memory_full (SIZE_MAX);
|
||||
|
|
|
|||
|
|
@ -1016,11 +1016,6 @@ treesit_call_after_change_functions (TSTree *old_tree, TSTree *new_tree,
|
|||
static void
|
||||
treesit_ensure_parsed (Lisp_Object parser)
|
||||
{
|
||||
/* Make sure this comes before everything else, see comment
|
||||
(ref:notifier-inside-ensure-parsed) for more detail. */
|
||||
if (!XTS_PARSER (parser)->need_reparse)
|
||||
return;
|
||||
|
||||
struct buffer *buffer = XBUFFER (XTS_PARSER (parser)->buffer);
|
||||
|
||||
/* Before we parse, catch up with the narrowing situation. */
|
||||
|
|
@ -1029,6 +1024,11 @@ treesit_ensure_parsed (Lisp_Object parser)
|
|||
because it might set the flag to true. */
|
||||
treesit_sync_visible_region (parser);
|
||||
|
||||
/* Make sure this comes before everything else, see comment
|
||||
(ref:notifier-inside-ensure-parsed) for more detail. */
|
||||
if (!XTS_PARSER (parser)->need_reparse)
|
||||
return;
|
||||
|
||||
TSParser *treesit_parser = XTS_PARSER (parser)->parser;
|
||||
TSTree *tree = XTS_PARSER (parser)->tree;
|
||||
TSInput input = XTS_PARSER (parser)->input;
|
||||
|
|
|
|||
|
|
@ -124,7 +124,14 @@ test_module_dir := src/emacs-module-resources
|
|||
|
||||
all: check
|
||||
|
||||
ifeq ($(HAVE_NATIVE_COMP),yes)
|
||||
SYSTEM_TYPE = @SYSTEM_TYPE@
|
||||
TEST_NATIVE_COMP = $(HAVE_NATIVE_COMP)
|
||||
# Avoid fork failures on Cygwin. See bug#62450 and etc/PROBLEMS
|
||||
# ("Fork failures in a build with native compilation").
|
||||
ifeq ($(SYSTEM_TYPE),cygwin)
|
||||
TEST_NATIVE_COMP = no
|
||||
endif
|
||||
ifeq ($(TEST_NATIVE_COMP),yes)
|
||||
SELECTOR_DEFAULT = (not (or (tag :expensive-test) (tag :unstable)))
|
||||
SELECTOR_EXPENSIVE = (not (tag :unstable))
|
||||
SELECTOR_ALL = t
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ FROM emacs-base as emacs-eglot
|
|||
|
||||
RUN apt-get update && \
|
||||
apt-get install -y --no-install-recommends -o=Dpkg::Use-Pty=0 \
|
||||
snapd wget lsb_release add-apt-repository gpg \
|
||||
snapd wget lsb-release software-properties-common gpg \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
|
||||
# A recent clangd. It must be at least clangd 14, which is in Debian
|
||||
|
|
@ -73,8 +73,8 @@ RUN bash -c "$(wget --no-check-certificate -O - https://apt.llvm.org/llvm.sh)"
|
|||
|
||||
# A recent pylsp. Since Debian bookworm there is the package
|
||||
# python3-pylsp.
|
||||
RUN snap install core
|
||||
RUN snap install pylsp
|
||||
# RUN snap install core
|
||||
# RUN snap install pylsp
|
||||
|
||||
COPY . /checkout
|
||||
WORKDIR /checkout
|
||||
|
|
@ -100,7 +100,7 @@ FROM emacs-base as emacs-native-comp
|
|||
# The libgccjit version must correspond to the gcc version.
|
||||
RUN apt-get update && \
|
||||
apt-get install -y --no-install-recommends -o=Dpkg::Use-Pty=0 \
|
||||
libgccjit-10-dev \
|
||||
libgccjit-10-dev zlib1g-dev \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
|
||||
FROM emacs-native-comp as emacs-native-comp-speed0
|
||||
|
|
|
|||
|
|
@ -256,24 +256,22 @@ test-eglot:
|
|||
# This is needed in order to get a JUnit test report.
|
||||
make_params: '-k -C test check-expensive LOGFILES="lisp/progmodes/eglot-tests.log"'
|
||||
|
||||
# The next two jobs are commented out due to bug#62210.
|
||||
build-image-gnustep:
|
||||
stage: platform-images
|
||||
extends: [.job-template, .build-template, .gnustep-template]
|
||||
variables:
|
||||
target: emacs-gnustep
|
||||
|
||||
# build-image-gnustep:
|
||||
# stage: platform-images
|
||||
# extends: [.job-template, .build-template, .gnustep-template]
|
||||
# variables:
|
||||
# target: emacs-gnustep
|
||||
|
||||
# test-gnustep:
|
||||
# # This tests the GNUstep build process.
|
||||
# stage: platforms
|
||||
# extends: [.job-template, .gnustep-template]
|
||||
# needs:
|
||||
# - job: build-image-gnustep
|
||||
# optional: true
|
||||
# variables:
|
||||
# target: emacs-gnustep
|
||||
# make_params: install
|
||||
test-gnustep:
|
||||
# This tests the GNUstep build process.
|
||||
stage: platforms
|
||||
extends: [.job-template, .gnustep-template]
|
||||
needs:
|
||||
- job: build-image-gnustep
|
||||
optional: true
|
||||
variables:
|
||||
target: emacs-gnustep
|
||||
make_params: install
|
||||
|
||||
# The next two jobs are commented out due to high workload on
|
||||
# emba.gnu.org.
|
||||
|
|
|
|||
|
|
@ -23,6 +23,10 @@
|
|||
(require 'ert)
|
||||
|
||||
(ert-deftest benchmark-tests ()
|
||||
;; Avoid fork failures on Cygwin. See bug#62450 and etc/PROBLEMS
|
||||
;; ("Fork failures in a build with native compilation").
|
||||
(skip-unless (not (and (eq system-type 'cygwin)
|
||||
(featurep 'native-compile))))
|
||||
(let (str t-long t-short m)
|
||||
(should (consp (benchmark-run nil (setq m (1+ 0)))))
|
||||
(should (consp (benchmark-run 1 (setq m (1+ 0)))))
|
||||
|
|
|
|||
|
|
@ -5940,6 +5940,26 @@ def func():
|
|||
(equal (list (python-tests-look-at "if (" -1 t))
|
||||
(python-info-dedenter-opening-block-positions)))))
|
||||
|
||||
(ert-deftest python-info-dedenter-opening-block-positions-7 ()
|
||||
"Test case blocks."
|
||||
(python-tests-with-temp-buffer
|
||||
"
|
||||
match a:
|
||||
case 1:
|
||||
match b:
|
||||
case 2:
|
||||
something()
|
||||
case 3:
|
||||
"
|
||||
(python-tests-look-at "case 1:")
|
||||
(should-not (python-info-dedenter-opening-block-positions))
|
||||
(python-tests-look-at "case 2:")
|
||||
(should-not (python-info-dedenter-opening-block-positions))
|
||||
(python-tests-look-at "case 3:")
|
||||
(equal (list (python-tests-look-at "case 2:" -1)
|
||||
(python-tests-look-at "case 1:" -1 t))
|
||||
(python-info-dedenter-opening-block-positions))))
|
||||
|
||||
(ert-deftest python-info-dedenter-opening-block-message-1 ()
|
||||
"Test dedenters inside strings are ignored."
|
||||
(python-tests-with-temp-buffer
|
||||
|
|
@ -6125,6 +6145,24 @@ elif b:
|
|||
(point))
|
||||
(python-info-dedenter-statement-p)))))
|
||||
|
||||
(ert-deftest python-info-dedenter-statement-p-6 ()
|
||||
"Test case keyword."
|
||||
(python-tests-with-temp-buffer
|
||||
"
|
||||
match a: # Comment
|
||||
case 1:
|
||||
match b:
|
||||
case 2:
|
||||
something()
|
||||
case 3:
|
||||
"
|
||||
(python-tests-look-at "case 1:")
|
||||
(should-not (python-info-dedenter-statement-p))
|
||||
(python-tests-look-at "case 2:")
|
||||
(should-not (python-info-dedenter-statement-p))
|
||||
(python-tests-look-at "case 3:")
|
||||
(should (= (point) (python-info-dedenter-statement-p)))))
|
||||
|
||||
(ert-deftest python-info-line-ends-backslash-p-1 ()
|
||||
(python-tests-with-temp-buffer
|
||||
"
|
||||
|
|
|
|||
|
|
@ -281,6 +281,31 @@ The whitespace before and including \"|\" on each line is removed."
|
|||
(file-truename
|
||||
(expand-file-name (format "ruby-mode-resources/%s" ,file))))))
|
||||
|
||||
(ert-deftest ruby-ts-imenu-index ()
|
||||
(ruby-ts-with-temp-buffer
|
||||
(ruby-ts-test-string
|
||||
"module Foo
|
||||
| class Blub
|
||||
| def hi
|
||||
| 'Hi!'
|
||||
| end
|
||||
|
|
||||
| def bye
|
||||
| 'Bye!'
|
||||
| end
|
||||
|
|
||||
| private def self.hiding
|
||||
| 'You can't see me'
|
||||
| end
|
||||
| end
|
||||
|end")
|
||||
(should (equal (mapcar #'car (ruby-ts--imenu))
|
||||
'("Foo"
|
||||
"Foo::Blub"
|
||||
"Foo::Blub#hi"
|
||||
"Foo::Blub#bye"
|
||||
"Foo::Blub.hiding")))))
|
||||
|
||||
(defmacro ruby-ts-deftest-indent (file)
|
||||
`(ert-deftest ,(intern (format "ruby-ts-indent-test/%s" file)) ()
|
||||
;; :tags '(:expensive-test)
|
||||
|
|
|
|||
|
|
@ -254,7 +254,7 @@
|
|||
(should (string-collate-equalp "xyzzy" "XYZZY" nil t))
|
||||
|
||||
;; Locale must be valid.
|
||||
(should-error (string-collate-equalp "xyzzy" "xyzzy" "en_DE.UTF-8")))
|
||||
(should-error (string-collate-equalp "xyzzy" "xyzzy" "en_XY.UTF-8")))
|
||||
|
||||
;; There must be a check for valid codepoints. (Check not implemented yet)
|
||||
; (should-error
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue