G. Milde wrote:
At least my experiences with computers gave me fairly much hints on the
problems with non-ASCII chars (Unix-DOS-Windows incompatibility, failed
searches in web-pages, Emails with missing or very strange looking chars,
...)
I have had those experiences too. But I'm a power user and a programmer, and have used computers since the mid-eighties. Lots of people aren't in any of these categories. People on the lyx-devel list, sure. But try to have some non-tech people use lyx for writing. They may accept that lyx is for books and documents, not so much for formatting greeting cards. But lots of "don't do this and that" can be bad.
Out of this I assume anyone with a bit of computer experience will knowI hope that lyx will evolve to be a word processing option for anybody,
that "special chars" are special, how often they may be needed in the
native language.
So, while possibly true for the average PC user, this will not hold for the average LyX user...
not just today's average lyx user. The developers may want lyx to differ
from common word processors in a number of ways (WYSIWYM, higher
quality, . . .) but I hope we can avoid "strange" little limitations in
the user interface, particularly when they don't come from the
underlying philosophy at all.
You can't use ERT inside a label? Have you tried this, or didAn illegal label made with ERT (or pure LaTeX in an imported document) will trigger a long search and a "but it worked fine in LyX" groan.
I misunderstand you?
I can user ERT to create a label. I agree, that this is nothing that
LyX garantees to succeed.
Yes, that is possible.
However, when I import a part of my document (be it something that is updated by a spreadsheet or script or by a non-lyxing coworker), I have to use different label in this part than in the rest of my LyX document. While this is not a bug, I do not like this feature and would prefer a consistent labeling policy (which unfortunately is fixed by TeX to exclude ÃÃÃÃ).
I don't see the problem here. You can obviously limit yourself to use only a-z even if lyx will allow ÃÃ etc. That should work fine with your latex-using coworkers or latex files referenced from lyx (and latex files referencing the lyx-generated labels.)
This is why I opt for a insert-label dialog that refuses illegal
characters and explains the reason in the status line (as we already do
when the user enters 2 spaces in "normal" mode). This way the common user
will "learn by doing".
I don't think you see the problem.
I see the problem from a different angle. For me, live would be easier with the possibility to use e.g. my name in a label, however it would be harder with the label being "G=252nter" in the LaTeX source...
Well, but if you need "nice" latex, then use Gunter instead of GÃnter for a label. You don't have to use the non-ascii stuff just because you can.
People don't think that way. See the problem people have with "no
spaces in filenames/paths." They cannot see why that would be a
problem.
Their main problem is, IMHO, that some commonly used OS already did set up their directories to contain spaces. Thus they expect the LyX developers to solve this problem rather than having to move everything used by LyX to a place with a conforming path name.
But also here a discussion is going on about "how much deviation from simple/clean/robust/known coding is allowed to please the average
windows user?" and "is this worth the effort?"
Interesting questions indeed. A scheme that encodes non-ascii in labels by numbers isn't all that hard though. I certainly understand the objection that the developers may have something better to spend their time on. But what if someone who thinks it is worth the effort codes it up? I see no problem then, because using non-ascii in labels is optional even if it becomes possible. The ideal solution is a (la)tex based on unicode instead of ascii - I am not sure that is going to happen in the near future though. (And when saying based on unicode, I mean that unicode characters goes _everywhere_, not only as part of typeset text, but as label names, command names counter names etc. I see no need a fully translated latex language, but the ability to use any character anywhere is necessary to avoid getting unexpected occational problems.
please understand that the division into ascii and non-ascii letters
seems _random_ to the average non-technical user!
While I dislike all the limitations of the use of ÃÃÃÃÃÃÃ in a lot of software, I assume everyone that speaks at least one foreign languae (or has learned at least one programming language) will recognise a distinction between a-z and Ã-Ã.
The programmer - yes. Someone knowing several languages will know that the alphabeths differ somewhat - and will want the pc to support all those letters so they can write freely in each language.
If lyx encodes all "label text" with latex-legal characters then no problems happen with latex.
Unless you happen to edit the latex source. Then, no hard problem, but a annoyance appeares.
Yes - if the label uses non-ascii. There's no need for encoding a label that happens to be all ascii. Well, someone could theoretically write G=252nter literally in one label and have it collide with a GÃnter label. Doing that they get what they deserve though. :-)
So my initial post reflected my personal rating on which problem is more annoying - LyX-LaTeX inconsistency or a limited set of label-forming letters.
Maybe, it is a point of looking at LyX either as a "LaTeX frontend" or as
a "Document preparation system" that happens to use LaTeX for
typesetting...
I see it as the latter. I have no problems with the former kind of use, but don't see a need to introduce limitations in this case. Latex users can simply restrict themselves to the a-z they have to use when in latex, and leave the non-ascii stuff to the "ignorant" non-programmers.
If I knew, that LaTeX 3 allows for non-ascii chars in labels (and we doHelge Hafting
not have to wait another 10 years for LaTeX 3 to appear), I would
immediately opt for unlimited labels with a LaTeX2e hack.
