does not work (was: poor man R2L support)
10 years, 5 months
Uwe Brauer
>> "Jeff" == Jeff Sparkes <jsparkes(a)gmail.com> writes:
> The xemacs-gtk port uses pango to display. It will display Hebrew in R2L.
> Moving the cursor through the string makes the display a mess
> unfortunately. It's okay for reading, but difficult to edit. You may
> want to give it a try.
I just compiled with the following options:
./configure '--with-mule' '--with-xim' '--with-xfs'
'--with-optimization' '--without-error-checking' '--with-toolbars'
'--with-xpm' '--with-xface' '--with-gtk'
And hebrew is not display R2L
I will try without xfs and xim.
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: poor man R2L support
10 years, 5 months
Uwe Brauer
>> "Jeff" == Jeff Sparkes <jsparkes(a)gmail.com> writes:
> The xemacs-gtk port uses pango to display. It will display Hebrew in R2L.
> Moving the cursor through the string makes the display a mess
> unfortunately. It's okay for reading, but difficult to edit. You may
> want to give it a try.
Very interesting. But what happens when I start to type hebrew, how is
it displayed?
I never compiled xemacs with gtk, so I just add to configure
the --with-gtk and that's it?
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: poor man R2L support
10 years, 5 months
Stephen J. Turnbull
Uwe Brauer writes:
> Yes and no. Because if you do this with your function you get visual
> hebrew.
The naming scheme of "visual" vs "logical" R2L still confuses me 15.5
years after M17N-1998.
> Kile has a similar input to your function but results in (when I
> open the file say with less
>
> _shalom
Is that what you see in Kile? If not (if you see the text in proper
R2L form), Kile probably just uses pango or similar to display (this
is what Aidan was talking about with getting R2L almost for free with
pango, but I don't think it works that way in Emacsen).
> Which is displayed: (when I open with GNU emacs24) as
>
> _molahs
>
> The issue is the display engine has to be touched, but the input part is
> simpler. But maybe the hard part is the display engine not the input.
Yeah, unfortunately since you want the file in logical order, you want
the buffer that way too. So input is trivial but display is really
hard if you want proper bidi. I think the proper thing to do is to
port Eliz's implementation of UAX #9 from GNU Emacs.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: large el files and performance: replace words from lists
10 years, 5 months
Aidan Kehoe
Ar an t-aonú lá déag de mí na Samhain, scríobh Uwe Brauer:
> > The interesting question about this approach is how big this regexp will be
> > and how slow searching with it will be. It will be cached, on the upside.
> > It’s something you’d need to experiment with; maybe creating several regexps
> > with regexp-opt is the way to go.
>
> Oops I have not finished the list, but it might be larger than I
> thought, 4 Megas maybe. Regexp-opt can deal with that?
There’s nothing to prevent it. It’ll be slow, but it only has to run the
first time.
> > -- Save the map from the words without niqqud to the words with niqqud in a
> > Berkeley or DBM database; see #'open-database, #'put-database, and the code
> > that uses them in descr-text.el in XEmacs 21.5. Be careful about the CODESYS
> > argument to #'open-database.
>
> And that should be faster as a hashtable?
A little slower--not much, though, the main overhead is from the Emacs Lisp
funcall, and the relevant databases are actively developed, I’m sure their
performance is acceptable.
> Since modern hebrew is written without niqqud, there are difference in
> spelling in order to avoid such uncertainties
>
> So for example if in haaretz, say David Kastrup is mentioned, his name
> would be written (using logical hebrew here)
>
> דויד.
>
>
> Since I want such function for modern hebrew[1], I am not much worried
> about this problem.
Good!
--
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
poor man R2L support
10 years, 5 months
Uwe Brauer
Hello
I am using the R2L engine of GNU emacs24, which is quite nice, it has even
visual cursor support.
I know that nobody is working on R2L support for Xemacs.
Now GNU emacs displays logical hebrew correctly and also as a nice
input interface:
- the cursor jumps to the right, then when typing moves to the
left.
I have seen simpler input methods for example in kile. When hebrew is
turned on:
The cursor is blocked on the left side and the letters just appear.
This sounds like visual hebrew, but it is not, it is logical hebrew with
a simpler input interface.
Would that be (considerable) easier to implement in Xemacs?
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
large el files and performance: replace words from lists
10 years, 5 months
Uwe Brauer
Hello
I would like to have a lisp pkg which would replace certain words in a text.[1]
For this I need two things,
- a function which does the replacement and
- a list containing words with and without niqqud.
Concerning the first, I have already a function, which is loosely
based on iso-accentuate, or a function
(TeX-to-char) which was provided by Aidan
some years ago, which replaces latex symbols by its UTF8
equivalents. I am not sure which code is more efficient, I'll
will to post the central part of the code later.
However what bothers me more is the second part. I obtained the
hebrew bible in UTF8 format and could then generate the desired
list. However it seems to me that this list would be huge, at
least 2000 to 3000 words if not more.
What is a reasonable size limit for such a list???
Is 2000 words to big? or must I divide the list in several parts
(and files) and write corresponding functions?
Footnotes:
[1] to be precise, to substitute hebrew words by hebrew words with
vowels, so called niqqud
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: supporting GTK 3.0 only?
10 years, 5 months
Stephen J. Turnbull
Jeff Sparkes writes:
>> (There's no deadline at this point, we just need to decide before
>> Jeff and anybody who decides to pitch in starts dropping 50 kloc
>> patches on us. :-)
> The code is in https://bitbucket.org/jsparkes/xemacs-gtk
> I'm up to date with the main xemacs repository. If you want it
> pulled or pushed, into main, there should be no impact.
> Right now it's a pretty usable GTK2 version. I have a few more
> changes to make before I switch it to GTK3.
You haven't started working on conversion to GTK3 yet?
I'm not sure when I'm going to have time to look at this. Although I
agree in principle, this is a pretty big step, and I'd definitely like
to have a current reviewer look at it before approving a merge into
mainline. Could somebody step up and do that?
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
supporting GTK 3.0 only?
10 years, 5 months
Jeff Sparkes
I've been dreading the autoconf work to select between two different
versions of GTK. I wonder how people would feel about dropping support for
GTK 2 and supporting GTK 3 only.
It's not like it's completely working anyway. I will ifdef the changes
making it possible to port back to GTK 2 if somebody really wanted to.
--
Jeff Sparkes
jsparkes(a)gmail.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta