Hi, as I said I started working to i18n support for XPrompt. These are the first set patches. I'm not submitting them since I want to clean up the code. Moreover I need some feedback, but please don't use this code on a your working instance of XMonad. I did not extensively tested it yet. Attached you'll find 2 patches: a set of patches for X11-Extras (Mats code plus a couple of functions needed by XPrompt); and a set of patches for XMonadContrib. A new module was added to XMonadContrib, to store some FFI stuff: XPromptLib.hsc. As the name suggests it must be processed by hsc2hs, so, in order to compile XMonad with XPrompt now you need to edit xmonad.cabal and add XMonadContrib.XPromptLib to the "other-modules" field, that should now read: other-modules: Config Operations StackSet XMonad XMonadContrib.XPromptLib The ShellPrompt does not depend on readline anymore, so the previous one is the only modification to be done to xmonad.cabal (is it possible to do that with the new docstring stuff? - can you point me to some documentation about it?). So far only ShellPrompt is using the i18n stuff. It is also an example of usage. Please report to me any malfunctioning and any positive tests. I need both before submitting code to the core team. Thanks for your kind attention. Andrea
Andrea Rossato
Hi,
as I said I started working to i18n support for XPrompt.
These are the first set patches. I'm not submitting them since I want to clean up the code. Moreover I need some feedback, but please don't use this code on a your working instance of XMonad. I did not extensively tested it yet.
Attached you'll find 2 patches: a set of patches for X11-Extras (Mats code plus a couple of functions needed by XPrompt); and a set of patches for XMonadContrib.
A new module was added to XMonadContrib, to store some FFI stuff: XPromptLib.hsc. As the name suggests it must be processed by hsc2hs, so, in order to compile XMonad with XPrompt now you need to edit xmonad.cabal and add XMonadContrib.XPromptLib to the "other-modules" field, that should now read: other-modules: Config Operations StackSet XMonad XMonadContrib.XPromptLib
The ShellPrompt does not depend on readline anymore, so the previous one is the only modification to be done to xmonad.cabal (is it possible to do that with the new docstring stuff? - can you point me to some documentation about it?).
So far only ShellPrompt is using the i18n stuff. It is also an example of usage.
Please report to me any malfunctioning and any positive tests. I need both before submitting code to the core team.
Thanks for your kind attention. Andrea
Thanks for the work. Non-English words can be displayed correctly, now. However, there are a few issues. Apart from an obvious warning: : XMonadContrib/XPromptLib.hsc:53:16: : Warning: Defined but not used: data constructor `IConv' which presumably doesn't make anything worse, I also observed that a) The cursor is not at the correct place, when there are non-English characters, such as CJK double-width characters or Cyrillic, exist. b) I'm no longer be able to choose a different font. Finally, one not related to the new patch is that some special characters, like spaces or quotes, in the path name are not properly escaped, which in turn makes the path name completion useless, when such characters are in the path. It completes, but apparently the completion doesn't work properly. Best regards, Xiao-Yong -- c/* __o/* <\ * (__ */\ <
On Fri, Sep 14, 2007 at 12:15:03AM -0400, Xiao-Yong Jin wrote:
a) The cursor is not at the correct place, when there are non-English characters, such as CJK double-width characters or Cyrillic, exist.
oops, I left a line commented out... in printPrompt (fsl,psl) = (textWidth fontst f, textWidth fontst p) should be (fsl,psl) = (wcTextEscapement (fset st) f, wcTextEscapement (fset st) p) (the commented out line has mbTextEscapament which is wrong). See the amended patch attached to this message.
b) I'm no longer be able to choose a different font.
Yes, the possibility of setting fonts was missing (I forgot about it): added in this amended patch.
Finally, one not related to the new patch is that some special characters, like spaces or quotes, in the path name are not properly escaped, which in turn makes the path name completion useless, when such characters are in the path. It completes, but apparently the completion doesn't work properly.
Yes indeed. Since I do not use spaces or other special characters I didn't notice it. I'll take care of that too. We should escape spaces and quotes: what else? Thank you. Andrea
On Fri, Sep 14, 2007 at 12:15:03AM -0400, Xiao-Yong Jin wrote:
Finally, one not related to the new patch is that some special characters, like spaces or quotes, in the path name are not properly escaped, which in turn makes the path name completion useless, when such characters are in the path. It completes, but apparently the completion doesn't work properly.
I'm a bit puzzled about escaping spaces, actually. Now the string in the prompt is broken down to words in order to use the last one for finding new completions: this is what makes it possible to complete a command and then complete a file path. How can I tell which space must be escaped and which is not to be escaped? I think we should just replicate the behavior of a command line: you must manually escape characters, and I must take that into account when splitting the string. Am I right? What do you think? Andrea
On Fri, Sep 14, 2007 at 02:23:52PM +0200, Andrea Rossato wrote:
On Fri, Sep 14, 2007 at 12:15:03AM -0400, Xiao-Yong Jin wrote:
Finally, one not related to the new patch is that some special characters, like spaces or quotes, in the path name are not properly escaped, which in turn makes the path name completion useless, when such characters are in the path. It completes, but apparently the completion doesn't work properly.
I'm a bit puzzled about escaping spaces, actually. Now the string in the prompt is broken down to words in order to use the last one for finding new completions: this is what makes it possible to complete a command and then complete a file path. How can I tell which space must be escaped and which is not to be escaped?
I think we should just replicate the behavior of a command line: you must manually escape characters, and I must take that into account when splitting the string.
Am I right? What do you think?
Agreed (about replicating behavior of command line), but this means you *don't* need to manually escape spaces. Try: cd /tmp date > hello\ world cat hel[HIT TAB THEN ENTER HERE] As you'll see, bash expands the 'hel as 'hello\ world', and you correctly cat the file. Note: I haven't looked carefully at the ShellPrompt module, but I wonder if it could call bash to do the completions, like DirectoryPrompt does (which does properly handle directories with spaces in them). Unfortunately, it seems to be hard to get the full power of the bash programmable completions framework out of bash, which seems a poor design to me. :( -- David Roundy Department of Physics Oregon State University
On Fri, Sep 14, 2007 at 06:57:25AM -0700, David Roundy wrote:
On Fri, Sep 14, 2007 at 02:23:52PM +0200, Andrea Rossato wrote:
I think we should just replicate the behavior of a command line: you must manually escape characters, and I must take that into account when splitting the string.
Agreed (about replicating behavior of command line), but this means you *don't* need to manually escape spaces. Try:
cd /tmp date > hello\ world cat hel[HIT TAB THEN ENTER HERE]
I meant that you have to manually escape when you write: date > hello\ world When a completion is returned XPrompt should take care of escaping spaces and quotes.
Note: I haven't looked carefully at the ShellPrompt module, but I wonder if it could call bash to do the completions, like DirectoryPrompt does (which does properly handle directories with spaces in them).
Yes, now ShellPrompt uses both compgen -A command and -A file but does not handles multiple spaces in a path. I'll take care of the problem. Andrea
Andrea Rossato
On Fri, Sep 14, 2007 at 12:15:03AM -0400, Xiao-Yong Jin wrote:
Finally, one not related to the new patch is that some special characters, like spaces or quotes, in the path name are not properly escaped, which in turn makes the path name completion useless, when such characters are in the path. It completes, but apparently the completion doesn't work properly.
I'm a bit puzzled about escaping spaces, actually. Now the string in the prompt is broken down to words in order to use the last one for finding new completions: this is what makes it possible to complete a command and then complete a file path. How can I tell which space must be escaped and which is not to be escaped?
I think we should just replicate the behavior of a command line: you must manually escape characters, and I must take that into account when splitting the string.
Am I right? What do you think?
Andrea
Is it possible to do it like a shell completion, which is completed when you usually type tab in a shell? The path is escaped when it is completed. For example, when I type $ xpdf f[TAB] bash will expand it into $ xpdf file\ name\ has\ special\ characters\ \@\"#\?\$\\\*\\\(\\\)\\\]\\\[\\\;.pdf Xiao-Yong -- c/* __o/* <\ * (__ */\ <
On Fri, Sep 14, 2007 at 10:06:21AM -0400, Xiao-Yong Jin wrote:
$ xpdf f[TAB]
bash will expand it into
$ xpdf file\ name\ has\ special\ characters\ \@\"#\?\$\\\*\\\(\\\)\\\]\\\[\\\;.pdf
Ok, this is what now you should get with the attached amended patches. And what about cursor positioning? Did the previous patch solved your problem? Please let me know. Cheers, Andrea
Andrea Rossato
On Fri, Sep 14, 2007 at 10:06:21AM -0400, Xiao-Yong Jin wrote:
$ xpdf f[TAB]
bash will expand it into
$ xpdf file\ name\ has\ special\ characters\ \@\"#\?\$\\\*\\\(\\\)\\\]\\\[\\\;.pdf
Ok, this is what now you should get with the attached amended patches.
Some conflicts arose, when I apply that patch. I'll look closely, when I have time.
And what about cursor positioning? Did the previous patch solved your problem?
The previous patch works awesome.
Please let me know.
Cheers,
Andrea
_______________________________________________ Xmonad mailing list Xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
-- c/* __o/* <\ * (__ */\ <
On Mon, Sep 17, 2007 at 01:20:28AM -0400, Xiao-Yong Jin wrote:
Some conflicts arose, when I apply that patch. I'll look closely, when I have time.
remember that since the last ones were amended patches you need first to unrecord and revert before applying.
The previous patch works awesome.
Great. I can now clean up the code, remove the FontStruct stuff and submit the patches. I still don't know if XPrompt should/will be able to deal with right-to-left writing. While I read that the newly imported X11 functions could permit that I would need someone that can test and report back. Anyone here? It would be cool... Thanks Andrea
Andrea Rossato
On Mon, Sep 17, 2007 at 01:20:28AM -0400, Xiao-Yong Jin wrote:
Some conflicts arose, when I apply that patch. I'll look closely, when I have time.
remember that since the last ones were amended patches you need first to unrecord and revert before applying.
My bad. I forgot to unpull one patch. It works flawlessly so far. Great job. Xiao-Yong -- c/* __o/* <\ * (__ */\ <
participants (3)
-
Andrea Rossato -
David Roundy -
Xiao-Yong Jin