perspective of the dawn of time, so "next" means "newer" and "previous"
means "older". Libedit, by contrast, uses reverse chronology and
regards history from the perspective of the present, such that "next"
means "longer ago" and "previous" means "not so long ago".
The following patch fixes previous_history() and next_history()
as proposed by Bastian Maerkisch.
But there is a related problem demonstrated by Bastian's regression
tests that his patch did not fix: next_history() can advance not
only to the newest entry, but beyond it, which core libedit cannot
do. So that feature must be implemented locally in readline.c.
With that, the last of Bastians tests is fixed, test_movement_direction().
This patch also improves libedit documentation to more clearly state
what "previous" and "next" mean. GNU readline documentation is
just as unclear, but we can't easily fix that since libedit doesn't
include its own readline.3 manual.
(Ingo Schwarze)
implementation: libedit goes to the entry with the given number
stored in the HistEvent structure, while GNU subtracts history_base,
then advances that many entries from the oldest one. If entries were
removed in between, GNU advances further than libedit.
The call sequence H_CURR, H_DELDATA, H_CURR, H_NEXT_EVDATA looks
weird, as if part of that must somehow be redundant. But actually,
the user interface is so counter-intuitive that every single step
is really required.
- The first H_CURR is needed to be able to go back after an error.
- The H_DELDATA is needed to move the cursor. Even though it takes
a pointer to ev, that structure is not filled in when the call
succeeds. H_DELDATA only moves the cursor, it doesn't tell us
the new event number.
- Consequently, the second H_CURR is required to get ev.num filled
in. But it doesn't return the data because ev has no field for
that.
- So even though the cursor is already positioned correctly,
H_NEXT_EVDATA is needed as the final step merely to get the data.
(Ingo Schwarze)
- Put the data type el_rfunc_t into the public header <histedit.h>.
- Make el_read in struct editline an opaque pointer rather
than an embedded struct.
- Do not include "read.h" everywhere, but only in the two files
needing access to el_read, read.c and el.c.
- To functions that don't need more, pass the struct el_read_t *
rather than the full EditLine *.
- Of course, that means that read_init() can now fail from
memory exhaustion, but it's easy to clean up after that.
* Replace fcns.c by a shorter and simpler func.h
and include it only in the one file needing it, map.c.
* Combine help.h and help.c into a simplified help.h
and include it only in the one file needing it, map.c.
* Check the very simple, static files editline.c, historyn.c, and
tokenizern.c into CVS rather than needlessly generating them.
* So we no longer autogenerate any C files. :-)
* Shorten and simplify makelist by deleting the options -n, -e, -bc,
and -m; the latter was unused and useless in the first place.
* Move the declaration of el_func_t from fcns.h to the header
actually needing it, map.h. Since that header is already
included by el.h for unrelated reasons, that makes el_func_t
just as globally available as before.
* No longer include the simplified fcns.h into el.h,
include it directly into the *.c files needing it.
* Delete the stubs of the XK_EXE mechanism that was never implemented.
From a security, stability, and simplicity perspective, i would
consider implementing it a truly terrible idea, so let's better
get rid of it.
* Do not use the local variable "num" in el_wgets() alternately for
two completely different purposes. Only use it for the number
of characters read, as stated in the comment (or -1 as long as
that number is still unknown), not for the (more or less boolean)
return value of read_getcmd(). Actually, there is no need at
all to save the latter return value after testing it once.
* The function read_getcmd() has very unusual return values:
It returns -1 for success and 0 for EOF/error. Switch that around
to 0 for success and -1 for EOF/error to be less confusing, and
get rid of the OKCMD preprocessor macro.
* Get rid of one #ifdef section in el_wgets() by using
el->el_chared.c_macro directly at the only place
where it is used.
* Delete the unused MIN() macro.
- The file tokenizer.c no longer uses chartype.h,
so don't include the header.
- The dummy definitions of ct_{de,en}code_string() for the
NARROWCHAR case are only used in history.c, so move them there.
- Now the whole content of chartype.h is for the wide character
case only. So remove the NARROWCHAR ifdef and include the
header only in the wide character case.
- In chartype.h, move ct_encode_char() below the comment explaining it.
- No more need for underscores before ct_{de,en}code_string().
- Make the conversion buffer resize functions private.
They are only called from the decoding and encoding functions
inside chartype.c, and no need can possibly arise to call them
from anywhere else.
build crtbeginS.o with -O1 as GCC tries to be very smart with the
__DTOR_LIST__ as it believes it knows the size of the array at
compile time (which is not true until link time). on SPARC and
MIPS, the result was emitting a call to 0.
technically, i believe that GCC isn't "wrong" to make this choice,
as the array is declared with a well-known initialiser size in the
crtbegin.c compilation unit, and we have noticed that the libgcc
version of this code has some hacks added, most likely to avoid
being bitten by this optimisation.
this makes sshd work for me on earm and sparc with GCC 5.
- there is a ktr_version field
- the ordering of ktr_type and ktr_version is byte-order dependent
- ktr_time is now a timespec, not a timeval
- there's now a ktr_lid field
- there is no such thing as a ktr_buf field and it's certainly not
a caddr_t.
XXX: I would appreciate it if someone who knows how this stuff works
XXX: could review this file in case it's still lying in some more
XXX: subtle way.
For a floating-point computation, in the language of IEEE 754,
`underflow' means the output was rounded and is too small to be
represented *normally*.
There are many nonzero floating-point numbers to which the exact
output may have been rounded -- namely subnormals. The condition
under which strtod returns ERANGE for small magnitudes is when the
magnitude of the exact result is so small it is rounded to zero, not
even to a subnormal.
While here, use parallel language about large magnitudes instead of
the (albeit correct) word `overflow', to avoid temptation to treat
`underflow' as the opposite notion with zero instead of infinity.
Switch to the "Linux" runtime, which is kind of misnamed for the mostly
ELF based implementation. Make sure to hook up the runtime source
only for the profile library as it uses constructors for the output
creation.
functional error) in c_gets(), file chared.c.
Run any program using libedit in the default way. At the el_[w]gets()
prompt, invoke ed-command (for example, in emacs mode, press the
escape key, then type the letter 'x'). You should see a ": " prompt.
Type the letter 'x' again. Now press the backspace key a few times,
looking at the screen after each key press:
- The 1st BS deletes the 'x'.
- The 2nd BS deletes the blank after the prompt.
- The 3rd BS deletes the colon of the prompt.
- The 4th BS moves the cursor up one line.
- The 5th BS gives me "Segmentation fault (core dumped)".
Depending on your platform, it might take a few more or a few less
backspaces for the buffer underrun to trigger the segfault, but
you should be able to hit it sooner or later no matter what.
Run the same program again, connect again and invoke ed-command again.
Now type: 'b', backspace, 'i', backspace, 'n', backspace, 'd', enter.
The "bind" command gets executed, even though you deleted what you
typed before hitting enter.
From Ingo Schwatze.
Let "el.h" include everything needed for struct editline,
and don't include that stuff multiple times. That also improves
consistency, also avoids circular inclusions, and also makes it
easier to follow what is going on, even though not quite as nice.
But it seems like the best we can do...
christos