So I so love how I specifically that tables are a problem and get people
wondering why I can't use lyx for tables. Imagine you have to get a table
of attributes all with starting with a letter and a period with a width of
.26in but no cellpadding on that particular column because it is left
justified and the extra .01in leaves just enough space for an m to look
good. This letter should appear as a block like
a. some text
some text
AND then there should also be another column with even more text. How about
if some rows contain multi column or multi row environments? How about if I
am importing from R and need to use long tables instead? That is a simple
copy and paste, chance tabular to longtable and continue on my way. Tables
are inherently difficult. Latex knows this which is why it says in many
many documents that tables are difficult. Lyx even admits that tables are
difficult but provides a UI to get some functionality. Regularly I hit that
wall and find it much easier to just use latex markup even with sometime
like using spaces between rows as oppose to lines (which is much better
design). I tried it once a long time ago. I couldn't make it do what I
wanted. Perhaps it is time to a revisit when things are not so hectic. I
use three part tables with booktabs because I need professional looking
tables to present scientific results. These tables need to be spell checked
because there is sometimes a lot of text embedded in them.
I am less worried about having too much spelling highlighted than too many.
I see two ways easily to get around the problem. The first is to have a set
of reserved or defined words. Other editors have figured out how to write
up latex code while having the display not underline every command. It is
also possible that they prescan for all defined words and don't highlight
them. I actually have not worked with document processors befores so I
don't know how language specific commands or other defined/reserved words
are not automatically recognized. A lot of other text editors do it though
so I can't imagine that to be difficult.
The second, and slightly more hacky way, would be to just add every
reserved word to my personal dictionary. It cannot be any more hacky then
writing the ERT, copying that into a new document, fixing spelling, and
copying it back. That is actually the exact situation I want to avoid. I
suppose a third option would be to use a non-ui like device to create
tables and then import the latex into lyx. I would prefer to not have to do
that though but it sounds like redefining ERT is sort of hacky.
Thank you for all the fine ideas. I will try to think about how to better
approach the problem. I suppose the huge feature request would be to make
ERT into an expansive latex or tex editor with defined functions like in an
editor such as MikTex. I don't have time right now to tackle the problem
but that seems like the not so hacky way to deal with it.
Thanks again,
~Ben
On Wed, May 28, 2014 at 10:18 AM, Richard Heck <rgh...@lyx.org> wrote:
> On 05/28/2014 04:38 AM, Scott Kostyshak wrote:
>
>> On Tue, May 27, 2014 at 7:04 PM, Benedict Holland
>> <benedict.m.holl...@gmail.com> wrote:
>>
>>> Hi everyone. Yes, I did check the archived mail and no, I didn't find an
>>> answer. I am running lyx 2.1 and I need to spell check ERT. How can I
>>> make
>>> this happen?
>>>
>>> Before you ask, why he is still using ERT the answer is tables. I cannot
>>> make lyx do what I want with tables and I am not going to go through and
>>> remove each string from ert. That would make my document unreadable. So.
>>> How
>>> do I make lyx spell check within ERT?
>>>
>> Hi Benedict,
>>
>> You might be able to redefine ERT in local layout (Document > Settings >
>> Local layout). Please read about layouts and about the Spellcheck keyword
>> in Help > Customization. If redefining ERT doesn't work, consider making
>> your own inset that does the same thing as ERT except that it spell checks.
>>
>
> This is hardcoded in the case of ERT: allowSpellCheck() returns false. But
> yes, in principle, you could define your own ERT-like inset (PassThru 1,
> etc), and allow spell check inside it. You do then have the problem that
> Stephan mentioned, though.
>
> Richard
>
>
