[E-devel] eesh with libeditline and libedit
Hi,
last month using libeditline or libedit with eesh was briefly
discussed. Since having no history and no decent line editing in eesh
has annoyed me for ages, I gave it a try.
My qualification for this job was (and still is) outstanding: I didn't
know anything about X11 programming till last sunday, I haven't
written a line of C in the last two years (and not really much before
either), and I never used libreadline, libeditline or libedit. So
please have a look at my code if i'm doing something stupid.
Furthermore I don't know anything about autoconf or automake. So I
just hacked the auto-generated Makefile to link to libeditline and
libedit (no patch attached).
Because I couldn't connect to the CVS server of sourceforge last
friday, I used enlightenment-0.16.7-0.65.tar.gz as a template. Since
main.c of eesh isn't that large I'll mail the complete file and not a
patch (see attachment). I introduced to #defines, USE_EDITLINE and
USE_EDIT, to control which library is used.
About libedit: you can use $HOME/.editrc to configure it, e.g. bind
-v invokes vi keyset, see editrc (5el).
My setup:
Debian testing/unstable
official Debian enlightenment 0.16.6-1 (I'm just using eesh from
0.16.7 to talk to it, maybe I shouldn't this?)
official Debian libeditline0 1.12-5
official Debian libedit2 2.6.cvs.200201
Why did I implement it this way:
1) The prompt: to see if the user can type now. I could get rid of
it when everything works. IMHO it looks better with a prompt.
2) I couldn't just replace the lines
k = 0;
while ((ret = read(0, (buf[j]), 1) 0))
{
...
with the appropriate code for editline/edit or leaving the
whole FD_SET-select-stuff out because
a) the prompt resp. input will be messed up:
no prompt shows but you can write without visible
line-editing, type ENTER and the prompt shows with the
text the user entered before including the line-editing,
e.g. history.
b) no output shows.
c) if the eesh command doesn't produce any output
d) misc. other symptoms (I went through several stages to get
to the present state, I don't want to recount everything.)
So I had use two fd_set variables and two calls to select: one,
which looks for readfds and writefds, and another, which only
looks for readfds. BTW, I could use only one variable and clear
it by FD_ZERO, any preferences on your side?
Maybe this is all self-evident to you but I included it because
I hope it is easier for you to spot any errors.
Bugs:
- CTRL d doesn't quit the interactive mode, use CTRL c
- libeditline: type CTRL d = segfault
- libedit: type CTRL d, line-editing etc. don't work anymore;
just continue typing, focus other windows, re-focus eesh,
do whatever, eventually it will work again
- just type ENTER, mostly the terminal hangs; focus another
window, focus terminal with eesh again, get a new prompt
- the indent isn't consistent with the rest of the file, I'll
correct this for the final patch
- I'm sure there are others, we just have to find them :-)
First of all I'd be grateful if someone could look over my code and
tell me if there any obvious errors (see my programming skills above).
Ralf
PS: I hope my further mails will be shorter. :-)
/*
Copyright (C) 2000-2004 Carsten Haitzler, Geoff Harrison and various contributors
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the Software), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies of the Software, its documentation and marketing publicity
materials, and acknowledgment shall be given in the documentation, materials
and software packages that this Software was used.
THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#define USE_EDITLINE 0
#define USE_EDIT 1
#include E.h
#include sys/time.h
#include sys/types.h
#include unistd.h
#if USE_EDITLINE
#include editline.h
#elif USE_EDIT
#include histedit.h
#endif
extern char waitonly;
static int stdin_state;
void
[E-devel] X.org
E17 have support to X.org(all features) ? and what's the diferent between Evas+Canvas and Cario+Glitz? Regards, João Martins --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] X.org
On Tue, 08 Jun 2004 14:06:40 MDT, [EMAIL PROTECTED] said: E17 have support to X.org(all features) ? and what's the diferent between Evas+Canvas and Cario+Glitz? Umm.. which all features do you mean, exactly? There's quite a few features in there that E17 doesn't care about one way or another. For instance, there's support for setting the gamma value for the monitor. which E shouldn't care about, that's what xgamma and xvidtune are for. On the other hand, E may care about *reading* the gamma values (or more likely, E will call libraries like libpng that will care about reading the gamma values, in order to adjust an image, at which point the question becomes does libpng support it?) pgppEvjycn84u.pgp Description: PGP signature
[E-devel] [marc_soft@merlins.org: Bug#253247: E gets confused about window layering]
Please reply to [EMAIL PROTECTED] to reach the submitter and bug tracking system. Thanks. ---BeginMessage--- Package: enlightenment Version: 1:0.16.6-1 Severity: normal I recently upgraded from 0.16.5 to 0.16.6, and now, my Eterms (which all have a name like this: Eterm -n window9) get their layering confused, and some sometimes stay on top when I make one go on top with alt + left click, and then go back to another window (i.e I bring the other window on top too, but it deosn't stay: it gets overlapped by the other one as soon as I release it). The fix is to select stacking on the other window and reset it to normal again, but I shouldn't have to do that, esepcially multiple times (all my stackings are set to normal) I haven't quite found a way to reliably reproduce this yet, but it's never happened to me in the 4 yeaqrs I've been using E, and I get it several times a day since I upgraded to 0.16.6 (without upgrading anything else) Any suggestions? Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems security what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger [EMAIL PROTECTED] for PGP key ---End Message---
Re: [E-devel] X.org
On Tue, 08 Jun 2004 16:19:17 -0400 [EMAIL PROTECTED] babbled: (B (B On Tue, 08 Jun 2004 14:06:40 MDT, [EMAIL PROTECTED] said: (B E17 have support to X.org(all features) ? and what's the diferent between (B Evas+Canvas and Cario+Glitz? (B (B Umm.. which "all features" do you mean, exactly? There's quite a few features (B in there that E17 doesn't care about one way or another. (B (B For instance, there's support for setting the gamma value for the monitor. (B which E shouldn't care about, that's what xgamma and xvidtune are for. On the (B other hand, E may care about *reading* the gamma values (or more likely, E (B will call libraries like libpng that will care about reading the gamma values, (B in order to adjust an image, at which point the question becomes "does libpng (B support it?") (B (Bwell actually why would X read the gamma? the video card can adjust the DAC to (Bcompensate for the entire screen without a single cpu cycle being needed :) i (Bsee gamma correction as an "SEP" (somone elses problem). sure we could provide a (Bsmall "set your gamma correction" tool that simply asks x to adjust its gamma (Bcorrection... but thats as far as i see our involvement being needed. also with (Bthe increasing spread of lcd screens - gamma is looking much nicer :) (B (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://2004/guadec.org (B___ (Benlightenment-devel mailing list (B[EMAIL PROTECTED] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [marc_soft@merlins.org: Bug#253247: E gets confused about window layering]
On Tue, 8 Jun 2004 16:42:52 -0400 [EMAIL PROTECTED] babbled: (B (Bthis is a known issue - try cvs. e16 as of 0.16.6 has been rather confused about (Bstacking :( (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://2004/guadec.org (B___ (Benlightenment-devel mailing list (B[EMAIL PROTECTED] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] X.org
On Tue, 08 Jun 2004 14:06:40 -0600 [EMAIL PROTECTED] babbled: (B (B (B E17 have support to X.org(all features) ? and what's the diferent between (B Evas+Canvas and Cario+Glitz? (B (Bcairo+_glitz require X. evas does not. not to mention evas's software rendering (Boutstrips xrenders performance substantially (since most operations will involve (Ba scale of some sort and xrender's scaling is about 30-50 times slower than (Bevas/imlib2 - you go figure). (B (Balso evas work on ANY xserver. it can also use opengl ala glitz. evas will work (Bon xfree86, x.org, sun's xservers, xfree86 3.3, and a host of servers (Birrespectively. also it is the api we use. we're not going to change to cairo. (Bfor performance any many other reasons. now i DON'T rule out anyone contributing (Ba cairo rendering engine for evas (though i'd really say - just use xrender (Bdirectly), but as i said above. i have not done this as my performance tests (Bshowed xrender to not be a viable target to write an engine for at this stage. (B (Bfor those that have forgotten/don't know the performance benchmarker is here: (B (Bhttp://www.rasterman.com/files/render_bench.tar.gz (B (Bthe day xrender gets CLOSE to imlib2 in all those speed tests, let me know. i (Bwill write an xrender engine. until then i'm not going to even try. (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://2004/guadec.org (B___ (Benlightenment-devel mailing list (B[EMAIL PROTECTED] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2 text rendering bug?
On Wed, 09 Jun 2004 02:19:59 +0200 Kim Woelders [EMAIL PROTECTED] wrote: I think imlib_render_str() doesn't calculate the width of the text being rendered correctly. A typcial example can be seen if using E16.7 with a theme using TT fonts, e.g winter or 23oz, and making a window with title #e. The 'e' will be clipped a bit on the right side. I'm not sure this is the correct solution, but the patch below it seems to fix the problem (can only be seen using an entirely up to date E16 CVS). I just checked out imlib2 from cvs and applied your patch. After building this new imlib2 and a new cvs e-0.16.7 build I still see the font clipping in the winter theme. Strangely, in the winter theme I only see vertical clipping, i.e. the last letter in certain, but not all, menu items. In other themes such as Cyrus, each and every menu item is horizontally clipped, i.e. the bottom of every letter in every menu item is clipped. It is as if the bottom 10% is sliced off each menu item. Brad --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
