Selon Dov Feldstern <[EMAIL PROTECTED]>: > > Agreed. I have a simple solution: use 2 checkboxes. One for notes, the > other for > > disabled branches. > > Sure it's simple enough, but then a third person wants comments (as > opposed to notes) treated a third way,
Indeed. I thought that comments would go to output, so that they shouldn't be spellchecked in most cases... Solution: add a third checkbox, the last (other text insets all go to output, right?). > a fourth wants to be able to > choose *which* instances of notes he wants spell checked and which he > wants ignored, This is not a common usage of notes, but it's already possible by using branches (or layouts). > etc., etc. It becomes too ad-hoc, the code gets more and > more complicated in order to deal with ever-more specific cases, and we > are still not as flexible as possible. Precisely, that's why what you propose (lower level) won't make things easier; you'll have to develop many tools for each person's specific needs. > That's why I think we're better off starting with a very basic level: it > will allow maximum flexibility, because the user can do *anything*. And > it's a simple concept, so the user also knows exactly what to expect, > and can easily *see* what's going on if necessary. And as I explained, > we can still make it easier to work with by building layers on top of > that; but because it's simple at the basic level, then it's easy to > override in specific cases in which the more sophisticated layers don't > do exactly what the user wants. And then *we* don't have to provide for > every single case, but we still allow the user to deal with any case. I don't follow you... The settings available with this approach (I mean checkboxes and keyword) are already sufficient for most of usages (what's not already possible actually? no much situations). Further, what's the most simple? 1) make a small patch using existing high level mechanisms; 2) make a (bigger) patch at a low-level, and then code some high level tools from start to manage the lower level. > > I propose: default value = spellcheck anything unless the layout says not > to do > > it. If the user clicks on the checkbox, he'll know what will happen. > > But it's not just layout: you just provided 2 checkboxes above, which > are in addition to the layouts. It starts getting complicated. Let's say > that I now want to know exactly which parts of my document are going to > be spell checked (or ignored by the spell-check) --- is there an easy > way for me to find that out? The more rules there are, the more check > boxes and layout definitions, etc., the harder it becomes to answer that > simple question. You don't need to have a visible effect to know that LyX-Code won't be spellchecked, you don't care of this. If a layout is defined as being not spellchecked, that's because it doesn't make sense to do so (because it doesn't include text in natural language, or just because it has some semantic which makes it clear enough that spellchecking won't arise). > Don't get me wrong --- I like the idea of being able to define a layout, > or character style, or inset type, that will ignore spelling. But that > should not be the most basic layer: the basic layer should be dead > simple, I shouldn't have to think about it at all. What basic thing will you be able to do in that way, that isn't already possible with the patch? That looks negligable to me... Using a charstyle or a branch is basic enough IMO: even a single character can be ignored! > > What about an inset? This would be clear enough IMO. And that doesn't > exclude > > having a list of ignored words per document. > > There are a few reasons why I prefer character styles to insets: You already have them as well :) > *) I think it'll be easier to deal with when we get to generating the > latex: this marking of text should have absolutely no effect on how the > text is output to latex. But if it's in a separate inset, that would be > hard to achieve, I think: there are certain things which happen at the > latex output stage when we open/close insets, which should *not* happen > in this case. Dealing with that will complicate that code quite a bit, > and it's already too complicated. You can manage this with a branch (see bug 1042). I admit that it would be more user friendly to have a special inset for this, but that wouldn't require so much coding IMO. Dealing with low level info/high level tools will clearly need more code to be written! > *) From a purely aesthetic point of view, I think that character styles > are more appropriate if I want to be able to mark small chunks of text > here and there. > > *) In addition, it would be easier to turn a green underline on or off > at will, that to do such a thing with an inset... Use a charstyle for one or a few word(s), and an inset for big regions. That's enough IMO. Perhaps an inset could easily be defined so that to draw a frame around its contents, or to highlight it (change its background) which is as clear as a green underline... And of course, it could be turned on/off as well. Maybe the most difficult part would be not to break lines... Mael.
