In my use of BaseX I am regularly troubled by one minor shortcoming (as I see it :) in the interactive graphical user interface. When I am concentrating hard on formulating a query, my fingers automatically type Emacs keystrokes to move the cursor around. The result is that I end up inserting ^A, ^D, ^E, and ^K characters into the buffer. (Other Emacs users might end up with stray ^N and ^P characters, but this usually doesn't happen to me.)
It would make the XQuery box in the GUI a lot more convenient for me if these keystrokes had their normal Emacs meaning there. Consider that a request for enhancement.
In the meantime, I have the problem that if I type one of these characters by accident, and then move away from the location (which happens quite often, since some of these characters are often parts of sequences of cursor movements), then I get an error message from BaseX (e.g. the message now showing in my status bar, "[XPST0003] Query contains an illegal character (#1)." But there is no visual indication of where the stray character is: all of these characters are invisible in the XQuery buffer.
If it were possible to make these illegal characters visible in some way (as "^A" or some kind of dot or box, for example), it would help at least those users who, like me, have Emacs keystrokes wired into their fingers.
Another RFE.
Thanks!
Michael
Michael,
thanks for your feedback. I hope you were successful switching to our latest versions? Some more questions:
– does the problem persist with our latest minor verion (6.2.9)? Source: http://www.inf.uni-konstanz.de/dbis/basex/maven/org/basex/basex/6.2.9/basex-...
– as I didn't manage yet to reproduce the issue: which keys do you exactly use to end up with the control codes, and which OS are you using? In BaseX, shortcuts like ctrl+a should only responsible for marking all the text, etc.
Christian
On Wed, Oct 13, 2010 at 1:50 AM, C. M. Sperberg-McQueen cmsmcq@blackmesatech.com wrote:
In my use of BaseX I am regularly troubled by one minor shortcoming (as I see it :) in the interactive graphical user interface. When I am concentrating hard on formulating a query, my fingers automatically type Emacs keystrokes to move the cursor around. The result is that I end up inserting ^A, ^D, ^E, and ^K characters into the buffer. (Other Emacs users might end up with stray ^N and ^P characters, but this usually doesn't happen to me.)
It would make the XQuery box in the GUI a lot more convenient for me if these keystrokes had their normal Emacs meaning there. Consider that a request for enhancement.
In the meantime, I have the problem that if I type one of these characters by accident, and then move away from the location (which happens quite often, since some of these characters are often parts of sequences of cursor movements), then I get an error message from BaseX (e.g. the message now showing in my status bar, "[XPST0003] Query contains an illegal character (#1)." But there is no visual indication of where the stray character is: all of these characters are invisible in the XQuery buffer.
If it were possible to make these illegal characters visible in some way (as "^A" or some kind of dot or box, for example), it would help at least those users who, like me, have Emacs keystrokes wired into their fingers.
Another RFE.
Thanks!
Michael
--
- C. M. Sperberg-McQueen, Black Mesa Technologies LLC
- http://www.blackmesatech.com
- http://cmsmcq.com/mib
- http://balisage.net
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
On Oct 12, 2010, at 8:20 PM, Christian Grün wrote:
Michael,
thanks for your feedback. I hope you were successful switching to our latest versions?
Yes. I am now running BaseX 6.1 under Mac OS X 10.6.4, installed from the .dmg on the download page.
Some more questions:
– does the problem persist with our latest minor verion (6.2.9)? Source: http://www.inf.uni-konstanz.de/dbis/basex/maven/org/basex/basex/6.2.9/basex-...
I'll check. [...] Yes. That is, control-A continues to insert the illegal character U+0001 into the buffer and to elicit an error message. The behavior is different, however, in that the token nearest the invisible ^A is now highlighted in pink (unless the ^A is the first character in the query, in which case it remains invisible). The highlighting gives me a visual clue about where the problem is, and goes a long way toward solving the visibility problem. Thank you!
– as I didn't manage yet to reproduce the issue: which keys do you exactly use to end up with the control codes, and which OS are you using? In BaseX, shortcuts like ctrl+a should only responsible for marking all the text, etc.
I wonder if the phenomenon is related to the domestication (if that's the right word -- similar to localization, but not quite the same thing!) of the Java window interface on the Mac: in most cases where Windows and Linux use control keys, OS X uses the 'commend' key, so I type command-a to select the entire text, command-c to copy it, etc., instead of the control-a, control-c one typically uses in Windows and Linux apps.
So I speculate that you will be able to replicate the issue only on a Mac.
I hope this helps.
p.s. If there is a dmg package for 6.2.9, or instructions for integrating newer jar files into an existing BaseX.app, I'd be grateful for a pointer -- the color highlighting of syntax problems is a good help!
Thank you for your quick response.
On Oct 13, 2010, at 8:21 AM, C. M. Sperberg-McQueen wrote:
p.s. If there is a dmg package for 6.2.9, or instructions for integrating newer jar files into an existing BaseX.app, I'd be grateful for a pointer -- the color highlighting of syntax problems is a good help!
In case other Mac users need to upgrade their BaseX.app to new jar files and don't already know how, I'll just record that the following procedure worked fine for me:
(1) in a shell window, navigate to
/Applications/BaseX.app/Contents/Resources/Java/repo/org/basex/basex
In my case, this contained a directory named 6.1, containing basex-6.1.jar.
(2) Create a 6.2 directory, and copy the new jar file into it. In my case:
mkdir 6.2; mv ~/Downloads/basex-6.2.9.jar ./6.2
(3) Edit the file /Applications/BaseX.app/Contents/info.plist in an XML editor. Find the key/value pair for ClassPath and change it appropriately. In my case, this meant changing
<key>ClassPath</key> <array><string>$JAVAROOT/repo/org/basex/basex/6.1/basex-6.1.jar</string></array>
to
<key>ClassPath</key> <!--* <array><string>$JAVAROOT/repo/org/basex/basex/6.1/basex-6.1.jar</string></array> *--> <array><string>$JAVAROOT/repo/org/basex/basex/6.2/basex-6.2.9.jar</string></array>
Save the file.
(4) Relaunch BaseX.
In case of difficulty, check to make sure you didn't accidentally render the info.plist document ill-formed.
There may be other better ways to do this, but this seemed simple enough to me.
Thanks for the how-to... Btw, I've asked the Mac users in our project to check out if they can reproduce the control code issue.
On Thu, Oct 14, 2010 at 1:07 AM, C. M. Sperberg-McQueen cmsmcq@blackmesatech.com wrote:
On Oct 13, 2010, at 8:21 AM, C. M. Sperberg-McQueen wrote:
p.s. If there is a dmg package for 6.2.9, or instructions for integrating newer jar files into an existing BaseX.app, I'd be grateful for a pointer -- the color highlighting of syntax problems is a good help!
In case other Mac users need to upgrade their BaseX.app to new jar files and don't already know how, I'll just record that the following procedure worked fine for me:
(1) in a shell window, navigate to
/Applications/BaseX.app/Contents/Resources/Java/repo/org/basex/basex
In my case, this contained a directory named 6.1, containing basex-6.1.jar.
(2) Create a 6.2 directory, and copy the new jar file into it. In my case:
mkdir 6.2; mv ~/Downloads/basex-6.2.9.jar ./6.2
(3) Edit the file /Applications/BaseX.app/Contents/info.plist in an XML editor. Find the key/value pair for ClassPath and change it appropriately. In my case, this meant changing
<key>ClassPath</key> <array><string>$JAVAROOT/repo/org/basex/basex/6.1/basex-6.1.jar</string></array>
to
<key>ClassPath</key> <!--* <array><string>$JAVAROOT/repo/org/basex/basex/6.1/basex-6.1.jar</string></array> *--> <array><string>$JAVAROOT/repo/org/basex/basex/6.2/basex-6.2.9.jar</string></array>
Save the file.
(4) Relaunch BaseX.
In case of difficulty, check to make sure you didn't accidentally render the info.plist document ill-formed.
There may be other better ways to do this, but this seemed simple enough to me.
--
- C. M. Sperberg-McQueen, Black Mesa Technologies LLC
- http://www.blackmesatech.com
- http://cmsmcq.com/mib
- http://balisage.net
Hi List,
Btw, I've asked the Mac users in our project to check out if they can reproduce the control code issue.
we managed to both, reproduce and fix the issue on OSX. The latest repository version as well as the to be released BaseX 6.3 will contain that fix.
In case other Mac users need to upgrade their BaseX.app to new jar files and don't already know how, I'll just record that the following procedure worked fine for me:
For building the Application Bundle, you could add:
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>osxappbundle-maven-plugin</artifactId> <version>1.0-alpha-2</version> <configuration> <mainClass>org.basex.BaseXWin</mainClass> <iconFile>${basedir}/etc/build/OSXBundle/BaseX.icns</iconFile> <jvmVersion>1.5+</jvmVersion> </configuration> <executions> <execution> <phase>package</phase> <goals> <goal>bundle</goal> </goals> </execution> </executions> </plugin>
to '/projects/build/plugins' in our pom.xml and issue: $ mvn package osxappbundle:bundle -DskipTests=true or simply $ mvn package to get a working bundle & dmg from source. Don't know if it really saves you time, at least it saves you from editing the Info.plist manually ;-)
Hope this helps.
Kind regards Michaels
basex-talk@mailman.uni-konstanz.de
-
C. M. Sperberg-McQueen -
Christian Grün -
Michael Seiferle